{"slug":"triage/07-GOVERNANCE_BOUNDARY","title":"07 — Governance Boundary","section":"triage","sectionLabel":"Triage","status":"canon","type":"document","path":"triage/07-GOVERNANCE_BOUNDARY.mdx","bytes":2906,"description":"The hard boundary between triage classification and governance approval: triage never promotes.","updated":"2026-08-24","source":"integratewise/Integratewise-docs-wiki","content":"\n\n## What Triage May Write\n\nTriage may write only to bounded operational/staging state:\n\n| Write | Table/Store | Purpose |\n|---|---|---|\n| Triage item | `triage_items` (DO SQLite) | Operational intake record |\n| Extracted candidate | `triage_results` (Neon/D1) | Staging for human review |\n| Classification | `triage_results.classification` | Category, type, intent |\n| Entity links | `triage_results.metadata.entity_refs` | Links to known entities |\n| Provenance | `triage_results.metadata` | Source, tenant, user |\n| Confidence | `triage_results.confidence` | Quality dimensions |\n| Conflict findings | `triage_results.metadata.canonical_review` | Duplicates, conflicts |\n| Review state | `triage_results.approval_status` | pending/approved/discarded/deferred |\n| Continuity event | Continuity service | Evidence emission |\n\nThese writes are **operational records**, not canonical organizational truth.\n\n## What Triage May Never Write\n\nTriage must never directly write:\n\n| Forbidden Write | Why |\n|---|---|\n| Canonical entity state | Only governed canonical writers |\n| Approved organizational memory | Only Pipeline promotion |\n| Authoritative policy | Only Governance service |\n| Permissions | Only Identity service |\n| Authority grants | Only Governance service |\n| Canonical relationships | Only Pipeline/Spine |\n| Promoted outcomes | Only Pipeline promotion |\n\n## The Authority Law\n\n> **Confidence never grants authority.**\n\nA 0.99-confidence proposal and a 0.55-confidence proposal require the identical approval to become real. Confidence describes evidence quality. It is an input to human judgement, never a substitute for it.\n\n## Human Decision Boundary\n\nThe `PATCH /v1/knowledge/triage/:id` endpoint is the human decision boundary. It requires:\n\n1. **Authenticated principal** — `x-user-id` header\n2. **Tenant authority** — `x-tenant-id` header, must match triage item\n3. **Optimistic check** — current state must be `pending` or `deferred`\n4. **Approver identity/time** — recorded in metadata\n5. **Immutable audit** — decision logged with full context\n6. **Promotion event** — on approve, triggers consolidation queue\n\nThe endpoint itself does not become a second canonical writer. It updates review state and triggers downstream processes.\n\n## Slack as Review Channel\n\nSlack is a **review channel**, not an authority bypass. A Slack reaction must become a verified approval event:\n\n1. Reaction received → verify binding to triage item\n2. Verify tenant and principal identity\n3. Verify candidate version hasn't changed\n4. Create approval event with full audit context\n5. Route to consolidation pipeline\n\nThe Slack integration never writes canonical memory directly.\n"}