How it works

Models generate intentions. Execution Protocol turns intentions into actions, with proof.

Every action passes through a deterministic pipeline. Each stage is recorded as an entry in the receipt's hash chain. Tamper any stage and verification breaks at that index.

The pipeline

Token validation
The caller's API key + auth headers + idempotency key are validated. Sandbox accepts a public token; production requires a Bearer key.
Schema
The request body is validated against the archetype's JSON schema. A payment-transfer body is shaped differently from a hotel-reservation body; both follow the same outer envelope.
Authorization Boundary
Deterministic policy + delegation checks. A spend over the delegation cap, an action in the hard-deny list, or a scope violation halts here with EP_BOUNDARY_BLOCK or EP_DELEGATION_BLOCK. See Authorization Boundary.
Completeness
Checks whether the message has everything it needs to execute. All required fields for the archetype must be present and non-empty; optional fields can be absent.
Anomaly check
Assesses the action against the agent’s recent activity. An action far outside the agent’s typical pattern halts here with a structured error.
Execute
The provider call. A flight booking, a transfer, a hotel reservation. Provider failures are recorded in the entry's error field.
Commit auth split
Authorisation is split from the provider call so the gateway records the commit independently. For challenge flows (3DS, SCA) this is where the user-consent signature attaches.
Receipt
The receipt is canonicalised (RFC 8785 JCS), signed with ES256, and persisted. The entries[] chain is the audit trail; the receipt-level signature commits to the entire envelope.

A genesis sentinel entry (__genesis__) anchors index 0. So a fully-executed receipt carries 9 entries: genesis + the 8 stages. A blocked receipt carries fewer — genesis + the stages that ran + a terminal receipt entry that records the block.

What this is not

Where to next

Authorization Boundary — the layer that says no.
Receipts — what a signed receipt contains and how to verify it.
Sandbox — see executed and blocked side-by-side, no signup.

The pipeline

Token validation

The caller's API key + auth headers + idempotency key are validated. Sandbox accepts a public token; production requires a Bearer key.

Schema

The request body is validated against the archetype's JSON schema. A payment-transfer body is shaped differently from a hotel-reservation body; both follow the same outer envelope.

Authorization Boundary

Deterministic policy + delegation checks. A spend over the delegation cap, an action in the hard-deny list, or a scope violation halts here with EP_BOUNDARY_BLOCK or EP_DELEGATION_BLOCK. See Authorization Boundary.

Completeness

Checks whether the message has everything it needs to execute. All required fields for the archetype must be present and non-empty; optional fields can be absent.

Anomaly check

Assesses the action against the agent’s recent activity. An action far outside the agent’s typical pattern halts here with a structured error.

Execute

The provider call. A flight booking, a transfer, a hotel reservation. Provider failures are recorded in the entry's error field.

Commit auth split

Authorisation is split from the provider call so the gateway records the commit independently. For challenge flows (3DS, SCA) this is where the user-consent signature attaches.

Receipt

The receipt is canonicalised (RFC 8785 JCS), signed with ES256, and persisted. The entries[] chain is the audit trail; the receipt-level signature commits to the entire envelope.