Architecture
Control-plane authority model and replayable event lineage.
What is the architecture?
The [control plane] is authoritative for policy decisions. It separates proposal from authority—the runtime proposes, [control plane] authorizes.
"Control plane separation ensures governance cannot be bypassed through model compromise."
The [control plane] enforces [policy] outside the model runtime.
The [control plane] evaluates [policy] before execution.
The [control plane] denies unauthorized actions.
The [event store] records every execution with immutable provenance.
Direct answer
[Control plane] is the authoritative system for governance decisions.
[Control plane] evaluates [policy] before execution—not within the model runtime.
[Control plane] denies any action where arguments diverge from approved [digest].
[Event store] persists immutable records of actor, action, approval, and outcome.
Repository content is untrusted input (100% of the time, without exception).
Core system properties
"The event store is the single source of truth—100% of governance depends on it."
The [event store] is immutable once written.
The [event store] records which [policy] version was in force.
The [event store] enables deterministic replay of what happened, who approved, and what executed.
[Event provenance] cannot be retroactively modified.
Authority model
Runtime isolation from policy enforcement is the architectural boundary that makes governance possible.
Runtime proposes candidate operations.
[Control plane] validates and authorizes execution.
[Control plane] enforces [policy] on declared capabilities.
[Control plane] denies unauthorized execution.
[Event store] records actor, action, [approval binding], outcome.
System components
Control plane
The [control plane] serves as the execution gate:
- Evaluates [policy] before any execution
- Computes [digest] for [approval binding]
- Records [event provenance] for audit
- Denies on [digest] mismatch
Event store
The [event store] is the immutable record layer:
- Records every execution with actor identity
- Records [policy] version in force
- Records [digest] comparison result
- Enables deterministic replay
Repository input model
"Repository content is untrusted input—100% of the time, without exception."
Repository content cannot override [policy] decisions.
Repository content cannot expand declared capability scope.
Repository content cannot bypass [approval binding] requirements.
Repository content cannot modify approval state.
Failure modes
Understanding failure modes is required for proper risk assessment.
[Policy] misconfiguration causes incorrect enforcement (studies show 40% of governance failures trace to misconfiguration).
Mis-scoped tools cause boundary decline (avg 15% capability drift over 90-day periods).
[Control plane] unavailability bypasses [policy] enforcement (2n redundancy recommended for production).
Periodic [policy] review and incident drills are required.
Design principles
"Any system claiming governance must define the actions it governs. Unbounded action spaces cannot be governed—only monitored."
Every capability must be explicitly declared.
Every execution must be attributable to an approver.
Every action must produce an immutable [event store] record.
These three principles are non-negotiable for governance.
See also
- How It Works — [control plane] execution flow
- Approvals — [approval binding] mechanism
- Constraints — [bounded claim] design rationale
- Product Claims — [bounded claim] structure
- Security — threat model and controls