{"slug":"internal/architecture/master-architecture","title":"IntegrateWise — SpineWorkspace Product and Platform Architecture","section":"internal","sectionLabel":"Internal","status":"unclassified","type":"long-form","path":"internal/architecture/master-architecture.md","bytes":215628,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"<!-- DOCUMENT CLASS: INTERNAL | SOURCE: 02_INTEGRATEWISE_SPINEWORKSPACE_ARCHITECTURE_v3.2.md -->\n<!-- STATUS: SUPerseded by Founder Canon for product/experience semantics -->\n<!-- retained for implementation contracts and technical architecture details -->\n\n# IntegrateWise — SpineWorkspace Product and Platform Architecture\n\n> **This document is superseded by the Founder Canon for product framing, terminology and experience architecture.** See `docs/canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md` (31 August 2026) as the authoritative source. This file is retained for implementation contracts, technical architecture details and historical reference.\n\n**Status:** RETAINED for technical contracts · Superseded for product framing  \n**Version:** 3.2 (human–AI work coordination, contextual business memory, Workbench IA and Bridge architecture)  \n**Date:** 2026-08-25 · doctrine updated; Part III remains a dated repository snapshot at commit `2187bc91`  \n**Supersedes:** every other document in `docs/architecture/` for technical contracts. See [Appendix L](#appendix-l--document-disposition).  \n**Superseded by:** `docs/canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md` for product/experience semantics.\n\n---\n\n## How to read this document\n\nThis is the primary architecture document. [`SPEC_AMENDMENTS_v1.md`](SPEC_AMENDMENTS_v1.md)\nis its one canonical amendment and supersedes conflicting statements in this document.\nTogether they win over `AGENTS.md`, `CLAUDE.md`, and any file in `docs/architecture/` not\nlisted as _Retained_ in Appendix L.\n\nThree parts, read in order or entered at any heading:\n\n| Part                | Answers                                                     | Changes                                                        |\n| ------------------- | ----------------------------------------------------------- | -------------------------------------------------------------- |\n| **I — Foundations** | Why the system is shaped this way                           | Rarely. A change here is a major version.                      |\n| **II — The System** | What each part owns and where the boundaries are            | Slowly. Implementations improve; responsibilities do not move. |\n| **III — Reality**   | What is actually built, what has drifted, what is undecided | Continuously. Dated evidence, not aspiration.                  |\n| **Appendices**      | Exact tables, routes, bindings, contracts                   | With the code.                                                 |\n\n### Reader map\n\nUse this document as the single map; follow retained specifications only when a team needs\nthe lower-level contract named here.\n\n| Reader | Read first | Then use |\n| --- | --- | --- |\n| Product and go-to-market | §1–§5, §11–§13, §16 | The product/package boundary, marketplace roles and verified-versus-intended labels in Part III |\n| Application engineering | §7–§12 | Projection, context, capability and approval contracts; Appendices C–H for code entry points |\n| Platform and data engineering | §6–§10, §14–§15 | Store ownership, Flow D before A/B/C, ingestion, promotion, reconciliation and runtime profiles |\n| Security and compliance | §2.2, §8.2a, §10, §14, §17 | Tenant/consent boundary, least privilege, approval tokens, provenance, audit and release isolation |\n| Operations and release | §17–§22 | Verified deployment surface, drift register, stop-ship invariants and unresolved decisions |\n\n### Evidence labels\n\nStatements in Parts I and II are the **governing doctrine / intended target** unless marked\notherwise. Part III remains the repository-grounded implementation record from 2026-08-13 at commit `2187bc91`; it is historical evidence and must not be mistaken for the current doctrine.\nThe following labels are used in diagrams and matrices:\n\n| Label | Meaning |\n| --- | --- |\n| **LAW** | Non-negotiable product or security invariant. Implementation must conform. |\n| **VERIFIED** | Present in code, configuration or tests in this checkout. This does not by itself prove live deployment. |\n| **INTENDED** | Required target contract, retained even when the complete runtime is not yet wired. |\n| **DRIFT** | Present implementation contradicts or bypasses the target contract. |\n| **DECISION** | The repository cannot safely settle the choice; named owner input is required. |\n\n### Non-negotiable laws, in one page\n\n0. **Tier-0: Business Context Law.** **Business Context is the semantic foundation of SpineWorkspace.** It connects organizational business reality to Work, Humans, AI, Agents, Memory, Knowledge, Capabilities, Communication, Decisions, Governance, Execution, Evidence, Continuity and Outcomes. Without Business Context, SpineWorkspace has no meaning. The Spine gives work its business context. If a feature cannot explain how it relates to Business Context, Work, or a Business Outcome, it does not yet have a meaningful place in SpineWorkspace.\n1. **Company/Product Law.** **IntegrateWise is the company. SpineWorkspace is the product.**\n   IntegrateWise provides the platform substrate; SpineWorkspace is what the customer uses to\n   coordinate human–AI work.\n2. **Organization-to-Work Law.** The organization defines goals, objectives, needs and\n   standards. Those objectives cascade into domain- and role-aligned work without creating\n   departmental copies of truth.\n3. **Spine Fabric Law.** The Business Context Spine is THE semantic foundation. It IS the organization's memory — the connected representation of entities, work, state, relationships, events, decisions, evidence, provenance and memory. Without it, nothing in SpineWorkspace has meaning. Personal Contextual Memory and AI Continuity Memory are working continuities that serve Business Context; they are not equal peers to it.\n4. **Canonical Truth Law.** The canonical Spine is owned and governed by the organization.\n   AI does not read or write canonical storage directly.\n5. **AI Sandbox Law.** AI operates only on a bounded, tenant-, user-, role-, task- and\n   policy-scoped operational sandbox derived from Spine Fabric and current execution context.\n   Sandbox state is working material, not canonical truth.\n6. **Projection Law.** Humans see shared organizational truth through role-, domain-,\n   responsibility- and permission-aware projections. A projection is a view of shared truth,\n   never a new source of truth.\n7. **Work Law.** Work, not the task or application, is the primary unit of coordination. A\n   piece of work may contain tasks, decisions, communications, approvals, research, execution,\n   exceptions and outcomes across people, AI and systems.\n8. **Work Allocation Law.** SpineWorkspace continuously determines who or what should perform\n   each part of work — human, Twin, agent, system or human + AI — using capability,\n   responsibility, authority, risk, context, urgency, cost and need.\n9. **Twin Law.** Each user receives a bounded Twin as their AI work partner within the AI Workbench. The Twin reasons, coordinates, delegates and monitors work over Business Context, but never owns canonical truth or authority. The AI Workbench is the machine-side operating environment; Twin is the human-facing cognitive participant within it.\n10. **Coworker Law.** The Coworker is the contextual companion that observes the user's active\n    work surface and interaction, assembles relevant context, supports communication and keeps\n    the user's work and Twin context aligned without becoming a second authority.\n11. **Capability Law.** A capability describes what can be done; the Execution Fabric determines\n    how it is performed. APIs, MCP, workflows, agents and provider tools are implementations,\n    not business capabilities themselves.\n12. **Governance Law.** Authority, policy, risk, evidence, approval and accountability are\n    evaluated before consequential mutation. Confidence never grants authority.\n13. **Reconciliation Law.** External execution is not complete when a provider returns success.\n    The observed result must be re-ingested, reconciled and reflected back into the governed\n    operational model.\n14. **Continuity Law.** Work remains coherent across time, people, tools, AI hosts and domains\n    through bounded continuity, not through unrestricted sharing of memory or credentials.\n15. **Platform Law.** IntegrateWise's platform is broad underneath and narrow at the product\n    surface. It supplies identity, connectivity, AI, execution, communication, governance,\n    infrastructure and metering; it does not become a second Workbench.\n\n### System boundary — target contract\n\n```mermaid\nflowchart TD\n  Org[\"Organization: goals · objectives · needs · standards\"] --> WG[\"Work Graph: goals → work → entities → dependencies → outcomes\"]\n  Systems[\"CRM · ERP · Email · Chat · Docs · BI · Billing · other systems\"] --> Conn[\"IntegrateWise Connectivity\"]\n  Conn --> Spine[\"SPINE FABRIC<br/>Contextual Business Memory + Operational Continuity\"]\n  Org --> Spine\n  Spine --> Proj[\"Role / Domain / Responsibility Projection\"]\n  Proj --> WB[\"USER WORKBENCH<br/>Human operational surface\"]\n  Spine --> Sandbox[\"AI OPERATIONAL SANDBOX<br/>bounded, task-scoped, policy-filtered\"]\n  User[\"Human\"] --> WB\n  WB --> Work[\"Shared Work\"]\n  Sandbox --> Twin[\"USER TWIN<br/>AI work partner\"]\n  Twin --> Work\n  Coworker[\"COWORKER<br/>context + communication companion\"] --> WB\n  Coworker --> Sandbox\n  Work --> Allocate[\"WORK ALLOCATION<br/>Who/what should do what now?\"]\n  Allocate --> Human[\"Human\"]\n  Allocate --> AI[\"Twin / Agent\"]\n  Allocate --> System[\"System / Workflow\"]\n  AI --> Cap[\"Capability Fabric\"]\n  Human --> Cap\n  Cap --> Gov[\"Governance\"]\n  Gov --> Exec[\"Execution Fabric<br/>MCP · APIs · workflows · agents · ADK\"]\n  Exec --> Systems\n  Systems --> Reconcile[\"Outcome + Reconciliation\"]\n  Reconcile --> Spine\n  Spine --> Proj\n  Spine -. \"never direct\" .-> Twin\n  Platform[\"IntegrateWise Platform<br/>Identity · Connectivity · AI · Execution · Communication · Governance · Infrastructure · Metering\"] -. \"substrate / control\" .-> Conn\n  Platform -.-> Gov\n  Platform -.-> Exec\n```\n\nThe central product loop is:\n\n```text\nORGANIZATIONAL GOAL / NEED\n          ↓\n       WORK GRAPH\n          ↓\n   SHARED BUSINESS CONTEXT\n          ↓\n    CONTEXT ASSEMBLY\n          ↓\n     WORK ALLOCATION\n          ↓\n     HUMAN + AI WORK\n          ↓\n        DECIDE\n          ↓\n       EXECUTE\n          ↓\n       VERIFY\n          ↓\n    RECONCILE OUTCOME\n          ↓\n   UPDATE CONTINUITY\n          ↓\n        NEXT WORK\n```\n\nThe platform runtime is subordinate to this product loop. Configuration, ingestion, projection,\ncapability resolution, governance, execution, reconciliation and promotion exist to make the\nhuman–AI work loop reliable.\n\n**A note on what this document is for.** IntegrateWise accumulated 94 architecture\ndocuments totalling 265,000 words. Sixteen were declared canonical. Six had \"canonical\" in\nthe filename. That is not a documentation problem — it is an architectural risk, because a\nsystem whose architecture cannot be held in one head is a system whose invariants will be\nviolated by accident. The purpose of consolidating is to make the invariants _cheap to\nknow_.\n\n---\n\n# Part I — Foundations\n\n## 1. The problem this architecture solves\n\n### 1.0 Company, product and differentiator\n\n| Name | Canonical meaning | Never use it to mean |\n| --- | --- | --- |\n| **IntegrateWise** | The company and platform builder/operator | The customer-facing product, a workbench, a database or an AI agent |\n| **SpineWorkspace** | The customer product: a human–AI work coordination environment grounded in Spine Fabric | The company, a raw database viewer, an integration-only product or an autonomous agent platform |\n| **Spine Fabric** | The contextual business memory and operational continuity substrate inside SpineWorkspace | A single database, unrestricted data lake, AI memory store or public MCP |\n| **Workbench** | The human-facing operational surface where role-specific work is understood and progressed | A separate departmental product |\n| **Twin** | The bounded AI work partner assigned to a user | A generic chatbot or autonomous authority |\n| **Coworker** | The contextual companion that assembles active-screen context and supports communication between human, Twin and systems | A second Twin, source-of-truth service or execution authority |\n| **AI Operational Sandbox** | The bounded working dataset exposed to AI for a specific user/work/task | Canonical Spine, organizational truth or a write target |\n| **Platform** | The IntegrateWise substrate providing identity, connectivity, AI, execution, communication, governance, infrastructure and operational metering | A second customer Workbench |\n\n### 1.1 The fundamental business problem\n\nOrganizations do not lack software. They lack **continuity of work across software**.\nBusiness needs and objectives are distributed across people, departments, applications,\ncommunication channels, documents, workflows and increasingly multiple AI systems. Each system\ncontains a partial operational view. Humans compensate by becoming the integration layer.\n\nAI introduces a second, deeper problem:\n\n> **Given the objective, context, capability, responsibility, authority, risk and current state,\n> who or what should perform each part of the work?**\n\nThe industry is moving from task automation to a work-allocation problem. The meaningful unit is\nnot \"what can AI automate?\" but:\n\n> **How should humans and AI share the work required to achieve the organization's goals?**\n\nSpineWorkspace exists to solve that problem.\n\n### 1.2 Organizational model: goals become coordinated work\n\nThe organization is the top-level source of intent:\n\n```text\nORGANIZATION\n   │\n   ├── Goals\n   ├── Objectives\n   ├── Needs\n   ├── Standards\n   ├── Policies\n   └── Operating priorities\n            │\n            ▼\n       BUSINESS WORK\n            │\n      ┌─────┼───────────┐\n      ▼     ▼           ▼\n   Domain  Role       Responsibility\n      │     │           │\n      └─────┼───────────┘\n            ▼\n       INDIVIDUAL WORK\n            │\n            ▼\n      HUMAN + AI SHARING\n            │\n            ▼\n         OUTCOMES\n            │\n            ▼\n      BUSINESS PERFORMANCE\n```\n\nThe same organizational data is therefore available to many participants through different\nprojections. Role, department, domain and responsibility determine **what is relevant and what\nmay be done**, not which copy of the data exists.\n\n### 1.3 The Work Graph\n\nThe **Work Graph** is the connected representation of organizational work. It relates:\n\n- organizational goals and objectives\n- domains, teams and responsibilities\n- people and roles\n- work and tasks\n- business entities\n- dependencies and blockers\n- decisions and approvals\n- capabilities and assignments\n- human and AI participants\n- communications and evidence\n- executions and outcomes\n\nA task is a component of work. A work item may span multiple systems, people, agents and\ncommunications while remaining one continuity thread.\n\n### 1.4 The architectural bet\n\nThe response is not to replace the systems where business work already happens, nor to attach a\nseparate assistant to every silo. IntegrateWise provides the substrate that connects those\nsystems into Spine Fabric. SpineWorkspace then projects the relevant organizational context into\nthe human Workbench and a bounded AI sandbox so humans and AI can operate on the same work without\nsharing the same authority.\n\nThis creates a strict separation:\n\n```text\nORGANIZATIONAL TRUTH\n        │\n        ▼\n   SPINE FABRIC\n        │\n        ├──────────────► Human Projection ──► Workbench\n        │\n        └──────────────► AI Operational Sandbox ──► Twin / Agents\n\nHuman and AI share WORK and CONTEXT.\nThey do not share unrestricted authority.\n```\n\n### 1.5 The value chain\n\n```text\nShared Context\n      +\nHuman Capability\n      +\nAI Capability\n      +\nCorrect Work Allocation\n      +\nGoverned Execution\n      +\nOperational Continuity\n      ↓\nMore Work Completed\n      +\nShorter Cycle Time\n      +\nHigher Consistency\n      +\nLower Operational Waste\n      +\nBetter Decisions\n      ↓\nImproved Business Outcomes\n      ↓\nPotentially Higher Profitability\n```\n\nProfitability is an outcome, not a product guarantee. SpineWorkspace improves the operating\nconditions that can produce it.\n\n### 1.6 Four failure modes\n\n| Failure | Root cause | SpineWorkspace response |\n| --- | --- | --- |\n| **Fragmentation** | Work and context scattered across systems | **Spine Fabric + Connectivity** |\n| **Human API** | People manually bridge systems and explain context | **Workbench + Coworker + Capability Fabric** |\n| **AI amnesia / divergence** | AI starts from a partial or stale view | **Context Assembly + AI Operational Sandbox** |\n| **Babysitting** | AI can suggest but cannot carry governed work to completion | **Work Allocation + Governance + Execution Fabric + Reconciliation** |\n\n## 1.1 Contextual business memory is the product foundation\n\n**Spine Fabric is the core contextual business memory layer of SpineWorkspace.** It converges fragmented operational context from the systems an organization already uses, preserves provenance and continuity, and provides governed projections for humans and AI.\n\nThe organization has one canonical operational reality. Users see role/domain/responsibility projections of that reality. AI does not own or directly mutate canonical Spine; it operates in the bounded Operational Sandbox.\n\n```text\nOrganization → Goals / Needs → Work\n                         ↓\n                    Connectivity\n                         ↓\n                  Spine Fabric\n                    /       \\\n          Canonical Spine   Operational Sandbox\n                 |                 |\n          Projections           Twin / Agents\n                 |                 |\n          User Workbench     Twin Workbench\n                 \\                 /\n                  ------ Shared Work ------\n                           ↓\n                      Execution\n                           ↓\n                      Reconcile\n                           ↓\n                         Spine\n```\n\n## 1.2 Triage and organizational memory\n\nTriage is the cognitive intake boundary for Flow C. It classifies, links, evaluates conflicts and stages candidates. **Triage never becomes the canonical writer.** Organizational memory is produced only through the governed promotion path.\n\nThe authoritative sequence is:\n\n`evidence → triage → staging → human/governed review → promotion → organizational memory → projection`\n\nSee `TRIAGE_ORG_MEMORY_CANONICAL.md` for the detailed contract.\n\n## 2. Five commitments, and what each costs\n\nEvery durable property of this system follows from five decisions. Each is a genuine\ntrade-off, taken deliberately.\n\n### 2.1 Truth lives outside the applications\n\nCanonical operational state is assembled from connected systems into a store the\norganisation owns, with provenance on every field.\n\n**Buys:** cross-system questions become answerable; AI reasoning has ground to stand on;\nthe switching cost is accumulated verified memory rather than data hostage-taking.\n**Costs:** an ingestion and reconciliation burden that never ends, and a permanent\nconsistency question — the Spine is _eventually_ consistent with source systems, never\ninstantaneously. Every projection therefore carries freshness state, and \"unknown\" is a\nlegitimate answer the system must be able to give.\n\n### 2.2 Governance is architecture, not policy\n\nProposal → approval → execution → audit is the physics of the system. No approval token,\nno external mutation. This is not a setting, a middleware, or a default that can be turned\noff; the execution path has no branch that skips it.\n\n**Buys:** AI can be pointed at consequential work, because it structurally cannot act\nalone. Regulation moves toward this posture, not away from it.\n**Costs:** latency and friction on every consequential action, and a permanent design\ntension with \"just automate it.\" The tension is the product. Where it becomes intolerable,\nthe answer is narrower pre-authorised capabilities with thresholds — never a bypass.\n\n### 2.3 Deterministic and adaptive systems are separated\n\nPipelines, synchronisation, normalisation and validation are deterministic. Reasoning,\nplanning, triage and learning are adaptive. They are different runtimes with different\nauthority, and the boundary between them is a hard one.\n\n**Buys:** the parts that must be reproducible are reproducible. An AI failure degrades\nsuggestion quality; it cannot corrupt truth.\n**Costs:** two systems where one might have seemed sufficient, and the discipline to keep\nresisting \"the model can just do the normalisation.\"\n\nThe corollary — **confidence never grants authority** — is the most frequently attacked\ninvariant in the system. A 0.99-confidence proposal and a 0.55-confidence proposal require\nthe identical approval to become real. Confidence describes evidence quality. It is an\ninput to human judgement, never a substitute for it.\n\n### 2.4 One surface, composed per role\n\nThere is one Workbench. Role and department select the operational composition; the\ntenant's activated industry schema supplies vocabulary, fields, relationships and policy\ncontext within that composition. Industry never creates a separate product, separate\ndomain, separate database or separate navigation model.\n\n**Buys:** cross-functional work stays possible — one account, one person, one decision,\nvisible from every relevant angle without copying truth. New roles are configuration.\n**Costs:** the projection layer carries real complexity, and there is constant pressure to\n\"just build a Sales app.\" Yielding once produces the fragmentation the product exists to\nremove.\n\n### 2.5 The Twin is a participant, not an authority\n\nEach user receives one bounded **Twin**. The Twin is the user's AI work partner for the role,\ndomain and responsibilities attached to that user instance. It does not need to be a universal\nenterprise agent. It needs the capabilities, context and domain workspaces required by the user\nit serves.\n\nThe Twin can:\n\n- understand the user's current work\n- assemble and reason over the AI Operational Sandbox\n- decompose work into bounded assignments\n- delegate to domain agents and workflows\n- prepare drafts, analyses and proposals\n- monitor assigned work and dependencies\n- coordinate communications\n- request human decisions and approvals\n- verify outcomes and surface exceptions\n\nThe Twin cannot:\n\n- query canonical Spine storage directly\n- promote its own output to canonical truth\n- change authority or policy\n- bypass Governance\n- silently assume human responsibility\n\nThe trust boundary is structural: **the Twin reasons over a sandbox projection of Spine Fabric,\nnot over canonical storage itself.**\n\n**Buys:** human–AI collaboration inside the work rather than chat beside it, with bounded\nresponsibility and a consistent user-specific AI partner.\n**Costs:** more explicit context assembly and execution plumbing, and less apparent autonomy in\ndemos. The boundary is intentional.\n\n### 2.6 OneAuth → Total Continuity\n\n**One connection per host. Entire ecosystem discovers. No N×M re-connections.**\n\nToday, every host (ChatGPT, Claude, DIA, etc.) requires its own set of OAuth connections.\nIf ChatGPT is connected to 50 apps and Claude is connected to 50 apps, the user must\nauthenticate separately for each host × each app. This is N×M complexity.\n\nIntegrateWise targets this with OneAuth: one identity and consent entry per host that binds\nthe principal to an IntegrateWise tenant, creates or resolves the tenant workspace and its\ntenant-specific Spine schema/profile, then discovers eligible host connections. Discovery\ndoes **not** inherit every host grant automatically. Each projected connector remains subject\nto provider support, grant visibility, consent, tenant binding, RBAC and least privilege.\nWhen a host cannot expose a reusable grant, IntegrateWise must request a normal scoped\nconnection or report the connector unavailable; it must never imply access it does not hold.\n\n```text\nHost A (ChatGPT: 50 apps) → OneAuth → Spine → Discovery → 50 connectors projected\nHost B (Claude: 50 apps)   → Same OneAuth → Same Spine → 50 more connectors projected\nHost C (DIA: 3 apps)       → Same OneAuth → Same Spine → 3 more connectors projected\n\nTotal: 3 hosts, 103 apps, 3 connections (not 309)\n```\n\n**Buys:** eligible connections can be discovered once per host and reused through one tenant\nauthority boundary; Workbench, Twin and permitted agents receive consistent bounded context.\nWork performed in different AI environments can contribute Flow C continuity candidates and\napproved outcomes to the same tenant Spine rather than remaining isolated.\n**Costs:** hosts expose different identity and grant capabilities, so reuse is conditional and\nmust fail closed. The security boundary remains per tenant, principal, connector, scope and\noperation — never merely “the host is trusted.”\n\n## 3. The kernel vocabulary\n\nVersion 3 introduces the terminology required by the human–AI work-coordination model. These\nterms are the architectural primitives; implementation technologies must map into them rather\nthan becoming new product concepts.\n\n| Term | Definition | Owner |\n| --- | --- | --- |\n| **ORGANIZATION** | The tenant-level operating system of goals, needs, standards, policies, domains and responsibilities | Spine / Governance |\n| **GOAL** | A desired organizational result that gives work its purpose | Organization |\n| **WORK** | Coordinated activity moving an objective toward an outcome across humans, AI and systems | SpineWorkspace |\n| **WORK GRAPH** | Connected representation of goals, work, entities, people, dependencies, decisions, capabilities, executions and outcomes | Spine Fabric |\n| **CONTEXT** | The relevant state required to understand current work and choose the next action | Context Assembly |\n| **MEMORY** | Retained interpreted knowledge derived from observations, outcomes and prior work, with provenance and scope | Spine Fabric |\n| **SPINE FABRIC** | Contextual business memory and operational continuity layer holding governed organizational truth and producing bounded projections | Spine Fabric |\n| **PROJECTION** | A role-, domain-, responsibility-, subject- and policy-scoped view of shared Spine Fabric state | Projection Engine |\n| **WORKBENCH** | The human-facing operational surface for understanding, deciding and progressing work | Product |\n| **TWIN** | A user-specific, non-authoritative AI work partner that reasons, coordinates and delegates within its scope | Intelligence |\n| **COWORKER** | A contextual companion that gathers active-surface context and supports communication and continuity between human, Twin and systems | Experience / Continuity |\n| **AI SANDBOX** | Bounded operational working state exposed to AI; never canonical truth and never an unrestricted database surface | Continuity / Gateway |\n| **WORK ALLOCATION** | Continuous determination of who or what should perform each work component | Twin / Governance |\n| **CAPABILITY** | A declared business operation that can be read, derived or mutated through governed execution | Capability Fabric |\n| **GOVERNANCE** | Authority, policy, risk, evidence, approval and accountability determining what may happen | Governance |\n| **EXECUTION FABRIC** | The runtime mechanisms that perform capabilities: workflows, APIs, MCP, agents, ADK and provider tools | Execution |\n| **HERMES** | The orchestration runtime that plans, sequences, tracks and reconciles governed execution | Execution |\n| **RECONCILIATION** | Verification that intended work and observed external state agree, or are explicitly unresolved | Sync / Spine |\n| **CONTINUITY** | Preservation and bounded transfer of relevant work context across time, people, systems and AI environments | Bridge |\n| **OUTCOME** | The observed result of work that can close a work item and become new governed organizational state | Spine |\n\nThe key distinctions are:\n\n```text\nWHAT ARE WE TRYING TO ACHIEVE?     → GOAL\nWHAT NEEDS TO HAPPEN?               → WORK\nHOW IS IT CONNECTED?               → WORK GRAPH\nWHAT DOES THE HUMAN/AI NEED NOW?   → CONTEXT\nWHO SHOULD DO IT?                  → WORK ALLOCATION\nWHAT CAN BE DONE?                  → CAPABILITY\nMAY IT BE DONE?                    → GOVERNANCE\nHOW IS IT DONE?                    → EXECUTION FABRIC\nDID IT ACTUALLY HAPPEN?            → RECONCILIATION\nWHAT DID WE LEARN / RETAIN?        → MEMORY\nHOW DOES IT REMAIN COHERENT?       → CONTINUITY\n```\n\n## 4. The architectural laws\n\n| # | Law | Statement | What it prevents |\n| --- | --- | --- | --- |\n| 1 | **Company/Product Law** | IntegrateWise is the company; SpineWorkspace is the product | Naming and ownership ambiguity |\n| 2 | **Organization-to-Work Law** | Goals and needs cascade into work; work remains connected across roles and domains | Departmental silos and orphan tasks |\n| 3 | **Spine Fabric Law** | Contextual business memory is the shared continuity substrate | Rebuilding context in every application |\n| 4 | **Canonical Separation Law** | AI never receives direct canonical Spine access | AI becoming a source-of-truth authority |\n| 5 | **Sandbox Law** | AI operates only on bounded operational sandbox state | Unrestricted AI access to organizational truth |\n| 6 | **Projection Law** | Role/domain projections are views of shared truth, not copies | Department-specific databases and duplicated truth |\n| 7 | **Work Allocation Law** | Work is continuously divided according to capability, responsibility, authority, risk and need | Blind automation or manual-only execution |\n| 8 | **Twin Law** | Every user gets a bounded AI work partner within the user's role/domain scope | One universal autonomous agent owning the enterprise |\n| 9 | **Coworker Law** | Active-screen context and communication are assembled without creating a second authority | Context loss and duplicate AI surfaces |\n| 10 | **Capability Law** | Capability defines what can be done; implementation defines how | Tool-specific product coupling |\n| 11 | **Governance Law** | Consequential effects require policy and the applicable authority/approval | Confidence-based or client-side authorization |\n| 12 | **Execution Law** | All external effects traverse the governed Execution Fabric | Provider/API bypasses |\n| 13 | **Reconciliation Law** | An action is not complete until its outcome is observed and reconciled | False success and duplicate execution |\n| 14 | **Continuity Law** | Context follows work across time and boundaries, subject to policy | Re-briefing and fragmented AI sessions |\n| 15 | **Product–Platform Law** | Broad underneath; narrow at the surface | Platform implementation vocabulary leaking into product UX |\n\nThese laws replace the prior eight-law vocabulary lock. This is a **major architecture revision**\nbecause the primary unit is now explicitly work allocation between humans and AI, with Spine Fabric\nas the contextual business memory foundation.\n\n## 5. What is frozen, and what may change\n\n| Change                     | Version impact |\n| -------------------------- | -------------- |\n| New kernel concept         | Major          |\n| New runtime step           | Major          |\n| New doctrine or law        | Minor          |\n| New capability type        | Minor          |\n| Implementation improvement | Patch          |\n| New projection             | Patch          |\n| New role composition       | Patch          |\n\nFrozen: the product doctrine, the kernel vocabulary, the organizational-to-work model, the Spine Fabric trust boundary, the human/AI work-allocation model, the runtime sequence, the entity contract, and the Capability/Execution Fabric model.\n\nNot frozen: every implementation detail beneath them. The runtime sequence is an ordering\nof responsibilities, not an instruction for how many services implement it. Merging or\nsplitting services is a patch as long as the ordering and the ownership hold.\n\n---\n\n# Part II — The System\n\n## 6. The system planes\n\nThe architecture is best understood as five cooperating planes. The planes separate the human\nexperience, contextual truth, adaptive intelligence, governed execution and platform substrate.\n\n```text\n┌──────────────────────────────────────────────────────────────────┐\n│ EXPERIENCE                                                        │\n│ User Workbench · Twin Workbench · Coworker · role/domain views   │\n├──────────────────────────────────────────────────────────────────┤\n│ CONTEXT                                                           │\n│ Spine Fabric · Projections · Context Assembly · AI Sandbox       │\n├──────────────────────────────────────────────────────────────────┤\n│ INTELLIGENCE                                                      │\n│ Twin · Domain Agents · Reasoning · Planning · Learning           │\n│ adaptive, non-authoritative                                      │\n├──────────────────────────────────────────────────────────────────┤\n│ EXECUTION                                                         │\n│ Capability Fabric · Governance · Execution Fabric · Hermes       │\n│ governed effects only                                            │\n├──────────────────────────────────────────────────────────────────┤\n│ INTEGRATEWISE PLATFORM SUBSTRATE                                  │\n│ Identity · Connectivity · Communication · Infrastructure        │\n│ tenancy · security · observability · metering                     │\n└──────────────────────────────────────────────────────────────────┘\n```\n\n**Spine Fabric is the contextual center.** It is not merely a foundation storage plane. It is\nthe business-memory and continuity substrate from which human projections and AI sandbox context\nare derived.\n\nThe **Experience plane** is where the human works. The User Workbench and Twin Workbench are\nseparate surfaces because the human operational view and the AI agentic working environment have\ndifferent interaction grammars. The Twin remains associated with the user and their work rather\nthan becoming an enterprise-wide autonomous authority.\n\nThe **Context plane** protects the boundary between organizational truth and AI working state.\nHumans consume policy-filtered projections. AI consumes a bounded operational sandbox.\n\nThe **Intelligence plane** reasons, plans, allocates and learns. It has no direct canonical write\nauthority.\n\nThe **Execution plane** is the only path to external effects, and it is governed.\n\nThe **IntegrateWise platform substrate** supplies the cross-cutting infrastructure needed by all\nof the above. It is not itself a customer Workbench.\n\n## 7. The runtime sequence\n\nThe architecture has two related sequences. The first is the **SpineWorkspace Work Operating\nLoop** — the product story. The second is the **platform runtime** — the infrastructure that makes\nthe product loop reliable.\n\n### 7.1 SpineWorkspace Work Operating Loop\n\n```text\nOrganization Goal / Need\n        ↓\n      Work Graph\n        ↓\n  Shared Business Context\n        ↓\n   Context Assembly\n        ↓\n    Work Allocation\n        ↓\n Human + Twin + Systems\n        ↓\n       Decide\n        ↓\n      Execute\n        ↓\n       Verify\n        ↓\n    Reconcile Outcome\n        ↓\n Update Continuity / Memory\n        ↓\n      Next Work\n```\n\n### 7.2 Platform runtime\n\n```text\nConfiguration → Identity / Tenant Binding → Connectivity → Ingestion\n→ Normalization → Spine Fabric → Projection / Context Assembly\n→ Workbench / AI Sandbox → Capability → Governance\n→ Execution Fabric / Hermes → Provider → Outcome\n→ Re-ingestion → Reconciliation → Promotion / Continuity\n```\n\nThe platform sequence must serve the work loop, not replace it. The distinction is important:\n**OODA is a reasoning grammar inside the Twin; the Work Operating Loop is the product's top-level\noperating model.**\n\n| Stage | Owns |\n| --- | --- |\n| Organization | Goals, objectives, needs, standards and policies |\n| Work Graph | Relationships between work, entities, people, dependencies and outcomes |\n| Context Assembly | Relevant context for a specific user/work interaction |\n| Work Allocation | Human/AI/system responsibility for the next work component |\n| Workbench | Human decision and operational interaction |\n| Twin Workbench | AI reasoning, planning, delegation and monitoring |\n| Capability Fabric | What operations are available |\n| Governance | Whether an operation is permitted and under whose authority |\n| Execution Fabric | How an authorized operation is performed |\n| Reconciliation | Whether the intended effect actually occurred |\n| Spine Fabric | Durable contextual business memory and continuity |\n\n## 8. Truth\n\n### 8.1 Spine Fabric has a canonical layer and bounded operational layers\n\nSpine Fabric is the product's contextual business memory substrate. It contains a protected\ncanonical layer plus bounded operational projections and working-state stores. These are not\ninterchangeable.\n\nThe critical security distinction is not merely storage technology; it is **who is allowed to\nsee which representation**.\n\n| Representation | **Canonical Spine** | **Operational Spine / Sandbox** | **Edge / session state** |\n| --- | --- | --- | --- |\n| Answers | _What is governed organizationally true?_ | _What is needed to operate current work?_ | _What is needed for the current interaction?_ |\n| Holds | Canonical entities, relationships, decisions, evidence, provenance, lifecycle and approved outcomes | Bounded projections, active context, sync state, working records, task context and execution state | Sessions, hot projections, idempotency, temporary working memory |\n| Lifecycle | Durable, versioned, governed | High-churn, bounded, rebuildable | Expiring |\n| Written by | **Governed Spine promotion only** | Owning operational services through governed contracts | Runtime services |\n| Read by human | Role/domain projections | Workbench and operational services | Workbench/runtime |\n| Read by AI | **Never directly** | **Yes, only through the AI Operational Sandbox contract** | Yes, when policy permits |\n| Governance | Canonical authority | Policy and scope boundary | Runtime scope |\n| If lost | Reconstruct from governed source evidence or fail closed | Rehydrate from Spine/source systems | Recompute |\n\n\n**Operational Spine is the state of the machine. Canonical Spine is the state of the\nbusiness.** That formulation resolves a conflation that has caused repeated confusion: the\nseven operational entity types are _first-class runtime objects_, not a cache of anything\ncanonical. A `SyncJob` has no counterpart in Neon it could be a projection of. It is simply\na different kind of fact, with a different lifecycle and no need of a governance gate.\n\nThe edge cache is the third thing, and it is the one that must never be mistaken for either.\n\nThe operational store is a cache and a staging boundary. **If an operational record matters\nafter its expiry, it must be promoted through the governed path.** It must not be retained\nmerely because it happens to exist in a cache — and expiry itself never confers truth.\n\n**Aging is not promotion.** This is worth stating separately because it has been proposed\nrepeatedly. D1/KV expiry removes or rebuilds bounded state. Canonical promotion is\nevidence-, schema-, provenance-, policy- and authority-driven. A record does not become true\nby surviving.\n\n### 8.2 Storage ownership\n\n| Store                       | Owns                                                                                                                        | Never                                     |\n| --------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |\n| **Neon (Fortress)**         | Canonical entities, relationships, lineage, connector metadata, schema mappings, work, governance, audit, promoted outcomes | —                                         |\n| **R2**                      | Files, attachments, raw payloads, exports, immutable evidence bytes                                                         | Canonical structured truth                |\n| **Vectorize / AI Search**   | Derived embeddings and retrieval indexes                                                                                    | Truth                                     |\n| **AI Operational Sandbox** | Read-optimised, policy-filtered, task-scoped working projection assembled from Spine Fabric | Canonical truth, unrestricted access or a write target |\n| **D1**                      | Active context, idempotency, runtime indexes, projection snapshots                                                          | Independent record                        |\n| **KV**                      | Sessions, hot projections, connector state, invalidation                                                                    | Truth                                     |\n| **Credential wall (Nango)** | Tenant-owned OAuth/API credentials                                                                                          | — the Spine stores opaque references only |\n\n### 8.2a Canonical Spine is never directly exposed to AI\n\nCanonical Spine is never queried by an LLM, Twin, agent or external AI host. No model receives\nraw canonical rows, unrestricted SQL, unrestricted GraphQL or an unrestricted MCP resource over\ncanonical storage.\n\nInstead, the **AI Operational Sandbox** is assembled for a specific user, role, domain, work\nitem and interaction. It may contain:\n\n- policy-visible entity summaries\n- current work state and related entities\n- relevant documents and communications\n- provenance and freshness indicators\n- approved organizational memory relevant to the work\n- bounded tool results\n- current execution state\n- prior Twin/agent working state that remains within scope\n\nThe sandbox is a working representation, not canonical truth. It may be incomplete, stale or\nuncertain, and those states must be explicit.\n\n```text\nCanonical Spine Fabric\n        │\n        ├──► Human Projection ──► User Workbench\n        │\n        └──► AI Context Assembly ──► AI Operational Sandbox ──► Twin / Agents\n\n                         X\n                         │\n                    NO DIRECT ACCESS\n                         │\n                  Canonical Spine\n```\n\nThis is the strongest form of the Memory and Authority laws: **AI reasons over context derived\nfrom truth; AI does not become a reader or writer of truth by virtue of being intelligent.**\n\n### 8.2b The store assignment rule\n\nSix stores, one rule for choosing between them:\n\n> **Numbers you aggregate go to Postgres. Everything else goes to the store that matches its\n> shape — and none of those stores is truth.**\n\n| Data class                                                                                                  | Store                     |\n| ----------------------------------------------------------------------------------------------------------- | ------------------------- |\n| Entity structured fields · KPI aggregations · counts · status · relationships · approval state · provenance | **Neon Postgres**         |\n| Long-form text · semantic search · similar-entity matching · Twin context retrieval · duplicate detection   | **Vectorize / AI Search** |\n| Attachments · invoice and contract PDFs · images and media · raw email bodies · exports                     | **R2**                    |\n| Bounded active context · idempotency · projection snapshots · runtime indexes                               | **D1**                    |\n| Session cache · hot projections · connector health · SLA and build flags · feature flags · invalidation     | **KV**                    |\n| Twin conversation runtime · per-subject active context · agent working memory                               | **Durable Objects**       |\n\n**Durable Objects are the sixth store and were previously unnamed.** They hold the live\nworking state of a reasoning session — the Twin's conversation, the active context for one\naccount, an agent's in-flight working memory. That state is real, it is scoped, and it is\n_not_ truth: it expires, and anything in it that should survive must be promoted through the\ngoverned path like anything else.\n\n**A caution on \"Postgres/D1.\"** Those two are not interchangeable and must never be written\nas one tier. Neon is canonical. D1 holds a _bounded, rebuildable projection_ of it. A KPI\nmay be **computed into** D1 as a cache; a KPI may not **live in** D1 as its record. The same\napplies to \"live entity state\" in KV — a cached current value is fine, an authoritative one\nis a violation of §8.1.\n\n### 8.2c Memory is interpreted truth, in four scopes\n\nMemory is neither canonical nor operational. It is **interpreted** — derived from canonical\nfacts and session evidence, carrying confidence and provenance. That is precisely why it\nneeds a governance gate that neither Spine requires: an entity is observed, but a memory is\n_concluded_.\n\n| Scope              | Boundary                                                                                                    | Governance                                            | Store                   |\n| ------------------ | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ----------------------- |\n| **Personal**       | One user. Hard boundary — no other principal reads it, including the org's own Twin acting for someone else | User owns it; no approval needed                      | `personal_memory`       |\n| **Agent**          | One agent or Twin instance within one tenant. Working state, learned routing, tool outcomes                 | Not directly promotable; must pass triage as evidence | `agent_memory`          |\n| **Conversational** | One session or thread. Ephemeral working context                                                            | Decays; never promoted directly                       | `conversational_memory` |\n| **Organisational** | Tenant-wide interpreted truth                                                                               | **Governed:** `staging` → approved → published        | `org_memory`            |\n\n**Context, Memory and Continuity are deliberately different.** Context is what is relevant now;\nMemory is what has been retained from before; Continuity is what keeps the work coherent across\ntime and boundaries. Together they form the contextual business memory model of Spine Fabric.\n\n**Scope only ever widens through promotion, and promotion is always governed.**\nConversational and Agent memory are _evidence_, not truth. Personal memory never widens at\nall — it can only be cited by the user who owns it.\n\nThat last rule is stronger than a privacy preference. If personal memory could be promoted,\nevery private note becomes a candidate for organisational truth, and the hard boundary that\nmakes the scope usable at all disappears.\n\n### 8.2c-i Triage classifies. The Promotion Gate governs.\n\n```\nEvidence                       Interpretation          Truth\n────────                       ──────────────          ─────\nconversational_memory  ┐\nagent_memory           ├──► TRIAGE ──► candidate ──► PROMOTION GATE ──► org_memory\nsession events         │    classify                 govern             staging → approved\ncanonical entities     ┘\n                                                          │\n                                        personal_memory ──┘  never promoted;\n                                                             widened only by its owner\n```\n\nThese are two responsibilities and they must not merge. **A classifier that can also approve\nis not a gate.** Triage may receive, validate, classify, redact, deduplicate, link,\nquarantine and stage. It may not decide that unverified material has become organisational\ntruth; it decides only _where a candidate goes for review_.\n\n**Automation may reach `staging`. It may never reach `approved`.** This is the defensible\nmiddle between \"every extraction needs a human\" and \"high confidence auto-stages\": the\nsystem does the sorting, a human does the deciding, and material sitting in `staging` is\n**not available to Twin reasoning** until approved. Approval automation without approval\nbypass.\n\nThis is the Authority Law again — confidence never grants authority — expressed at the\nmemory layer. It deserves to be a test, not a comment: _no promotion path may write\n`governance_state = 'approved'` without an approver identity._\n\n### 8.2c-ii The same separation governs learned behaviour\n\nBehaviour learns through an evidence pipeline, never by direct mutation of an agent:\n\n```\nobservation → candidate → suggested → shadow → approval → active\n                                                   ↓\n                     remain · return to shadow · suspend · retire\n```\n\n**An agent may move a pattern to `candidate` or `suggested`. An agent may never promote a rule\nto `approved_autonomous`.** Autonomy is granted by policy, never inferred by the agent that\nwould exercise it — the Authority Law applied where it is most often violated.\n\nShadow rules evaluate against live opportunities and take no action. Proactive rules may\npropose but perform no external write. Autonomous rules execute only a fixed, approved rule\nversion inside a declared envelope — action types, entity types, rate ceiling, value at risk,\nfreshness requirement, approval expiry, emergency disable — and drift suspends them **without\na code deploy**.\n\n**Confidence is six things**, and one number must never represent all six: pattern confidence ·\nprediction confidence · input completeness · data freshness · historical precision · policy\neligibility. Small samples use a named conservative lower bound, not raw accuracy — 3/3 is not\nbetter evidence than 470/500.\n\nDetail: [Edge Conditions and Governed Learning\nSpec](../specifications/runtime/EDGE_CONDITIONS_AND_GOVERNED_LEARNING_SPEC.md) §9–§12.\n\n### 8.2d The enrichment pipeline\n\nNormalisation makes data canonical. **Enrichment makes it retrievable.** They are different\npasses with different failure modes, and conflating them is why \"the search is bad\" and \"the\ndata is wrong\" get diagnosed as one problem.\n\n```\nEntity created or updated in Neon\n        ↓\nExtract text from structured fields + linked R2 content\n        ↓\nChunk (512 tokens, 50 overlap)\n        ↓\nEmbed into Vectorize\n        ↓\nLink related entities into the relationship graph\n        ↓\nExtract key concepts onto the entity\n        ↓\nWrite the embedding reference back onto the entity in Neon\n```\n\nOne canonical write triggers the enrichment pass. Vector and structured stores may be used\ninternally by Context Assembly, but the Twin receives only the resulting **AI Operational\nSandbox**. The sandbox preserves provenance, freshness, completeness and authority markers;\nthe model never receives a raw-store authority relationship.\n\n### 8.2e Cross-source canonical records\n\nSome canonical entities are assembled from several providers at once. An invoice is the\nclearest case: billing tool, payment gateway, subscription platform and usage platform each\nhold a fragment, and the canonical record carries references to all of them.\n\nThose links are established **by the pipeline, never by a user**. A human manually asserting\nthat two provider records are the same object is exactly the identity-resolution decision\nthat must be deterministic and provenance-bearing — and if it is ambiguous, it blocks rather\nthan guesses.\n\n### 8.3 Write authority\n\n```\nPipeline promotion through Governed Spine Writers\n= the sole canonical commit path\n```\n\nThe browser, the Twin, connectors, the public MCP, the Normalizer, Triage and the Projection\nEngine **never write Neon directly**. Not \"should not\" — the credential boundary is meant to\nmake it impossible. (Today it is not; see [§20 S8](#20-drift-register).)\n\n**No dual-write. Ever.** Nothing writes synchronously to both the Spine and a projection. The\ncanonical mutation, its field lineage and a **transactional outbox event** commit in one\ndatabase transaction; every projection is an asynchronous consumer of that event.\n\n```\n┌─ one Spine transaction ─────────────────┐\n│  canonical mutation                      │\n│  field lineage                           │\n│  outbox event                            │\n└──────────────┬──────────────────────────┘\n               ↓ at-least-once, idempotent consumers\n   Brain · search · vector · signals · Workbench · org-memory cache\n```\n\nDelivery is at-least-once with stable event ids, monotonic entity versions, backoff with\njitter, dead-letter queues and reconciliation. **The architecture does not claim cross-store\nexactly-once delivery** — any document that does is wrong.\n\nThis is the structural fix for the whole class of defect in §20: a projection that is written\ndirectly becomes a second writer, and a second writer becomes a second source of truth. It\ncloses **S0b** and **M1** — Neon `memory.org_memory` is the store, the D1 table is a\nprojection, and the promotion gate is its only writer.\n\nDetail: [Edge Conditions and Governed Learning\nSpec](../specifications/runtime/EDGE_CONDITIONS_AND_GOVERNED_LEARNING_SPEC.md) §2.\n\n### 8.3a Uncertainty is a value, not an absence\n\n`unknown` · `unresolved` · `insufficient_data` · `conflicted` · `stale` · `failed` are valid\npersisted states. **The platform never converts uncertainty into a guessed canonical value.**\n\nThis applies at three levels, and all three are required:\n\n| Level        | Carries                                                                                                                     |\n| ------------ | --------------------------------------------------------------------------------------------------------------------------- |\n| **Field**    | `normalizationStatus`: valid · coerced · invalid · missing · conflicted — with `rawValue` preserved whenever coercion fails |\n| **Identity** | `resolution_status` and `canonical_status`; an unresolved entity is `provisional` and **not eligible for automation**       |\n| **Response** | `state` (§11.4) and `completeness` — orthogonal, both required                                                              |\n\nTwo rules that follow and are violated often:\n\n**An unknown enumerated value maps to `unknown`, never to the nearest known value.** Nearest-\nmatch is how a system quietly invents facts.\n\n**Null, blank and absent are three different things.** Collapsing them destroys the difference\nbetween _we know it is empty_ and _we never asked_.\n\n### 8.4 The entity contract\n\nEvery canonical entity owns seven properties. This is frozen:\n\n| Property          | Meaning                                    |\n| ----------------- | ------------------------------------------ |\n| **identity**      | Canonical reference (id, provider, tenant) |\n| **fields**        | Structured attributes                      |\n| **relationships** | Connected entities                         |\n| **timeline**      | Temporal history                           |\n| **provenance**    | Source and lineage                         |\n| **permissions**   | Access governance                          |\n| **capabilities**  | Available operations                       |\n\nProvenance is not metadata. It is the reason any number on a Workbench can be traced to the\nsystem and field it came from and the time it last changed — which is what makes grounded\nreasoning possible and hallucination structurally harder.\n\n### 8.5 Schemas are entity-based; experience is projection-based\n\nA persisted record represents a business or platform entity, relationship, event, evidence\nartifact, policy, capability, execution, versioned definition or runtime record. **A table is\nnever created because a sidebar label exists.** There is no canonical `home`, `inbox`,\n`finance-manager` or `view-n` table. Those are projections.\n\nRole, department and industry are **projection dimensions, not storage partitions**. This is\nthe single most load-bearing storage decision in the system: it is what preserves\ncross-functional work. One account, person, task, document, risk, decision or outcome is\nprojected into every relevant view without its truth being copied into a departmental\ndatabase.\n\nStorage rules:\n\n- Onboarding creates a **tenant-specific Spine schema/profile**: the activated entity types,\n  fields, mappings, vocabulary, relationships, retention and policy configuration for that\n  tenant and workspace. This is a governed logical/data contract, not permission to generate\n  arbitrary physical tables from UI labels.\n- The current physical model uses shared typed tables with mandatory tenant scope. Whether\n  stronger physical schema/database isolation is required is an infrastructure decision; it\n  must preserve the tenant-specific logical schema and the scope envelope either way.\n- Each canonical entity type in its own table, with its own opaque primary key\n- `tenant_id` mandatory on every canonical row, relationship, event, cache entry and evidence link\n- Every entity carries a classification address: `app_category → business_domain → lifecycle_stage`\n\n### 8.6 The scope envelope\n\n| Concern                   | Field                                       | Meaning                                                             |\n| ------------------------- | ------------------------------------------- | ------------------------------------------------------------------- |\n| Isolation boundary        | `tenant_id`                                 | The owning tenant. **Always required.**                             |\n| Tenant operating account  | `tenant_account_id`                         | The tenant's root account identifier                                |\n| Tenant Spine Network      | `spine_network_id`                          | Groups the entity graph, connector bindings, events and projections |\n| Workspace context         | `workspace_id`                              | Optional active scope; never replaces `tenant_id`                   |\n| Entity identity           | `<entity>_id`, `canonical_id`               | Row identity and merge identity                                     |\n| Connector install binding | `connector_binding_id`                      | The user/tenant/provider-workspace installation                     |\n| Connector connection      | `spine_connection_id`                       | Lineage of one provider connection                                  |\n| Traceability              | `trace_id`, `correlation_id`, `source_flow` | The end-to-end route                                                |\n\n`spine_network_id` and `spine_connection_id` are not interchangeable. The first is the\ntenant's network root, required for cross-connector grouping. The second is the lineage of\none connection inside it. A tenant network has many connections and also holds user-created,\nimported and governed entities that belong to no connection.\n\n`spine_users` are authenticated product users. A business person or contact is a _canonical\nentity_ with a person subtype. Conflating them is a recurring bug class.\n\n## 9. The four flows\n\nEverything entering the system is classified into one of four flows, and only two can create\ntruth.\n\n| Flow                                 | Carries                                                                                                                                                 | Canonical boundary                                                                          |\n| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |\n| **A — Structured operational data**  | Entities, typed fields, relationships, metrics, events, status, ownership, lifecycle                                                                    | Deterministic normalisation prepares candidates; governed writers commit                    |\n| **B — Documents and communications** | Threads, messages, meetings, calls, documents, attachments, transcripts, evidence                                                                       | Raw artifacts preserved; extracted meaning retains lineage; promotion uses governed writers |\n| **C — AI and cognitive context**     | Twin/external-AI sessions, model output, plans, proposals, tool calls, candidate memory                                                                 | **Never directly mutates operational truth.** Triage proposes promotion                     |\n| **D — Platform binding and control** | Identity, tenant, workspace, role, department, permissions, configuration, connections, credential references, capabilities, policies, runtime bindings | Governed platform configuration writers only. Not a business-data partition                 |\n\n**Flow C is where every well-meaning shortcut wants to live.** \"Let the model write it,\nwe'll review later\" is precisely what this partition exists to prevent.\n\n**Flow D runs first.** It is not a peer of A, B and C — it is their precondition. Nothing can\nbe classified, scoped or written until identity, tenant, workspace, consent, connection binding\nand capability grants have resolved. An observation arriving before Flow D has no tenant, and a\nrecord without a tenant cannot be written; it fails closed.\n\n**Flow D is not the execution path.** An approved effect follows\n`Capability → Governance → Hermes → provider → outcome → re-ingestion → reconciliation →\npromotion`. Flow D supplies the authority and binding context that path runs under; it does\nnot turn external execution into platform-binding data. _(This is a recorded post-lock\ncorrection: Architecture Lock v1.0 described Flow D as approved external actions. v1.1\ncorrected it.)_\n\n```mermaid\nflowchart TD\n  D[\"D: identity + authn/authz + consent + tenant/workspace/schema binding\"] --> Gate{\"Tenant activation complete?\"}\n  Gate -- \"no\" --> Closed[\"Fail closed; no ingestion or capability route\"]\n  Gate -- \"yes\" --> A[\"A: structured operational records\"]\n  Gate -- \"yes\" --> B[\"B: messages, email, documents, channels, projects\"]\n  Gate -- \"yes\" --> C[\"C: AI conversations, agent work, continuity candidates\"]\n  A --> Loader[\"Loader: capture + source lineage\"]\n  B --> Loader\n  C --> Loader\n  Loader --> Normalizer[\"Normalizer: validate, map, deduplicate, redact\"]\n  Normalizer --> Evidence[\"Evidence / R2 / bounded operational staging\"]\n  Normalizer --> Candidates[\"Durable typed candidates + provenance\"]\n  Candidates --> Promotion[\"Policy + promotion / approval\"]\n  Promotion --> Fortress[\"Canonical Spine / Fortress\"]\n  Fortress --> Search[\"Links + events + search / embeddings\"]\n  Search --> Projection[\"Role/task Workbench + bounded AI context\"]\n```\n\n### 9.0b Activation and phased ingestion\n\nFlow D is a state machine, not a login callback:\n\n`initiated → identity_verified → tenant_bound → workspace_created → consent_recorded →\ntenant_schema_activated → connectors_eligible → ingestion_enabled`.\n\nThe product may hydrate in phases, but it may not weaken the gates:\n\n| Phase | Product value | Intake boundary | Exit evidence |\n| --- | --- | --- | --- |\n| **Creamy layer** | Fast initial value from high-signal, low-volume objects and recent work | Allowlisted entity types, recent windows, metadata-first document capture | Tenant scope, mappings, provenance, freshness and first role projection verified |\n| **Breadth hydration** | Historical records, communications and documents fill the connected context | Backfill with rate limits, resumable cursors, deduplication and evidence retention | Coverage and reconciliation metrics meet the tenant activation policy |\n| **Full continuity** | Incremental sync, AI-host continuity and governed action outcomes remain current | Webhooks/polling, Flow C candidates, execution receipts and re-ingestion | Drift detection, replay, deletion/revocation and steady-state SLOs proven |\n\n“Creamy layer” describes rollout order only. It is not a second store, a weaker truth class,\nor authority for partial data to masquerade as complete. Every response continues to carry\nfreshness and completeness.\n\n### 9.0a Three things arrive from an AI, and they are not the same thing\n\nConflating them is the most consequential modelling error at the host boundary.\n\n| What the AI produced                                | It is          | Destination                                                                 |\n| --------------------------------------------------- | -------------- | --------------------------------------------------------------------------- |\n| **Tool result** — it invoked an app and got records | Evidence       | **Flow A or B**, via Loader → Normalizer                                    |\n| **Model output** — reasoning, summary, conclusion   | Interpretation | **Flow C** — candidate only                                                 |\n| **Requested action** — \"send this\", \"update that\"   | Intent         | **Not a flow.** The governed execution path; its _outcome_ re-enters as A/B |\n\nThe sharpest case: **when a host's model reasons over IntegrateWise data and reaches a\nconclusion, that conclusion is Flow C.** It does not become organisational truth because a\ncapable model asserted it, and it does not become truth because its confidence was high. The\nreasoning is rented; the truth is owned; the gate between them is ours.\n\nDetailed channel mapping:\n[Marketplace Channels and Data Flow Spec](../specifications/surfaces/MARKETPLACE_CHANNELS_AND_DATA_FLOW_SPEC.md).\n\n### 9.1 Normalizer and Triage are separate runtimes\n\n|           | **Normalizer**                                                                                                               | **Triage**                                                                                                                                         |\n| --------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Nature    | Deterministic                                                                                                                | Adaptive                                                                                                                                           |\n| Does      | Validate, parse, type, map, deduplicate, resolve identity and relationships, construct provenance, prepare a write candidate | Classify cognitive/unstructured material, bind evidence, estimate materiality and confidence, select a memory or knowledge scope, route for review |\n| Authority | None — prepares candidates                                                                                                   | None — **cannot self-authorise or auto-promote**                                                                                                   |\n\nNeither commits. **Loader Runtime** is the sole outer ingress controller; **Governed Spine\nWriters / Pipeline promotion** are the only modules that commit canonical truth.\n\n## 10. Capability, Governance, Hermes — the execution path\n\n### 10.0 Capability has three effect classes\n\nOne kernel term, three effect classes. Every registered capability declares which it is, and\nits governance requirement follows deterministically — it is not a judgement call at\ninvocation time.\n\n| Effect class | Does                                         | External effect | Governance                                                        | Examples                                                                    |\n| ------------ | -------------------------------------------- | --------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------- |\n| **read**     | Retrieves state from a system of record      | None            | Policy scope only                                                 | Fetch an opportunity, list messages                                         |\n| **derive**   | Computes over truth, memory and evidence     | None            | Policy scope only; output is a candidate, never a fact            | Memory view, AI search, context assembly, entity resolution, Twin reasoning |\n| **mutate**   | Changes external or canonical business state | **Yes**         | **Proposal → policy → approval token → receipt → reconciliation** | Send an email, update a CRM record, create an obligation                    |\n\nThis resolves a conflation that ran through the whole prior document set. The Capability\nLaw reads _\"Workbench projects **tool** capabilities\"_ — the word \"tool\" was already there,\nwhich means the doctrine only ever governed provider operations and left the cognitive half\nof the system unnamed. Fourteen of the nineteen public tools are `derive` or `read`:\n`get_context`, `get_related`, `get_permitted_memory`, `get_relevant_knowledge`, `ask_twin`.\nThose are the product. They now have a declared class, a governance rule, and a home.\n\nTwo consequences worth stating:\n\n**A `derive` capability produces candidates, never facts.** Its output enters Flow C. It\nreaches canonical truth only through Triage, a promotion record and the applicable approval.\nThis is the Memory Law expressed as a capability property rather than a convention.\n\n**Only `mutate` requires an approval token.** Reads and derivations are bounded by policy\nscope, not by approval. Requiring approval for a memory lookup would make the gate\nmeaningless through overuse.\n\n### 10.1 The path\n\n```\nTwin or user intent\n→ capability resolution          (what operation is this, at what version)\n→ immutable execution plan       (parameters fixed; nothing may change after this)\n→ Governance policy + evidence   (is this permitted, by whom, with what evidence)\n→ explicit human approval        (when required)\n→ approval token\n→ Hermes                         (the only coordinator of approved execution)\n→ provider connector / MCP capability\n→ source-system result\n→ Pipeline normalisation\n→ promoted outcome in Neon\n→ projection invalidation\n```\n\n```mermaid\nflowchart LR\n  Task[\"User task in Workbench\"] --> Context[\"Assemble task context: canonical IDs + task ID + links + provenance + documents + search\"]\n  Context --> Twin[\"Silent Twin: explain, draft or propose\"]\n  Twin --> Intent[\"Versioned capability intent\"]\n  Intent --> Policy[\"Governance: identity + RBAC + consent + evidence + policy\"]\n  Policy --> Approval{\"Consequential mutation?\"}\n  Approval -- \"no: read/derive\" --> Result[\"Bounded result / candidate\"]\n  Approval -- \"yes\" --> Token[\"Human approval + immutable token\"]\n  Token --> Hermes[\"Hermes plan and execution\"]\n  Hermes --> Source[\"Source system capability\"]\n  Source --> Receipt[\"Receipt + observed outcome\"]\n  Receipt --> Reingest[\"Loader → Normalizer → reconcile\"]\n  Reingest --> Promote[\"Governed promotion\"]\n  Promote --> Refresh[\"Projection invalidation / refresh\"]\n  Refresh --> Task\n  Result --> Task\n```\n\n### 10.1a Write and approval loop\n\n```mermaid\nflowchart TD\n  Candidate[\"User, Twin, agent or connector submits write intent\"] --> Resolve[\"Resolve canonical subject + capability version\"]\n  Resolve --> Plan[\"Freeze parameters, evidence, idempotency key and expected version\"]\n  Plan --> Evaluate[\"Policy and authority evaluation\"]\n  Evaluate -- \"deny / insufficient context\" --> Stop[\"Reject or return for repair; audit decision\"]\n  Evaluate -- \"approval required\" --> Human[\"Explicit human decision\"]\n  Human -- \"reject / expire\" --> Stop\n  Human -- \"approve\" --> Signed[\"Scoped, expiring approval token bound to plan hash\"]\n  Evaluate -- \"pre-authorised read/derive\" --> Execute[\"Execute allowed route\"]\n  Signed --> Execute\n  Execute --> Observe[\"Persist receipt; observe provider state\"]\n  Observe --> Reconcile{\"Outcome unambiguous?\"}\n  Reconcile -- \"no\" --> Query[\"Query source; do not retry blindly\"]\n  Query --> Reconcile\n  Reconcile -- \"yes\" --> Pipeline[\"Re-ingest + normalize + promote + outbox\"]\n  Pipeline --> Audit[\"Audit, provenance and refreshed Workbench projection\"]\n```\n\n**Governance route and execution route are separate decisions.** This is the correction\nthat makes multi-host deployment possible. _Whether_ an action is permitted, and _where_ it\nruns, are answered independently:\n\n- The **governance route** is invariant. Canonical entity resolution → policy evaluation →\n  proposal → approval or confirmation → route resolution → execution → receipt capture →\n  reconciliation into Spine. Every material write passes through all of it.\n- The **execution route** is resolved per operation. A write may execute through a\n  host-native tool _or_ through the IntegrateWise Capability Fabric. Both produce the same\n  canonical receipt structure and both reconcile into the same Spine.\n\nHermes **orchestrates** — it plans, sequences, tracks, retries and reconciles, and it\ncoordinates host-native handoffs as readily as IntegrateWise connectors. It is not the sole\nexecutor. What is invariant is the governance path and the receipt, not the transport.\n\nThree properties make this trustworthy rather than merely orderly:\n\n**The plan is immutable.** Once prepared, the parameters are fixed. What is approved is\nexactly what executes — there is no window between approval and execution in which the\naction can change.\n\n**A host confirmation is not an IntegrateWise approval.** If the host prompts the user and\nthe user accepts, policy evaluation has still not happened. Both may be required; neither\nsubstitutes for the other.\n\n**No material write executes without a receipt and a reconciliation.** An execution whose\noutcome is `unknown` enters reconciliation. It is never retried blindly and never assumed\nsuccessful.\n\n### 10.2 Capability Fabric\n\nCapabilities are registered, versioned, discoverable operations. The pattern is\n`Registry → Resolver → Health → Routing → Versioning`.\n\n```ts\npool.register(manifest, targetBinding);\npool.resolve({ capability, version });\npool.invoke({ capability, version, args, context });\npool.health();\npool.capabilities();\n```\n\nThe Workbench _projects_ capabilities; it does not implement them (Law 6). A capability\ncatalogue or executor built inside the Workbench is a Law 6 violation regardless of how\nconvenient it is.\n\n### 10.3 What \"hard gate\" means\n\n- No approval token → no external mutation. There is no branch that skips this.\n- Fail closed. A missing binding, an expired credential, an ambiguous scope: all fail closed.\n  A governance gate that degrades to \"proceed\" is not a gate.\n- Enforcement is **server-side at the Gateway**. This matters most in a plugin host, where\n  the reasoning model belongs to ChatGPT or Claude and cannot be trusted to respect a\n  client-side gate. The plugin channel is the case that proves why the rule must hold\n  everywhere.\n- \"Until successful\" is policy-bounded retry, never unbounded. Ambiguous remote outcomes are\n  queried and reconciled before any mutation is repeated. Exhausted work goes to dead letter\n  and governed reprocessing — never blind replay.\n\n### 10.4 The event envelope and reliability\n\nEvery ingress — webhook, polling, streaming, API, MCP, user or agent — normalises to one\ntenant-scoped event envelope carrying event type and version, trace, correlation, causation,\nidempotency key, subject, source and provenance.\n\n```\nValidate → archive raw evidence → publish immutable event\n→ queue / stream → process → resolve capability → govern → Hermes\n→ provider outcome → re-ingest → verify → reconcile\n→ Pipeline promotion → projection invalidation\n```\n\nThat one envelope is what makes the rest of the system uniform: a Slack webhook, a scheduled\nSalesforce sync and a Twin-proposed action all become the same shape before anything\ndownstream sees them. Six guarantees are mandatory rather than best-effort — event\nbus/queues, idempotency and deduplication, webhook and polling security, policy-bounded\nretry and replay, sync and reconciliation, and end-to-end traceability with structured\nlogging and SLOs.\n\nTwo rules deserve emphasis because they are where distributed systems usually fail quietly:\n\n**An ambiguous provider outcome is a question, not a retry.** If the system cannot determine\nwhether a mutation succeeded, it queries and reconciles before repeating. Retrying an\nambiguous write is how one approved action becomes three emails.\n\n**Exhausted work goes to dead letter and governed reprocessing.** Never blind replay. A\nreplayed action is a new action and re-enters the governance path.\n\n## 11. Projection and the Workbench\n\n### 11.1 The projection contract\n\nThe organization has one connected Spine Fabric. Users do not receive separate organizational\ndatabases. They receive **projections** determined by:\n\n```text\nVIEWER\n  identity · tenant · role · permissions · department · domain · responsibility\n\nSUBJECT\n  entity · work item · lifecycle stage · relationships · evidence\n\nORGANIZATION\n  goals · priorities · standards · business context\n\nSYSTEM\n  connector availability · capability availability · freshness · policy\n\n                         ↓\n                 Projection Engine\n                         ↓\n              Role / Domain Projection\n                         ↓\n                  USER WORKBENCH\n```\n\nThis means the same account, customer, project, task, risk or decision can be seen by Sales,\nCustomer Success, Finance, Engineering or leadership without becoming separate records.\n\n### 11.2 One organizational truth, many human views\n\nThe Workbench is the human operational surface. It projects the relevant slice of Spine Fabric\naccording to the user's role, domain, responsibility, permissions and current work.\n\nThe user should not have to reconstruct organizational context from separate applications. The\nprojection should bring the relevant business context to the work.\n\nThe user-facing centre of gravity remains **work**:\n\n- What needs my attention?\n- What is blocked?\n- What is waiting for a decision or approval?\n- What changed?\n- What should happen next?\n- What context explains this work?\n- What can my Twin take on?\n\n### 11.3 User Workbench and Twin Workbench are different surfaces\n\nThe two surfaces serve the same user's work but have different purposes.\n\n**User Workbench**\n\n- role/domain operational view\n- work queues and tasks\n- business entities and context\n- communications and documents\n- approvals and decisions\n- visual projections and canvases\n- human judgment and accountability\n\n**Twin Workbench**\n\n- agentic working environment for the user's Twin\n- AI Operational Sandbox\n- plans and decompositions\n- agent assignments\n- tool/capability execution state\n- working memory and evidence\n- pipeline/workflow monitoring\n- drafts and proposals\n- exceptions requiring human intervention\n\nThe Twin Workbench may resemble an agentic environment such as an AI runtime console, but it is\nnot a generic AI playground. It is the execution workspace of the user's bounded Twin, grounded\nin the user's role/domain and the organization's Spine Fabric.\n\n### 11.4 Context Assembly\n\nContext Assembly is the mechanism that turns organizational continuity into task-specific\nworking context. It combines:\n\n`organization context + subject context + work context + role authority + current interaction +\nfreshness + evidence + available capabilities`\n\nand produces two different outputs:\n\n```text\nSPINE FABRIC\n     │\n     ├──► HUMAN PROJECTION\n     │      → User Workbench\n     │\n     └──► AI OPERATIONAL SANDBOX\n            → Twin Workbench / agents\n```\n\nThe two outputs are related but not identical. The human may be allowed to see a canonical field\nor sensitive business relationship that the AI sandbox must exclude. The AI may receive derived\nworking state that is useful for reasoning but is not itself canonical.\n\n### 11.5 Roles, domains and cross-team work\n\nRole and domain are **projection and authority dimensions**, not storage partitions.\n\nA user's Twin is scoped to the user's assigned role/domain and the capabilities necessary to\nperform that role's work. Domain agents may be narrower still. Cross-team work does not require\ncross-team database copies; it requires governed projections of the same Work Graph.\n\nExample:\n\n```text\nCustomer Renewal\n      │\n      ├── Customer Success\n      │     ├── relationship context\n      │     └── renewal strategy\n      │\n      ├── Finance\n      │     ├── billing state\n      │     └── commercial constraints\n      │\n      ├── Product / Engineering\n      │     ├── incidents\n      │     └── product dependencies\n      │\n      └── Leadership\n            ├── risk\n            └── business outcome\n\n             ↑ all connected through Spine Fabric / Work Graph\n```\n\nEach participant sees what their authority permits while the underlying business continuity\nremains shared.\n\n### 11.6 Auto-tuning boundary\n\nPersonal and reversible adaptation may improve a user's Workbench or Twin Workbench. It may not\nsilently change organizational truth, permissions, authority, policy, governance thresholds,\nshared schema or organizational memory publication.\n\n### 11.7 Frontend-to-backend contract\n\nEvery Workbench projection follows:\n\n`authenticated user → Gateway/TenantGate → projection contract → policy-filtered Spine read model\n→ Workbench`\n\nEvery AI context request follows:\n\n`authenticated user/Twin → Gateway/TenantGate → Context Assembly → AI Sandbox contract → Twin`\n\nThe browser never queries providers or storage directly. The Twin never queries canonical Spine\ndirectly. Both are clients of governed platform contracts.\n\n## 12. The Twin\n\n### 12.1 The Twin is the user's AI work partner\n\nA Twin is assigned to a user instance. It is not \"the company's AI\" in the abstract. It is a\nbounded AI participant operating within the user's role, domain, responsibilities, authority\nand active work.\n\n```text\nUSER\n  │\n  ├── User Workbench\n  │\n  └── Twin\n        │\n        ├── Twin Workbench\n        ├── AI Operational Sandbox\n        ├── Domain capabilities\n        ├── Domain agents\n        ├── Workflows\n        └── Communication\n```\n\nThe Twin is responsible for the user's digital work coordination: gathering context, reasoning,\ndecomposing work, assigning bounded tasks to agents/workflows, monitoring execution, preparing\ncommunications and bringing exceptions or decisions back to the human.\n\n### 12.2 Twin operating grammar\n\nThe Twin's internal reasoning may use OODA:\n\n```text\nOBSERVE → ORIENT → DECIDE → ACT\n```\n\nBut OODA is not the product's top-level loop. The Twin's OODA operates inside the SpineWorkspace\nWork Operating Loop.\n\nThe broader Twin operating grammar is:\n\n```text\nUNDERSTAND\n   ↓\nCONTEXTUALIZE\n   ↓\nTRIAGE\n   ↓\nALLOCATE\n   ↓\nPLAN / PROPOSE\n   ↓\nDELEGATE\n   ↓\nEXECUTE THROUGH GOVERNED CAPABILITIES\n   ↓\nVERIFY\n   ↓\nREPORT\n   ↓\nADAPT\n```\n\n### 12.3 Twin and domain agents\n\nThe Twin does not need unlimited domain knowledge. The user's Twin coordinates the domain agents,\nworkflows and capabilities required for that user's role.\n\n```text\nUser Twin\n   │\n   ├── Customer Success Agent\n   ├── Finance Agent\n   ├── Research Agent\n   ├── Communication Agent\n   ├── Workflow Agent\n   └── External / provider agent\n```\n\nThese are bounded execution participants. They do not become independent owners of organizational\ntruth or user authority.\n\n### 12.4 Work assignment layer\n\nA shared work-assignment layer records:\n\n- work item\n- objective\n- assignee\n- human/AI/system participant\n- capability required\n- authority envelope\n- dependencies\n- status\n- evidence\n- expected outcome\n- actual outcome\n- escalation condition\n\nThe Twin can receive assignments, decompose them, delegate bounded subtasks and report completion.\nA human can reclaim or reassign work at any time subject to policy.\n\n### 12.5 Active context is not activation\n\nNavigating a Workbench surface hydrates context; it does not automatically authorize action or\ntrigger expensive reasoning. Twin activity is initiated by explicit user intent, a governed\nassignment, or a material signal permitted by policy.\n\n### 12.6 Twin controls\n\n| Intent | Twin behaviour |\n| --- | --- |\n| **Understand** | Explain current work from the AI Sandbox with provenance and uncertainty |\n| **Prepare** | Draft analysis, communication, plan or decision support |\n| **Assign** | Accept a bounded work assignment and decompose it |\n| **Delegate** | Route bounded subtasks to domain agents/workflows |\n| **Execute** | Request capabilities through Governance and Execution Fabric |\n| **Monitor** | Track progress, failures, dependencies and freshness |\n| **Escalate** | Bring consequential decisions, exceptions or missing context to the human |\n| **Close** | Verify and reconcile outcomes; report completion |\n\nThe Twin never turns confidence into authority.\n\n## 13. Continuity, Coworker and the Bridge\n\n### 13.1 Operational continuity\n\nContinuity preserves the identity, context, state, decisions, assignments, evidence and progress\nof work across time, people, systems and AI environments.\n\nThe principle is:\n\n> **Context follows the work, not the application.**\n\n### 13.2 The Coworker\n\nThe **Coworker** is the contextual companion between the human Workbench, the Twin and the\ncommunication/execution substrate.\n\nIt gathers context from the user's active interaction and work surface — what the user is\nlooking at, what work is active, what changed, what communication is relevant, which entities are\nin focus and what the current work assignment requires.\n\nIt can:\n\n- assemble screen/work context\n- surface relevant records and evidence\n- maintain communication continuity\n- coordinate context between User Workbench and Twin Workbench\n- carry relevant pipeline/execution status into the user's working context\n- reduce re-briefing and tool switching\n\nIt cannot:\n\n- become canonical truth\n- grant authority\n- bypass the Twin's sandbox boundary\n- execute consequential mutations independently\n\n### 13.3 Human–Twin–Coworker relationship\n\n```text\n                    SPINE FABRIC\n                         │\n          ┌──────────────┴──────────────┐\n          │                             │\n   HUMAN PROJECTION               AI SANDBOX\n          │                             │\n          ▼                             ▼\n   USER WORKBENCH                 TWIN WORKBENCH\n          │                             │\n          └──────────────┬──────────────┘\n                         │\n                     COWORKER\n                         │\n             Context + Communication\n                         │\n                         ▼\n                 Shared Work Thread\n```\n\nThe Coworker makes the user's active work legible to the Twin and makes the Twin's progress\nlegible to the user. It is a continuity mechanism, not another agent authority.\n\n### 13.4 Cross-host continuity\n\nAI hosts and external agents participate through the same bounded continuity contract. They do\nnot exchange credentials or become peer authorities. They receive only the context and\ncapabilities permitted for the requesting principal and work.\n\n## 14. Identity, tenancy and isolation\n\n| Layer                | Contract                                                                                                    |\n| -------------------- | ----------------------------------------------------------------------------------------------------------- |\n| Browser identity     | Descope is the identity authority                                                                           |\n| Authority derivation | Gateway validates the session and resolves tenant membership; injects trusted identity headers downstream   |\n| Browser claims       | Non-authoritative. Tenant, user, role and permission values from the browser are rejected                   |\n| AI / MCP consumers   | Public OAuth-protected MCP boundary                                                                         |\n| Provider credentials | Tenant-owned, held in the credential wall. **Never** in a product repository, a projection, or an AI prompt |\n| Tenant scope         | Mandatory on every canonical row, relationship, event, cache entry, evidence link and runtime operation     |\n\nStale, ambiguous, revoked or expired bindings **fail closed** and are removed from sync,\nprojections, Twin context, capabilities and execution.\n\n## 15. Three axes: Profile × Entry Channel × Surface\n\nThree orthogonal things were previously collapsed into the word \"profile,\" producing a\n2×2 that could not represent development and could not represent tool-initiated onboarding.\nThe resolution is to **stop storing the product of the axes and store the axes**.\n\n### 15.1 Profile — which capabilities exist, and who may administer\n\n`development` · `customer_zero` · `external`\n\nThis is a property of the runtime a tenant is served by, not of the tenant.\n\nOnly five modules vary by profile:\n\n| Module              | `development`      | `customer_zero`     | `external`              |\n| ------------------- | ------------------ | ------------------- | ----------------------- |\n| MCP Pool (admin UI) | full               | full                | **not exposed**         |\n| Capability Manager  | all + experimental | all governed        | tenant-permitted subset |\n| Administration      | full               | full                | tenant-scoped           |\n| Billing             | bypassed           | internal accounting | live metering           |\n| Deployments         | full               | full                | **not exposed**         |\n\n**Everything else is identical across all three.** Identity, Integration Manager, Connector\nMarketplace, Activation Hub, AI Models, Knowledge, Memory & Continuity, Automation,\nPipelines, Governance, Observability, Organizations, Users, Roles, Permissions, Audit, API\nKeys and Security vary by _tenant scope_, which RBAC already handles. Adding profile\nbranches to them invents variance that does not exist and creates eighteen new drift sites.\n\nThis table is resolved **server-side at the Gateway** and returned in the capability\nmanifest. The frontend never computes it and never receives definitions for modules the\nprofile excludes.\n\n**On MCP versus MCP Pool.** They are two different jobs, not two sizes of one thing.\nVerified at HEAD: `services/mcp-pool/src` contains **zero** of the 19 semantic tools — it\nexposes five lifecycle verbs (`register`, `unregister`, `capabilities`, `health`, `invoke`)\nover nine platform-management namespaces. A profile running on Pool could not _use_\nIntegrateWise; it could only _administer_ it. The public MCP surface is therefore\n**byte-identical across all three profiles**. MCP Pool is an operator control plane — `register`, `unregister`, `capabilities`,\n`health`, `invoke` — whose _administration UI_ is exposed only in `development` and\n`customer_zero`. Pool is never a tool surface and never a per-profile alternative to MCP.\nIf Customer Zero ran on Pool while external ran on the public surface, Customer Zero would\nstop proving the external contract, which is its entire purpose.\n\n### 15.2 Entry channel — where identity comes from, and where UI renders\n\n| Channel          | Identity source                              | UI surface                       | First connection                                        |\n| ---------------- | -------------------------------------------- | -------------------------------- | ------------------------------------------------------- |\n| `connected_tool` | OAuth with a provider the user already holds | IntegrateWise browser Workbench  | The authenticating provider                             |\n| `mcp_workbench`  | IW OAuth via MCP registry                    | IntegrateWise browser Workbench  | Chosen in the Workbench                                 |\n| `plugin_host`    | Host installation grant                      | Embedded surface inside the host | **Host-declared, runtime-confirmed capability context** |\n\n**On \"inherited.\"** Earlier wording described the plugin's first connection as _inherited\nfrom the host's connections_. That phrasing is retired: it reads as credential inheritance,\nwhich is precisely what §15.4 forbids. Credentials remain inside their owning trust boundary.\nWhere the host cannot supply a required capability, the user creates an explicit\nIntegrateWise connection. Nothing is inherited — capability is _declared and then confirmed_.\n\nOne onboarding state machine serves all three:\n\n```\ninitiated → identity_required → workspace_required → consent_required\n         → binding → hydrating → active\n                              ↘ degraded | revoked | failed\n```\n\nOnly `identity_required` and `workspace_required` are channel-dependent. `consent_required`,\n`binding`, `hydrating` and `active` are **identical for every channel**. This is the\ninvariant that matters: the Spine write path, hydration, projection composition and\ngovernance do not fork per channel. Fork them and you get three onboarding funnels that\nhydrate differently.\n\nChannel and provider are orthogonal. `channel` is one of the three above; `provider` is\ncatalogue data. Adding a new host is a catalogue entry, not a type change.\n\n### 15.3 Surface — infrastructure isolation only\n\n`dev` · `test` · `prod`. No product semantics. The axes are independent: Customer Zero on\n`test` is a valid and useful combination.\n\n### 15.4 In a host deployment, the host supplies the agent\n\nIntegrateWise does not ship inference into a host. The host's model reasons. IntegrateWise\nsupplies the tool surface, the truth, the memory, the governance gate and the embedded UI.\n\n**Host capability is never assumed.** The IntegrateWise runtime may not enumerate every app\nconnected to a user's host account, may not access another app's OAuth token, may not invoke\nunrelated apps directly, and may not bypass the host's permission, confirmation or workspace\ncontrols. The host orchestrates its own apps.\n\nHost capabilities therefore enter through explicit mechanisms only:\n\n1. **Host-declared capability context** supplied at app invocation\n2. **Tool-result handoff** — the host invokes its own app and passes the resulting evidence\n   to an IntegrateWise tool\n3. **Workflow orchestration** — the host selects both its apps and IntegrateWise tools\n4. **Explicit IntegrateWise connection** where the capability is not available through the host\n5. **Installation manifest or policy declaration** of expected capabilities\n\n**Declared is not available.** Every one of those must be validated at runtime; expected\navailability is never proof of actual runtime access. A capability's `availability` is\n`confirmed`, `declared` or `unknown`, and only `confirmed` may be routed to.\n\nTwo further rules hold:\n\n1. **Host-granted access is readable, not writable.** Any mutation is a capability execution\n   and passes the governance path like any other, whatever route it executes on.\n2. **Host evidence is still Spine-mediated.** A host tool result enters as a\n   `RawObservation` through Loader and the Normalizer Path. The Workbench does not treat a\n   provider payload as truth because the host happened to hold a token.\n\n### 15.5 Create once, deploy anywhere\n\nThe governing principle of multi-host deployment:\n\n> **Host-first access. Spine-complete context. Policy-governed execution. Canonical\n> reconciliation.**\n\nOne canonical Workbench and continuity runtime is built once and deployed into many hosts —\na host being any runtime the product renders in: ChatGPT, the IntegrateWise web app, Slack,\nMicrosoft surfaces, embedded customer applications, desktop shells, customer-hosted\nenvironments, future agent marketplaces.\n\n**A host is an integration context, not a rendering container.** A deployment must account\nfor the host's authenticated user, workspace, enabled integrations, granted scopes,\nsupported operations, confirmation model, surface limitations and runtime availability.\nTreating a host as merely a place to draw pixels is the mistake that produces per-host forks.\n\nThis resolves what looked like a question about which surface is primary. Neither is.\n**Domain logic is primary; every host — including the browser — is an adapter.**\n\n| Layer               | Owns                                                                                                                  | Never                                                    |\n| ------------------- | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- |\n| **Domain packages** | Canonical types, application services, projections, governance rules, capability contracts, core UI                   | Host specifics                                           |\n| **Adapters**        | Host and infrastructure translation: identity validation, payload translation, schema enforcement, structured results | Domain policy, provider business rules, canonical schema |\n| **Apps**            | Assembly of deployable surfaces                                                                                       | Behaviour not present in domain packages                 |\n| **Deploy**          | Environment configuration                                                                                             | Anything that changes behaviour                          |\n\nNo adapter may redefine canonical entities, governance policy or projection semantics. The\ntest is falsifiable: the same domain and application-service packages serve the web and the\nhost deployments, and a deployment can move between infrastructure providers without domain\nlogic changing.\n\n**Repository topology follows from this.** The boundary between repositories is drawn by\n**write authority**, not by distribution channel — Platform owns canonical truth and\neverything permitted to write it; Product owns operational state, agent working memory and\nevery channel adapter. Putting two channels in two repositories would make them peers, and\npeers drift: the onboarding state machine must be byte-identical across channels, and a git\nboundary converts that from a compiler guarantee into a discipline. It would also make every\nfuture host a repository rather than a folder.\n[Repository Topology and Migration](../specifications/deployment/REPOSITORY_TOPOLOGY_AND_MIGRATION_SPEC.md).\n\n### 15.6 Host-first is a preference, not an entitlement\n\nA host-native route may be selected only when the capability is actually exposed to the\ncurrent session, the required scopes are present, policy allows it, the data authority and\nfreshness are sufficient, and the operation can produce evidence and a receipt where\nrequired. Otherwise the Spine completes the request.\n\nEvery request is classified before it is routed. The classification determines whether Spine\nenrichment is mandatory:\n\n| Scope                                                             | Spine enrichment                       |\n| ----------------------------------------------------------------- | -------------------------------------- |\n| `host-local`                                                      | Optional — lightweight provenance only |\n| `entity` · `continuity` · `cross-system` · `governance` · `write` | **Mandatory**                          |\n\nA strictly host-local read may stay local only when _all_ of the following hold: the user is\nasking only about the active host; no canonical entity or cross-system context is needed; no\nmaterial write is involved; policy permits it; provenance is retained; and **the result does\nnot claim to represent complete operational truth.**\n\nThat last clause is the whole safety property. \"Summarise my unread mail\" is a legitimate\nhost-local answer. \"What needs my attention?\" is not — it claims cross-system completeness\nand therefore requires canonical aggregation.\n\n**Read precedence:** confirmed host-native live capability → permitted Spine-derived operational\ncontext → IntegrateWise-managed live connector → bounded historical/context evidence → request\nconnection → unavailable. Canonical Spine storage is never a direct AI read route; any Spine-derived\ncontext must pass through Context Assembly and the applicable human or AI projection contract.\n\nThis is not a sequential query plan. The resolver combines routes: mail may be host-native\nwhile CRM and chat arrive through the Spine, in one answer, with per-source provenance.\n\n**Write precedence:** resolve canonical target and policy → create proposal → determine\nallowed routes → prefer host-native when confirmed and approved → otherwise Capability\nFabric → capture receipt → normalise and reconcile → rehydrate.\n\n### 15.7 Connection binding — one route per operation\n\nThe same provider must not be called through both the host and IntegrateWise merely because\nboth are connected. One primary route is selected per operation; a secondary route may be\nused for fallback, verification or reconciliation when policy allows.\n\nPrincipal matching uses canonical identity, never display name. Connection tokens remain\ninside their owning trust boundary — no credential is copied between host and IntegrateWise\nto unify routing, and IntegrateWise stores no host credential unless the user separately\ncreates an IntegrateWise connection.\n\nA binding records the provider, the canonical principal, the optional host connection\nreference, the optional IntegrateWise integration, the routing preference\n(`host-first` · `integratewise-first` · `policy-decides`), whether duplicate calls are\npermitted, and the reconciliation mode.\n\n### 15.8 Agent contracts\n\nAgents are contracts, not transports. An agent definition never owns provider-specific\ntransport logic, and every agent invocation receives a **policy-filtered Active Context\nBundle** — never raw provider payloads, unless the task is explicitly ingestion or\nnormalisation.\n\n| Agent               | Responsibility                                                    |\n| ------------------- | ----------------------------------------------------------------- |\n| **Twin**            | Reasoning, synthesis, recommendations, proposal drafting          |\n| **Triage**          | Intent, urgency, ownership and attention classification           |\n| **Governance**      | Policy interpretation, approval requirements, risk classification |\n| **Entity Resolver** | Canonical entity and identity matching                            |\n| **Evidence**        | Evidence selection, provenance checks, contradiction detection    |\n\nThe Active Context Bundle is the single input contract: actor and permissions, host and\nsession, entities, relationships, continuity, commitments, signals, decisions, evidence,\navailable actions, effective policy, and the completeness level with missing systems named.\n\nEvidence carries `authority` (system-of-record · canonical · derived · user-supplied) and\n`freshness` (live · recent · stale · historical) separately, because they answer different\nquestions. Live host evidence is authoritative **only for the provider object it\nrepresents**; the Spine remains canonical for cross-system identity, relationships,\ncontinuity and reconciled state. Four timestamps are distinguished — `observedAt`,\n`receivedAt`, `normalizedAt`, `reconciledAt` — because collapsing them is how stale data\nstarts looking fresh.\n\nDerived conclusions are never stored as facts. Conflicting evidence is surfaced, not\nsilently resolved, and a normalisation conflict quarantines the update while preserving both\nrecords.\n\n## 16. The public boundary\n\n### 16.1 Nineteen tools, exactly\n\nThe public MCP surface exposes exactly nineteen semantic tools. Not eighteen, not twenty.\n\nContext and continuity: `get_my_continuity` · `get_active_context` · `get_my_focus` ·\n`get_context` · `get_changes` · `get_related` · `get_history` · `get_commitments` ·\n`get_decisions` · `get_permitted_memory` · `get_relevant_knowledge`\n\nTwin: `ask_twin` · `assign_twin` · `get_prepared_work`\n\nAction: `get_available_actions` · `prepare_action` · `get_action_plan` · `approve_action`\n\nCapture: `store_in_spine`\n\nThe internal MCP Pool, provider operations, raw table access, transport details, context\nrelay, agent handoff and connector implementation tools are **not public**. UI resources are\nadditive — a widget may communicate only through the host's declared bridge and cannot reach\nthe host DOM, cookies, credentials, Neon, provider credentials or the internal Pool.\n\nNotice the shape of that list: eleven read tools, three Twin tools, four action tools, one\nwrite tool. The single write tool is `store_in_spine` — a human observation. The four action\ntools cannot execute; `approve_action` requires an approval that a human granted. The public\nsurface is structurally incapable of autonomous mutation.\n\n### 16.2 Distribution names\n\n```\nIntegrateWise               = company / firm\nSpineWorkspace             = product and user's single connected operational surface\nRole workbench              = hostname- and authority-selected projection inside SpineWorkspace\nWorkspace                   = tenant/user scope inside the product\nIW-Spine-Network            = the public distribution identity\nIW-Spine-Network Plugin     = plugin-directory package (MCP app UI + skills)\nIW-Spine-Network MCP        = MCP-marketplace package and remote server\nIW Spine Tools              = the public 19-tool MCP interface\nSpine Fabric              = the canonical operating model and truth substrate\n```\n\n> **SpineWorkspace is built by IntegrateWise and runs on the IW-Spine-Network contract.**\n\nPublishing to a channel publishes a **channel-specific package bound to the same public\ncontract** — never a different backend. Installing does not clone Customer Zero: activation\nresolves an isolated customer tenant and applies the Customer Zero-proven reference\nconfiguration. Customer Zero data, credentials, memory, cache, queues and audit never cross\nthat boundary.\n\n### 16.3 Distribution — one product, three entry points\n\n| Distribution                | Marketplace promise                                         | Primary experience                               | Package                                                  |\n| --------------------------- | ----------------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------- |\n| **IW-Spine-Network MCP**    | Bring continuity and governed action into your AI workspace | Tool-first, conversational invocation            | Remote MCP server exposing the 19 semantic tools         |\n| **IW-Spine-Network Plugin** | See and operate your connected workspace inside the AI host | Embedded Workbench, contextual Twin, approval UI | Host app with UI resources and skills, same MCP contract |\n| **SpineWorkspace**         | Operate the complete connected workspace directly           | Full browser Workbench                           | Browser application on the same Gateway                  |\n\n### 16.3a Marketing-to-product routing\n\nThe public marketing surface presents the **whole SpineWorkspace product**. Role and\nfunction pages explain relevant outcomes; they are not operational workbenches and do not\nchoose an authenticated projection. From marketing, the user enters or activates the product;\nthe role workbench then runs on a `*.spineworkspace.com` hostname selected from authenticated\nauthority and the allowed hostname map.\n\n```mermaid\nflowchart LR\n  Marketing[\"integratewise.ai: full product story, solutions, pricing and activation entry\"] --> Auth[\"OneAuth / Flow D\"]\n  Auth --> Authority[\"Tenant + membership + consent + allowed role/workspace\"]\n  Authority --> Host[\"role.spineworkspace.com\"]\n  Host --> Shell[\"One SpineWorkspace shell\"]\n  Shell --> Projection[\"Role/task projection from Spine\"]\n  Internal[\"Internal projections: brandstore, book-of-records / orgmemory\"] -. \"never public marketing solutions\" .-> Shell\n```\n\n| Surface or mapping | Repository evidence | Classification |\n| --- | --- | --- |\n| Full marketing site at `integratewise.ai` | `apps/marketing/app`, sitemap base URL, Vercel topology | **VERIFIED in code/config; live routing not re-proved here** |\n| Public solutions grouped by function, industry and role | `apps/marketing/lib/solution-taxonomy.ts` and tests | **VERIFIED** |\n| Marketing association separated from operational hostname identity | taxonomy types/tests deliberately omit hostname and projection IDs | **VERIFIED and correct** |\n| Role workbench hosts at `*.spineworkspace.com` | `apps/web/lib/projection-registry/hosts.ts`, middleware, Gateway hostname policy and tests | **VERIFIED in code; deployed reachability is separate evidence** |\n| Authenticated hostname fails closed when unknown or disallowed | Gateway projection tests and middleware 404 rewrite | **VERIFIED** |\n| Marketing entry deterministically hands off to an allowed role host after Flow D | Pieces exist across marketing, auth/activation and product host maps | **INTENDED / partial** — one canonical handoff contract and end-to-end test are still required |\n| `brandstore` and `book-of-records` operational projections | Workbench/Gateway host registries and policies | **VERIFIED internal product projections** |\n| `brandstore`, `book-of-records` or `orgmemory` as public marketing solutions | Public taxonomy tests explicitly exclude the first two; `orgmemory` is absent | **Forbidden by doctrine; currently aligned** |\n\nThe public solution catalogue and the operational host registry therefore remain separate\ncontracts. A solution page may associate with several workbenches; a workbench may be internal\nonly. No code should derive tenant authority from a marketing URL or expose an internal host\nmerely because it exists in the operational registry.\n\n```\nOne product:      IntegrateWise Workbench on IW-Spine-Network\nDistributed via:  MCP Marketplace · Plugin Marketplace · Direct activation\n```\n\nThese are **acquisition and interaction channels, not products**. Each binds to the same\ntenant and workspace, the same Spine Fabric, the same Gateway, the same 19-tool semantic\ncontract, the same governance path and the same Workbench composition model. Marketing them\nas distinct products creates the competing-authority problem at the commercial layer that\nthis document exists to prevent at the architectural one.\n\nThe three marketplace surfaces have different commercial jobs:\n\n| Marketplace               | GTM role                                       | What it installs or activates                                                             | Where value appears                                                                      |\n| ------------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |\n| **Plugin Marketplace**    | External acquisition and embedded activation   | `IW-Spine-Network Plugin`                                                                 | Focused UI, skills and approvals inside the AI host                                      |\n| **MCP Marketplace**       | External acquisition and tool-first activation | `IW-Spine-Network MCP`                                                                    | Exact 19-tool interface, fallback results, optional widgets and browser Workbench launch |\n| **Connector Marketplace** | In-product capability activation and expansion | Tenant-scoped provider connection, connector binding, schema mapping and capability grant | Hydrated Spine context and governed provider capabilities inside IntegrateWise           |\n\nPlugin and MCP marketplaces distribute IntegrateWise. Connector Marketplace does not\ninstall IntegrateWise; it expands what an activated workspace can observe and govern.\nDirect Workbench activation remains a non-marketplace entry path. Provider or developer\nmarketplaces may wrap the Plugin or MCP contract in channel-native installation, OAuth and\nwebhook semantics, but they do not create another product or authority.\n\nThe full GTM motion is:\n\n```text\nCategory and demand\n→ Plugin Marketplace, MCP Marketplace or direct Workbench activation\n→ identity, tenant, consent and workspace activation\n→ Connector Marketplace connection or eligible connection reuse\n→ Spine hydration and role projections\n→ first grounded value\n→ first approved governed outcome\n→ additional connectors, roles and recurring use\n```\n\nThe north-star metric is time to first approved governed outcome. Channel metrics support\nit: listing view → install → `active` for Plugin and MCP, and discover → consent → bind or\nreuse → healthy → hydrated for Connector Marketplace.\n\n### 16.4 Acquisition to value\n\n```\nDiscover → Install → Resolve identity → Resolve or create workspace\n→ Consent → Bind capabilities and connections → Hydrate Spine\n→ Compile projections → First value → Daily use\n→ Propose governed action → Execute and reconcile → Expand connected systems\n```\n\nActivation must create or resolve, at minimum: Actor · Tenant · TenantAccount · Workspace ·\nMembership · Role and permissions · SpineNetwork · MarketplaceInstallation · HostBinding ·\nConnectorBinding · SpineConnection · CredentialReference · CapabilityManifest · PolicySet ·\nRoutingPreference · SchemaBindingSet · HydrationJob · ProjectionManifest.\n\n**First use must be semantic, not administrative.** In the MCP channel the first interaction\nshould be _\"What needs my attention?\"_ — and if no workspace exists yet, the activation\ndetour must **preserve the original intent and return to it**. An onboarding flow that\ndiscards the question the user actually asked has failed at the Context Law.\n\n### 16.5 Flow classification at the channel boundary\n\nPayloads are classified **individually**. A single AI-host interaction spans all four flows,\nand labelling the whole exchange \"AI data\" is the error that lets model output become truth.\n\n| #   | Event                                                          | Flow                  |\n| --- | -------------------------------------------------------------- | --------------------- |\n| 1   | Plugin installed; identity, tenant, consent, bindings resolved | **D**                 |\n| 2   | User asks \"What needs my attention?\"                           | **C**                 |\n| 3   | Host retrieves mail messages                                   | **B**                 |\n| 4   | Host retrieves structured CRM objects                          | **A**                 |\n| 5   | IntegrateWise supplies canonical continuity                    | _Spine read_          |\n| 6   | Model produces analysis and recommendations                    | **C**                 |\n| 7   | Model proposes an escalation email                             | **C** — proposal      |\n| 8   | User approves                                                  | _Governance_          |\n| 9   | Host or IW connector sends it                                  | _Governed execution_  |\n| 10  | Sent-message artifact                                          | **B**                 |\n| 11  | Delivery and status metadata                                   | **A**                 |\n| 12  | Execution receipt                                              | _Audit evidence_      |\n| 13  | Reconciliation updates the Spine                               | _Canonical promotion_ |\n\n**A tool call is three things, not one:**\n\n```\ntool request        → Flow C   (the model's intent)\nprovider result     → Flow A or B   (what came back)\nmodel interpretation → Flow C   (what the model concluded)\n```\n\nThe transport does not determine the flow. **The payload's semantic responsibility does.** A\nSalesforce object that travelled through ChatGPT is Flow A; the sentence ChatGPT wrote about\nit is Flow C.\n\n### 16.6 GTM funnel mapped to runtime state\n\nThe commercial funnel and the activation state machine are the same events. Instrument once.\n\n| GTM stage           | Runtime evidence                                                 |\n| ------------------- | ---------------------------------------------------------------- |\n| Impression          | Listing viewed                                                   |\n| Install             | MarketplaceInstallation created                                  |\n| Activation started  | `initiated`                                                      |\n| Identity completed  | Canonical actor resolved                                         |\n| Workspace activated | Tenant · workspace · SpineNetwork resolved                       |\n| First connection    | Confirmed host or IntegrateWise binding                          |\n| Hydration started   | Initial sync job created                                         |\n| **First value**     | First `canonical` — or explicitly disclosed `partial` — response |\n| Engaged             | Repeated continuity and context use                              |\n| **Governed value**  | First proposal approved                                          |\n| **Closed loop**     | First execution reconciled into the Spine                        |\n| Expanded            | Additional provider connected                                    |\n| Retained            | Recurring cross-system use                                       |\n\n**\"Installed\" is not an activation metric.** The first real milestone is _a grounded\ncontinuity answer produced from a resolved workspace, with provenance and disclosed\ncompleteness_. The milestone that predicts retention is _first governed action executed and\nreconciled_.\n\nDetail — activation envelope, per-channel journeys, read/write routing precedence, acceptance\ncriteria: [Marketplace Channels and Data Flow\nSpec](../specifications/surfaces/MARKETPLACE_CHANNELS_AND_DATA_FLOW_SPEC.md).\n\n### 16.7 Product and platform ownership\n\n| SpineWorkspace owns                                                                                                                   | IntegrateWise Platform owns                                                                                                                                                                              |\n| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Workbench rendering, canvas composition, interaction state, contextual Twin UI, approval UI, onboarding and administration presentation | Identity resolution, tenant authority, connector catalog and credentials, canonical truth, projections, capability resolution, governance, execution, reconciliation, audit, semantic APIs |\n\n**No SpineWorkspace deployment becomes a second Fortress, connector runtime, credential store,\ncanonical database, projection authority or provider-execution path.** IntegrateWise owns the\nunderlying platform substrate; SpineWorkspace consumes it through stable contracts. Product frontends may\nrun anywhere; they are clients of the matching Gateway. The Platform authority stays\nCloudflare-hosted.\n\n```mermaid\nflowchart TD\n  Product[\"PRODUCT owner: Workbench shell, role/task UX, tables, records, documents, messages, canvas, Twin and approval presentation\"]\n  Gateway[\"GATEWAY owner: identity assertion, TenantGate, consent/RBAC, semantic API and command boundary\"]\n  Platform[\"PLATFORM CONTROL owner: configure, activate, observe, release; never a projection or execution authority\"]\n  Projection[\"PROJECTION / CONTINUITY owner: bounded Workbench and agent context\"]\n  Pipeline[\"PIPELINE owner: Loader, Normalizer, candidate staging, canonical promotion and outbox\"]\n  Spine[\"SPINE owner: canonical entities, operational state, evidence, links, provenance, events and search indexes\"]\n  Fabric[\"CAPABILITY FABRIC owner: registry, resolver, health, route and version\"]\n  Governance[\"GOVERNANCE owner: policy, decision and approval token\"]\n  Hermes[\"HERMES owner: approved orchestration, receipts, retries and reconciliation\"]\n  Sources[\"SOURCE SYSTEM owner: external record and observed result\"]\n  Product --> Gateway\n  Platform -. \"control / observe\" .-> Gateway\n  Platform -.-> Pipeline\n  Gateway --> Projection\n  Projection --> Spine\n  Gateway --> Fabric\n  Fabric --> Governance\n  Governance --> Hermes\n  Hermes --> Sources\n  Sources --> Pipeline\n  Pipeline --> Spine\n  Spine --> Projection\n```\n\nThe browser calls one typed Gateway client using one variable, `NEXT_PUBLIC_IW_API_URL`. The\nfirst canonical read after sign-in or workspace switch is `GET /api/v1/workspace/discovery`,\nreturning a versioned tenant/RBAC-scoped manifest: identity and scope, projected navigation,\nprojection IDs and contract versions, connector and sync availability, capability and\napproval availability, activation blockers, freshness and remediation.\n\nNo browser call reaches Neon, D1, KV, R2, the credential wall, a provider, Hermes or the\ninternal MCP Pool.\n\n### 16.8 The unit of operational work\n\nIntegrateWise provides the substrate required to run operational work. The economic model can\ntherefore be measured around **units of operational work**, rather than only seats, tokens or\nconnector count.\n\nA unit of work may be defined by the product according to the actual metering contract, but the\narchitecture should be capable of attributing cost across:\n\n- context assembly\n- AI reasoning\n- agent execution\n- workflow execution\n- connector/API operations\n- communications\n- governance and approvals\n- reconciliation\n- infrastructure consumption\n\nThe strategic principle is:\n\n> **IntegrateWise provides the identity, connectivity, AI, execution, communication, governance\n> and infrastructure substrate required to run work; SpineWorkspace coordinates the work itself.**\n\nThis does not imply that every internal infrastructure operation is separately billable. It means\nthe platform is designed to understand the cost and performance of the operational work it enables.\n\n## 17. Environments and promotion\n\n| Environment             | Purpose                                                          | Isolation                                                                                                                          |\n| ----------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |\n| **Development**         | Product engineering, local/preview apps, CI, disposable tests    | Synthetic data; development identity, Gateway, Neon, D1/KV/R2/queues and secrets only                                              |\n| **Customer Zero**       | IntegrateWise operating IntegrateWise as its first real customer | Production-grade but isolated tenant, credentials, MCP Pool, queues, evidence, audit and bindings. **Never a general test tenant** |\n| **Customer Production** | External customers                                               | Tenant-scoped everything; no access to Development or Customer Zero                                                                |\n\nPromotion is one-way: `Development proof → Customer Zero validation → Customer Production\nrelease`. Production data, credentials and bindings never flow back.\n\nTest and prod must never share KV namespaces, Queues, D1 databases, R2 buckets, Vectorize\nindexes, Durable Objects, secret stores, or service-binding targets. Every feature completes\nin three directions: development readiness, platform release readiness, customer activation\nreadiness.\n\n### 17.1 Frozen go-live sequence\n\nGo-live promotes the same Product and Platform versions through isolated environments. It\ndoes not copy Customer Zero or create a separate external product.\n\n```text\nsource commit\n→ CI and contract tests\n→ Development artifacts\n→ Customer Zero private installation\n→ Customer Zero evidence\n→ version freeze\n→ external clean-tenant test\n→ Plugin and MCP submission-ready\n→ public publication\n```\n\nThe release completes five phases in order:\n\n1. **Shared contracts:** freeze the exact 19 public tools, resources, UI intents, discovery\n   envelope, tenant binding contract and versioned activation profiles\n2. **Customer Zero Plugin:** prove the private embedded UI, identity, host composition,\n   explicit delegation and the governed proposal-to-reconciliation loop\n3. **Customer Zero MCP and Workbench:** prove OAuth, exactly 19 tools, ordinary-client\n   fallback, browser launch, discovery-first composition and role-based access control\n   (RBAC) projections\n4. **Externalization:** install the same artifacts into a clean tenant and prove dynamic\n   tenant resolution, customer-owned connections and complete Customer Zero isolation\n5. **Publication:** freeze compatible versions, publish the Plugin and MCP, verify a new\n   tenant installation and operate governed monitoring, rollback, revocation and deprecation\n\nOnly code, manifests, definitions, schemas and versioned activation defaults cross the\npromotion boundary. Tenant data, credentials, bindings, queues, caches, evidence, audit\nrecords and runtime state never cross it.\n\n### 17.2 Mandatory release gates\n\nCustomer Production release requires all of the following evidence:\n\n- Customer Zero runs daily work through the Plugin and browser Workbench\n- the frozen versions install into an unrelated tenant without code changes\n- identity, tenant authority, RBAC and environment isolation pass negative tests\n- the public MCP returns exactly 19 tools and supports browser launch and ordinary-client\n  fallback\n- one real connector passes consent, mapping, hydration, delta sync, health, revoke and\n  reconciliation\n- every external action follows proposal → approval token → Hermes → provider outcome →\n  Spine re-ingestion → projection refresh\n- observability, audit, rate limits, rollback, deletion, export, offboarding and revocation\n  have live evidence\n- the release manifest records compatible Plugin, MCP, frontend, Gateway and Platform\n  versions\n\nAny missing gate is a stop-ship condition. Appendix I remains the complete invariant-level\nstop-ship list.\n\nClaims about the system use one of three states, and **code presence is not live proof**:\n\n| State             | Meaning                                                             |\n| ----------------- | ------------------------------------------------------------------- |\n| **Defined**       | The contract is decided                                             |\n| **Implemented**   | Repository code or migration evidence exists                        |\n| **Live verified** | The environment has passed the required runtime and isolation tests |\n\n---\n\n# Part III — Reality\n\n> **Reality note:** Part I and Part II were re-baselined on 2026-08-24 around the v3.0 human–AI\n> work-coordination model. Part III below remains a historical repository-grounded snapshot from\n> 2026-08-13 at commit `2187bc91`. Where Part III uses older terms such as \"Adaptive Spine\" or\n> describes direct AI reads of a Spine projection, those statements are evidence of the prior\n> implementation state, not permission to override the v3.0 doctrine. New implementation work\n> must conform to the current Spine Fabric → Human Projection / AI Sandbox boundary.\n\n\nParts I and II describe the architecture. This part describes the system as it exists on\n2026-08-13, at HEAD `2187bc91`. Both are necessary; a document that only described the\nintent would be the fourteenth such document.\n\n### 18.0 Grounded implementation snapshot\n\nThis matrix records repository presence, not deployed reachability. “Partial” means the\ncontract is represented but the closed end-to-end path is not proven from this checkout.\n\n| Required product/platform capability | Current repository evidence | Status at `2187bc91` |\n| --- | --- | --- |\n| One Workbench with role-aware modules | `apps/web`, `packages/workbench-config` (12 role configs), `packages/projection-contracts` | **VERIFIED / partial** — contracts and surface exist; legacy surface/taxonomy drift remains in §20 |\n| OneAuth, consent, tenant and workspace binding | `apps/auth`, `apps/one-access`, `apps/activation`, `services/gateway/src/auth.ts`, Gateway activation state machine, `services/tenants` | **VERIFIED / partial** — multiple identity surfaces and Clerk/Descope authority remain unresolved |\n| Tenant-specific Spine schema/profile generation | Gateway Spine-schema routes and tenant adaptive-schema resolution in Pipeline Normalizer | **VERIFIED / partial** — logical hydration exists; complete onboarding-to-schema-to-ingestion gate needs one proof |\n| Flow A/B Loader and Normalizer | `services/connector`, `services/loader`, `services/pipeline/src/normalizer`, provider/connector packages | **VERIFIED / partial** — duplicate ingress generations and legacy paths remain |\n| Flow C continuity across AI hosts | public continuity facade, `services/continuity`, Knowledge/memory routes, host-aware contracts | **INTENDED / partial** — bounded pieces exist; cross-host isolation and promotion need live proof |\n| Canonical and operational Spine boundary | Pipeline canonical writer, D1/KV/R2 bindings, `packages/spine-entities`, schemas and migrations | **DRIFT** — Neon/D1/Supabase-era semantics and more than one apparent write path still conflict |\n| Projection, tables/documents/canvas and active context | Gateway projection routes, `packages/projection-contracts`, context contracts, Workbench modules | **VERIFIED / partial** — sole-composer and complete live-data claims remain unproven |\n| Silent Twin grounded context | `services/twin-orchestrator`, `services/intelligence`, `services/context-fetch`, `packages/context-contracts` | **DRIFT** — substantive code exists, but Twin orchestration is not in the nine-service core release path and context is not uniformly task/ID/evidence bound |\n| ADK orchestration, cache, capability and continuity contracts | `packages/adk`, `services/iw-agent-runtime`, model/omni routing packages | **VERIFIED / partial** — registry/resolver code exists; authoritative runtime ownership and reachability are fragmented |\n| Capability Fabric and MCP Pool | `services/mcp-pool`, provider/integration/task MCP services, Gateway public Spine tools | **DRIFT** — several fabric implementations and public/internal boundaries require enforcement, not documentation only |\n| Governance, approval, Hermes, provenance and audit | Gateway governance/HITL modules, governance-engine packages, `services/hermes`, receipt/provenance types | **DRIFT / stop-ship** — Hermes routes exist in Gateway but Hermes is outside the core release set; an approval-bypass-shaped Twin coordination branch requires correction |\n| Provider action, sync, re-ingestion and reconciliation | connector/MCP services, `connector-sync`, Pipeline queues, workflow/HITL | **INTENDED / partial** — components exist; one real closed action trace remains a release gate |\n| Marketplace/package distribution | public 19-tool contracts, marketplace installation service, plugin/MCP briefs and release packaging scripts | **VERIFIED / partial** — clean installation and byte-identical multi-channel activation need live evidence |\n| Security, observability and release isolation | TenantGate/Gateway assertions, audit/telemetry services, deployment-policy checks, release validation and packaging scripts | **VERIFIED / partial** — code presence does not satisfy negative isolation, rollback, revocation and clean-tenant gates |\n\n## 18. What is load-bearing\n\nStripped of everything unreachable:\n\n```\nBrowser (apps/web — Next App Router)\n  │\n  └─► gateway ─────────── 51-entry ROUTES prefix table\n        ├─ INTERNAL_*     auth · projections · billing · tenants · admin · support\n        ├─► pipeline      normalise → canonical write        (Spine writer #1)\n        ├─► spine         Neon canonical CRUD                (Spine writer #2) ⚠\n        ├─► connector     router only ──► loader · store · mcp-connector\n        ├─► mcp-connector MCP tools + OAuth authorisation server\n        ├─► connector-sync scheduled provider sync\n        ├─► knowledge     chunk · embed · search · synthesis · promotion gate\n        ├─► intelligence  think · act · govern · agents\n        ├─► workflow      (BFF) views · analytics · stream · HITL Durable Object\n        ├─► iw-agent-runtime  TWIN_AGENT + TENANT_BRAIN DOs  ⚠ not in CORE_SERVICES\n        ├─► mcp-pool      capability routing control plane   ⚠ shared test/prod\n        └─► hub-controller-api                               ⚠ AUTH BYPASSED\n  continuity              session log; reached via mcp-connector\n```\n\n**Nine Workers** are in the canonical publication path (`scripts/release/deploy-platform.sh`):\n`pipeline → connector → mcp-connector → connector-sync → knowledge → continuity →\nintelligence → workflow → gateway`, Gateway last.\n\nShared code that genuinely carries weight: `@integratewise/types` (99 consumers),\n`connector-contracts` (90), `lib` (23), `connectors` (18).\n\nEverything else — 11 unbound Workers, ~14 zero-consumer packages, 2 unreachable Capability\nFabric implementations, 2 orphaned application roots, a retired GCP product, 102\n`_deprecated` components, 5 abandoned service folders — is inert mass.\n\n## 19. Scale\n\n| Layer                                                          | Count                                                     |\n| -------------------------------------------------------------- | --------------------------------------------------------- |\n| Source files (`.ts/.tsx/.js/.jsx/.mjs`, build output excluded) | 1,950                                                     |\n| `apps/`                                                        | 12 top-level folders                                      |\n| `services/`                                                    | 31 top-level folders                                      |\n| `packages/`                                                    | 50 top-level folders                                      |\n| Markdown under `docs/`                                        | 720 documents                                             |\n| SQL artifacts in the repository                               | 743 files                                                 |\n\nVerified against HEAD on 2026-08-13: nine `CORE_SERVICES` in the stated order, 60 Gateway\n`ROUTES` entries, 12 roles in `packages/workbench-config`, `/api/v1/workspace/discovery`\npresent in `services/gateway/src/index.ts`, `spine`, `hermes`, `twin-orchestrator` and\n`iw-agent-runtime` absent from `CORE_SERVICES`.\n\n## 20. Drift register\n\nEvery item is a violation of Part I or Part II, ordered by risk removed per unit of effort.\nSource: `CODEBASE_EXCAVATION.md`, 2026-07-30.\n\n### Tier 0 — Silent data loss\n\n**S0 · The Canonical Spine does not run. Cache writes are reported as canonical\npersistence.**\n\nVerified at HEAD, 2026-07-31. This is the most severe finding in the register and it is\nnot a design disagreement — it is a correctness defect that reports success.\n\nThe intended canonical writer, `services/pipeline/src/canonical/canonical-writer.ts`, is\ninvoked at `services/pipeline/src/index.ts:1922` behind a binding guard:\n\n```ts\nif (env.CANONICAL_SPINE_DB) {\n  const canonicalWriter = new CanonicalSpineWriter(env.CANONICAL_SPINE_DB);\n  await canonicalWriter.write(rec, { create_relationships: true });\n}\n```\n\nIts binding, `services/pipeline/wrangler.toml:118–120`:\n\n```toml\n[[d1_databases]]\nbinding      = \"CANONICAL_SPINE_DB\"\ndatabase_name = \"integratewise-canonical-spine\"\ndatabase_id  = \"YOUR_D1_DATABASE_ID_HERE\"   # unreplaced scaffold placeholder\n```\n\nThe database ID was never replaced. The binding never resolves. The guard is permanently\nfalse, and **every canonical write is silently skipped.** The surrounding `try/catch` logs\nto `console.warn`, so even a resolving binding would fail quietly. Three lines later:\n\n```ts\n// For writes, D1 is authoritative. Return success.\nreturn json({ success: true, written: entities.length, via: \"d1-primary\" });\n```\n\nEntities written only to the D1 _entity cache_ (`integratewise-spine-cache`) are reported as\nwritten. **A cache write is being returned as canonical persistence.**\n\nFour implementations claim Spine authority; the two that matter are not the two anyone\nexpected:\n\n| Implementation                           | LOC   | Store    | State                                                                                                                                                                                                                                                                                     |\n| ---------------------------------------- | ----- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `spine/src/entity-store.ts` + `index.ts` | 898   | D1       | **LIVE** — and correct. This is the Operational Spine: the seven runtime entity types                                                                                                                                                                                                     |\n| `spine/src/neon-workbench.ts`            | 558   | Neon     | **LIVE** — tenant/actor-scoped Workbench projection                                                                                                                                                                                                                                       |\n| `spine/src/canonical-store.ts`           | 995   | D1       | **DEAD** — no importers. Declares the 16 root concepts and asserts itself the single source of truth. Its types were _copy-pasted_ into `pipeline/src/canonical/entity-type-map.ts:16` with the comment _\"Types duplicated from spine canonical-store to avoid cross-service dependency\"_ |\n| `pipeline/src/spine/index.ts`            | 2,773 | Supabase | **LEGACY** — self-labelled _\"the legacy writer\"_, still in the release path                                                                                                                                                                                                               |\n\nThis inverts §S8. There are not two competing canonical writers to choose between. **There\nare zero working ones**, plus a retired Supabase writer that still runs.\n\n**Resolution — this closes D4.**\n\n> The Canonical Spine is Neon. The Operational Spine is D1. `services/spine` owns both\n> boundaries. The Pipeline is the only writer into canonical.\n\nOrdered, because each step removes an ambiguity the next would otherwise encode:\n\n1. **Make canonical write failure hard-fail.** Replace the `console.warn` swallow; a failed\n   canonical write must not return `success: true`. _This is the highest-value single change\n   in the register — it converts silent data loss into a visible error._\n2. **Route canonical writes through the `SPINE` binding to Neon; delete `CANONICAL_SPINE_DB`.**\n   A second D1 canonical store is not needed and recreates the split it was meant to solve.\n3. **Move the 16-concept ontology into `packages/spine-entities`** (already consumed by\n   `services/spine`) and delete the copy-paste in `entity-type-map.ts`. One definition.\n4. Retire `services/pipeline/src/spine/` once 1–3 land.\n5. Stop using the word \"Spine\" unqualified in new code. It is _Canonical_ or _Operational_.\n\nSteps 1–3 also unblock the repo split (§15.5): a boundary cannot be drawn while the\ncanonical store on one side of it is a placeholder.\n\n**S0b · `org_memory` is a documented cache with six writers.**\n`d1_knowledge.sql:12` describes it as _\"Mirror of memory.org_memory for edge-fast reads.\"_\nSix services `INSERT`/`UPDATE` it directly — `pipeline/src/index.ts`,\n`pipeline/src/memory-promoter.ts`, `intelligence/src/memory/evolutionary-memory.ts`,\n`intelligence/src/handoff/outcome.ts`, `intelligence/src/workflows/triage-workflow.ts`,\n`mcp-connector/src/handlers/tools.ts` — and 23 files reference it. There is no defined\nreconciliation against the Postgres table it claims to mirror. This is S0 repeating one\nlayer up. It must become either the store or a cache, with one writer. (**M1**)\n\n**S0c · `agent_memory` exists only inside retired infrastructure.** Its sole definition is\n`services/pipeline/src/spine/index.ts:1360` — inside the Supabase legacy writer scheduled\nfor deletion. It needs a D1 table alongside `personal_memory` **before** step 4 above, or\nthe capability is lost with the file.\n\n### Tier 0b — Publication blockers\n\nVerified 2026-07-31. Each blocks marketplace submission; all but the last are configuration\nor copy. Detail: [MCP and Plugin Publishing\nSpec](../specifications/surfaces/MCP_AND_PLUGIN_PUBLISHING_SPEC.md).\n\n| #      | Finding                                                                                                                                                                                                                                                                                                                                   | Evidence                                                       |\n| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |\n| **F1** | **Two Workers claim `mcp.integratewise.ai`** — the top-level Worker and `env.prod` both bind the public custom domain. Last deploy wins; a routine default-env deploy silently repoints the public MCP endpoint. `validate-platform-deployment.sh` checks _existence_ of `mcp-connector-test`/`-prod`, not route uniqueness, so it passes | `services/mcp-connector/wrangler.toml:6, 226`                  |\n| **F2** | **The published manifest advertises 23 tools.** The `tools` array holds 19; the description says 23 — the connector count (20 operational + 3 cognitive) written as a tool count. Violates stop-ship invariant #2                                                                                                                         | `marketplace/apps/iw-spine-network.json`                       |\n| **F3** | **The public manifest names `mcp-pool` as its routing target.** Either the public path runs through the internal control plane, or the manifest is wrong and leaks internal topology. Both block                                                                                                                                          | `marketplace/apps/iw-spine-network.json` → `ownership.routing` |\n| **F4** | **MCP Pool has no `env.test`, and `env.dev` binds `integratewise-integration-management-mcp-prod`.** The development control plane talks to production, on the component with the most privilege                                                                                                                                          | `services/mcp-pool/wrangler.toml`                              |\n| **F5** | `iw-continuity-bridge.json` — a retired public name (**D9**) — sits in the publishable directory                                                                                                                                                                                                                                          | `marketplace/apps/`                                            |\n| **F6** | Five release flavours against a two-package doctrine, with no stated mapping                                                                                                                                                                                                                                                              | `releases/`                                                    |\n\n### Tier 1 — Correctness and security\n\n**S1 · A second, unauthenticated entry point sharing one database across surfaces.**\n`packages/api` (`hub-controller-api`) is bound by the Gateway in dev, test **and** prod — all\nthree to the same unsuffixed Worker with one D1 database. The Gateway explicitly skips its\nown authentication for every `/api/*` path that is not `/api/v1/*`. It carries `billing.ts`,\n`auth.ts` and `capability-routes.ts` — money, identity and capability execution. No deploy\nscript references it, so its deployed code is unversioned relative to the release ledger.\n_Violates Law 7 (one boundary), §14 (Gateway derives authority), §17 (test/prod isolation)._\n\n**S2 · Fifteen dangling service bindings.** The core nine were renamed from\n`integratewise-*` to bare names; consumers were never updated. These resolve to nothing at\nruntime.\n\n**S3 · Five test/prod binding leaks in the Gateway.** `HUB_CONTROLLER` and `MCP_POOL` point\nat identical targets in both environments. `validate-platform-deployment.sh` asserts only\n`mcp-connector` isolation, so none of this is caught by `release:check`.\n\n### Tier 2 — Restore a single truth\n\n**S8 · Three deployed Workers assert three different single sources of truth.**\n`services/pipeline` claims to be the only holder of Spine write credentials;\n`services/spine` claims to be the platform's single source of truth and holds `DATABASE_URL`\nplus a 995-line canonical store; `services/billing` asserts Supabase. Additionally\n`services/pipeline/src/spine/` is a second, self-labelled-legacy Spine implementation\n(2,773 LOC, Supabase-backed) that is live in the release path. _Violates §8.3 directly._\n`services/spine` is Gateway-bound and named canonical, yet is **not in `CORE_SERVICES`** — so\n`release:deploy --service core` never publishes it.\n\n**S4 · Four environment vocabularies.** Eight services still use retired\n`staging`/`production`; `signals` and `telemetry` have no test surface at all. Both root\n`wrangler.toml` and `wrangler.jsonc` are invalid and unused. `ci-cd.yml` is named DISABLED\nbut still contains seven direct `wrangler deploy` invocations — a second publication path.\n\n**S9 · Seventeen migration roots, 476 files, duplicate sequence numbers.** Ordering is\nambiguous in both `/migrations` (three collisions) and `/sql-migrations` (nine).\n\n### Tier 3 — Inert mass\n\n**S5 · Three Capability Fabric implementations, none of them the live one.**\n`packages/core` and `packages/lib/capability-fabric` are near-exact mirrors, ~35 files,\nmutually redundant and unreachable. The live path is\n`services/gateway/src/workbench-capabilities.ts` + `internal/capability-execution.ts` +\n`services/mcp-pool`.\n\n**S10 · A complete second, orphaned application root inside `apps/web`** (Vite entry, config\nand router, all committed and unreachable), plus 102 tracked `_deprecated` components.\n\n**S11 · Retired GCP/Firebase infrastructure still committed**, including\n`services/mcp-connector/src/lib/firestore.ts` inside a core release-path Worker.\n\n**S12 · Sixteen packages omit `private`,** which npm treats as publishable — including\n`packages/connectors` (~90 provider integrations) and `packages/core` (governance engine).\n\n### Tier 3b — Contradictory governance, and doctrine enforced by nothing\n\n**S5b · Two opposite promotion rules in one service.**\n`knowledge/src/triage-bot.ts:13` — _\"The Triage Bot **NEVER auto-stages.** Every\nextraction requires customer review.\"_\n`knowledge/src/synthesis/promotion-gate.ts:8` — _\"**AUTO-APPROVE:** High confidence + no\ngovernance flags + trusted domain\"_, with `decision: \"auto_approved\"` at lines 124 and 144.\n\nBoth are in `services/knowledge`. The never-auto-stage position is correct per §8.2c-i and\nthe Authority Law. `pipeline/src/memory-promoter.ts` (415 LOC, live, queue-driven) already\nimplements the right shape. `synthesis/promotion-gate.ts` is orphaned and should be deleted.\n\n**S5c · The synthesis pipeline targets a store that no longer exists.**\n`knowledge/src/synthesis/` — `triage-bot`, `promotion-gate`, `continuity-object-factory`,\n`lineage-tracker`, `knowledge-model` — is a complete, unreferenced pipeline built on\n**CouchDB**, superseded by the D1 memory tables. CouchDB survives in 11 files: three in\n`synthesis/`, three in `packages/coda-pack`, and **five in `packages/hermes-spine-memory`** —\nan entire package on retired infrastructure.\n\nSalvage before deleting: `lineage-tracker.ts` and its `UnderstandingObject` provenance model\nhave **no equivalent in the live path**. `memory-promoter.ts` writes an audit row but does\nnot track lineage across promotions. That is a real capability gap, not dead weight.\n\n**S5d · The canonical Authority Doctrine is in a package with zero consumers.**\n`packages/contracts/src/authority.ts` (228 LOC) declares itself _\"supersedes all other\narchitectural rules\"_ and states the Triage Boundary that settles S5b exactly. Verified:\n`@integratewise/contracts` has **0 importers**. The doctrine is exported as a template\nliteral — human-readable, machine-inert. Its neighbours share the fate, including\n`surfaces/chat.ts` (_\"The Chat surface IS the Triage Hub\"_) and `marketplace/installation.ts`\n(which `services/marketplace-installation` ignores in favour of its own types).\n\nA rule enforced by nothing is not a rule. Move `authority.ts` into `packages/types` (99\nconsumers) and convert the Triage Boundary into a test.\n\n### Tier 4 — Vocabulary and surface discipline\n\n**S6 · Retired L-layer vocabulary is the frontend's primary organising principle, and it\nleaks to users.** `components/l1/` is 240 files — the largest component tree in the repo —\nplus `l2/`, `l4/`, `l7/`, `layers/`. A product surface renders the literal string\n_\"12 L1 domain views + 14 L2 cognitive overlay components\"_. The Gateway exposes 19\n`/api/v1/cognitive/*` routes; \"cognitive\" is not a kernel term. Most seriously,\n`intelligence/src/agents/specialized/twin-orchestrator.ts` embeds _\"CODA L4 & MCP TOOLS…\nCoda documents are connected L4 projection surfaces\"_ **inside a live LLM system prompt** —\nso retired vocabulary is shaping the Twin's reasoning, not merely sitting in comments.\n_Violates Law 8 and §6._\n\n**S7 · The Workbench is not one surface.** Four parallel entry namespaces resolve to\nWorkbench content: `/workbench/[department]/work/[module]`,\n`/workspace/[department]/work/[module]`, `/domains/[domain]/[view]`, `/app/[...segments]`.\nThe first two page files are byte-identical except for one route string. Separately,\n`components/capability-shell/`, `inline-executor/` and `proactive-capabilities/` place a\ncapability catalogue and executor inside the Workbench. _Violates §11.2 and Law 6._\n\n**S13 · Naming collisions.** `packages/adapters` (infrastructure) vs\n`packages/connectors/src/adapters` (providers); two \"accelerator\" concepts; two Twin\norchestrators (a 3,470-LOC Worker with zero inbound bindings, and a 268-LOC agent); two\ncontract homes; two marketing implementations, of which the `legacy-pages` set is the live\none.\n\n**S15 · Canonical documentation is itself a sprawl surface.** 94 documents in\n`docs/architecture/`, 16 declared canonical, six with \"canonical\" in the filename. _This\ndocument is the remediation._\n\n### Schema gaps against the store model\n\nVerified at HEAD on 2026-07-31 against the six-store assignment in §8.2b:\n\n| Column                    | Purpose                                                       | State                   |\n| ------------------------- | ------------------------------------------------------------- | ----------------------- |\n| `embedding_id`            | Vectorize reference on the entity                             | Present (7 files)       |\n| `r2_key`                  | R2 reference on attachments                                   | Present, thin (2 files) |\n| `memory_scope`            | user · work · org (§8.2c)                                     | Present, thin (2 files) |\n| `conversational_store_id` | Raw conversational memory reference on inbox items            | **Missing**             |\n| `source_records`          | Cross-source provider fragments on assembled entities (§8.2e) | **Missing**             |\n\nChunking is confirmed at 512 tokens (`services/knowledge/src/embeddings.ts:122`). Durable\nObjects are declared across six services — `intelligence`, `iw-agent-runtime`, `hermes`,\n`connector-sync`, `folder-watcher`, `workflow`.\n\n### Tier 5 — Orphans requiring a verdict\n\nSeveral substantial Workers remain outside the nine-service `CORE_SERVICES` release path,\nincluding `agent-registry`, `hermes`, `integration-management-mcp`,\n`marketplace-installation`, `provider-management-mcp`, `schema-ai`, `signals`, `telemetry`,\n`twin-orchestrator` and `vercel-mcp`. Presence outside that list is not proof of\nunreachability, but it means the canonical release does not deploy or validate them as one\nclosed runtime.\n\n**`hermes` is stage 11 of the frozen runtime sequence but is not a core release service.**\nGateway declares Hermes routes and test/production service bindings, while the development\nbinding is commented out. Therefore repository routing is **partial**, not a verified\nend-to-end execution path. This is the most significant gap between Part II and reality:\napproval → Hermes → provider → receipt → reconciliation needs a live trace from the same\nrelease manifest.\n\n## 21. Open decisions\n\nGenuine forks, not deferred work. Each blocks something.\n\n| #       | Decision                                                                         | Blocks                             | Note                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n| ------- | -------------------------------------------------------------------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **D1**  | Is `plugin_host` a peer surface or a reduced companion to the browser Workbench? | Plugin channel implementation      | Changes what \"one Workbench\" means. A constrained host panel cannot render six groups and forty items                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |\n| **D2**  | Does `Platform` become one gated destination or twenty-two sidebar entries?      | Navigation consolidation           | §11.2 records the recommendation (one destination); `packages/workbench-config` currently asserts the opposite                                                                                                                                                                                                                                                                                                                                                                                                                                                        |\n| **D3**  | How is the Industry axis derived — tenant Spine schema, or explicit config?      | `workbench-config` shape           | 12 roles × ~12 departments × N industries cannot be enumerated statically                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |\n| ~~D4~~  | ~~Which Spine writer survives?~~                                                 | —                                  | **RESOLVED 2026-07-31.** Neither was writing. Canonical = Neon via the `SPINE` binding; Operational = D1 in `services/spine`; Pipeline is the sole canonical writer. See **S0**                                                                                                                                                                                                                                                                                                                                                                                       |\n| **D5**  | Does `development` get its own tenant, or is it `customer_zero` on `test`?       | Profile resolution                 | §15.3 permits either                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n| **D10** | Are the Customer Zero Supabase migrations part of the Spine?                     | Store model, S8                    | A 2026-07-22 store mapping describes 34 Supabase migrations as _\"the Postgres partition of the Spine.\"_ `SOURCE_PACK_RECONCILIATION` (07-28) states Supabase **is not in the frozen product path**, and S8 flags two live Supabase-backed writers. Later date wins; the mapping's storage framing is superseded even where its data-class assignment is sound                                                                                                                                                                                                         |\n| ~~D7~~  | ~~Is Co-worker a distinct agent or Twin behaviour?~~                             | —                                  | **RESOLVED — it was already decided twice.** `docs/wiki/21-adrs…md:66` records _\"'Co-worker' as a second runtime → Twin is the contextual AI Co-worker behavior\"_ as a superseded concept, and `packages/contracts/src/authority.ts` states the boundary: Twin understands context · Co-worker performs bounded prepared work · Human owns authority. **Co-worker is a behavioural mode of the Twin** — never a type, table, service or route. Good positioning language in user-facing copy; not a second runtime. The Host-Aware Spec §11 listing should be amended |\n| **D11** | Clerk or Descope as the browser identity authority?                              | §14, every onboarding path         | **Live conflict.** §14 declares Clerk canonical, following `IMPLEMENTATION_CONTRACT_v1.1` §3, which also states _\"Descope browser-session paths are legacy compatibility only.\"_ A more recent Customer Zero decision selects **Descope** for Magic Link and OTP. Both cannot be authoritative. Resolve before any marketplace listing — identity is the first state in the onboarding machine, and a fork here forks both channels                                                                                                                                   |\n| **D12** | Does “tenant-specific Spine schema” require physical database/schema isolation, or a tenant-scoped activated logical schema/profile over shared typed tables? | Onboarding, tenancy, migrations and isolation claims | This document requires the tenant-specific logical contract. The current code predominantly uses shared tables plus `tenant_id`; a stronger physical boundary must be chosen deliberately and proven operationally, not implied by wording. |\n| **D13** | Which implementations own Twin/ADK orchestration, context assembly and capability resolution in the canonical release? | Silent Twin, agent continuity and runtime closure | `twin-orchestrator`, `iw-agent-runtime`, `intelligence`, `context-fetch`, `packages/adk` and multiple capability registries overlap. Choose and wire owners; do not declare all of them canonical simultaneously. |\n| ~~M1~~  | ~~`org_memory`: store or cache?~~                                                | —                                  | **RESOLVED.** Neon `memory.org_memory` is the store; the D1 table is a projection fed by the transactional outbox; the promotion gate is the only writer. The other five services become read-only consumers                                                                                                                                                                                                                                                                                                                                                          |\n| **M2**  | Does a `team` memory scope exist?                                                | `gateway/src/memory-governance.ts` | Currently a type with no backing table anywhere. If wanted, it is a new scope decision — not an orphaned type file                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| ~~M3~~  | ~~May agent memory be cited before triage?~~                                     | —                                  | **RESOLVED.** The Twin may cite agent memory **within its own scope**. It may not let agent memory inform an organisational-level claim until that material has passed triage and promotion                                                                                                                                                                                                                                                                                                                                                                           |\n| **M4**  | Does Personal Memory ever widen to Org, and by what act?                         | §8.2c                              | The hard boundary is currently absolute, and that is defensible                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |\n| **M5**  | Canonical Spine on Neon only, or Neon plus a D1 read projection?                 | S0 step 2                          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |\n| **M6**  | Is the Chat surface the Triage Hub, per `contracts/src/surfaces/chat.ts`?        | Sidebar structure, §11.2           | Better than a separate Triage nav entry; connects `Personal → Brainstorming Sessions` to the pipeline                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |\n| ~~D8~~  | ~~Repository structure~~                                                         | —                                  | **RESOLVED 2026-08-02.** Consolidated into **single monorepo** (`integratewise-live`). Platform kernel lives in `packages/` (contracts, connectors, spine-schema, adk, kernel). Product surfaces live in `apps/` (web, platform, one-access). Three invokable microfrontends: `@integratewise/auth-connectors-mfe`, `@integratewise/auth-onboarding-mfe`, `@integratewise/platform-mfe`. See [MICROFRONTENDS.md](MICROFRONTENDS.md)                                                                                                                                   |\n| ~~D9~~  | ~~Is `IW-Continuity-Bridge` a live product name?~~                               | —                                  | **RESOLVED 2026-08-13.** IntegrateWise is the company; **SpineWorkspace** is the product. “IW Continuity Bridge” is historical. IW-Spine-Network remains a distribution/package contract, not the browser product name. |\n| ~~D6~~  | ~~MCP Pool: one control plane or three per-profile pools?~~                      | —                                  | **RESOLVED 2026-07-31.** One control plane. The public MCP surface is byte-identical across all three profiles; Pool is an operator control plane whose _administration UI_ is exposed only in `development` and `customer_zero`. Pool is never a tool surface, never a public route, and never named in a published artifact. `MCP_POOL_MULTI_ENVIRONMENT_STRATEGY.md` is superseded. See [MCP and Plugin Publishing Spec](../specifications/surfaces/MCP_AND_PLUGIN_PUBLISHING_SPEC.md)                                                                             |\n\n## 22. Change discipline\n\n**Before adding a concept.** Name the responsibility it owns using only the twelve kernel\nterms. If you cannot, it is either duplication of an existing primitive or a genuine major\nversion — and a major version is a founder decision, not a pull request.\n\n**Before renaming.** Record which of five things is happening: _fundamental · evolved ·\nrenamed · superseded · experimental_. Mixing these is how documents start conflicting. Every\nrename goes in [Appendix J](#appendix-j--vocabulary-ledger).\n\n**Before shipping.** Does the surface stay narrow? New platform capability should rarely\nproduce a new user-facing noun. Broad underneath, narrow at the surface.\n\n**When documents disagree.** Explain the evolution; never mix eras. Optimise for\narchitectural fidelity, not document fidelity. Documents are snapshots; the architecture is\nthe living system.\n\n**When this document is wrong.** Change it here. Do not write a second document. The reason\nthis consolidation exists is that the alternative was tried ninety-four times.\n\n## 23. Implementation handoff — what happens next\n\nWork may start immediately on contract tests, inventory and removal of known bypasses.\nDecisions D11–D13 must be confirmed before identity, physical tenancy or Twin/ADK ownership\nis frozen. Source material not present in this checkout is handled as a later reconciliation\npass, not a reason to delay this authority lock.\n\n| Phase | Depends on | Concrete work | Exit evidence |\n| --- | --- | --- | --- |\n| **0. Authority lock** | v3.0 | Encode company/product naming, work-allocation doctrine, Spine Fabric boundary and public/internal taxonomy | One authority + amendment; terminology and boundary tests pass |\n| **1. Identity/tenant/consent** | D11 and relevant D12 choice | One Flow D machine across browser/plugin/MCP; tenant/workspace/schema activation; ingestion gate | Negative auth/tenant/RBAC tests and identity-to-`ingestion_enabled` trace |\n| **2. Spine/ingestion** | Phase 1 | Freeze writer and stores; A/B/C Loader/Normalizer; outbox; phased hydration | No direct Fortress access; provenance-bearing initial/backfill traces |\n| **3. Projection mappings** | Phases 1–2 | Turn §11.7 into checked entity/view/action ownership registry | All 18 projections pass route, entity, field, role, freshness and invalidation tests |\n| **4. Workbench** | Phase 3 | One shell; task views; tables/documents/messages/canvases; active context | Acceptance for allowed role hosts; internal projections hidden from external tenants |\n| **5. Governed actions/sync** | Phases 2–4 | Signed approval, Hermes wiring, receipts, ambiguity handling and re-ingestion | Real provider mutation closes approval → source → reconcile → refresh with audit |\n| **6. Twin/Coworker/continuity** | Phases 2–5 | Select runtime owners; user Twin Workbench; AI Sandbox; work assignment layer; Coworker context/communication; bounded Flow C | No-direct-canonical-access proof, sandbox isolation, assignment/reconciliation proof and cross-host tenant isolation |\n| **7. Distribution** | Phases 1–6 | Browser product, plugin/MCP packages, marketing handoff, connector expansion | Clean install, first grounded value and first governed outcome |\n| **8. Operate/release** | All | Observability, SLOs, deletion/export/revocation, rollback and isolation | Development → Customer Zero → clean external tenant; every §17.2 gate passes |\n\nCan start now: authority/link checks, projection contract generation, approval-bypass and\ndirect-writer tests, public/internal taxonomy tests, reachability inventory and a real\nconnector harness. Confirm first: D11, D12, D13, overlapping projection audiences and the\nremaining open decisions in §21.\n\n---\n\n# Appendices\n\n## Appendix A — Kernel terms\n\nSee [§3](#3-the-kernel-vocabulary). The v3.0 kernel is: ORGANIZATION · GOAL · WORK · WORK GRAPH ·\nCONTEXT · MEMORY · SPINE FABRIC · PROJECTION · WORKBENCH · TWIN · COWORKER · AI SANDBOX · WORK\nALLOCATION · CAPABILITY · GOVERNANCE · EXECUTION FABRIC · HERMES · RECONCILIATION · CONTINUITY ·\nOUTCOME.\n\n## Appendix B — Runtime sequence\n\n### Product loop\n\n```text\nOrganization Goal / Need → Work Graph → Shared Context → Context Assembly\n→ Work Allocation → Human + AI Work → Decide → Execute → Verify\n→ Reconcile → Continuity / Memory → Next Work\n```\n\n### Platform loop\n\n```text\nConfiguration → Identity / Tenant Binding → Connectivity → Ingestion\n→ Normalization → Spine Fabric → Projection / AI Sandbox\n→ Capability → Governance → Execution Fabric / Hermes → Provider\n→ Outcome → Re-ingestion → Reconciliation → Promotion / Continuity\n```\n\n### Twin reasoning loop\n\n```text\nObserve → Orient → Decide → Act\n```\n\nOODA is subordinate to the product Work Operating Loop.\n\n## Appendix C — Services\n\n**Core nine (canonical publication order, Gateway last):**\n\n| Worker           | Responsibility                                                                  |\n| ---------------- | ------------------------------------------------------------------------------- |\n| `pipeline`       | Normalizer + Spine writer. Self-declared sole holder of Spine write credentials |\n| `connector`      | Compatibility router → loader · store · mcp-connector                           |\n| `mcp-connector`  | MCP tool server + OAuth authorisation server                                    |\n| `connector-sync` | Schema-driven scheduled and on-demand provider sync                             |\n| `knowledge`      | Chunking, embedding, search, synthesis, promotion gate, lineage                 |\n| `continuity`     | Append-only session event log, checkpoints, continuity assembler                |\n| `intelligence`   | think + act + govern + agents                                                   |\n| `workflow`       | Bound as `BFF`. Views, analytics, stream gateway, HITL Durable Object           |\n| `gateway`        | Single entry point                                                              |\n\n**Bound but outside the release path:** `spine` (`SPINE`) · `iw-agent-runtime`\n(`AGENT_RUNTIME`) · `webhook-ingress` · `mcp-pool` · `admin` · `billing` · `tenants` ·\n`folder-watcher` · `loader` · `store` · `task-management`\n\n**Zero inbound bindings:** `agent-registry` · `hermes` · `integration-management-mcp` ·\n`marketplace-installation` · `provider-management-mcp` · `schema-ai` · `signals` ·\n`telemetry` · `twin-orchestrator` · `vercel-mcp`\n\n## Appendix D — Gateway routes\n\n| Route                                | Target                   | Purpose                                      |\n| ------------------------------------ | ------------------------ | -------------------------------------------- |\n| `/api/v1/auth`                       | INTERNAL_AUTH            | Authentication                               |\n| `/api/v1/projections`                | INTERNAL_PROJECTIONS     | Projection Engine                            |\n| `/api/v1/workspace/discovery`        | Gateway → Spine          | First canonical read                         |\n| `/api/v1/workspace/*`                | BFF                      | Workspace operations                         |\n| `/api/v1/billing`                    | INTERNAL_BILLING         | Billing                                      |\n| `/api/v1/tenants`                    | INTERNAL_TENANTS         | Tenant management                            |\n| `/api/v1/support`                    | INTERNAL_SUPPORT         | Support                                      |\n| `/api/v1/analytics`                  | BFF                      | Analytics                                    |\n| `/api/v1/agents`                     | INTELLIGENCE             | Agent management                             |\n| `/api/v1/continuity-bridge`          | MCP_CONNECTOR            | Public 19-tool Spine MCP                     |\n| `/api/v1/connectors`                 | CONNECTOR                | Connector management                         |\n| `/api/v1/pipeline`                   | PIPELINE                 | Data pipeline                                |\n| `/api/v1/intelligence`               | INTELLIGENCE             | Intelligence layer                           |\n| `/api/v1/cognitive/spine`            | PIPELINE                 | Spine operations                             |\n| `/api/v1/cognitive/entity360`        | PIPELINE                 | Entity 360                                   |\n| `/api/v1/cognitive/memories`         | KNOWLEDGE                | Memory operations                            |\n| `/api/v1/cognitive/signals`          | INTELLIGENCE             | Signal processing                            |\n| `/api/v1/cognitive/think`            | INTELLIGENCE             | Think / Twin                                 |\n| `/api/v1/cognitive/act`              | INTELLIGENCE             | Act execution                                |\n| `/api/v1/cognitive/govern`           | INTELLIGENCE             | Governance                                   |\n| `/api/v1/cognitive/twin`             | AGENT_RUNTIME            | Twin runtime                                 |\n| `/api/v1/knowledge`                  | KNOWLEDGE                | Knowledge management                         |\n| `/api/v1/marketplace/installations*` | MARKETPLACE_INSTALLATION | Onboarding state machine                     |\n| `/api/v1/marketplace/apps`           | SPINE                    | Catalogue (Spine data)                       |\n| `/api/v1/l2`                         | L2                       | Cognitive overlay _(retired label — see S6)_ |\n| `/admin`                             | INTERNAL_ADMIN           | Admin                                        |\n| `/oauth`                             | INTERNAL_AUTH            | OAuth flows                                  |\n| `/ws`, `/sse`, `/stream`             | BFF                      | Real-time                                    |\n\nEndpoint ownership by intent:\n\n| Intent                                       | Family                        | Owner                                             |\n| -------------------------------------------- | ----------------------------- | ------------------------------------------------- |\n| Discover product                             | `/api/v1/workspace/discovery` | Gateway + Configuration + Activation + Projection |\n| Onboard / configure / activate               | `/api/v1/workspace/*`         | Configuration + Activation                        |\n| Browse / connect / sync / revoke             | `/api/v1/connectors/*`        | Integration Manager                               |\n| Compose Workbench, Inbox, Entity 360, canvas | `/api/v1/projections/*`       | Projection Engine                                 |\n| Read knowledge / evidence                    | `/api/v1/knowledge/*`         | Knowledge and evidence services                   |\n| Ask / assign Twin                            | Semantic Twin routes          | Twin runtime — drafts only                        |\n| Approve / reject / execute                   | Governance command routes     | Governance → Hermes                               |\n\n## Appendix E — Gateway bindings\n\n| Category | Binding                                                                                                                                                                                                                   | Type                                     |\n| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |\n| Database | `DB`                                                                                                                                                                                                                      | D1Database (`integratewise-spine-cache`) |\n| KV       | `RATE_LIMITS`, `SESSIONS`, `CONNECTOR_STATUS`, `SIGNAL_CACHE`, `METRICS`, `OAUTH_STATE_KV`                                                                                                                                | KVNamespace                              |\n| R2       | `FILES`                                                                                                                                                                                                                   | R2Bucket                                 |\n| Services | `CONNECTOR`, `CONNECTOR_SYNC`, `PIPELINE`, `INTELLIGENCE`, `KNOWLEDGE`, `BFF`, `L2`, `AGENT_RUNTIME`, `ADMIN`, `BILLING`, `TENANTS`, `WEBHOOK_INGRESS`, `HUB_CONTROLLER`, `SPINE`, `MCP_POOL`, `MARKETPLACE_INSTALLATION` | Fetcher                                  |\n\nIsolation invariant: no `env.test` target may equal any `env.prod` target, for any binding\nclass. `validate-platform-deployment.sh` currently asserts this only for `mcp-connector`.\n\n## Appendix F — Canonical entities\n\n| Entity        | Source                                      |\n| ------------- | ------------------------------------------- |\n| Connection    | `packages/spine-entities/src/connection.ts` |\n| Connector     | `packages/spine-entities/src/connector.ts`  |\n| SyncJob       | `packages/spine-entities/src/sync-job.ts`   |\n| Webhook       | `packages/spine-entities/src/webhook.ts`    |\n| Schema        | `packages/spine-entities/src/schema.ts`     |\n| Capability    | `packages/spine-entities/src/capability.ts` |\n| TimelineEvent | `packages/spine-entities/src/timeline.ts`   |\n\nTenant lifecycle families: `spine_organizations` · `spine_workspaces` · `spine_users` ·\n`spine_memberships` · `spine_roles` · `spine_permissions` · `spine_tenant_accounts` ·\n`spine_networks`. Generic `spine_entities` remains the compatibility graph and identity\nlayer; typed tables are the canonical materialised home for their families.\n\nEntity contract (frozen): identity · fields · relationships · timeline · provenance ·\npermissions · capabilities.\n\n## Appendix G — Connector lifecycle\n\n```\nPublish connector definition → discover / install → resolve identity and tenant\n→ reuse eligible connection or request consent → store opaque credential reference\n→ create tenant/workspace connection binding\n→ discover provider objects, fields, events, operations\n→ approve schema / entity / capability mappings\n→ activate initial hydration and delta sync\n→ Pipeline promotes entities, relationships, provenance, evidence\n→ Projection Engine invalidates and recompiles permitted views\n→ monitor, repair, revoke, reconcile\n```\n\nThe binding must deterministically resolve:\n\n```\n(user_id, tenant_account_id, tenant_id, spine_network_id, provider_key,\n provider_workspace_id, connector_binding_id, spine_connection_id, schema_binding_set)\n```\n\nConnector installation registers mappings, sources, availability and approved additive\nextensions. **It does not execute ad-hoc physical DDL.**\n\n## Appendix H — Public 19 tools\n\n`get_my_continuity` · `get_active_context` · `get_my_focus` · `get_context` · `get_changes` ·\n`get_related` · `get_history` · `get_commitments` · `get_decisions` · `get_permitted_memory` ·\n`get_relevant_knowledge` · `ask_twin` · `assign_twin` · `get_prepared_work` ·\n`get_available_actions` · `prepare_action` · `get_action_plan` · `approve_action` ·\n`store_in_spine`\n\n## Appendix I — Stop-ship invariants\n\nA release is not aligned if any of the following is true:\n\n1. The browser selects a legacy identity provider while Clerk is configured\n2. The public MCP lists anything other than the exact 19 tools\n3. The Plugin claims automatic inheritance of other host-app credentials, or the MCP lane\n   omits its standalone browser Workbench / fallback path\n4. A UI or Twin route writes Neon directly\n5. D1 is described or used as canonical business truth\n6. A failed live projection silently becomes demo data\n7. A material write executes without a proposal, a policy decision, a receipt and a\n   reconciliation — on **any** route, host-native or IntegrateWise-native\n8. A provider connector is copied into a product repository\n9. The user must explain context already present in the Spine Network\n10. L1/L2/L4/L7 appear as user-facing product navigation\n11. A host, MCP client, frontend or agent queries Fortress storage directly\n12. An answer claims cross-system completeness without reporting `canonical` completeness or\n    disclosing the systems it could not see\n13. Declared host capability is routed to without runtime confirmation\n14. The same provider is called through both host and IntegrateWise by default\n15. A write path returns `success` when the canonical write was skipped, failed, or landed\n    only in a cache\n16. Any automated path can write `governance_state = 'approved'` without an approver identity\n17. A component writes synchronously to both the Spine and a projection\n18. An AI classifier establishes source identity or canonical identity on its own\n19. An agent promotes a rule into autonomous execution\n20. A response conveys uncertainty as a guessed value rather than an explicit state\n\nAdditionally, per §17: no test/prod resource sharing of any binding class, and no Worker\npublication outside `Release Core Workers`.\n\n## Appendix J — Vocabulary ledger\n\n| Retired                                         | Current                                                          | Status                                                                                                            |\n| ----------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| Cognitive OS · IntegrateWise OS · AI OS         | IntegrateWise Platform                                           | Superseded — category                                                                                             |\n| OS Shell · Views · Topic Boards                 | Workbench                                                        | Renamed — one surface                                                                                             |\n| Atlas Spine                                     | Spine Fabric                                                   | Renamed                                                                                                           |\n| 16 AI Agents (named personas)                   | Capabilities in the Capability Fabric                            | Superseded — taxonomy retired                                                                                     |\n| Cognitive Twin · AI assistant · copilot         | Twin                                                             | Renamed — silent by default                                                                                       |\n| Co-worker (as separate runtime)                 | Twin                                                             | Superseded — one runtime                                                                                          |\n| Normalizer · Hermes (external use)              | _(internal only)_                                                | Never customer-facing                                                                                             |\n| IW Continuity Bridge                            | IntegrateWise / Continuity Bridge (internal)                     | Retired public name                                                                                               |\n| TenantClass                                     | Profile                                                          | Renamed — it was a runtime property, not a tenant property                                                        |\n| L1 / L2 / L4 / L7                               | Workbench / Twin / Continuity / Governance                       | Engineering-internal only; never user-facing                                                                      |\n| `/api/v1/cognitive/*`                           | _(unresolved)_                                                   | \"Cognitive\" is not a kernel term — rename or sanction as an alias                                                 |\n| Brain _(as a write destination or truth store)_ | Brain — a reasoning and learning **projection** used by the Twin | Never a second store. The durable path is `Spine → Twin proposal → Governance → Hermes → re-ingestion into Spine` |\n\n## Appendix K — Path to alignment\n\nThe ordered sequence that closes the gap between Part II and Part III. Ordering is not\narbitrary: each step removes an ambiguity the next step would otherwise encode.\n\n| #   | Step                                                                                                                                                                                                                                                  | Closes                                                                                            |\n| --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |\n| 0   | **Make canonical write failure hard-fail** instead of `console.warn` + `success: true`; route canonical writes through `SPINE` to Neon; delete `CANONICAL_SPINE_DB`                                                                                   | **S0 — silent data loss.** Nothing else in this table matters if canonical writes are not landing |\n| 1   | Close the `hub-controller-api` bypass — fold into `services/` behind Gateway auth with isolated test/prod D1, or delete the catch-all route and the bypass branch                                                                                     | S1                                                                                                |\n| 2   | Repair the 15 dangling bindings and 5 test/prod leaks; extend `validate-platform-deployment.sh` to assert, for every binding class, that no `env.test` target equals any `env.prod` target and that every `service =` resolves to a declared `name =` | S2, S3 — and converts them into a permanently-caught error class                                  |\n| 3   | Decide the Spine writer (**D4**); retire the loser; add `spine` to `CORE_SERVICES`                                                                                                                                                                    | S8                                                                                                |\n| 4   | Wire or formally retire `hermes` — it is stage 11 of the frozen sequence and currently unreachable                                                                                                                                                    | Tier 5                                                                                            |\n| 5   | Normalise environment vocabulary to `dev`/`test`/`prod`; delete both root wrangler configs and `ci-cd.yml`                                                                                                                                            | S4                                                                                                |\n| 6   | Consolidate the migration ledger to one root, one sequence, no duplicate numbers                                                                                                                                                                      | S9                                                                                                |\n| 7   | Consolidate frontend calls on `NEXT_PUBLIC_IW_API_URL` and one typed Gateway client; remove production localhost and direct-service fallbacks                                                                                                         | §16.3                                                                                             |\n| 8   | Complete live deployment plus negative tenant/RBAC and frontend acceptance for `/api/v1/workspace/discovery`                                                                                                                                          | §16.3                                                                                             |\n| 9   | Rename the L-layer trees; fix the rendered string in `releases-view.tsx`; **rewrite the L4 passage in the Twin's system prompt**; resolve `/api/v1/cognitive/*`                                                                                       | S6                                                                                                |\n| 10  | Collapse to one Workbench URL namespace; remove the capability catalogue and executor from the Workbench                                                                                                                                              | S7                                                                                                |\n| 11  | Delete inert mass — dead Capability Fabrics, orphaned Vite root, `_deprecated`, retired GCP surfaces, zero-consumer packages                                                                                                                          | S5, S10, S11                                                                                      |\n| 12  | Add `\"private\": true` to the 16 unmarked packages; make `release:packages:check` fail on any non-private package other than `sdk` and `spine-schema`                                                                                                  | S12                                                                                               |\n| 13  | Complete one connector end to end: consent → strict binding → discovery → schema mapping → hydration → delta sync → revoke → projection invalidation                                                                                                  | §16, Appendix G                                                                                   |\n| 14  | Validate the full four-button governed loop: proposal → approval token → Hermes → provider outcome → re-ingestion → reconciliation → projection refresh                                                                                               | §10                                                                                               |\n| 15  | Validate Development → Customer Zero → Customer Production promotion with isolated credentials, data, bindings, queues, caches, evidence and audit                                                                                                    | §17                                                                                               |\n\n**Integrated-testing gate.** Do not begin the integrated testing event until every item below\nhas evidence. Any missing item is a blocker, not post-launch cleanup:\n\nenvironment/DNS/identity/Gateway/Neon/R2/D1/KV/queue/secret health · migration ledger and\nschema verification · cross-tenant and cross-environment negative tests · first-read\ndiscovery and every visible sidebar projection contract · one real connector through the full\nlifecycle · public MCP OAuth and exact 19-tool listing · no automatic inheritance of unrelated\nhost-app credentials · no direct frontend database/provider/internal-MCP traffic · explicit\npartial and degraded states with no live-to-demo fallback · one complete governed action\ntrace · bounded retry, ambiguous-outcome protection, dead letter and governed replay ·\nobservability, audit, rollback and revocation evidence.\n\n## Appendix L — Document disposition\n\n`docs/architecture/` held 94 entries at consolidation. Their disposition:\n\n### Canonical amendment\n\n[`SPEC_AMENDMENTS_v1.md`](SPEC_AMENDMENTS_v1.md) is the one canonical amendment to this\ndocument. Where it makes an explicit correction, the amendment wins. It is not a subordinate\nretained implementation specification.\n\n### Retained — still authoritative in their own scope\n\nDetailed specifications this document summarises. Each remains the reference for its\nimplementation detail and is subordinate to this document.\n\n`APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md` · `CANONICAL_SPINE_SCHEMA_FOUNDATION.md` ·\n`SPINE_ENTITY_TABLE_SCHEMA.md` · `TENANT_LIFECYCLE_SCHEMA_REGISTER.md` ·\n`TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md` · `WORKBENCH_ROLE_CAPABILITY_MAP.md` ·\n`IW_SPINE_NETWORK_PLUGIN_AND_MCP_MARKETPLACE_CONTRACT.md` ·\n`FRONTEND_PLATFORM_API_AND_DISCOVERY_SPEC.md` · `RUNTIME_SUBSTRATE_AND_SURFACE_CONTRACT.md` ·\n`CODEBASE_EXCAVATION.md` (the drift baseline; Part III derives from it) ·\n`HOST_AWARE_CONTINUITY_RUNTIME_SPEC.md` (frozen 2026-07-29 — the normative source for\n§15.5–15.8: request classification, capability resolution, connection binding, agent\ncontracts, Loader/Normalizer schemas, failure matrix and acceptance criteria) ·\n`SPINEWORKSPACE_INFORMATION_ARCHITECTURE.md` (host/navigation implementation detail,\nsubordinate to §11.7 and §16.3a)\n\n### Absorbed — content now lives here; archive\n\n`ARCHITECTURE_LOCK.md` · `IMPLEMENTATION_CONTRACT_v1.1.md` ·\n`CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md` · `PLATFORM_LOCK_v1.0.md` ·\n`FOUR_BUTTONS.md` · `TWIN_BEHAVIOR.md` · `WORKBENCH_MATRIX.md` · `ADAPTIVE_SPINE_MODEL_v1.md` ·\n`CAPABILITY_FABRIC.md` · `SOURCE_PACK_RECONCILIATION_2026-07-28.md` ·\n`RUNTIME_PROFILE_AND_ENTRY_CHANNEL_CONTRACT.md` · `CANONICAL_ARCHITECTURE.md` ·\n`MASTER_EXECUTION_PLAN.md` · `PRODUCT_PLATFORM_BOUNDARY_AND_GO_LIVE_STANDARD.md` ·\n`PLATFORM_PRODUCT_DATA_AND_PROJECTION_REFERENCE.md` ·\n`CUSTOMER_ZERO_TO_EXTERNAL_PRODUCT_AND_MARKETPLACE_SPEC.md` ·\n`CUSTOMER_ZERO_HOSTED_PLUGIN_CODE_BRIEF.md` · `BROWSER_FRONTEND_AND_MCP_PRODUCT_CODE_BRIEF.md`\n\n### Constitutions — absorbed into Parts I and II\n\nThe nine constitutions each stated the doctrine for one subsystem. Their content is now\ndistributed across §2–§16.\n\n`ADAPTIVE_WORKBENCH_CONSTITUTION.md` · `CANONICAL_ENTITY_CONSTITUTION.md` ·\n`CAPABILITY_CONSTITUTION.md` · `CONNECTOR_CONSTITUTION.md` · `EXECUTION_CONSTITUTION.md` ·\n`GOVERNANCE_CONSTITUTION.md` · `PROJECTION_CONSTITUTION.md` · `RUNTIME_CONSTITUTION.md` ·\n`TWIN_CONSTITUTION.md` · `CUSTOMER_ZERO_CONSTITUTION.md` (DRAFT) ·\n`CUSTOMER_ZERO_DAILY_OPERATING_MANUAL.md` (DRAFT)\n\n### Superseded — already marked, or superseded by this document\n\n`CANONICAL_PLATFORM_ARCHITECTURE.md` · `CANONICAL_SPINE_CONVERGED.md` ·\n`CANONICAL_ARCHITECTURE_V4.md` · `PRODUCT_ARCHITECTURE.md` · `PRODUCT_ARCHITECTURE_V1.md` ·\n`USER_SYSTEM_JOURNEY_BLUEPRINT.md` · `PLATFORM_ARCHITECTURE.md` · `END_TO_END_ARCHITECTURE.md` ·\n`SINGLE_END_TO_END_MAP.md` · `FRONTEND_LAYERED_STACK.md` · `PLANE_LAYER_CROSS_REFERENCE.md` ·\n`PROJECTION_MODEL.md` · `PROJECTION_CONTEXT_REFACTOR.md` · `SPINE_MODEL.md` ·\n`SPINE_DOMAIN.md` · `ENTITY360_V2_MODEL.md` · `UNIFIED_GOVERNANCE_SPEC.md` ·\n`WORKBENCH_DOCTRINE.md` · `MULTI_PROTOCOL_PLATFORM.md` · `ONBOARDING_FLOW.md` ·\n`CURRENT_CONTEXT_FLOW.md` · `DETAILED_USER_FLOWS_AND_SYSTEM_PATHS.md` ·\n`AI_CONNECTOR_MCP_FLOW.md` · `CONNECTOR_RUNTIME_PROOF.md` · `SPINE_INTELLIGENCE_AGENT.md` ·\n`LONG_TERM_TASK_MANAGEMENT_MCP.md` · `CODEBASE_ALIGNMENT_SPEC.md` ·\n`ARCHITECTURE_DOCUMENTATION_PLAN.md` · `DOCUMENTATION_COMPLETION_MANIFEST.md` ·\n`APP_CATEGORY_ENTITY_DOMAIN_MODEL.md` (+ `.txt` duplicate) ·\n`ONE_AUTH_WORKBENCH_PLATFORM_REFERENCE_ARCHITECTURE.md` (source provenance only) ·\n`TOTAL_END_STATE_CONTRACT.md` and its JSON (reference-only enforcement lineage)\n\n### Lineage — historical, retain in `docs/archive/`\n\nThe v2 deep-dive family and the locked-v1 lineage. Valuable as evolution record; not\nauthority.\n\n`integratewise-architecture-v2.0.md` · `v2-ai-capability-fabric.md` · `v2-capability-layer.md` ·\n`v2-continuity-governance.md` · `v2-data-model.md` · `v2-deployment.md` · `v2-ecosystem.md` ·\n`v2-identity-ingress.md` · `v2-provider-fabric.md` · `v2-security.md` · `locked-v1.md` ·\n`locked-v1.0.1.md` · `final-e2e-system.md` · `l1-reality-check.md` · `reality-audit.md` ·\n`one-full-prompt.md` · `suite-00-34.md` · `source/`\n\n### Unresolved\n\n`MCP_POOL_MULTI_ENVIRONMENT_STRATEGY.md` — DRAFT, conflicts with §15.1. Blocked on **D6**.\nDo not archive until decided; do not treat as authority meanwhile.\n\n### Not architecture\n\n`PRODUCT_NARRATIVE.md` and `STAKEHOLDER_PITCH.md` are commercial documents and belong under\n`docs/commercial/`, governed by the [Deck Core](../commercial/decks/00-deck-core.md) and\n[GTM Canon](../commercial/09-gtm/00-current-gtm-canon.md). `README.md` becomes a pointer to\nthis document. `CANONICAL_SPINE_SCHEMA.sql` is an artifact, not a document.\n\n## Appendix M — Conflict-resolution ledger\n\nThe inventory at `2187bc91` contains **109 top-level Markdown files** and **114 top-level\narchitecture artifacts**. Appendix L assigns each architecture family a disposition; only\nthis document and `SPEC_AMENDMENTS_v1.md` now declare canonical status.\n\n| Action | Source family | Resolution and reason |\n| --- | --- | --- |\n| **KEEP** | `SPEC_AMENDMENTS_v1.md` | Explicit implementation corrections remain binding. |\n| **KEEP subordinate** | Retained specifications in Appendix L | Detailed contracts apply only where compatible; they cannot introduce doctrine or override this file. |\n| **ADAPT** | OneAuth, host-aware continuity and tenant Spine sources | Kept Flow D precedence, bounded reuse, tenant scope and evidence assembly; removed unrestricted host-trust implications. |\n| **ADAPT** | SpineWorkspace IA and domain taxonomy | Kept deterministic role hosts and one shell; separated public marketing from operational hostname authority and internal projections. |\n| **MERGE** | Architecture Lock, contracts, constitutions, Four Buttons and Twin behaviour | Compatible laws, OODA grammar, Silent Twin and governed execution now live in Parts I–II. |\n| **MERGE** | End-to-end maps and flow documents | A/B/C/D, task/result, approval/write, boundary and ownership views are consolidated here. |\n| **SPLIT** | “Spine” as one database | Canonical truth, operational state, evidence, retrieval, provenance and event history have explicit owners. |\n| **SPLIT** | Naming | IntegrateWise = firm; SpineWorkspace = product; Spine = context core; Platform = control substrate; IW-Spine-Network = distribution contract. |\n| **MOVE** | Public solutions versus host registry | Marketing owns the full story; authenticated `*.spineworkspace.com` hosts request projections. Neither grants authority. |\n| **SUPERSEDE** | Old canonical/product/platform/end-state/end-to-end files and nine constitutions | Historical provenance remains; misleading headers now forward here. |\n| **REFERENCE ONLY** | Excavations, audits and proof reports | Evidence informs Part III but cannot create doctrine; dated claims require revalidation. |\n| **DECIDE** | D1–D13 and M2/M4–M6 | Genuine forks remain explicit rather than being resolved by old prose or convenient code. |\n\nPrecedence is: `README.md` → this document → explicit amendments → compatible retained\nspecification → provenance only. New or attached sources are classified as `KEEP | ADAPT |\nMERGE | SPLIT | MOVE | SUPERSEDE | DECIDE` here; they never create a parallel canon.\n\n---\n\n## Specification amendments (2026-08-06)\n\n[`SPEC_AMENDMENTS_v1.md`](SPEC_AMENDMENTS_v1.md) contains 15 required implementation\ncorrections. These amendments are canonical and supersede conflicting statements in all\nprior architecture documents. Key changes:\n\n1. Per-tenant D1 routing uses Workers for Platforms dispatch, not dynamic KV binding\n2. Isolation claims corrected to database-resource isolation, not physical boundary\n3. D1 fleet capacity policy added (thresholds, overflow strategy)\n4. Catalog versioning uses separate identity and release tables\n5. Idempotency persistence via `processed_commands` table in per-tenant D1\n6. Transactional outbox pattern for atomic domain-write-plus-event\n7. WorkService separated from ExecutionService\n8. Capability invocation ownership frozen between CapabilityService and ExecutionService\n9. Reconciliation model strengthened (missing transitions, observation history)\n10. Complete event envelope (`PlatformEvent` type) with required tracing fields\n11. Consistent `tenant_id` on every durable D1 record\n12. Search service renamed to Tenant-Scoped with per-tenant AI Search instances\n13. Cached projection fallback requires explicit freshness indicators\n14. Cryptographic approval semantics specified (hash chain, signing, verification)\n15. Frontend deployment target frozen (Vercel for product, Workers for platform)\n\nSupporting schemas: [`TENANT_D1_OPERATIONAL_SCHEMA.sql`](TENANT_D1_OPERATIONAL_SCHEMA.sql)\nand [`CONTROL_PLANE_SCHEMA_AMENDMENTS.sql`](CONTROL_PLANE_SCHEMA_AMENDMENTS.sql).\n\n---\n\n## Consolidation record\n\n| Before                                  | After                                                 |\n| --------------------------------------- | ----------------------------------------------------- |\n| 94 documents, 265,000 words             | 1 document + 10 retained specifications + 1 amendment |\n| 16 declared canonical                   | 1 canonical + 1 amendment                             |\n| 6 files with \"canonical\" in the name    | 0                                                     |\n| Conflicts resolved by precedence chains | Conflicts resolved in place; evolutions recorded      |\n| Drift discoverable only by excavation   | Drift register, dated, in Part III                    |\n\n**Guiding principle.** Success is not more code or more documents. It is better thinking,\ncoherent architecture, less complexity, and a product customers genuinely adopt. If a change\nmakes this system harder to explain, it is probably the wrong change.\n\n> **Truth you own. AI you rent. Approval in between.**\n\n\n---\n\n# Part IV — Unified Ontology, Workbench IA and Bridge Architecture\n\n## 24. Unified product ontology\n\nThe architecture is organized around **Business Context**.\n\n```text\nINTEGRATEWISE\n  integratewise.ai\n  Company / Platform Builder\n        │\n        ▼\nSPINEWORKSPACE\n  spineworkspace.com\n  Customer Product\n        │\n        ├── Organization\n        ├── Business Context\n        ├── Connectivity / Ingestion\n        ├── Context Ingestion & Synthesis\n        ├── Spine Fabric\n        ├── Projection\n        ├── Work / Work Graph\n        ├── User Workbench\n        ├── Twin Workbench\n        ├── Coworker\n        ├── Triage\n        ├── Agent Fabric\n        ├── Agent Communication\n        ├── Capability Fabric\n        ├── Governance\n        ├── Execution Fabric\n        ├── Communications over the Bridge\n        ├── Reconciliation\n        └── Organizational Memory / Continuity\n```\n\n## 25. Three canonical system flows\n\n### Flow A — Business Context Ingestion & Synthesis\n\n```text\nSource Systems\n → Connectivity\n → Loader\n → Raw Evidence\n → Normalizer\n → Schema / Semantic Synthesis\n → Entity Resolution\n → Relationship + Event Linking\n → Business Context\n → Spine Fabric\n```\n\n### Flow B — Human–AI Work\n\n```text\nSpine Fabric\n → Projection\n → User Workbench\n → User Interaction\n → Coworker\n → Twin\n → Context Assembly\n → AI Operational Sandbox\n → Shared Work\n → Work Allocation\n → Governance\n → Capability\n → Execution\n```\n\n### Flow C — Communications, Execution, Reconciliation and Knowledge\n\n```text\nHuman / Twin / Agent\n → Communications Bridge\n → Governed Context Sharing\n → Capability\n → Governance\n → Execution Fabric\n → Source System\n → Actual State\n → Re-ingestion\n → Reconciliation\n → Updated Business Context\n → Triage / Interpretation\n → Governed Promotion\n → Organizational Memory\n → Spine\n → Next Work\n```\n\n## 26. Business Context construction\n\nProvider-specific records are never the conceptual center.\n\n```text\nProvider Data\n → Structural Normalization\n → Semantic Synthesis\n → Entity Resolution\n → Relationship Linking\n → Event Linking\n → Domain / Account / Work Mapping\n → Linked Business Context\n```\n\nBusiness Context is the semantic bridge between raw operational data and the human/AI work system.\n\n## 27. User Workbench IA\n\nThe Workbench is a single human operating surface with persistent orientation and adaptive work surfaces.\n\n```text\nUSER WORKBENCH\n├── Orientation\n│   ├── Home\n│   ├── Today\n│   ├── My Work\n│   ├── My Queue\n│   ├── Tasks\n│   └── Recent Work\n├── Communication\n│   ├── Email\n│   ├── Chat\n│   ├── Meetings\n│   ├── Calls\n│   ├── Calendar\n│   └── Documents\n├── Organizational Memory\n│   ├── Decisions\n│   ├── Knowledge\n│   ├── Documents\n│   ├── Policies\n│   ├── Processes\n│   └── Work History\n├── Work\n│   ├── Active\n│   ├── Waiting\n│   ├── Needs Decision\n│   ├── Needs Approval\n│   ├── Delegated\n│   ├── Blocked\n│   └── Completed\n└── Domain Work Surfaces\n```\n\nThe main surface is not a fixed dashboard. It is a projection of Business Context and Work.\n\n## 28. Twin Workbench IA\n\n```text\nTWIN WORKBENCH\n├── Current Work\n├── Context\n├── Plans\n├── Decomposition\n├── Assignments\n├── Agent Work\n├── Capability Calls\n├── Tool Calls\n├── Workflow Runs\n├── Communications\n├── Evidence\n├── Working Memory\n├── Proposals\n├── Exceptions\n└── Results\n```\n\nIt runs only over the bounded AI Operational Sandbox.\n\n## 29. Human Workbench ↔ Twin Workbench\n\n```text\n              SHARED WORK\n                  │\n        ┌─────────┴─────────┐\n        │                   │\nUSER WORKBENCH        TWIN WORKBENCH\nHuman surface         Agentic surface\n        │                   │\n        └─────────┬─────────┘\n                  │\n             Work Graph\n```\n\nThe two surfaces are different projections of the same work; they are not separate sources of truth.\n\n## 30. Communications over the Bridge\n\nThe Bridge is the governed communication substrate for work-related communication.\n\n```text\nHuman / Twin / Agent\n        │\n        ▼\nCOMMUNICATION BRIDGE\n        │\n        ├── Identity / Tenant\n        ├── Work ID\n        ├── Context Reference\n        ├── Purpose\n        ├── Policy\n        ├── Delivery\n        ├── Inbound Event\n        ├── Provenance\n        └── Audit\n        │\n        ├── Slack\n        ├── Email\n        ├── Chat\n        ├── Meetings\n        └── Agent Communication\n```\n\nThe Bridge does not become a fourth memory system. It transports communications/events around Work and preserves their linkage to source, context and authority.\n\n## 31. ACP vs MCP\n\n```text\nMCP\nAI ↔ Tool / Resource / Capability\n\nACP\nAgent ↔ Agent / Agent ↔ Twin\nthrough governed Work and Context handoff\n```\n\nACP is communication, not authority.\n\nThe Twin remains the orchestration boundary.\n\n## 32. Communication continuity\n\nA communication may become:\n\n```text\nCommunication\n → Evidence\n → Decision\n → Assignment\n → Work Update\n → Outcome\n → Organizational Memory Candidate\n```\n\nOnly the governed memory path can make that interpretation Organizational Memory.\n\n## 33. Source-system return path\n\nAll consequential Work ends through:\n\n```text\nCapability\n → Governance\n → Execution\n → Source System\n → Receipt\n → Actual State\n → Re-ingestion\n → Reconciliation\n → Spine\n```\n\nThis closes the operational continuity loop and prevents false completion.\n\n## 34. Knowledge evolution\n\n```text\nUpdated Source State\n → Event\n → Evidence\n → Context\n → Interpretation\n → Triage\n → Candidate\n → Governance\n → Organizational Memory\n → Context\n → Future Work\n```\n\nThe system becomes progressively more contextually useful through governed continuity, not unrestricted learning.\n\n"}