The architecture, in four parts.

Callers

• Applications (stage 12) 3 related functions
• AI-enabled services 3 related functions
• SDK clients: JS · Python · Go · Java 53 related functions
• Operators: console · admin API · SSO 32 related functions
• Agents and tools: signed action requests 7 related functions

Gateway edge

• Hardened HTTP edge: Security headers · CORS, Proxy and host validation, Request ID · client IP, Kill switch, Admission control, Rate limiting · lockout, Strict body validation, Idempotency keys, Graceful shutdown drain, Health and metrics probes (stage 01, 02) 20 related functions

Enforcement core

• Artifact and replay: Signature · expiry · binding, One-time nonce (stage 03, 04) 14 related functions
• Identity and tenancy: RBAC · SSO · MFA · tenants (stage 05) 20 related functions
• Consent and policy: 11 rule types · tenant floor (stage 06) 34 related functions
• Semantic inspection: Rule engine + embedding gates (stage 07, 10) 55 related functions
• DLP and content rules: Redact · mask · block (stage 07, 10) 5 related functions

Execution

• Execution layer: Execution invariant, Token-bound dispatch (stage 09) 14 related functions
• Provider router: OpenAI · Anthropic · Gemini, Mistral · Azure OpenAI, Bedrock · Llama · Local, Breaker · retry · failover (stage 09) 24 related functions
• Action and tool gateway: Action artifacts, Approvals · delegations, MCP servers (HTTPS) 15 related functions

Trust and evidence

• Signing and keys: Ed25519 · KMS / HSM option (stage 11) 32 related functions
• Audit chain: Hash-chained · checkpoints (stage 08, 11) 19 related functions
• Evidence ledger: Packages and bundles 6 related functions
• Transparency log: Merkle roots · proofs (stage 08, 11) 11 related functions

Foundation

• State: PostgreSQL · row-level tenant isolation, Redis · replay, limits, revocation, File stores · keys, policies, audit log 76 related functions
• Key custody: Local · Vault · AWS · Azure, Google Cloud · PKCS#11 HSM 9 related functions
• Observability: Logs · metrics · traces, Health · alerts · dashboards 98 related functions
• Offline verification: Standalone verifiers · SDK helpers, Published public key sets 10 related functions

Allowed

1. A scoped identity obtains a signed artifact and sends the request with it.
2. Gateway edge: kill switch, rate limit and admission control, then strict schema, size and content-type checks.
3. Artifact verified: signature, expiry, request binding and revocation, then a one-time nonce and burst check in one atomic step.
4. Tenant, organisation and signing identity are still active.
5. Consent is active and the rules pass, in priority order.
6. Inspection: the prompt is screened and an email address is redacted.
7. Intent evidence: the intent is written to the audit chain and the transparency log before the provider is called.
8. Provider call: an execution token is minted and the router dispatches, with retry and failover.
9. Output inspection: size cap, semantic check and DLP on the response, then it is released.
10. Decision evidence: an audit entry, a transparency leaf and a signed receipt.
11. Response: EXECUTE returns with artifact, key and proof references, and an optional signed receipt.

Refused

1. The same request arrives, now with an injected instruction in the prompt.
2. Gateway edge: kill switch, rate limit and admission control, then strict schema, size and content-type checks.
3. Artifact verified: signature, expiry, request binding and revocation, then a one-time nonce and burst check in one atomic step.
4. Tenant, organisation and signing identity are still active.
5. Consent and policy pass.
6. Inspection finds the injected instruction. BLOCK: this is the deciding gate, and nothing goes on to the provider.
7. The refusal is still recorded: a block entry and a transparency leaf are written, so it can be verified later.
8. A BLOCK with a reason code is returned. The provider was never called.

Refusals at the enforcement stages leave a block entry and a transparency leaf. Pre-authentication rejects are never audited (catalogue API-013).

Streaming

1. A streaming request is sent with its signed artifact.
2. Stages 01 to 07 run as for any request: edge, artifact, tenant and identity, consent and policy, then inspection.
3. Intent evidence is written before the provider is called.
4. Provider call: the router dispatches the streaming request.
5. Streaming requests release checked output in batches: each batch is checked before it goes on, and no unchecked byte is released.
6. When the stream ends, the audit entry and the transparency leaf are written.

Agent action

1. An agent sends a signed action request.
2. The request enters through the hardened HTTP edge.
3. Action and tool gateway: approvals and delegations are checked and a signed action artifact is issued. Delegation only narrows.
4. The tool is called through the MCP gateway: HTTPS JSON-RPC with a pinned server identity.
5. Executed once: each action artifact is one-shot and its hash is recomputed before the tool runs.
6. Recorded: ACTION_INTENT and COMMIT entries are written to the audit chain.
7. EXECUTE returns to the agent with a receipt.

The twelve stages describe an AI chat request, so the progress rail stays idle for an agent action.