An autonomous system does not become trustworthy because its instruction was valid when it was created. Authority must still be valid at the precise moment an action is consumed.
The race is the control problem
Imagine one mandate authorising one consequential action. One hundred workers receive the same instruction at nearly the same time. Every request looks legitimate in isolation. If the system checks authority and consumes it in separate steps, several workers can pass the check before any one of them records consumption.
That is not an unusual edge case. It is the normal shape of retries, distributed queues, network delays, and autonomous agents operating at machine speed.
Exactly-once is a policy property
Teams often treat exactly-once execution as transport infrastructure. The deeper issue is authority. A retry may be technically valid but no longer authorised. The transaction therefore needs to bind three facts together: whether the mandate is still active, whether its budget remains available, and whether this action consumes it.
Do not ask only whether an agent may act. Ask whether this exact action may still consume this exact authority now.
What enterprise control requires
- 01Authority is consumed atomically. Validation and state transition happen inside one database transaction.
- 02Budget includes reservations. In-flight commitments count before further spending is authorised.
- 03Evidence records the losing attempts. Rejections are part of the audit trail, not disposable errors.
What the evidence does not prove
The result comes from repository integration tests against PostgreSQL. It proves the locking and consumption invariant under the tested contention pattern. It does not prove production availability, regional recovery, or tamper-evident audit storage. Those remain separate gates.
Find the authority races in your architecture.
Map where identity, policy, budgets, retries, and evidence separate under contention.
Book an architecture assessment