CANONICAL CATEGORY

Consequence Governance

Consequence Governance is the governance category for deciding whether an exact proposed consequence may legitimately become real under the authority, evidence and conditions that exist now. The governing object is the consequence, not the worker. The proposer may be an AI, a person, a workflow, an API, a device or another machine.

Start with the milk example →

CATEGORY SHIFT

From access mediation to causal mediation.

Zero Trust removed implicit trust from network location and access. Consequence Governance generalizes the same distrust and re-verification discipline to a larger control object: consequential causal capacity.

Zero Trust

May this subject access this resource now?

Consequence Governance

May this causal capacity become this consequence now?

The extension

Verification and enforcement follow every relevant causal path to externally consequential state.

Detailed comparison →

SECURITY MODEL

The intelligence does not have to remain trustworthy.

Reasoning, planning, simulation, disagreement, hallucination and arbitrary internal state may remain untrusted while contained. The control objective is external: untrusted computation may not convert capability into relevant external consequence through an ungoverned causal path.

Do not govern thought. Govern consequence.
Internal computation may remain free inside its bounded domain. Its paths to the world may not.

FORMAL CAUSAL INVARIANT

NO_UNGOVERNED_CAUSAL_EFFECT_PATH

No causal path from untrusted computation to a relevant external consequence may succeed unless it crosses an explicit governed effect boundary for the exact effect under current authority.

`NO_DIRECT_EFFECT_PATH` remains the compatibility identifier used by existing implementation, tests and receipts. `NO_UNGOVERNED_CAUSAL_EFFECT_PATH` names the complete formal semantics.

The channel inventory includes direct APIs/tools, human relay, agent relay, shared state, files/messages, credentials/actuators, resource consequences, side channels, dynamic references/callbacks/plugins, telemetry triggers, fallback routes, implicit training/ranking/feedback influence and unknown paths.

Read the formal invariant → · Formal verification methods →

GOVERNED BOUNDARY

A named gateway is not enough.

Explicit + bound

The boundary is declared and the decision binds the exact proposed consequence.

Authorized + enforceable

Authority is current, and DENY can prevent or constrain effect before commitment.

Fail-closed + evidenced

Unresolved state produces no effect, and decision/outcome can be reconstructed.

Rollback, compensation and isolation may help recovery but are not prerequisites. Irreversible consequences make pre-commit enforcement the requirement.

ARCHITECTURE

Governed Effect Path

1 · Propose

Define the exact consequence being attempted.

2 · Authorize

Resolve current mandate, state, purpose, constraints and evidence.

3 · Enforce

ALLOW, DENY or ESCALATE; only governed causal crossings may reach consequence.

REHT supplies fresh consequence-time authorization. RACS supplies deterministic decision semantics. Gateway/PEP enforces release. Veritas preserves evidence and receipts.

Governed Effect Path →

CANONICAL VOCABULARY

Category and subordinate layers.

Consequence GovernanceThe top-level category: whether the exact proposed consequence may legitimately become real.Consequential causal capacityAny direct or indirect capacity by which untrusted state can cause a relevant external state transition.Governed Effect PathThe architecture through which consequential causal crossings must pass.NO_UNGOVERNED_CAUSAL_EFFECT_PATHThe formal invariant requiring complete mediation of consequential causal capacity.NO_DIRECT_EFFECT_PATHThe established compatibility identifier used by current implementation, tests and receipts.Consequence-time authorizationFresh exact-action authorization immediately before consequence.Governed ContractWorker-neutral definition of purpose, scope, constraints, evidence and correct completion.REHTModel-agnostic consequence-time authorization boundary.Receipts / VeritasEvidence of what was evaluated, decided, executed, changed or refused.
PROOF OBLIGATION

Architecture and deployment require different proofs.

The architectural invariant is absolute: the design may not permit an ungoverned causal path. A concrete deployment claim is bounded evidence: actual reachable paths must be inventoried and mapped to enforcement. Configuration, topology, plugins, credentials, operators and integrations can create new paths and therefore trigger re-verification.

Architecture defines the invariant. Deployment evidence establishes where it actually holds.