01 / The operating case
What changes in a real workflow?
Two agents each try a $7,000 refund under one remaining $10,000 authorization.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Reserve against one budget ID with an atomic compare-and-update, bind reservation to transaction, settle on confirmed effect and reconcile unknown outcomes before release.
InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome
03 / Failure and evidence
What goes wrong, and what can be proven?
Failure mode
Each child reads the same remaining balance and both refunds execute.
Evidence to retain
Retain reservation IDs, concurrent attempts, executor transaction IDs and final balance.
04 / Canonical scope
Why this reference stands alone
Fan-out governs child creation; this page owns aggregate consumption and concurrency.
Illustrative implementation artifact
Atomic reservation sequence
BEGIN TRANSACTION
remaining = lock(budgetId)
reject if remaining < requestedAmount
reservation = create(budgetId, actionId, requestedAmount)
decrement(budgetId, requestedAmount)
COMMIT
execute(actionId, idempotencyKey)
reconcile UNKNOWN before releasing reservationPrimary references