Governance

Governance owns policy and approval semantics. It is the operational control plane that decides whether inferred state, proposed actions, or execution candidates may advance.

Governance is not a chat window. Governance is not modal UI for its own sake. Governance appears when policy requires it.

UNDERSTAND → PROPOSE → GOVERN WHEN REQUIRED → EXECUTE → CONTINUE

Two Gates

Governance applies at two gates:

1. Composition Gate

When the Workbench is composed, governance evaluates each capability. The governance field tells the frontend which actions are allowed, which need approval, and which are denied.

Purpose: Users see accurate action availability. No surprise denials at execution time.

Implementation: Uses cached policy (fast, <30s TTL).

2. Execution Gate

When an action is executed, governance re-evaluates with fresh policy. This prevents TOCTOU (time-of-check-time-of-use) issues.

Purpose: Authoritative enforcement at the moment of execution.

Implementation: Uses fresh policy from the governance service.

Composition gate: cached policy (fast)
Execution gate: fresh policy (authoritative)

Governance Components

Component	Purpose
Identity	Who is making this request?
Tenant	Which organization does this belong to?
Role	What role does this person hold?
Permission	Is this action permitted?
Responsibility	Is this person responsible for this type of work?
Authority	Does this person have authority for this decision?
Policy	What policies apply to this action?
Risk	What is the risk level of this action?
Approval	Who must approve this action?
Evidence	What evidence supports this action?
Audit	What record must be kept?
Accountability	Who is accountable for this outcome?

Authority Law

From the canonical ontology, the authority law is:

confidence ≠ authority
agent ≠ authority
MCP access ≠ mutation authority
tool availability ≠ permission

Rules:

• Confidence in AI output does not grant authority to act
• Being an agent does not grant authority to act
• Having MCP access does not grant mutation authority
• Having tool availability does not grant permission

Consequential actions must traverse the governance path.

HITL Classification

Human-in-the-loop is governance behavior. Operators may act as:

Role	Purpose
Reviewer	Reviews proposed actions before approval
Approver	Authorizes consequential actions
Escalator	Routes exceptions to appropriate authority
Exception Handler	Manages out-of-policy situations

Rules:

• Human involvement does not make a feature a separate product boundary
• Human involvement does not bypass canonical write authority
• Human involvement is governance, not a product surface

Risk Classification

Actions are classified by risk level:

Risk Level	Example	Governance
Low	Update task status	Auto-approve
Medium	Send internal message	Policy check
High	Send customer email	Approval required
Critical	Modify contract terms	Multi-level approval
Catastrophic	Delete production data	Executive approval + audit

Governance and the Workbench

Governance is expressed through the Workbench as:

• Action availability — which actions the user can take
• Approval requirements — which actions need approval
• Policy feedback — why an action is restricted
• Audit trail — what was approved and by whom

Governance is not a standalone admin product unless explicitly required.

Related

• Capability Fabric — the capabilities governance protects
• Execution Fabric — where governance is enforced
• Twin — who proposes actions subject to governance
• Reconciliation — how governance decisions are verified