{"slug":"architecture/GOVERNANCE_CONSTITUTION","title":"Governance Constitution","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/GOVERNANCE_CONSTITUTION.mdx","bytes":3281,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: SUPERSEDED / ABSORBED — historical subsystem constitution. Current authority: [`INTEGRATEWISE_ARCHITECTURE.md`](INTEGRATEWISE_ARCHITECTURE.md) v2.2.\nScope: Two-gate governance model, approval tokens, risk scoring, audit, and compliance rules.\nCanonical Owner: IntegrateWise Platform\nLast Verified: 2026-07-20\n\n---\n\n## 1. Purpose\n\nThis document defines how IntegrateWise governs execution.\n\nNo capability mutates canonical state without governance. No external side effect occurs without approval.\n\n---\n\n## 2. Two-Gate Model\n\n```\nGate 1: Pre-Proposal\n  - ALLOW_PROCEED\n  - DENY\n  - REQUIRE_PRE_APPROVAL\n        │\n        ▼\nTwin Proposal\n        │\n        ▼\nGate 2: Post-Proposal\n  - AWAITING_HUMAN_APPROVAL\n  - HUMAN_APPROVED\n  - DENY\n```\n\n---\n\n## 3. Confidence Thresholds\n\n| Confidence | Gate 2 Action                                   | Token        |\n| ---------- | ----------------------------------------------- | ------------ |\n| ≥ 0.95     | Prioritize for human review; never auto-promote | Human-issued |\n| ≥ 0.85     | Surface as high-confidence proposal             | Human-issued |\n| 0.70–0.85  | Surface with uncertainty and evidence gaps      | Human-issued |\n| < 0.70     | Reject or retain as non-actionable candidate    | None         |\n\n---\n\n## 4. Approval Chains\n\n| Action                 | Level 1          | Level 2       | Level 3 |\n| ---------------------- | ---------------- | ------------- | ------- |\n| deal.close (<$10K)     | Sales Rep        | —             | —       |\n| deal.close ($10K-$25K) | Sales Rep        | Head of Sales | —       |\n| deal.close (>$25K)     | Sales Rep        | Head of Sales | Founder |\n| hiring.open            | Department Head  | Founder       | —       |\n| budget.adjust          | Finance Manager  | Founder       | —       |\n| release.deploy         | Engineering Lead | CTO           | —       |\n| code.rollback          | Engineering Lead | CTO           | —       |\n\n---\n\n## 5. Audit Rules\n\n1. Every action is logged with actor, capability, evidence, and approval status.\n2. Audit retention is immutable and seven-year minimum.\n3. Every approval emits a governance token with expiry and scope.\n4. Cross-department actions require cross-department approval.\n5. Emergency override is Founder-only with full audit trail.\n\n## 5a. Cryptographic Approval Semantics (Amendment 14)\n\nEvery approval record includes:\n\n- `payload_hash`: SHA-256 of the canonical payload (deterministic serialization)\n- `previous_event_hash`: hash-chain predecessor for tamper detection\n- `signature_algorithm`: algorithm identifier\n- `signature_key_id`: signing key identifier\n- `signature`: signature value\n- `signed_at`: signature timestamp\n\nHuman approval identity comes from the validated session and is bound into\nthe signed canonical payload. SHA-256 verifies content integrity; the\nsignature provides non-repudiation. Key rotation and verification procedures\nmust be documented before production deployment.\n\n---\n\n## 6. Invariants\n\n1. Governance is enforced by architecture, not policy alone.\n2. No execution path bypasses Gate 1.\n3. No side effect occurs without explicit human Gate 2 approval bound to the\n   exact proposal and scope.\n4. Approval authority matches risk.\n"}