{"slug":"architecture/GOVERNANCE","title":"Governance","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/GOVERNANCE.mdx","bytes":4344,"description":"The policy and approval semantics that determine whether actions may advance — two gates, HITL classification, authority law.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nGovernance owns policy and approval semantics. It is the operational control plane that decides whether inferred state, proposed actions, or execution candidates may advance.\n\nGovernance is not a chat window. Governance is not modal UI for its own sake. Governance appears when policy requires it.\n\n```text\nUNDERSTAND → PROPOSE → GOVERN WHEN REQUIRED → EXECUTE → CONTINUE\n```\n\n## Two Gates\n\nGovernance applies at **two gates**:\n\n### 1. Composition Gate\n\nWhen 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.\n\n**Purpose:** Users see accurate action availability. No surprise denials at execution time.\n\n**Implementation:** Uses cached policy (fast, <30s TTL).\n\n### 2. Execution Gate\n\nWhen an action is executed, governance re-evaluates with fresh policy. This prevents TOCTOU (time-of-check-time-of-use) issues.\n\n**Purpose:** Authoritative enforcement at the moment of execution.\n\n**Implementation:** Uses fresh policy from the governance service.\n\n```text\nComposition gate: cached policy (fast)\nExecution gate: fresh policy (authoritative)\n```\n\n## Governance Components\n\n| Component | Purpose |\n|-----------|---------|\n| **Identity** | Who is making this request? |\n| **Tenant** | Which organization does this belong to? |\n| **Role** | What role does this person hold? |\n| **Permission** | Is this action permitted? |\n| **Responsibility** | Is this person responsible for this type of work? |\n| **Authority** | Does this person have authority for this decision? |\n| **Policy** | What policies apply to this action? |\n| **Risk** | What is the risk level of this action? |\n| **Approval** | Who must approve this action? |\n| **Evidence** | What evidence supports this action? |\n| **Audit** | What record must be kept? |\n| **Accountability** | Who is accountable for this outcome? |\n\n## Authority Law\n\nFrom the canonical ontology, the authority law is:\n\n```text\nconfidence ≠ authority\nagent ≠ authority\nMCP access ≠ mutation authority\ntool availability ≠ permission\n```\n\n**Rules:**\n- Confidence in AI output does not grant authority to act\n- Being an agent does not grant authority to act\n- Having MCP access does not grant mutation authority\n- Having tool availability does not grant permission\n\nConsequential actions must traverse the governance path.\n\n## HITL Classification\n\nHuman-in-the-loop is governance behavior. Operators may act as:\n\n| Role | Purpose |\n|------|---------|\n| **Reviewer** | Reviews proposed actions before approval |\n| **Approver** | Authorizes consequential actions |\n| **Escalator** | Routes exceptions to appropriate authority |\n| **Exception Handler** | Manages out-of-policy situations |\n\n**Rules:**\n- Human involvement does not make a feature a separate product boundary\n- Human involvement does not bypass canonical write authority\n- Human involvement is governance, not a product surface\n\n## Risk Classification\n\nActions are classified by risk level:\n\n| Risk Level | Example | Governance |\n|-----------|---------|------------|\n| **Low** | Update task status | Auto-approve |\n| **Medium** | Send internal message | Policy check |\n| **High** | Send customer email | Approval required |\n| **Critical** | Modify contract terms | Multi-level approval |\n| **Catastrophic** | Delete production data | Executive approval + audit |\n\n## Governance and the Workbench\n\nGovernance is expressed through the Workbench as:\n\n- **Action availability** — which actions the user can take\n- **Approval requirements** — which actions need approval\n- **Policy feedback** — why an action is restricted\n- **Audit trail** — what was approved and by whom\n\nGovernance is not a standalone admin product unless explicitly required.\n\n## Related\n\n- [Capability Fabric](/architecture/CAPABILITY_FABRIC) — the capabilities governance protects\n- [Execution Fabric](/architecture/EXECUTION_FABRIC) — where governance is enforced\n- [Twin](/architecture/TWIN) — who proposes actions subject to governance\n- [Reconciliation](/architecture/RECONCILIATION) — how governance decisions are verified\n"}