One Authorization, One Commit Boundary

An approval is only useful if concurrent workers, retries, and crashes cannot turn it into more authority than intended.

The tempting design is a linear script: verify approval, mark it used, call the provider, then save the receipt. That sequence has gaps. Two workers can both observe an unused decision. A process can reserve budget and crash before creating work. A provider can commit an action while the local response disappears. The solution starts by separating what can be made atomic locally from what must be reconciled across an external boundary.

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It describes intended controls, not measured performance or operational assurance.

The target pattern is one durable authorization commit followed by an evidence-bearing execution workflow. It does not claim that a remote side effect participates in the same transaction.

Put the authorization facts in one local decision

At the authorization boundary, several facts must change together:

• the proposal is still current and policy-valid;
• the approval or delegation is valid for this proposal;
• the relevant per-action and cumulative capacity is available;
• the authority is marked consumed or the delegated capacity is reserved;
• an execution record is created with the proposal identity;
• a narrowly scoped execution grant is issued or made derivable;
• an evidence event is recorded for downstream processing.

If any part fails, none of those state changes should become visible. If all succeed, a retry should observe the existing authorization result instead of creating a second one.

This is an internal atomicity claim with a deliberately narrow boundary. The external provider remains outside it. Treating a network call as if it were part of a local commit only hides failure modes.

A state transition, not a helper function

Model authorization as a guarded transition from a proposed action to an authorized execution. The transition reads the proposal version, current policy, authority evidence, budget or quota state, and existing request identity. It then writes the consumed authority, reservation, execution intent, scoped grant reference, and audit entry in one durable commit.

The guard matters as much as the write. It should reject a proposal that changed after approval, an expired decision, an exhausted delegation, a mismatched tenant or workload, and any request identity already associated with different terms.

Keeping the transition in deterministic code makes its behavior reviewable and testable. An agent can propose a recovery, but it cannot decide that an expired approval is “close enough” or that a duplicate request “probably failed.”

Governed transaction flow

Conceptual target design. This diagram communicates intended trust boundaries and control flows; it is not a deployment topology or claim of production operation.

The flow has two important seams. Before the commit, the system may safely stop because no execution authority exists. After the commit, the system must preserve and recover the authorized work rather than silently rebuilding it from conversational context.

What crosses the boundary

An executor does not need the entire approval transcript or the agent’s working memory. It needs a minimal, verifiable package:

• a stable execution identity;
• the exact authorized action and constraints;
• the intended audience or destination class;
• a short validity window;
• a reference to the authorization decision;
• an idempotency identity for the external operation;
• a place to return result evidence.

That package should be immutable from the executor’s perspective. If execution discovers that a material field must change, it returns a structured rejection or clarification result. It does not edit the transaction under the existing authority.

The execution grant should be narrowly scoped and short-lived, but those labels are not enough. The verifier must check the scope, audience, workload, tenant, and expiry when the grant is presented. Otherwise, a well-shaped token can still be used in the wrong context.

Worked example

Consider a fictional software-renewal request. All values in this example are illustrative.

A bounded delegation permits renewals for an approved service category within a quarterly budget. The agent proposes renewing one subscription for USD 620. Deterministic policy confirms the supplier category, available budget, validity window, and requester authority. The authorization commit reserves USD 620, records the delegation capacity consumed, creates an execution intent, and emits an evidence handoff tied to one request identity.

A worker crashes immediately after that commit. Another worker receives the same request identity. It does not evaluate the conversation again or reserve another USD 620. It loads the existing authorized execution and continues from the durable handoff.

Now suppose the supplier receives the purchase request but the worker loses the response. The local authorization remains valid and reserved, but the outcome is not known. The worker must not create a fresh authorization and reorder. It records an uncertain result and starts reconciliation using the same external idempotency identity and any provider reference already available.

This is why authorization consumption and outcome resolution are separate state transitions. The first answers “was this action permitted and reserved?” The second answers “what happened at the external boundary?”

Crash points to design deliberately

Walk the flow one write at a time and ask what a retry will observe:

Before the authorization commit. Nothing has been consumed. A retry may re-run deterministic checks against current state.

After the commit but before a worker starts. The durable execution intent must be discoverable. A queue notification can be recreated from committed state; authority must not be recreated from the prompt.

After the request is sent but before acknowledgement. The outcome is uncertain. Preserve the reservation, retain the request identity, and reconcile before permitting another external attempt.

After acknowledgement but before local result storage. Reconciliation should recover the provider result and link it to the existing execution. A duplicate local outcome record must not imply a second provider action.

After final reconciliation. Close or release the reservation according to the confirmed result and retain the evidence chain under its configured policy.

Concurrency is an authorization concern

Two identical requests arriving together are not merely a performance race. They can consume the same approval, exceed a shared budget, or create duplicate external work.

Tests should force overlapping authorization attempts, not just sequential retries. Assert that only one commit can consume an exact approval, that cumulative limits are evaluated against reserved as well as completed work, and that reuse of a request identity with changed terms is rejected. Those behaviors belong at the storage and state-transition boundary; an in-memory lock around one process is insufficient as an architectural guarantee.

Failure modes

Evidence at each transition

The authorization record should explain which proposal and policy were evaluated, which authority mode applied, which limits were reserved, and which execution identity was created. The execution record should add provider references, timestamps, result classifications, reconciliation attempts, and the final disposition.

An evidence handoff can be an append-only event, an outbox-style record, or another durable mechanism. The public design does not prescribe storage or deployment technology. The requirement is behavioral: evidence must be recoverable from committed state, and publishing it twice must not authorize or represent two external actions.

Implementation checklist

• Define the exact local authorization commit boundary.
• Re-check proposal binding, policy version, validity, and identity inside that boundary.
• Consume exact approval or reserve delegated capacity atomically with execution creation.
• Count in-flight reservations when enforcing cumulative limits.
• Persist one stable request and idempotency identity across every retry.
• Make durable execution state the source of truth for work recovery.
• Keep the external provider call outside the local atomicity claim.
• Represent ambiguous responses as uncertain outcomes requiring reconciliation.
• Test overlapping workers, crashes at each handoff, changed terms, and repeated notifications.
• Link authorization, execution, result, and reconciliation evidence without storing credentials.

Start with What Exactly Did the Human Approve? if you need the transaction-binding model. Continue with Keeping Provider Credentials Outside the Agent to see what the executor should receive. The project overview and full case study place the pattern in the complete target architecture. For a private-source discussion, request repository access.