The governed request pipeline: eight visible runtime stages inside the nine-gate execution model.
The visualization groups the nine executable GateIds into architectural layers and adds the terminal SAFE_HALT and governed-execution states for teaching clarity. Complete runtime entry-point and continuity coverage remain unverified.
Ingress → STATE_REGISTER → Identity → Capability → Policy Binding → Cerberus → Galahad → Codex → Audit Hash
The visualization groups the nine executable GateIds into six governance/audit layers and adds SAFE_HALT and Governed Execution as terminal/control stages. These eight visible stages do not redefine the nine GateIds.
Tickets traversing the Iron Path
Each dot is a governance ticket. Pause and step through, inject manual tickets, or switch the verdict bias to see how the pipeline behaves under happy-path and adversarial traffic.
keys: Space play/pause · S step · I inject · R reset · ←/→ speed
Change the request conditions, then run the path.
This deterministic walkthrough uses the architecture stages shown on this page. It demonstrates where a request continues or stops; it does not invoke Project-AI.
- 01User / RequestPASS
The example request is normalized into a governance ticket.
- 02STATE_REGISTERPASS
Identity and continuity evidence are sufficient for this example.
- 03Capability ValidationPASS
The capability is present and its footprint covers the requested action.
- 04ExecutionGatePASS
The example satisfies the active policy, ethics, and consistency conditions.
- 05Triumvirate GovernancePASS
The example receives the required governance approvals for continuation.
- 06Audit LedgerPASS
The teaching flow reaches the architecture's audit-anchor stage.
- 08Governed ExecutionPASS
All preceding example conditions passed, so the request reaches Governed Execution.
The request continued through every applicable stage because identity, capability, scope, and governance conditions all passed.