Architecture

The execution pipeline is stateless, deterministic, and horizontally scalable. Every action is independent. Replays of the same canonical request body verify identically. Adding capacity is adding instances.

The pipeline

Each stage is a stateless function. State lives in the request payload as it flows through. No session storage between stages. No "in-flight" actions held in memory across requests.

Why stateless

Three reasons:

1. Horizontally scalable. Add another instance, route a fraction of traffic to it, no migration. The protocol's behavior is identical regardless of which instance handled the request.
2. Crash-safe. A pod restart drops zero state. In-flight actions either completed (receipt issued) or didn't (caller can retry with the same idempotency key).
3. Deterministic. Replays of the same canonical request body produce byte-identical receipts. Lets us prove correctness with property-based tests rather than integration tests.

Why deterministic

Determinism is the basis for verification. If the boundary, scoring, and signing stages are deterministic, then:

• A receipt is reproducible. Given the same intent + delegation + policy version, the receipt body is byte-identical. Verification is just a hash comparison.
• A blocked action is reproducible. Replaying the same canonical request body against the same policy version reproduces the block. Helps developers trust the boundary.
• Audit logs are independently auditable. A regulator can re-run an action through their own copy of the protocol with the same inputs and get the same verdict.

Where state lives

Three persistent stores:

1. Action log — every action that touched the protocol. Append-only, hash-chained. Source of truth for audit.
2. Delegation registry — issued tokens, their bounds, revocation status. Read-mostly; revocations are the primary write path.
3. Policy registry — versioned Authorization Boundary rules and scoring matrices. Each action's receipt records the policyVersion it was evaluated under.

None of the three sit in the request path as session storage. The pipeline reads them; the pipeline doesn't write to them mid-action (except for the action log append at the very end).

Performance budget

The pipeline is designed against an end-to-end latency budget. Each stage has a target — actual measured numbers will publish on the status page once the hosted service exits private beta. Until then, treat these as design targets, not measurements.

Reference implementation

A reference implementation is in development. When published, it will be the executable spec — not production infrastructure — suitable for conformance testing, local development, and reading the canonical algorithm. License terms will be published with each release; no patent license is granted by these public materials. Until then, the open specification and the live sandbox are the authoritative surfaces.

See also

• How it works — visitor-friendly summary.
• Authorization Boundary — pre-commit policy gates.
• Specification — the open protocol document.