Order Walkthrough

One example, used consistently end to end: a person approves an order for 120 units from supplier A, charged to buyer account B, delivered to location X. Before it executes, an agent or workflow attempts to change a detail. This page shows exactly which fields are protected, where the changed order is stopped, and what evidence establishes which order the destination actually placed. It's a teaching example, not a claim that PayReality only serves procurement; the same mechanics apply to a payment, a refund, or a claims decision. Every step below is marked with who operates it and what it can and cannot establish, using the same current/planned vocabulary as the homepage's control-boundaries section and the Current Readiness table.

1. The agent's proposed order, as a signed Intent IMPLEMENTED AND TESTED

Who operates this: the customer's own agent, signing with its own registered key.

{
  "agent_id": "agt_procurement_01",
  "action": "purchase_order_submit",
  "resource": "supplier:SUPPLIER_A",
  "context": {
    "quantity": 120,
    "buyer_account": "ACCT-B",
    "delivery_location": "location:X"
  },
  "requested_at": "2026-09-28T09:00:00Z",
  "nonce": "6b7e2f4a-..."
}

Establishes: this is the agent's own account of what it's asking to do, tamper-evident from the moment it's signed. Does not establish: that this reflects anything beyond the agent's own request, or that any other party has seen or agreed to it yet.

2. The Trusted Adapter's independently reported attempt, if configured REFERENCE IMPLEMENTATION

Who operates this: the customer's own Trusted Adapter, a separately registered and authenticated identity, not the agent itself. This step only exists at all if an Adapter is configured for this integration; an agent-direct Intent (step 1 alone) skips it.

Establishes: a second, independently authenticated description of the same attempted operation, submitted from closer to the actual integration boundary than the agent itself. Does not establish: the destination's own record of what happened; that's a distinct, later thing (step 8), and this step doesn't produce it.

3. The integration contract's declared material fields, and why omissions matter REQUIRES CUSTOMER INTEGRATION

Who operates this: the customer, through a governance-approved Integration Contract Version. It names which fields this integration ever binds; here, supplier, quantity, buyer account, and delivery destination.

resource_path:      "order.supplier"
context_bindings: {
  "quantity":          "order.quantity",
  "buyer_account":      "order.buyer_account",
  "delivery_location":  "order.delivery_location"
}

Establishes: exactly which fields are ever eligible to be checked for this integration; a field the contract doesn't name is rejected outright when submitted, not silently accepted. Does not establish: protection for anything left out. If a material detail (a settlement channel, a cost center, a delivery window) isn't declared here, a later change to it is invisible everywhere downstream, not just at this step. PayReality doesn't enforce a universal list of required order or payment fields; it enforces whatever a specific integration actually declares.

4. The decision, and human approval where required IMPLEMENTED AND TESTED

Who operates this: PayReality's own deterministic evaluation, plus a human reviewer where the active policy requires one.

Establishes: this specific order, with these specific declared fields, was checked against the organization's active policy and delegated authority at this exact moment. Does not establish: that anything executes, or that this same answer still holds later; see step 10.

5. Issuance of a constrained Capability Authorization IMPLEMENTED AND TESTED

Who operates this: PayReality.

// 200 OK
{
  "token": "<opaque signed capability token>",
  "capability_id": "cap_a19f30",
  "expires_at": "2026-09-28T09:05:00Z"
}

Establishes: a specific, time-limited, single-use authorization was minted, binding exactly this order's declared fields. Does not establish: that it will ever be used, or that anything happens at the destination.

6. Verification and single-use consumption at your enforcement point REFERENCE IMPLEMENTATION

Who operates this: the customer's own enforcement point, on the actual write path into the system that would place the order. PayReality issues and verifies the Capability; it doesn't call your enterprise system itself.

{
  "token": "<the issued token>",
  "audience": "reference-pep",
  "action": "purchase_order_submit",
  "resource": "supplier:SUPPLIER_A",
  "constraints": {
    "quantity": "120",
    "buyer_account": "ACCT-B",
    "delivery_location": "location:X"
  }
}

Establishes: this exact authorization was checked and can be used exactly once, right now, with the agent, organization, and integration re-checked live immediately before consumption (see step 10a). Does not establish: that your enforcement point then correctly performed the write, or that no other route into the same system exists. Any other path has to be closed on your side; PayReality can't secure a path it isn't wired into.

7. Rejection when a bound field changes IMPLEMENTED AND TESTED

Concretely: the order above was approved for buyer account ACCT-B. Before execution, something attempts to change it to ACCT-B-PRIME.

{
  "token": "<the same issued token>",
  "audience": "reference-pep",
  "action": "purchase_order_submit",
  "resource": "supplier:SUPPLIER_A",
  "constraints": {
    "quantity": "120",
    "buyer_account": "ACCT-B-PRIME",
    "delivery_location": "location:X"
  }
}

// 409 Conflict
{
  "detail": "capability_constraint_mismatch"
}

Establishes: a changed field the contract declared material is caught before the write proceeds; the token remains unconsumed, not burned by the rejected attempt. Does not establish: anything about a field the contract never declared in step 3; nothing compares those, because nothing recorded them.

8. What the current receipt path records and reconciles IMPLEMENTED AND TESTED

Who operates this: the customer's Trusted Adapter reports; PayReality reconciles what was reported against what was authorized.

MATCHED           # the reported execution matches what was authorized
MISMATCHED        # the reported execution differs from what was authorized
EXECUTION_FAILED  # the destination reported the action did not execute
PARTIAL           # only part of the authorized action was reported executed
RECEIPT_MISSING   # no execution receipt has been reported yet
INDETERMINATE     # the receipt could not be reconciled with confidence

Establishes: an authenticated integration's own account of what it observed, compared against what was actually authorized. Does not establish: that the destination itself independently committed the order exactly as reported. An authenticated adapter receipt is not the same evidentiary strength as an authoritative destination status record; PayReality authenticates who's reporting and checks it against what was authorized, it does not independently confirm the real-world outcome. This reconciliation is computed today when invoked directly; it isn't yet exposed through a documented public endpoint, see API Reference.

9. When the outcome is uncertain PLANNED

A Capability is claimed and consumed. The destination attempt is made. No durable receipt ever arrives, whether because the destination never received it, received it and hasn't responded, or responded and the response was lost before PayReality recorded it.

Establishes: nothing, deliberately. This state is never labeled failed, because nothing confirms the order didn't go through, and PayReality never automatically retries or reissues a Capability for it: a naive retry risks placing the same order twice. Recovering this state today means a customer-side investigation outside PayReality, comparing against the destination's own records. Automatically resolving it is a direction we're testing, not a shipped control.

10. When authority or policy changes between authorization and execution

Implemented and tested IMPLEMENTED AND TESTED: immediately before a Capability is consumed, in the same transaction as the atomic single-use check, PayReality re-checks that the origin agent, the organization, and the integration identity and enforcement binding it depends on are still active right now, not just when the Capability was issued. A revoked agent, for example, blocks any further consumption of a Capability tied to it, even one issued and still unexpired.

Planned PLANNED: PayReality does not yet proactively watch a pending, not-yet-consumed Capability and flag it the moment a relevant authority changes, before anyone tries to use it ("authority-change impact discovery"). It also does not yet automatically recover or resolve an ambiguous post-dispatch outcome (step 9) on its own. Both are directions we're actively testing, not production-ready claims; see the homepage's Current Readiness table for their status alongside everything else on this page.

Where this fits

For the product-level explanation of the decision engine this walkthrough's step 4 relies on, see Runtime Authority. For the full request/response detail behind steps 1, 5, 6, and 8, see Runtime API. For how every component named above fits together end to end, see Architecture.