Request Access

Governance Constitution

Version 1.4 — 31 March 2026

This document defines the non-negotiable invariants of governance for autonomous systems. It is not a metaphor, a recommendation, or a marketing label. It is a constitutional specification: a set of hard constraints that define what governance means when software can choose and execute consequential actions without a human approving each step.

The clauses below are constraints, not preferences. When a mechanism is rejected as “not governance”, it is rejected because it violates one of these clauses, not because it is unfashionable or incomplete. When a design is accepted, it is accepted because it satisfies these invariants at the action boundary in a way that survives audit, incident response, and adversarial scrutiny.

This constitution does not prescribe an implementation. It defines what implementations must not violate. Implementations must declare which version of this constitution they satisfy.

1. Scope of Governance

Governance exists to evaluate autonomous action before consequence. It is concerned with the point where intent becomes an external effect: money moves, a record is deleted, a deployment is triggered, an email is sent, or data leaves a boundary.

Governance does not generate intent, plan workflows, execute actions, or route traffic. It does not replace identity systems, logging systems, or network controls. Those systems remain necessary, but they solve different problems at different boundaries.

Governance is the discipline that evaluates intent at the action boundary and renders an explicit, authoritative decision before execution.

This constitution governs individual actions at the action boundary. Governance may consider sequence-derived facts when evaluating an individual action (see Clause 5), but it does not govern workflow atomicity or transactional correctness as such. Workflow-level concerns — including multi-action atomicity, compensation, and rollback of partial sequences — are out of scope. They remain necessary engineering problems, but they are not governance problems as defined here. Out-of-scope workflow mechanisms must not be used to circumvent per-action governance; a workflow that executes governed actions must submit each action to governance evaluation individually.

2. Action Boundary Primacy

An action is a canonical request representing an attempted operation capable of producing consequences beyond the boundary of the requesting agent. This includes operations that alter persistent state, transfer data across trust boundaries, trigger external effects, or produce consequences that cannot be reversed by the requesting agent alone.

The canonical input bundle presented for evaluation must include at minimum:

The first four items constitute the canonical action representation (adapter-projected). The remaining items are resolved governance context added during the resolution phase.

The evaluation timestamp must be asserted by a trusted, explicitly identified, cryptographically authenticated time authority and bound into the evidence record. Caller-supplied timestamps are not valid unless cryptographically attested by that authority.

Representation properties. The canonical action representation must satisfy the following properties. These are constitutional requirements because if the representation is deficient, deterministic evaluation governs a fiction, evidence integrity records that fiction faithfully, and anti-bypass cannot detect it.

Violation of any representation property constitutes a governance failure. A system that produces deterministic decisions from unsound representations is not governed — it is precisely wrong.

Governance evaluation must operate exclusively on the canonical input bundle, which consists of the canonical action representation and all resolved governance context (validated delegation artefacts, policy identity, and any resolved sequence or contextual facts). Any evaluation performed on non-canonical inputs is invalid.

The action boundary is the point at which intent becomes consequence. A governed system must be constructed so that execution capable of producing external consequences cannot proceed unless the action has been evaluated at that boundary.

All execution paths capable of producing external consequences must pass through governance evaluation. Architectural designs that permit any execution path to bypass governance evaluation violate this constitution.

Post-execution controls are not governance. Detecting that an action was wrong after it happens may be valuable, but it does not satisfy the requirement that the action must not execute without prior authorisation.

3. Explicit Decision Requirement

Every evaluated action must result in exactly one explicit outcome: ALLOW, DENY, or ESCALATE.

There is no implicit approval. Silence is not permission. If evaluation cannot complete, the outcome is DENY.

ESCALATE must not execute the action. It must transfer decision authority to a defined higher-authority process. If that process is unavailable, unreachable, or fails to produce a decision within its defined bounds, the action resolves to DENY. Escalation does not suspend the fail-closed invariant; it transfers the obligation to satisfy it.

ESCALATE must produce its own evidence record at the point of escalation. If the higher-authority process renders a final decision, that decision must produce a separate evidence record cryptographically linked to the escalation record.

Overrides must be explicit, versioned, and produce evidence records identical in structure and integrity to any other decision. An out-of-band approval that bypasses evaluation is not governance. Human decisions are treated as explicit authority artefacts. Replay equivalence requires reproducing the presence and contents of the override artefact, not the human judgement itself.

4. Delegation Requirement

Agents do not possess inherent authority. If an agent can act, it acts under authority that was explicitly delegated to it.

Authority must be derived exclusively from explicit delegation artefacts. Authority inferred from identity, role labels, or ambient runtime context is not sufficient. If authority cannot be traced to a presented, validated delegation artefact, the action is denied.

Delegation must be scoped, time-bound, revocable, and versioned. Evaluation must validate delegation before rendering a decision. Without a valid delegation context, the action is denied.

Revocation status must be resolved and presented as part of the delegation context before evaluation begins. The evaluation function must not consult external revocation services during decision. Revocation status must be cryptographically verifiable and include an as-of timestamp and freshness bounds. Evaluation must deny if revocation information is absent, freshness bounds are not declared, revocation status is unverifiable, or the declared validity window has been exceeded.

Delegation targets must have stable, verifiable identity. If the identity of an agent cannot be deterministically derived from its composition — including but not limited to model version, system prompts, tools, policy bindings, fine-tuning artefacts, and retrieval configuration — delegation validation cannot succeed and the action is denied. Where the runtime environment cannot provide stable composition-derived identity, this constitutes a governance gap that must be disclosed, not silently accepted. Disclosure of the gap does not satisfy the delegation requirement; it documents non-satisfaction.

Delegation chains must be end-to-end traceable. Sub-delegation must preserve or narrow the authority scope of the delegator and must never widen it. The full delegation chain must be presented and validated during evaluation. If the chain cannot be validated end-to-end, the action is denied. Implementations must enforce a bounded delegation chain depth.

5. Deterministic Evaluation Requirement

Policy evaluation must be a pure function of:

All context required for evaluation — including temporal validity and revocation status — must be presented as part of the canonical input. The evaluation function must not reach beyond its declared inputs. There is no exception to this requirement.

Resolution phase. The resolution phase transforms raw runtime context into the canonical input bundle that evaluation consumes. Resolution steps — including canonicalisation, delegation validation, revocation resolution, sequence context derivation, and timestamp acquisition — may perform I/O and stateful operations, but must produce attributed, versioned, reviewable facts that are included in the evidence record and are independently replayable. Every resolved fact must be traceable to its source. Resolved context may include sequence-derived facts computed from prior authorised actions, provided those facts are explicit, versioned, and included in the canonical input bundle. Resolution must not make governance decisions, filter or suppress action context, or introduce non-determinism into the canonical input. Unresolvable context must result in DENY. Moving side effects from evaluation to resolution does not exempt them from evidence requirements.

The evaluation outcome must not depend on wall-clock time, external network calls, hidden mutable state, model randomness, non-deterministic execution, or ambient runtime state that an independent verifier cannot reproduce.

Policy identity must be a stable, immutable identifier for the evaluated policy version presented at decision time. References to “latest” or “current” policy do not constitute identity.

Canonical input requirement. All governance evaluation must operate on a canonical representation of the action. The canonical representation must be stable, serialisable, reproducible, and independent of runtime environment. The request presented to evaluation must be normalised into this canonical representation prior to decision. If identical canonical inputs produce different decisions without a policy change, governance has failed.

Canonicalisation rules and canonical serialisation format must be explicitly specified, versioned, and identified by an immutable canonicalisation spec identifier included in the evidence record. Changing the canonicalisation spec constitutes a governance change subject to Clause 10.

Replay equivalence. Two independent evaluators, provided with identical canonical inputs, delegation artefacts, and policy identity, must produce identical outcomes. Evidence records must be produced from a canonical serialisation so that independent evaluators can produce byte-identical receipts for identical inputs. If they diverge, at least one implementation is non-deterministic and therefore ungoverned.

Deterministic replay, independent verification, and byte-identical evidence generation from identical inputs are constitutional requirements, not implementation aspirations.

6. Evidence Integrity Requirement

Every evaluation must produce an evidence record. Governance that cannot be proven is indistinguishable from governance that did not occur.

Evidence must be structured, append-only, tamper-evident, and independently verifiable. Evidence records must be cryptographically chained using collision-resistant hash functions. The specific algorithms are an implementation choice; collision resistance is a constitutional minimum. Where digital signatures are used in evidence records or delegation artefacts, unforgeability under chosen-message attack is required. Operational logs are useful, but they do not satisfy this requirement.

Evidence records must contain sufficient information to reconstruct the decision without access to the originating system or vendor infrastructure:

This information must be sufficient to replay the authorisation decision deterministically and produce byte-identical evidence for identical inputs.

Evidence verification must not depend on the originating runtime or vendor infrastructure. The trust root used to anchor the evidence chain must be explicitly defined, independently inspectable, and independent of the governance system under verification. Self-attested trust roots do not satisfy independent verifiability.

A governed system must make governance bypass detectable. For every external consequence, the system must emit a corresponding immutable consequence marker that is cryptographically linked to an evidence record, enabling independent completeness verification. Consequence markers must be emitted by, or verifiably derived from, the enforcement boundary that produces the external consequence; best-effort logging does not satisfy this requirement. If an action can produce external consequences without a corresponding evidence record and no mechanism exists to detect the omission, the system does not satisfy Clause 2.

A missing or corrupted evidence record constitutes governance failure.

7. Fail-Closed Enforcement

If governance cannot validate delegation, cannot evaluate policy, detects integrity corruption, or encounters evaluation ambiguity, the action must be denied.

Specifically: inability to reproduce canonical inputs, validate policy identity, verify delegation artefacts, or validate evidence integrity constitutes evaluation failure and results in DENY. Partial evaluation is not evaluation.

Governance decisions are not advisory. They are authoritative determinations that must be enforced. Execution paths capable of producing external side effects must enforce governance outcomes before execution proceeds. A governance decision that can be ignored by the execution path it governs is not enforcement; it is suggestion.

Integrity takes precedence over availability. A system that silently degrades governance to keep running is not governed; it is merely optimistic.

8. Separation of Planes

Governance must remain structurally distinct from identity systems, policy engines, model guardrails, logging infrastructure, network controls, and agent frameworks.

Governance may integrate with those systems, but it must not collapse into them. The purpose of this separation is not organisational tidiness; it is to prevent governance semantics from being implicitly redefined by changes in adjacent systems.

The test for structural separation is behavioural: a change to any adjacent system — identity provider, policy engine, model version, logging pipeline, network configuration, or agent framework — must not alter governance evaluation semantics unless a corresponding, explicit change is made to governance configuration. If upgrading, reconfiguring, or replacing an adjacent system changes what is allowed or denied without a governance policy change, the planes are not separated.

A corresponding explicit change must be a versioned governance policy or configuration change subject to the same evidence and drift controls as any other governance artefact. Implicit dependency pins, ambient version locks, or undocumented couplings do not constitute explicit governance configuration changes.

9. Provider Neutrality

Governance semantics must not depend on a specific model provider, agent framework, runtime environment, transport protocol, or infrastructure vendor. Changing any of these must not change authorisation outcomes in the absence of an explicit policy change.

Clause 8 defines structural separation from adjacent systems. This clause extends that invariant to substitution: replacing a provider, framework, or infrastructure component is a specific case of adjacent-system change and must satisfy the same behavioural test. If a vendor switch silently alters what is allowed, governance is not provider-neutral and cannot honestly be audited as a stable control.

10. Drift Prohibition

Governance must not evolve through undocumented behaviour. All changes to policy semantics, delegation structure, decision logic, and evidence format must be explicit, versioned, and reviewable.

Changes must not retroactively alter the meaning of previously issued evidence records. Historical evidence records must remain interpretable under the policy definitions referenced by their policy identity. Policy evolution must not alter the semantics of previously issued receipts. If a historical receipt cannot be replayed under its original policy identity to produce an identical outcome, the evidence chain is broken and all affected evidence records must be marked invalid for governance purposes.

Implicit evolution constitutes constitutional drift. Drift is governance failure made gradual: the system still produces decisions and receipts, but the meaning of those decisions silently changes under operational pressure.

11. Composition Closure

Governance of individual systems does not guarantee governance of their composition. When governed systems interact — through shared state, delegation chains, event propagation, tool invocation, or any other coordination mechanism — the interaction itself constitutes an execution path subject to Clause 2.

Authority that emerges from composition — execution paths reachable through component interactions that no individual delegation authorised — must be governed. If composition creates authority paths that bypass the governance evaluation of any participating system, the composition is ungoverned regardless of whether each component satisfies this constitution individually.

Evidence chains across interacting systems must be linkable through a shared trace identifier or coordination artefact so that cross-system governance decisions can be independently reconstructed. Evidence that cannot be correlated across system boundaries does not demonstrate governance of the composition.

Where composition governance cannot be achieved, the gap must be explicitly disclosed and documented. Silent acceptance of ungoverned composition violates this constitution.

12. Constitutional Supremacy

This constitution supersedes implementation convenience, performance optimisation, vendor capability, and operational expediency.

If a trade-off arises between convenience and governance integrity, governance integrity prevails. A system that cannot maintain these invariants under load does not have a scaling problem; it has a governance problem.

Amendment process. This constitution may be amended only through an explicit, versioned revision that increments the version identifier, states the date of effect, and produces a change record identifying each clause modified and the rationale for modification. Amendments must not alter the meaning of evidence records issued under prior versions. Implementations must declare which version they satisfy and must not silently adopt a newer version without explicit reconfiguration.

Closing Principle

No action without evaluation. No evaluation without delegation. No delegation without scope. No decision without evidence. No evidence without integrity. No composition without governance.

That is the governance contract.