{"slug":"canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON","title":"SpineWorkspace / IntegrateWise — Canon","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md","bytes":31902,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Class:** CANON — this is the only document permitted to redefine architecture.\n**Status:** CURRENT\n**Effective:** 2026-08-31\n**Source of authority:** the *SpineWorkspace Founder Canon, v6.0.0, 31 August 2026* — committed\nverbatim at [`FOUNDER-CANON-2026-08-31.md`](FOUNDER-CANON-2026-08-31.md). Load-bearing sections:\n§0A Founder Decision Register, §4A Dual-Workbench Context Model, §19 Governance outcomes, §31A\nSupersession Map, §32 Canonical Vocabulary, Appendix C Founder Freeze Decisions. This file is the\nrepository's in-tree statement of that canon; where the two differ, the Founder Canon governs and\nthis file is corrected.\n**Supersedes:** `PRODUCT_FRAMING_LOCK.md` (2026-08-25), `SPINEWORKSPACE_CANONICAL_PRODUCT_MANUAL.md`, and the Aug 1 canonical freeze **in the areas named in §7**.\n**Changing this document requires an ADR under [`adr/`](adr/).**\n\n**The constitutional product rule:**\n\n```text\nSPINEWORKSPACE\n= Human Workbench\n+ AI Workbench\n+ Shared Business Context\n+ Separate Human and AI Continuity\n+ Governed Work and Execution\n```\n\n---\n\n## 1. Positioning\n\n**SpineWorkspace**\n\n> The workspace where humans and AI work on the same business context, with separate continuity,\n> governed execution, and one continuous work loop.\n\n**IntegrateWise**\n\n> The infrastructure platform that provides the identity, connectivity, discovery, activation,\n> Spine, capabilities, governance, execution and continuity required to make SpineWorkspace\n> possible.\n\nSpineWorkspace is the product. IntegrateWise is the infrastructure underneath. Never use\nIntegrateWise as the product name; never use SpineWorkspace as the company name.\n\n**Core principle**\n\n> **Humans govern. AI helps. Spine preserves continuity.**\n\n---\n\n## 1A. Business Context is the semantic foundation — **TIER-0**\n\n**Tier-0 principle.** This sits before the product architecture, not inside it. Everything below it\nin this document is mechanism, and everything else in the canonical set derives from it.\n\n> **Business Context is the semantic foundation of SpineWorkspace. It connects organizational\n> business reality to Work, Humans, AI, Agents, Memory, Knowledge, Capabilities, Communication,\n> Decisions, Governance, Execution, Evidence, Continuity and Outcomes. Without Business Context,\n> SpineWorkspace has no meaning; it becomes another collection of tools and interfaces.**\n\nThe product-level expression, and one of the central anchors of the entire IntegrateWise\narchitecture:\n\n> **The Spine gives work its business context.**\n\n### The correction this makes\n\n> **SpineWorkspace is not a workspace with a Spine. It is a workspace *constituted by* the Business\n> Context Spine.**\n\nThat distinction is the whole framing. A workspace *with* a Spine treats business context as a\nfeature it offers — something retrievable, attachable, optional. A workspace *constituted by* the\nSpine has no coherent existence without it. Everything else derives from that.\n\nA view without business context is a table. An action without it is an untyped write. A Twin\nwithout it is a chatbot. An agent without it is a script. The Spine exists so that none of those is\nwhat the user gets.\n\nThe Spine is therefore **not primarily an integration layer or a data store. It is the semantic\noperating substrate through which organizational business becomes contextual, actionable and\ncontinuous.**\n\n### The canonical hierarchy\n\n```text\n                         ORGANIZATIONAL BUSINESS\n                                  │\n                                  ▼\n                    BUSINESS CONTEXT SPINE\n                  ───────────────────────────\n                  The semantic substrate\n                                  │\n          ┌───────────────────────┼───────────────────────┐\n          │                       │                       │\n          ▼                       ▼                       ▼\n       HUMAN                    AI                    ORGANIZATION\n          │                       │                       │\n          ▼                       ▼                       ▼\n  Human Workbench          AI Workbench           Shared Work\n          │                       │                       │\n          ▼                       ▼                       ▼\nPersonal Contextual       AI Continuity           Organizational\n     Memory                  Memory                   Memory\n          │                       │                       │\n          └───────────────────────┼───────────────────────┘\n                                  │\n                                  ▼\n                    Contextualized Capabilities\n                    Agents · Knowledge · Tools\n                    Communication · Decisions\n                                  │\n                                  ▼\n                       GOVERNED EXECUTION\n                                  │\n                                  ▼\n                    OUTCOME / EVIDENCE / STATE\n                                  │\n                                  ▼\n                    RECONCILIATION → SPINE\n```\n\nThe three branches are the three participants — **Human, AI, Organization** — and they line up\nexactly with the three continuity domains beneath them. Capabilities, agents, knowledge, tools,\ncommunication and decisions sit *below* all three, because they are **contextualized** by business\ncontext rather than being organizing principles of their own.\n\n### The critical loop\n\n```text\nBusiness → Context → Work → Action → Outcome → Context\n```\n\n**Not:**\n\n```text\nWorkspace → tools → AI → memory\n```\n\nThe second ordering is the fragmentation SpineWorkspace exists to end. It puts the container first\nand the meaning last.\n\n### Business Context is the connective tissue\n\nEvery major capability is contextualized against the business, and answers a business question:\n\n| Capability | The business question it must answer |\n|---|---|\n| **Work** | What business objective or responsibility does this work serve? |\n| **People** | Who is responsible, involved, accountable or affected? |\n| **AI** | Why is AI involved, and what business context does it operate on? |\n| **Agents** | What organizational role and business responsibility does this agent serve? |\n| **Memory** | What continuity matters to the organization, person or AI? |\n| **Knowledge** | What does the organization know about its business? |\n| **Capabilities** | What can be done in service of the business? |\n| **Tools / ecosystems** | Where does the underlying business data or action live? |\n| **Communication** | What business context does this message, update or decision belong to? |\n| **Decisions** | What business decision was made, by whom, with what authority? |\n| **Governance** | What is permitted in this business context? |\n| **Execution** | What business action is being performed? |\n| **Evidence** | What proves what actually happened? |\n| **Projection** | What portion of the business reality should this participant see? |\n| **Continuity** | What needs to persist so work can continue intelligently? |\n\nA capability that cannot answer its question is not yet part of the product.\n\n### The Spine *is* the business contextual memory\n\nThe product is **not** \"memory\" as a feature, and IntegrateWise does not offer agentic memory or\npersonal memory as things in themselves.\n\n> **The Spine is the business contextual memory. That is the product.**\n\nPersonal Contextual Memory and AI Continuity Memory remain first-class **separations**, and the\nthree-scope invariant in §3 holds unchanged. But their purpose is protective, not promotional: they\nexist so that a user's private thinking and an AI's working inference **cannot silently become\norganizational truth**. They are walls around business context, not parallel products beside it.\n\nThe three domains read cleanly once business context is the foundation:\n\n| Domain | What it holds |\n|---|---|\n| **Business / Organizational Memory** | What the organization knows, and what has become part of organizational reality. |\n| **Personal Contextual Memory** | What matters to the individual human **while they operate on the business**. |\n| **AI Continuity Memory** | What the AI needs to maintain continuity **while helping with business work**. |\n\n> **Both personal and AI memory operate *on* Business Context. They do not replace it.**\n\nMemory is subordinate to business context, and Organizational Memory is the **output** of the loop\nrather than a sibling of the other two:\n\n```text\n             BUSINESS CONTEXT\n                    │\n        ┌───────────┴───────────┐\n        ▼                       ▼\n PERSONAL CONTEXT          AI CONTINUITY\n    MEMORY                    MEMORY\n        │                       │\n        └───────────┬───────────┘\n                    │\n             GOVERNED WORK\n                    │\n                    ▼\n             BUSINESS OUTCOME\n                    │\n                    ▼\n        ORGANIZATIONAL MEMORY\n```\n\nPersonal and AI continuity feed governed work; the business outcome of that work is what becomes\norganizational memory. Neither participant's continuity becomes organizational truth by being\nwritten down — only by producing a governed outcome.\n\nThis reframes the open substrate question. It is not *\"where do we store AI memory?\"* — it is:\n\n> **How does AI Continuity maintain its own continuity while remaining continuously grounded in the\n> authoritative Business Context Spine?**\n\nGrounding is the requirement; storage is an implementation of it. See `G-10`.\n\nRead the constitutional memory rule in that light:\n\n```text\nUser thought  ≠  AI inference  ≠  Organizational truth\n```\n\nThe rule protects the middle thing the company actually sells.\n\n### What this obliges\n\n- **Business context leads everywhere.** It is the primary dimension of every surface, every\n  action, and every ranking — not an attribute retrieved after the fact.\n- **Priority is business priority.** Where work or actions compete for attention, objectives, goals\n  and KPIs decide the order — never recency or screen position.\n- **Business context is carried, not re-derived.** Any surface or action that cannot state the\n  business context it operates on is not ready to act.\n### The test for any future feature\n\n> **If a feature cannot explain how it relates to Business Context, Work, or a Business Outcome, it\n> does not yet have a meaningful place in SpineWorkspace.**\n\nA feature that fails this test is a tool sitting next to the product, which is the fragmentation\nSpineWorkspace exists to end. The test applies to new work before it is built, not as a review\nafterwards.\n\n---\n\n## 2. The Founder Canon — product model\n\n**The Human Workbench and the AI Workbench are not two independent applications. They are two\nprojections over the same business reality.**\n\n```text\n                 BUSINESS CONTEXT SPINE\n                         │\n             ┌───────────┴───────────┐\n             │                       │\n       HUMAN PROJECTION        AI PROJECTION\n             │                       │\n             ▼                       ▼\n      HUMAN WORKBENCH          AI WORKBENCH\n             │                       │\n       Personal Memory          AI Continuity\n             │                       │\n             └───────────┬───────────┘\n                         │\n                    SHARED WORK\n                         │\n                         ▼\n                 BUSINESS OUTCOMES\n```\n\nThe Spine is at the top because it is the foundation, not a service the Workbenches call. Each side\nreceives a projection of the same organizational reality and augments it with its own continuity —\nnever with its own truth.\n\n> **The projection changes. The business reality does not.**\n\nThat is one of the strongest architectural principles in the whole concept. The Workbenches are\n**different participant experiences over the same underlying business reality** — not two\napplications independently connected to the platform, and not silos.\n\nThis is why the product cannot be described as two apps sharing a database:\n\n- **A user does not come to SpineWorkspace to access applications.** They come because their work\n  has meaning within a business context.\n- **The AI does not operate because an LLM is available.** It operates because there is business\n  context, business work, business authority and a business outcome to support.\n\n### The invariant\n\n> **Shared business reality; separate participant continuity; governed promotion between scopes.**\n\n---\n\n## 2A. The five views are distinct\n\nTier-0 says business context is the foundation of everything. That must **not** be read as \"one\nprojection for everything.\" The opposite follows: because there is one business reality, the views\nover it can and must be specialised.\n\n> **User view, Platform view, Package view, Pipeline executions and Agentic executions are separate\n> views. They are not one and the same.**\n\n| View | Audience | Answers |\n|---|---|---|\n| **User view** | The person doing business work | What is my work, what does it mean, what should I do next? |\n| **Platform view** | Authorized platform operators | Is the substrate healthy, configured, connected and governed? |\n| **Package view** | Whoever installs, publishes or governs distributable units | What is available, installed, versioned and permitted in this tenant? |\n| **Pipeline executions** | Operators, and audit | Did information enter, normalize and promote correctly? |\n| **Agentic executions** | Operators, governance, and the responsible human | What did Twin or an agent actually do, under what authority, with what evidence? |\n\n### Why they must stay separate\n\nEach has a different audience, a different question and a different failure mode. Collapsing them\nbreaks all five:\n\n- **Pipeline or agentic execution detail in the user view** leaks infrastructure into daily work.\n  Canon §10 and Appendix C item 22 are explicit — infrastructure complexity stays hidden unless the\n  viewer is an authorized platform operator. A user should never need to read a reconciliation ID\n  to finish their work.\n- **User framing in the platform view** hides operational reality from the operator, who needs the\n  substrate, not a curated experience of it.\n- **Pipeline and agentic executions merged into one run log** loses the distinction that matters\n  most: whether information *arrived correctly* versus whether an actor *acted correctly under\n  authority*. These have different owners, different remedies and different accountability.\n- **Package view folded into the platform view** conflates *what is installed and permitted* with\n  *what is currently running*.\n\nThe Platform Console is an operator surface, **not a competing daily work destination** (canon\n§25).\n\n### What keeps them coherent\n\nThe same principle that governs the two Workbenches governs all five:\n\n> **The projection changes. The business reality does not.**\n\nEvery one of these views is a projection over the same Business Context Spine. That is what makes\nthem different views of one system rather than five disconnected tools — and it is why each still\nowes an answer to the Tier-0 test in §1A.\n\n> **Open — needs founder confirmation.** *Package view* is recorded here as the distributable-unit\n> surface — connectors, MCP servers, plugins, marketplace packages: what is available, installed,\n> versioned and permitted in a tenant. If it instead means the monorepo/developer package surface,\n> or something else, this row needs correcting rather than reinterpreting.\n\nHumans and AI operate over the **same** Business Context Spine. They receive **different**\nprojections of it. They retain **separate** continuity. Nothing crosses between continuity scopes\nexcept by governed promotion.\n\n---\n\n## 3. Canonical vocabulary\n\nOne meaning per term. Where the codebase currently uses a term differently, that is a gap\nrecorded in [`17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md`](17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md) — not a second definition.\n\n| Term | Definition |\n|---|---|\n| **SpineWorkspace** | The product. The workspace where humans and AI work on shared business context. |\n| **IntegrateWise** | The company, and the infrastructure platform beneath SpineWorkspace. |\n| **Human Workbench** | The primary human operating experience. |\n| **AI Workbench** | The AI operating environment over the same Business Context Spine. |\n| **Twin** | The human-facing contextual AI coworker, operating **inside** the AI Workbench. Twin *is not* the AI Workbench. |\n| **Spine Agents** | Governed digital employees operating within the business context, carrying identity, authority, memory namespace and capabilities. |\n| **Business Context / Organizational Memory** | The shared organizational reality and durable knowledge. |\n| **Personal Contextual Memory** | The human's private continuity. |\n| **AI Continuity Memory** | AI's own continuing working memory. |\n| **Business Context Spine** | The shared contextual substrate holding truth, work, events, relationships, decisions, evidence and organizational memory. |\n| **Shared Work State** | The medium through which Twin, Spine Agents and humans coordinate — not agent-to-agent re-explanation. |\n| **Capability Fabric** | How an intent *could* be performed. |\n| **Governance** | Whether it *may* be performed, and by whose authority. |\n| **Hermes** | Reliable coordination of approved execution. |\n| **Projection Engine** | The context → workspace compiler. |\n| **Continuity Pipeline** | Outcome back to verified organizational state. |\n\n### Drift watch — terms that keep reappearing from source material\n\n`Define-IntegrateWise-Spine.md` and material derived from it is **supporting evidence** (precedence\nlevel 4), not canon. It carries three variants that must not be absorbed:\n\n| Appears as | Canonical form | Why |\n|---|---|---|\n| \"Spine Workspace\" (two words) | **SpineWorkspace** | Founder Canon Appendix C item 1 fixes the product brand. Two-word form appears **zero** times in the Founder Canon. |\n| \"Twin AI Memory\" | **AI Continuity Memory** | Founder Canon §32. §31A explicitly supersedes the older broad \"Twin Memory\" description by splitting Personal Contextual Memory and AI Continuity Memory. |\n| `Human Workbench ↔ Twin ↔ Specialist agents` | Twin and Spine Agents operate **inside the AI Workbench** | Omitting the AI Workbench reinstates Twin-as-environment, superseded by [ADR-2026-08-31-01](adr/ADR-2026-08-31-01-ai-workbench-supersedes-twin-workbench.md). |\n\n### Terms deliberately not carried forward\n\n| Retired term | Disposition |\n|---|---|\n| **Twin Workbench** | Superseded by **AI Workbench**. Twin is an actor within it, not the environment itself. See [ADR-2026-08-31-01](adr/ADR-2026-08-31-01-ai-workbench-supersedes-twin-workbench.md). |\n| **Coworker** | **Retired, absorbed into Twin.** It appeared as a numbered architectural layer in the superseded Product Manual (layer 9) and as a defined term in the Framing Lock (§9). The Founder Canon uses \"coworker\" only as a common noun describing Twin — *\"Twin is the human-facing contextual AI coworker operating within the AI Workbench\"* — and Appendix C item 5 names the human-AI interface as **Twin**, with no Coworker beside it. Not a separate concept and not a second orchestration authority. |\n| **AI Orchestrator** (as a monolith) | Retired. Responsibilities stay separated across Twin, model routing, ADK, agents, Capability Fabric, Governance and Hermes. |\n| **\"Spine database\"** as the product definition | Retired. The Spine is a continuity substrate, not a database product. |\n| **Provider success as final truth** | Retired. Execution closes only after verification and reconciliation. |\n| **MCP as the core data plane** | Retired. MCP is one capability transport; the Projection API is the Workbench data plane. |\n| **Continuity Bridge as the full product** | Retired. It is the distribution/access boundary for external AI surfaces. |\n| **A blank, manually-built workspace as onboarding** | Retired. Onboarding goes from blank state to useful work. |\n\n### The dual-workbench context model\n\nBoth Workbenches read the same Business Context and receive different projections plus different\ncontinuity augmentation. This is the mechanism behind the invariant.\n\n```text\nHuman Active Context           AI Active Context\n=                              =\nBusiness Context Projection    Business Context Projection\n+ Personal Contextual Memory   + AI Continuity Memory\n+ Current Work                 + Current Objective\n+ Current Interaction Context  + Current Work State\n+ Authorized Knowledge/        + Evidence\n  Evidence                     + Authority Envelope\n+ Policy                       + Available Capabilities\n+ Capabilities                 + Agent Runtime State\n```\n\nThis is why the two sides can collaborate without collapsing privacy, inference and organizational\ntruth into one memory store.\n\n### The constitutional memory rule\n\n```text\nUser thought  ≠  AI inference  ≠  Cache content  ≠  Organizational truth\n```\n\n**Personal thought is not organizational truth. AI inference is not organizational truth. Cache\ncontent is not organizational truth** — until a governed process promotes and records it with\nprovenance. Spine Cache accelerates access to Spine truth and can be discarded and rebuilt; it is\nnever canonical.\n\nA Personal Contextual Memory item stays personal unless deliberately shared or promoted. An AI\nContinuity Memory item stays AI working continuity unless promoted through the Triage / Governance\n/ write path. Organizational Memory is durable business memory only after the organization accepts\nit into the governed Business Context Spine.\n\n---\n\n## 3A. The four context actions\n\nThe OODA grammar made operable:\n\n```text\nOBSERVE  →  Store in Spine        →  organizational truth\nORIENT   →  Ask your Twin         →  understanding\nDECIDE   →  Assign your Twin      →  proposal / prepared work\nACT      →  Approve               →  governed execution\n```\n\n> **These are not top buttons. They are inbuilt in every action.**\n\nThey are **ambient affordances**, not a toolbar: they appear against a specific owner — a record,\nsection, selection, signal or canvas object — and only where they legitimately apply. Availability\nis a governed, per-context decision (`available` / `hidden` / `disabled` / `already canonical`)\ncarrying a readable reason, never a global on/off.\n\nThis is why OODA stays internal. The user performs natural work actions; the interface never\nexposes four literal global controls.\n\n**Twin does not own ACT.** The human owns consequential authority. Twin can prepare the action, the\ncapability layer can execute it, and Governance decides whether approval is required — but\naccountability stays legible.\n\nEvery one of the four routes through the governed path:\n\n```text\nIntent → Twin Proposal → Capability Resolution → Policy Check\n      → Approval (if required) → Execution → Provider Acceptance\n      → Reconciliation → Spine Update\n```\n\nSee [ADR-2026-09-01-01](adr/ADR-2026-09-01-01-context-actions-are-ambient.md).\n\n---\n\n## 4. Human–AI work loop\n\n```text\nOrganization Intent → Goals / KPIs → Business Context → Work → Human + AI\n  → Decision / Proposal → Governed Action → Outcome → Verification\n  → Reconciliation → Memory / Continuity → Next Work\n```\n\nHumans remain responsible for consequential business decisions. AI reduces context assembly,\nrepetitive work and context switching — operating as a capable digital teammate, never an\nindependent authority.\n\nExecution is **not** complete because a provider returned success. It closes only after\nre-ingestion → verification → reconciliation → governed Spine update → rehydration.\n\n---\n\n## 4A. Actors and authority\n\nEvery actor has a bounded responsibility. The constitutional split:\n\n> **Humans own why, priorities, judgment, authority and accountability. Agents own context\n> assembly, preparation, bounded execution, monitoring and continuity.**\n\nHumans are **not** reduced to approval buttons. They remain the accountable organizational actors.\n\n| Humans own | Meaning |\n|---|---|\n| **Intent** | Goals, desired outcomes, priorities, what matters now. |\n| **Judgment** | Ambiguity, trade-offs, relationships, ethics, business meaning. |\n| **Authority** | Approve, deny, delegate or escalate consequential actions. |\n| **Accountability** | Responsibility for customer, financial, legal, people, strategic and operational decisions. |\n| **Exceptions** | Situations where policy, data, automation or prior assumptions do not fit reality. |\n| **Truth correction** | Challenge inaccurate context, validate material facts, promote information into organizational truth through governed process. |\n| **Leadership** | Direction for human-agent teams, and deciding what should *not* be automated. |\n\n| Agents own | Meaning |\n|---|---|\n| **Context assembly** | Collect and organize relevant records, history, relationships, evidence, current work. |\n| **Research and synthesis** | Find, compare, summarize, surface risks and opportunities. |\n| **Preparation** | Draft messages, plans, updates, briefs, tasks, decision material. |\n| **Monitoring** | Watch for changes, deadlines, health signals, exceptions, missing information. |\n| **Task decomposition** | Break an objective into bounded steps, dependencies, handoffs, required evidence. |\n| **Routine execution** | Permitted low-risk work through approved capabilities. |\n| **Verification support** | Gather evidence, compare expected vs observed, detect discrepancies, prepare reconciliation. |\n| **Continuity** | Preserve AI-side working memory so tasks continue across sessions, models and handoffs. |\n\n### What agents must never do\n\nAn agent cannot grant itself access, decide its own authority, convert assumptions into official\ntruth, or bypass required human approval. Every agent acts with an identity, tenant scope, assigned\npurpose, defined capabilities, policy boundary, delegated authority and audit trail.\n\n### The runtime authority model\n\nResponsibility is deliberately split, so that no single component owns context, memory,\npermissions, tools, decision-making, execution and truth at once:\n\n| Question | Responsible actor |\n|---|---|\n| What is the business reality? | Business Contextual Spine |\n| What does this mean, and what should we do? | Human with Twin |\n| How can the task be performed? | Capability Fabric |\n| May it be performed, and under whose authority? | Governance, and a human approver when required |\n| How is approved work coordinated reliably? | Hermes |\n| Did the real world actually change? | Sync, verification, reconciliation |\n| What should the organization retain? | Governed Spine writeback |\n\nThis separation is what prevents an \"AI orchestrator\" from becoming an uncontrolled god-service —\nthe pattern canon §3 retires by name.\n\n---\n\n## 5. Platform stack\n\nWhat IntegrateWise provides beneath the product:\n\n```text\nIW One Auth\n    ↓\nEcosystem Connectivity\n    ↓\nDiscovery\n    ↓\nActivation\n    ↓\nIngestion / Normalization\n    ↓\nBusiness Context Spine\n    ↓\nProjection / Context Assembly\n    ↓\nHuman Workbench + AI Workbench\n    ↓\nCapability Fabric\n    ↓\nGovernance\n    ↓\nHermes / Execution\n    ↓\nSource Systems\n    ↓\nRe-ingestion\n    ↓\nVerification\n    ↓\nReconciliation\n    ↓\nSpine / Continuity / Next Work\n```\n\n### Standing separations\n\nThese are load-bearing and must not be collapsed:\n\n- **Capability Fabric → Governance → Hermes.** Capability states what *could* be done and holds\n  no authority. Governance decides. Hermes coordinates approved execution and reads its authority\n  from Governance, never from itself. *This separation is already substantially correct in the\n  codebase and should not be redesigned.*\n- **Governance outcomes are exactly four** (canon §19): `ALLOW`, `DENY`, `REQUIRE APPROVAL`,\n  `DELEGATE / ALLOW WITH BOUNDED AUTHORITY`. `ALLOW` is an explicit bounded policy decision, not a\n  bypass; consequential external mutations default to `REQUIRE APPROVAL`. The runtime proposal/\n  ledger contract carries the three-way `GovernanceDecisionOutcome` vocabulary\n  (`allowed | approval_required | blocked`); bounded delegation resolves at the Governance boundary\n  into one of the three per invocation.\n- **Hermes never performs an arbitrary canonical Spine write.** It produces execution results,\n  evidence and outcome events. Sync, verification, reconciliation and the governed writer commit\n  canonical truth.\n- **No central orchestrator.** Responsibilities stay separated across Twin, model routing, ADK,\n  agents, Capability Fabric, Governance and Hermes. A single central brain is invalid.\n- **MCP is one capability transport**, not the data plane. The Adaptive Spine is truth; the\n  Projection API is the Workbench data plane.\n\n---\n\n## 6. Experience first\n\nThe user experiences relevant work, assembled context, evidence, recommendations, collaboration,\ndecisions, approvals and verified outcomes.\n\nThe platform internally handles projection, UI composition, AI context assembly, OODA, model\nrouting, ADK, agent runtime, MCP, Capability Fabric, Governance, Hermes, execution, sync,\nverification and reconciliation.\n\n**The architecture is complex so the experience does not have to be.** OODA, the UI composition\npipeline and the AI context composition pipeline are internal mechanisms — real, first-class, and\ninvisible to the user.\n\n\"One channel\" means **one coordination fabric across many surfaces** — not one chat interface.\n\n---\n\n## 7. Supersession map\n\nWhat this document changes relative to earlier repository artifacts:\n\n| Area | Earlier position | Canon position |\n|---|---|---|\n| AI operating environment | \"Twin Workbench\" — per-user, Twin-owned | **AI Workbench** — hosts Twin *and* Spine Agents |\n| Continuity scopes | Two: personal, org | **Three:** Business/Organizational, Personal Contextual, AI Continuity |\n| Personal context | Not a plane; a memory namespace | **Personal Contextual Spine** — a first-class plane |\n| Spine Agents | Named; effectively domain agents | First-class governed actors with identity, authority, memory namespace, capabilities, shared Work state |\n| Agent cooperation | Unspecified | Through **shared Work / context / evidence state** |\n| Primary product identity | IntegrateWise Workbench | **SpineWorkspace** |\n| Coworker | Numbered architectural layer | **Retired** — absent from the v6.0.0 Canonical Vocabulary (§32); the governed-co-worker role belongs to Twin and Spine Agents over shared Work. Repository: `CoworkerAgent` renamed `CollaborationLogAgent` (log/evidence role, not an authority) |\n\nEverything in the Aug 1 freeze not listed above is **retained** as the implementation baseline.\n\n---\n\n## 8. Related documents\n\n- [`README.md`](README.md) — the CANON / ALIGNMENT doctrine and source precedence\n- [`17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md`](17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md) — nine planes mapped to real code\n- [`17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md`](17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md) — where the repository does not yet match this document\n- [`adr/`](adr/) — the decisions that produced this document\n"}