From Request to Receipt: A Procurement Transaction Walkthrough

Architecture becomes easier to test when one transaction has to survive every boundary.

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It traces a fictional flow, not measured performance or live operation.

Illustrative Reference Project — not a deployed customer system. No supplier, purchase, user, or outcome below represents client activity.

All numbers and names in this example are illustrative.

This walkthrough follows one purchase from human intent to reconciled receipt. It keeps four identities separate, shows where authority is created and consumed, and branches when the provider outcome is ambiguous.

Worked example: the request

Mira, a fictional studio operations lead, asks an agent to purchase eight drawing tablets for a training session. The request names a delivery date and a budget ceiling of USD 3,200 but does not choose a supplier or model.

The human principal is Mira in her requester role. The procurement agent is the planning actor. The isolated purchasing workload will later execute an authorized action. The downstream supplier credential remains a separate capability managed at the execution boundary.

The agent normalizes the request into requirements: product class, quantity, compatibility, delivery site, delivery deadline, budget ceiling, acceptable return condition, and whether substitutes are allowed. It asks Mira to clarify compatibility and substitution because those facts could change the purchase decision.

The important output is not a polished paragraph. It is a proposal-ready set of typed facts with unresolved material fields made visible.

Source options without purchase authority

The agent searches eligible catalogs using discovery access. It finds an illustrative offer from Northwind Office: eight tablets for USD 2,960, delivery before the deadline, standard returns, and no recurring term.

Discovery does not require the supplier purchasing credential. The agent can compare catalog data and form a candidate proposal without being able to place the order. This limits what prompt injection or a compromised data source can turn into an external side effect.

The proposal now closes the terms that policy will evaluate: requester, supplier, product, quantity, total ceiling, delivery destination, deadline, return condition, substitution rule, policy version, validity, and one request identity.

Evaluate policy deterministically

The evaluator authenticates the principal and agent context, validates the proposal shape, and loads current policy state. It checks supplier eligibility, category, per-action ceiling, cumulative equipment budget, requester role, delivery destination, validity, and velocity.

The proposal fits the hard rules but crosses an illustrative USD 2,500 step-up threshold. Policy returns require exact approval and specifies a budget-owner role. The result includes the proposal identity, policy version, matched reason, and current reservation context.

The agent can explain why approval is needed. It cannot convert that result to allow.

Bind exact approval

The approver sees the supplier, item, quantity, total ceiling, delivery site, delivery date, return condition, and substitution rule. The displayed terms and executable proposal derive from the same canonical representation.

Approval binds those terms, the human and agent context, policy version, validity window, and request identity. If inventory, supplier, amount, destination, or material terms change, the existing proof no longer matches. The flow returns to policy rather than editing the approved cart.

This is exact transaction approval, not a claim that the approver granted the agent general purchasing authority.

Consume authority at one commit boundary

Immediately before authorization, deterministic controls verify that the proposal is unchanged, approval is fresh, policy hard rules still pass, and the approver role is valid. The local commit then records approval consumption, reserves USD 2,960 of the illustrative budget, creates an execution intent, associates the stable idempotency identity, and writes an evidence handoff.

If that commit fails, no execution authority exists. If a worker crashes after it succeeds, recovery loads the same authorized execution. It does not reconstruct authority from the conversation or reserve the budget again.

The scoped execution grant identifies tenant, workload, executor audience, authorized transaction, constraints, and expiry. It does not contain a broad supplier credential.

Execute behind the credential boundary

The isolated purchasing workload presents its identity and scoped grant to the credential broker. The broker verifies current authorization, workload, tenant, audience, action, transaction binding, and credential status. Only then does it make downstream access available inside the execution context.

The executor sends the exact order with the stable idempotency identity. Provider output is filtered before any status reaches the agent. The response can contain a safe acknowledgement, reference, and receipt fields, but not reusable credential material.

Request-to-receipt evidence chain

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

The chain answers three review questions: what was requested, what was authorized, and what externally happened? A receipt alone answers only the last question, and sometimes not even that if it cannot be matched to the original terms.

Reconcile the normal path

In the normal branch, the supplier returns an order reference and acknowledgement. Reconciliation verifies that supplier, items, quantity, amount, destination, and request identity match the authorized transaction. A later receipt confirms the same reference and terms.

The outcome moves to confirmed. The reservation becomes a completed commitment under the chosen accounting policy. The evidence ledger links the provider reference and receipt to the original instruction, policy decision, approval, grant, and execution.

The agent reports the confirmed result using those facts. It does not infer success merely because a tool call returned without an exception.

Branch on an uncertain acknowledgement

Now replay the same transaction with one change: the connection closes after the order request is transmitted but before the executor receives acknowledgement.

The executor cannot prove whether Northwind Office accepted the order. It records uncertain rather than failed. The budget reservation remains held, and a new order is blocked. The agent tells Mira that the supplier may have accepted the purchase and that reconciliation is in progress.

The reconciler queries supplier evidence using the same request and idempotency identities. If it finds a matching order, the transaction moves to reconciled success and records the reference. If provider evidence proves the request could not have committed, policy can consider a controlled resubmission under still-valid authority. If evidence remains incomplete, the transaction stays uncertain and escalates for review.

Elapsed time alone does not prove failure. Creating a second request identity would turn recovery into another logical order.

Inspect the final evidence record

The final record should let an authorized reviewer trace:

Evidence access should be narrower than general agent access. Purchase details can be commercially or personally sensitive. Retention, redaction, and deletion rules belong in the design, while integrity protection should make later substitution detectable.

The accurate target is tamper-evident evidence, whose strength depends on protected writers, key custody, verification, and retention. A diagram alone cannot establish those operational properties.

Keep identities distinct through every stage

This walkthrough uses all four identity concerns:

• Mira’s principal proves who supplied the request and approval context.
• The agent identity attributes the proposal without granting execution power.
• The workload identity proves which isolated runtime presents the grant.
• The supplier credential enables the external call without becoming the source of policy.

The evidence record should connect them without merging them. “The agent purchased” is convenient prose but incomplete authorization evidence. The reviewable statement is that a named principal’s request produced a policy decision, an authorized workload executed bound terms, and external evidence resolved the outcome.

Test the walkthrough as a state machine

Build tests around transitions and invariants rather than one successful script:

• unresolved requirements cannot become an executable proposal;
• a blocked supplier cannot be rescued by a low amount;
• exact approval fails after any material cart change;
• concurrent authorization cannot reserve the same capacity twice;
• a worker restart resumes the existing execution identity;
• credential rejection cannot expose protected material;
• an ambiguous response enters uncertain and blocks a new order;
• duplicated provider events converge on one outcome;
• a receipt with mismatched terms cannot close the evidence chain;
• reconciliation can continue after execution authority expires because it observes prior work rather than initiating new work.

These tests validate intended control behavior. They do not establish broader security or interoperability properties.

Failure modes

Implementation checklist

• Normalize the requester’s material constraints and keep unknowns explicit.
• Separate catalog discovery from purchase authority.
• Create an exact typed proposal with one stable request identity.
• Evaluate supplier, category, limits, budget, role, validity, and velocity deterministically.
• Bind step-up approval to the same terms the executor will receive.
• Consume authority, reserve capacity, create execution, and hand off evidence atomically.
• Bind the execution grant to tenant, workload, audience, transaction, constraints, and expiry.
• Broker downstream access only at the isolated execution edge.
• Classify provider results as confirmed, denied, failed-before-submission, or uncertain from evidence.
• Reconcile acknowledgement and receipt against the full authorized proposal.
• Keep reusable credentials out of the evidence chain.
• Test crashes, concurrency, cart drift, mismatched receipts, and persistently uncertain outcomes.

This completes the eight-part series. Return to Designing Spend Policies for Autonomous Buyers for the policy model, or start with What Exactly Did the Human Approve? for the authorization foundation. The project overview and full case study describe the public Target Reference Architecture. To discuss private implementation access, request repository access.