Inputs
- Published intent and translated contract
- Admission decision and signed permit
- Policy context and constraint inputs
- Execution and observation results
Decision and control
Control Plane
Coordinate the decision, not only the call.
Policy evaluation, decision coordination, execution state and optimisation across the governance lifecycle.
Responsibility
What Control Plane is responsible for
The Control Plane coordinates a governed transaction: it evaluates policy context, requests or selects a decision candidate, dispatches only against a verified permit, records execution state, and drives observation, reconciliation and audit.
The Control Plane is the coordinating service of the lifecycle. It does not invent authority; it composes the intent, the admission decision, the permit and the execution state into one governed transaction with a reviewable record.
It is also the place where partial failure must remain honest. When an external write times out, the Control Plane records the outcome as unknown until reconciliation establishes what happened — it does not report success because a request was accepted.
Lifecycle position
Where it sits in the governance lifecycle
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Decision
Coordinate policy, constraints and uncertainty.
Execution
Apply the effect through a controlled adapter.
Reconciliation
Compare expected and observed results.
Evidence and audit
Keep linked, ordered, reviewable records.
Verified capabilities
What is verified today
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
- Policy evaluation and decision coordination
- Dispatch only against a verified permit
- Execution state tracking including unknown and partial outcomes
- Observation and reconciliation orchestration
- Durable, ordered audit records per transaction
Outputs
- Decision record and execution state
- Reconciliation outcome
- Audit chain entries
- Operational read models for the console and AIOps
Evidence and maturity
What the evidence supports
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Maturity note
Decision, dispatch, observation, reconciliation and audit paths were verified in the local demonstration stack, including unknown outcomes and recovery. Lineage read APIs exist on a feature branch and are not claimed as integrated here.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- Local chain hops 5–11: decision, dispatch, observation, reconciliation and audit.
- Acceptance steps 6–8: adapter failure, timeout with possible effect, unknown → reconciled.
- Durable replay state survived restart (acceptance step 5).
- Read APIs returned real records in the November 2026 capability audit.
Dependencies
- Gatekeeper
- IDM Solver
- NARG
- Substrate
- Reconciliation
- Audit ledger
Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.
Limitations
What this product does not do (yet).
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
Limitations — read before evaluating
- Lineage read APIs are on a feature branch and are not part of the integrated path.
- No single signed lifecycle artefact spans every component; correlation is by decision id.
- Network readiness reporting is degraded when arbitration and stability context is missing.
- Container packaging is partial; the verified launch path is local.
No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.
Relationship to the platform
How it fits
The Control Plane is the coordination layer, not the authority layer. Gatekeeper admits; NARG and Substrate enforce; the Control Plane keeps the decision, execution and evidence connected so a reviewer can reconstruct what happened.
Evaluation questions
- How does the system represent an execution outcome that is genuinely unknown?
- Can a decision be reconstructed from records after a restart?
- Which policy context must exist before admission is meaningful?
Next step
Evaluate Control Plane against a real control problem.
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.