{"slug":"internal/architecture/triage","title":"IntegrateWise / SpineWorkspace — Triage & Organizational Memory Canonical","section":"internal","sectionLabel":"Internal","status":"unclassified","type":"document","path":"internal/architecture/triage.md","bytes":8980,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n\n\n# IntegrateWise / SpineWorkspace — Triage & Organizational Memory Canonical\n\n**Status:** CANONICAL TARGET\n**Date:** 2026-08-24\n**Scope:** Triage, Flow C, organizational memory, promotion, AI operational boundary\n**Foundation:** Business Context Spine (THE semantic foundation)\n\n## The Tier-0 Principle\n\n> **Business Context is the semantic foundation of SpineWorkspace.** Triage classifies evidence that may become Business Context. Without Business Context, Triage has nothing to serve.\n\n## 1. Purpose\n\nTriage is the cognitive intake and classification boundary between incoming evidence/AI output and the governed Business Context promotion path.\n\nTriage is **not** the owner of canonical truth. Triage is **not** a canonical writer. Triage is **not** an authority grantor.\n\nIts job is to:\n\n1. classify incoming evidence;\n2. link it to known entities and work where possible;\n3. identify duplicates, conflicts, ambiguity and materiality;\n4. classify the proposed memory scope;\n5. stage a candidate for governed review;\n6. route the candidate to human approval, rejection, deferral or repair;\n7. emit a durable audit trail.\n\n## 2. Memory boundary\n\n```text\nSOURCE / USER / AI / AGENT EVENT\n |\n v\n Triage Intake\n |\n classify + link\n |\n v\n TRIAGE CANDIDATE / EVIDENCE\n |\n +-------+--------+\n | |\n reject/defer review\n |\n HUMAN DECISION\n / \\\n reject approve\n | |\n v v\n terminal GOVERNED PROMOTION\n |\n v\n BUSINESS CONTEXT UPDATED\n |\n v\n BUSINESS CONTEXT SPINE\n```\n\n### Non-negotiable rule\n\n> **AI may propose organizational memory; only the governed promotion path can publish it.**\n\nHigh confidence does not itself authorize promotion.\n\n## 3. What Triage may write\n\nTriage may write only to bounded operational/staging state:\n\n- triage item\n- extracted candidate\n- classification\n- entity links\n- provenance\n- confidence dimensions\n- conflict findings\n- proposed memory scope\n- governance recommendation\n- review state\n- correlation/causation identifiers\n\nThese writes are operational records, not canonical organizational truth.\n\n## 4. What Triage may never write\n\nTriage must never directly write:\n\n- canonical entity state\n- approved organizational memory\n- authoritative policy\n- permissions\n- authority grants\n- canonical relationships\n- promoted outcomes\n\nThose changes must pass through governed promotion / canonical writers.\n\n## 5. Memory scopes\n\n| Scope | Meaning | Promotion |\n|---|---|---|\n| Personal | Private user memory | Never widens automatically |\n| Conversational | Session/thread working memory | Evidence only |\n| Agent | Agent/Twin working memory | Evidence only |\n| Organizational staging | Candidate organizational memory | Human/governed review required |\n| Organizational published | Approved tenant-wide memory | Canonical governed state |\n\n## 6. Triage decision model\n\nTriage evaluates:\n\n- source and provenance\n- entity/link confidence\n- semantic category\n- duplication\n- conflict with canonical truth\n- sensitivity\n- materiality\n- freshness\n- completeness\n- proposed memory scope\n- policy eligibility\n\nRecommended output:\n\n```json\n{\n \"classification\": {},\n \"linking\": {},\n \"canonical_review\": {},\n \"memory\": {\n \"scope\": \"personal|conversational|agent|organizational\",\n \"candidate\": true\n },\n \"governance\": {\n \"decision\": \"stage|reject|defer|repair|review\",\n \"reason\": \"\"\n },\n \"provenance\": {},\n \"confidence\": {}\n}\n```\n\nThere is deliberately **no `AUTO_APPROVE` outcome for organizational memory**.\n\n## 7. Promotion state machine\n\n```text\ncandidate\n |\n +--> repair\n |\n +--> rejected\n |\n +--> deferred\n |\n +--> pending_approval\n |\n +----+----+\n | |\n reject approve\n | |\n v v\n terminal promote\n |\n v\n published\n```\n\n## 8. Canonical write path\n\n```text\nTriage\n -> candidate staging\n -> governance review\n -> approval record\n -> canonical writer / Pipeline promotion\n -> provenance + lineage + outbox\n -> search/index projections\n -> refreshed user/Twin context\n```\n\nThere is no direct Triage → Neon/R2/Vectorize/Supabase canonical promotion path.\n\n## 9. AI operational boundary\n\nAI works on governed operational context derived from Spine.\n\n```text\nCanonical Spine\n |\n Context Assembly\n |\n permission + purpose + freshness + relevance\n |\n v\nOperational Sandbox\n |\n +--> Twin\n +--> Coworker\n +--> Domain Agents\n +--> External Agents\n```\n\nAI-generated conclusions remain Flow C evidence/candidates until promoted.\n\n## 10. Organizational memory semantics\n\nOrganizational memory is not a transcript dump. It is curated, provenance-bearing, semantically classified knowledge that has survived the promotion gate.\n\nExamples:\n\n- durable business facts\n- approved decisions\n- explicit organizational preferences\n- stable relationships\n- validated insights\n- policy/knowledge candidates that have passed governance\n\n## 11. Activation contract\n\nTriage is considered **active** only when all of the following are true:\n\n1. the Triage runtime is deployed;\n2. its intake trigger is wired to the intended Flow C ingress;\n3. staging writes are tenant-scoped;\n4. the approval endpoint updates review state;\n5. approval triggers canonical promotion through the governed writer;\n6. direct canonical writes from Triage are impossible by credentials/bindings;\n7. rejection/defer/repair are terminal or resumable states with audit;\n8. a test proves approved memory appears in canonical retrieval and rejected memory does not;\n9. observability exposes triage throughput, pending queue, approval latency, promotion success and failure;\n10. the end-to-end path is proven in Customer Zero before external tenants.\n\n## 12. Architectural law\n\n> **Triage classifies. Governance decides. The Pipeline promotes. Spine owns organizational memory. Twin consumes the governed result.**\n\n\n---\n\n# 13. Relationship to the Full SpineWorkspace Ontology\n\nTriage participates in the third system flow:\n\n```text\nCommunication / Source / User / Twin / Agent\n ↓\nOperational Sandbox / Flow C Intake\n ↓\nTriage\n ↓\nCandidate + Evidence + Classification + Provenance\n ↓\nStaging\n ↓\nGovernance / Human Review\n ↓\nPipeline Promotion\n ↓\nOrganizational Memory\n ↓\nSpine Context\n ↓\nUser Workbench / Twin\n```\n\nTriage is downstream of Context Assembly and upstream of governed Organizational Memory.\n\n## 14. Triage and Communications over the Bridge\n\nSlack, email, chat, meetings and agent communications may produce evidence or memory candidates.\n\nThe Bridge is the transport/context boundary.\n\n```text\nCommunication Bridge\n ↓\nWork / Context Reference\n ↓\nTriage\n```\n\nA communication reaction is not itself an authority grant.\n\nAny approval must become an authenticated, tenant-scoped, version-bound approval event before promotion.\n\n## 15. Triage and the Twin\n\nThe Twin consumes published memory through bounded context.\n\nThe Twin may:\n\n- produce candidate evidence;\n- request triage;\n- cite published Organizational Memory;\n- use agent-scoped working memory;\n- recommend work.\n\nThe Twin may not turn confidence into authority or publish Organizational Memory directly.\n\n## 16. Triage and the Human Workbench\n\nPending candidates must remain distinguishable from published memory.\n\n```text\nPending Candidate\n ≠\nPublished Organizational Memory\n```\n\nThe User Workbench may expose:\n\n- pending review;\n- conflicts;\n- evidence;\n- proposed memory;\n- approval;\n- rejection;\n- defer;\n- repair.\n\nThe projection must preserve lifecycle status.\n\n## 17. Triage completion conditions\n\nTriage is active only when:\n\n1. runtime is deployed;\n2. intake trigger is connected;\n3. staging writes are tenant-scoped;\n4. approval endpoint is authenticated and version-checked;\n5. promotion uses the governed canonical writer;\n6. direct canonical writes are impossible;\n7. reject/defer/repair are audited;\n8. approved candidates become retrievable published memory;\n9. rejected/deferred candidates do not become published memory;\n10. observability covers throughput, queue depth, approval latency, promotion success/failure and reconciliation.\n\n## 18. Canonical triage law\n\n> **Triage classifies. Governance decides. The Pipeline promotes. Spine owns organizational memory. Twin consumes the governed result.**\n"}