{"slug":"canonical/FOUNDER-CANON-2026-08-31","title":"SpineWorkspace","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/FOUNDER-CANON-2026-08-31.md","bytes":75945,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"## Canonical Product, Experience, Context, AI and Platform Architecture\n\n**IntegrateWise Infrastructure Platform**  \n**Version:** 6.0.0 - Founder Canon  \n**Date:** 31 August 2026  \n**Status:** Founder-authoritative canonical consolidation; supersedes the 1 August 2026 product framing where explicitly stated  \n**Scope:** SpineWorkspace product, Human Workbench, AI Workbench, shared Business Context Spine, Personal Contextual Memory, AI Continuity Memory, Twin, Spine Agents, user experience, UI/AI context pipelines, OODA, platform infrastructure, capability execution, governance, continuity, distribution, implementation alignment and go-live doctrine.\n\n> **One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.**\n>\n> **Humans govern. AI helps. Spine preserves continuity.**\n\n---\n\n# 0. Document Authority, Source Precedence and Supersession\n\nThis document is the **31 August 2026 Founder Canon**. It does not merely restate the repository freeze from 1 August 2026. It incorporates the founder decisions made after that freeze and treats those decisions as the highest authority for product meaning, experience architecture and the human-AI operating model.\n\n## 0.1 Source precedence\n\nWhen sources disagree, use this order:\n\n1. **Founder decisions dated 31 August 2026 and the latest project conversations** - highest authority for product, experience, memory boundaries, Human Workbench, AI Workbench and the human-AI operating model.\n2. **Late-August SpineWorkspace consolidation decisions and master-system visual** - authoritative design direction where they elaborate the founder decisions.\n3. **1 August 2026 GitHub canonical freeze** - implementation baseline and retained technical contracts where not superseded. The repository still shows `39d48073fcac6d805a28a5a854910513d22cf1fa` as the latest canonical architecture freeze.\n4. **Earlier canonical/downstream architecture documents and code** - evidence of implementation, migration state and historical design.\n5. **External 2026 market research** - validation of the category and design pressures only. It does not define IntegrateWise or SpineWorkspace.\n\nThis precedence exists specifically to prevent a later founder decision from being overwritten by an older repository document simply because the repository has not yet been updated.\n\n## 0.2 What the August 1 freeze still contributes\n\nThe 1 August architecture remains the technical baseline for contracts that the founder decisions did not replace: One Auth-to-Ecosystem, Configuration Manager, Integration Manager, Activation Bridge, Gateway, Loader Runtime, Flow A/B/C/D, Normalizer/Triage, Governed Spine Writers, Base Spine, Projection Engine, Capability Fabric, Governance, Hermes, Sync/Verification/Reconciliation, Continuity Bridge, IW Spine Network MCP, MCP Pool, ADK, traceability, Customer Zero and evidence-based readiness. [I1][I3][I4]\n\n## 0.3 What this Founder Canon supersedes\n\nThis document supersedes the August 1 framing in the following product-level areas:\n\n1. **Primary product identity.** The product is **SpineWorkspace**. **IntegrateWise** is the infrastructure/platform powering it.\n2. **Two first-class work environments.** The system contains a **Human Workbench** and an **AI Workbench** operating over the same organizational business context.\n3. **Human Workbench primacy.** Human Workbench is the primary daily product for users. Platform machinery stays largely invisible unless the user is an authorized operator.\n4. **AI Workbench.** AI has a first-class working environment over business context. It is not merely a chat panel, an API payload or the Twin itself.\n5. **Three continuity scopes.** Shared Business Context / Organizational Memory, Personal Contextual Memory and AI Continuity Memory are distinct in purpose, authority and lifecycle.\n6. **Twin vs AI Workbench.** Twin is the human-facing contextual AI coworker operating within the AI Workbench; Twin is not the complete AI operating environment.\n7. **Spine Agents.** Specialized agents operate as governed organizational actors with identity, authority, capability access, Work state, evidence and continuity.\n8. **Shared Work is the coordination medium.** Humans and agents hand off through durable Work/context/evidence state rather than re-explaining the organization in conversation.\n9. **Experience is first class.** UI composition, AI context composition and OODA are internal product machinery. Users should experience work that already carries context rather than needing to understand the machinery.\n10. **No monolithic AI Orchestrator.** Cognition, model routing, agent runtime, capability resolution, authority and execution remain separated across Twin, model/inference routing, ADK, Capability Fabric, Governance and Hermes.\n11. **Verified closure.** Provider success is not completion. The loop closes only after re-ingestion, verification, reconciliation, governed Spine update and rehydration of both Workbenches.\n\nWhere a prior document conflicts with any item above, **this Founder Canon wins**.\n\n---\n\n# 0A. Founder Decision Register - 31 August 2026\n\nThe following decisions are the explicit basis for this revision and must be treated as constitutional product decisions rather than optional interpretation. [F1]\n\n| Decision | Canonical consequence |\n|---|---|\n| **Workbench is the primary product for users.** | Human Workbench is the main daily surface and the product must be experience-first. |\n| **There is also an AI Workbench.** | AI receives its own first-class operating environment over business context, not merely a chat session. |\n| **Humans have Personal Contextual Memory.** | User continuity is independently scoped and does not automatically become organization truth. |\n| **AI has its own continuing memory.** | AI Continuity Memory persists AI working continuity across turns, model changes and agent handoffs. |\n| **Human memory and AI memory are separate.** | Neither memory scope may be silently merged with the other. |\n| **Both operate on shared Spine business memory/context.** | Business Context Spine / Organizational Memory is the common organizational substrate for authorized humans and AI. |\n| **Spine Agents must operate and work together.** | Agents are governed organizational actors and coordinate through shared Work, context, evidence and handoff state. |\n| **Platform must be fully represented.** | Product architecture must include identity, connectivity, ingestion, projection, agent runtime, capabilities, governance, execution and continuity. |\n| **Experience and user experience are first class.** | Product documentation begins with the user experience and only then explains the underlying architecture. |\n| **UI pipeline and AI pipeline are internal.** | Projection/UI composition and AI context/runtime composition are part of the product but should not burden the normal user. |\n| **OODA is internal operating grammar.** | Observe-Orient-Decide-Act governs the loop while the user experiences natural work actions. |\n| **The underlying execution remains inside the product.** | Capability Fabric, Governance, Hermes, providers, verification and reconciliation are integral even when invisible to the end user. |\n\n### Constitutional memory rule\n\n```text\nUser thought\n≠\nAI inference\n≠\nOrganizational truth\n```\n\nA Personal Contextual Memory item remains personal unless deliberately shared/promoted. An AI Continuity Memory item remains AI working continuity unless promoted through the appropriate Triage/Governance/write path. Organizational Memory is durable business memory only after the organization accepts it into the governed Business Context Spine.\n\n### Constitutional product rule\n\n```text\nSPINEWORKSPACE\n=\nHuman Workbench\n+\nAI Workbench\n+\nShared Business Context\n+\nSeparate Human and AI Continuity\n+\nGoverned Work and Execution\n```\n\nThe infrastructure exists to make this experience coherent, continuous and trustworthy.\n\n\n# 1. Executive Definition\n\n## 1.1 SpineWorkspace\n\n**SpineWorkspace is one product with two first-class operating sides: the Human Workbench for people and the AI Workbench for Twin and Spine Agents.** They are separate working environments over the same organizational Business Context Spine. Each carries its own continuity memory, and neither side owns organizational truth by itself.\n\n\n**SpineWorkspace is a self-organizing shared work environment in which humans and AI operate over the same governed business context, while each retains its own continuity memory.**\n\nHumans use the Human Workbench to understand, prioritize, collaborate, decide, approve and remain accountable. AI uses the AI Workbench to assemble context, research, analyze, plan, prepare, coordinate, monitor and execute work that policy allows. Twin is the contextual co-worker closest to the human; Spine Agents can perform specialized work behind it. Both sides operate over the same organizational business reality.\n\nThe user should experience a narrow, direct product even though the platform underneath is broad: the relevant information is already assembled; the current work already has history and evidence; the Twin can prepare difficult or repetitive work; approvals appear when authority requires them; and verified outcomes return to the same work surface. This carries forward the August product principle that “work already knows its context.” [I2]\n\n## 1.2 IntegrateWise\n\n**IntegrateWise is the infrastructure platform that connects the organization’s software ecosystem, preserves governed business context and continuity, composes SpineWorkspace for humans and AI, and coordinates authorized work across APIs, MCP, agents, workflows, models, local runtimes and human routes.**\n\nIntegrateWise is not the daily destination for most users. It is the infrastructure substrate that makes the SpineWorkspace experience possible.\n\n## 1.3 The Core Thesis\n\nOrganizations do not run inside a single software tool. Their business is distributed across CRM, ERP, support, email, chat, calendar, files, documents, project systems, engineering systems, finance applications, databases, internal APIs and increasingly AI systems and agents.\n\nHistorically, the human became the hidden integration and context layer: searching, switching tabs, copying information, reconciling conflicting states and remembering why a decision was made. AI embedded separately inside each application repeats the same fragmentation at machine speed. An AI attached only to one tool understands only that tool; an agent without persistent context or continuity must reconstruct the situation on every run.\n\nThe platform thesis is therefore:\n\n> **Neither humans nor AI should have to reconstruct the organization every time they need to work.**\n\nAnd the durability doctrine is:\n\n> **Tools are replaceable. Models are replaceable. Agents are replaceable. Organizational continuity is not.**\n\n---\n\n# 2. Why This Product Exists\n\n## 2.1 Software fragmentation became work fragmentation\n\nThe modern enterprise already operates across a large application estate. Okta’s 2026 Businesses at Work reporting showed that large enterprises averaged 259 applications, while even smaller organizations continued to add tools. [E11] Asana’s work research reports that knowledge workers spend a majority of their time on “work about work” such as searching for information, coordinating, switching tools and chasing status; its State of Work Innovation reported 53% of time on busywork and only 12% of workers saying new information flows quickly across departments. [E4]\n\nThe architectural problem is not simply “too many apps.” The deeper problem is that the meaning of the business is distributed between them.\n\nA customer renewal, for example, may be spread across CRM fields, support cases, meeting notes, contract files, finance records, Slack messages, product usage, email and a manager’s memory. None of those systems independently contains the complete operating context.\n\n## 2.2 AI inherits the same fragmentation\n\nAdding an AI assistant to every SaaS application does not create one organizational intelligence. It creates many intelligent fragments. Each assistant sees a local slice, has a different memory boundary, uses different permissions and usually cannot preserve a durable, governed record of the organization’s evolving decisions and outcomes.\n\nThe 2026 market is converging on the need for shared enterprise context. OpenAI Frontier describes “Business Context” connecting enterprise systems so AI coworkers can use the same information people do and build durable institutional memory. [E1] Atlassian describes Teamwork Graph as a living map of people, goals, code, content and decisions that gives agents context across tools. [E7] Glean similarly combines organization-wide context with personal graphs. [E6] Palantir’s Ontology emphasizes an evolving operational representation and decision lineage accessible to both humans and agents. [E8]\n\nSpineWorkspace takes the same problem seriously but frames the product around **shared work and continuity between humans and AI**, rather than around search, graph, agent management or integration alone.\n\n## 2.3 Human authority remains central\n\nThe emergence of agents does not eliminate human responsibility. Microsoft’s 2026 Work Trend Index frames the emerging organization as one where agents take on more execution while humans have more room to direct work, make calls and own outcomes. [E2] Asana’s 2026 human-agent product direction similarly emphasizes humans and agents working from the same plan and context under shared governance. [E3]\n\nSpineWorkspace therefore does not position AI as an unrestricted autonomous replacement for the organization. It treats AI as a digital teammate that can perform context assembly, research, preparation, coordination, repetitive work, monitoring and permitted execution, while humans retain judgment, accountability and control over consequential decisions.\n\n---\n\n# 3. The Final Product Hierarchy\n\nThe complete system has three levels that must remain distinct. The product hierarchy below reflects the 31 August founder decision rather than the older 'IntegrateWise Workbench' naming freeze.\n\n| Level | Canonical meaning |\n|---|---|\n| **SpineWorkspace** | The product and daily working experience. |\n| **Spine Context & Continuity System** | The shared Business Context Spine plus Personal Contextual Memory and AI Continuity Memory. |\n| **IntegrateWise Platform** | The infrastructure, connectivity, activation, intelligence, governance, execution and continuity machinery underneath. |\n\nInside SpineWorkspace are two first-class operating environments:\n\n| Human Workbench | AI Workbench |\n|---|---|\n| Primary user-facing product surface | AI-side operating environment |\n| Human-readable and attention-oriented | Agent-readable and context-oriented |\n| Understand, prioritize, decide, collaborate, approve | Understand, research, analyze, plan, prepare, coordinate, monitor |\n| Uses Personal Contextual Memory | Uses AI Continuity Memory |\n| Receives role/responsibility projections | Receives task/agent/authority projections |\n| Human owns accountability | AI owns execution state, not business accountability |\n\nThey share the same business reality but do not share every private or runtime memory item.\n\n---\n\n# 3A. Experience Contract - What the User Sees and What the Product Hides\n\nThe user should not have to understand the architecture in order to benefit from it.\n\n## Human-visible experience\n\nA normal user should experience:\n\n```text\nOpen SpineWorkspace\n→ see what matters now\n→ enter current work\n→ find the relevant business history and evidence already assembled\n→ ask or assign Twin when useful\n→ review prepared work / recommendation / proposal\n→ decide or approve when authority is required\n→ continue working\n→ see the verified result return to the same context\n```\n\nThe user should **not** be forced to understand MCP Pool, ADK, Flow C, model routing, queue semantics, reconciliation identifiers, Spine Cache or the execution topology.\n\n## AI-visible experience\n\nTwin and Spine Agents should experience:\n\n```text\nI have an identity\n→ I know my objective\n→ I have the authorized business context\n→ I have my AI continuity memory\n→ I know the current Work state\n→ I know the evidence\n→ I know my authority\n→ I know which capabilities are available\n→ I can hand work to another authorized agent without losing continuity\n→ I can return evidence and resume later\n```\n\nThe product absorbs the complexity for both sides.\n\n## Internal experience machinery\n\nThe following are product internals, not user concepts:\n\n```text\nProjection Engine\nWorkbench Contract\nUI Composition\nAI Context Builder\nModel Resolver\nADK / Agent Runtime\nCapability Discovery\nCapability Fabric\nGovernance\nHermes\nEvents / Queues\nSync\nVerification\nReconciliation\nOODA state transitions\n```\n\nThey are still part of the product architecture because the user experience depends on them.\n\n\n# 4. The Three Continuity and Memory Scopes\n\nThe final architecture deliberately separates three types of continuity.\n\n## 4.1 Business Context Memory - organizational and shared\n\n**Business Context Memory belongs to the organization.** It is the shared, governed continuity substrate used by every authorized human, Twin and agent.\n\nIt includes:\n\n- mission, objectives, goals, KPIs and initiatives;\n- organizations, teams, people, roles and responsibilities;\n- customers, accounts, partners, vendors, products, projects and assets;\n- work, tasks, commitments, lifecycle states and dependencies;\n- relationships between entities and work;\n- events, changes, signals and temporal history;\n- communications, meetings, documents and artifacts where policy allows;\n- decisions, rationale, approvals and authority lineage;\n- knowledge, evidence, provenance and source references;\n- policies, capabilities and execution eligibility;\n- expected outcomes, actual outcomes, verification and reconciliation state;\n- durable organizational memory and lessons that have passed the promotion/governance boundary.\n\nIt answers: **What does the organization know, what is true enough to operate on, what is happening, what was decided, and what happened next?**\n\n## 4.2 Personal Contextual Memory - human continuity\n\n**Personal Contextual Memory belongs to the human’s working context, subject to enterprise privacy, compliance and retention policy.** It exists because a human carries important continuity that should not automatically become company truth.\n\nExamples include personal notes, drafts, reminders, priorities, bookmarks, private working knowledge, what the user was investigating, unfinished thoughts, personal task ordering, preferences, recurring work patterns and context the user wants available across sessions.\n\nPersonal Contextual Memory is private by default. Sharing or promoting an item into organizational memory is an explicit governed transition, not an automatic side effect of writing a note.\n\nThe Human Workbench therefore assembles:\n\n```text\nHuman Workbench Context\n=\nAuthorized Business Context\n+ Personal Contextual Memory\n+ Current Work\n+ Current Interaction Context\n+ Policy and Capabilities\n```\n\n## 4.3 AI Continuity Memory - Twin and agent continuity\n\n**AI Continuity Memory is the AI-side continuity layer. It exists so Twin and Spine Agents do not restart from zero on every turn, model change, session or handoff. Operationally it is scoped to the AI participant/runtime; governance, retention and legal ownership remain governed by tenant policy.**\n\nIt can hold prior assignment state, working summaries, unresolved questions, current plans, active hypotheses, tool/capability state, agent handoff context, prior observations, pending verification, interaction preferences and model-independent continuity information.\n\nAI Continuity Memory is not organizational truth. An AI-generated inference, summary or hypothesis becomes organizational memory only after the appropriate Triage, Governance and governed-write path.\n\nThe AI Workbench therefore assembles:\n\n```text\nAI Workbench Context\n=\nAuthorized Business Context\n+ AI Continuity Memory\n+ Current Objective\n+ Current Work State\n+ Evidence\n+ Authority\n+ Available Capabilities\n```\n\nThe August platform architecture already separated Adaptive Spine, Twin Memory, Knowledge, Session Logs, Audit Logs, Cache, Sync State and ephemeral runtime. This document turns that separation into an explicit product-level contract. [I1][I3]\n\n---\n\n\n# 4A. Dual-Workbench Context Model\n\nThe two Workbenches share organizational context but receive different projections and different continuity augmentation.\n\n```text\nHuman Active Context\n=\nBusiness Context Projection\n+ Personal Contextual Memory\n+ Current Work\n+ Current Interaction Context\n+ Authorized Knowledge/Evidence\n+ Policy\n+ Capabilities\n```\n\n```text\nAI Active Context\n=\nBusiness Context Projection\n+ AI Continuity Memory\n+ Current Objective\n+ Current Work State\n+ Evidence\n+ Authority Envelope\n+ Available Capabilities\n+ Agent Runtime State\n```\n\nThe invariant is:\n\n> **Shared business reality; separate participant continuity; governed promotion between scopes.**\n\nThis is the core reason the Human Workbench and AI Workbench can collaborate without collapsing privacy, inference and organizational truth into one memory store.\n\n\n# 5. Business Contextual Spine Fabric\n\n## 5.1 Definition\n\nThe **Business Contextual Spine Fabric** is the tenant-scoped system of organizational operating context, continuity and governed state. It is not merely a database and it is not an ESB.\n\nThe closest ESB analogy is that it provides a common coordination substrate across many systems. The analogy stops there. A traditional integration bus primarily transports, routes and transforms messages. The Spine Fabric preserves the semantic and temporal context needed for humans and AI to understand work, decisions, evidence, authority and outcomes over time.\n\nThe July architecture correction explicitly rejected the N×M “ESB hub” metaphor and reframed the Spine as a governed canonical context network: tools connect once, and governed context becomes reusable. [I1]\n\n## 5.2 Logical domains\n\nThe logical Business Context Spine carries three coupled domains from the August freeze, expanded by this document’s three-memory separation: [I1]\n\n**Operational Truth.** Entities, fields, relationships, lifecycle state, work state, decisions, approvals, expected outcomes, source ownership and reconciliation status.\n\n**Knowledge and Evidence.** Documents, chunks, embeddings/search representations, citations, attachments, source artifacts and evidence references.\n\n**Business Memory and Continuity.** Continuity runs, commitments, decisions, synthesized organizational context, promotion state, temporal history and organizational memory.\n\nPersonal Contextual Memory and AI Continuity Memory remain separate scoped stores or namespaces even when they use the same physical infrastructure.\n\n## 5.3 Logical truth before physical storage\n\nThe product architecture freezes the **logical Spine contract**, not one vendor-specific database. The August architecture explicitly allows the physical implementation to use Postgres/D1, object storage, vector/search, event stores, caches and queues underneath the logical contract. [I1]\n\nThis resolves older internal documentation conflicts that alternately treated D1 or Postgres/Neon as the single physical source of truth. The final rule is:\n\n> **The Business Context Spine is the canonical logical authority. Physical storage authority is an implementation/deployment ADR and must not redefine product semantics.**\n\n## 5.4 Mandatory Base Spine and additive expansion\n\nEvery tenant receives a valid mandatory Base Spine. The Spine is not generated only from whichever connectors a customer happens to install. Role, department, industry, connector and tenant context extend the Base Spine additively. [I1][I3]\n\n```text\nEffective Spine\n=\nMandatory Base Spine\n∪ Department Expansion\n∪ Industry Expansion\n∪ Role Expansion\n∪ Connector Expansion\n∪ Tenant Expansion\n∪ Contextual Expansion\n```\n\nNo expansion may remove tenancy, provenance, authority, evidence, lifecycle, sync or reconciliation contracts.\n\n---\n\n# 6. Work Is the Shared Unit of Human-AI Coordination\n\nHuman and AI collaboration must not rely on endless conversational handoffs. The central coordination object is **Work**.\n\nEvery meaningful work item should carry a durable identity and enough state to allow a different human, Twin, agent or provider to continue without re-explaining the entire situation.\n\nA Work object should conceptually bind:\n\n```text\nwork_id\nobjective\nbusiness context references\nowner / responsible human\ncurrent executor\nstate and lifecycle\nsubtasks and dependencies\nevidence\ncommitments\nproposals\npolicy / authority envelope\navailable capabilities\nexpected outcome\nactual outcome\nhandoff history\ntrace and continuity identifiers\n```\n\nThe operating rule is:\n\n> **No participating worker begins meaningful work without a Spine-derived authorized context and Work identity.**\n\nThis applies whether the worker is a human, Twin, Spine Agent, ADK runtime, workflow or execution provider. Earlier Spine Fabric work already established shared Work state and continuity as the handoff mechanism rather than chat alone. [I9][I11]\n\n---\n\n# 7. Human Workbench - The Primary Product Experience\n\n## 7.1 Definition\n\nThe Human Workbench is the primary daily product surface inside SpineWorkspace. It is not a dashboard, a database UI, a role-specific isolated SaaS app, or a chatbot with integrations.\n\nThe Workbench composes the fields, records, relationships, knowledge, evidence, communications, work, capabilities, approvals and Twin context relevant to the user’s role and active situation. The August product architecture already established that the same Base Spine can project differently for Sales, Customer Success, Support, Marketing, Finance, Engineering or a founder. [I2]\n\n## 7.2 Stable shell, adaptive work\n\nNavigation stays stable enough to be learnable. The work surface adapts.\n\nA representative information architecture is:\n\n- Home;\n- My Work: Inbox, Tasks, Queue, Approvals, Notifications, Recent, Favorites;\n- Communications: Activity, Email, Calendar, Meetings, Chat, Calls, Shared Documents;\n- Personal: Notes, Personal Knowledge, Brainstorming, Activity and permitted personal utilities;\n- Work: adaptive role/department/lifecycle projections;\n- Platform/Administration for authorized operators only.\n\nThe platform should adapt visibility, default routes, views, fields, actions and capabilities without making the global product taxonomy unstable. [I2]\n\n## 7.3 Self-organizing Workbench\n\nSelf-organization is a technical composition rule, not a marketing metaphor.\n\n```text\nEffective Human Workbench\n=\nMandatory Workbench Standard\n+ Business Context Projection\n+ Personal Contextual Memory\n+ Role and Responsibility\n+ Department and Industry Context\n+ Active Lifecycle and Current Work\n+ Connected Data Coverage\n+ Knowledge and Evidence\n+ Available Capabilities\n+ Governance and Entitlements\n+ User Preferences\n+ Freshness and Readiness\n```\n\nThe user should not have to create every database, design every view, map every tool, build every dashboard or repeatedly explain the same context to AI. The system discovers, activates, hydrates and projects the operating environment.\n\n## 7.4 Tables, views, pages and operational surfaces\n\nSpineWorkspace can expose multiple form factors over the same context:\n\n- **Tables** for structured operational data;\n- **Views** for filtered, grouped and role-routed lenses;\n- **Pages/Docs** for narrative, planning, linked context and evidence;\n- **Boards** for state and lifecycle;\n- **Queues** for action-ready work;\n- **Calendar/Timeline** for time projections;\n- **Canvas** for free-form operational composition;\n- **Entity 360-style projections** for cross-system business objects;\n- **Twin** for contextual reasoning and preparation.\n\nThe form factor does not own truth. The projection contract does.\n\n---\n\n# 8. AI Workbench - The AI Operating Environment\n\n## 8.1 Definition\n\nThe **AI Workbench** is the machine-side operating environment in which Twin and Spine Agents perform business work over the shared Business Context Spine.\n\nIt does not need to appear to the customer as a separate visible app. It is first-class architecturally because an AI worker needs a stable operational environment just as a human does.\n\n## 8.2 What the AI Workbench contains\n\nA complete AI Workbench context can include:\n\n- active objective;\n- assigned Work record and current state;\n- authorized Business Context Bundle;\n- relevant Business Memory;\n- AI Continuity Memory;\n- relevant entities and relationships;\n- evidence and provenance;\n- current plan and subtasks;\n- dependencies and blockers;\n- agent roster and agent state;\n- available capabilities and provider health;\n- authority/delegation envelope;\n- proposals and pending approvals;\n- execution state;\n- expected versus observed outcomes;\n- verification, exception and handoff state.\n\n## 8.3 Twin versus AI Workbench\n\nTwin is not the entire AI Workbench. Twin is the contextual co-worker closest to the human: it retrieves, reasons, explains, prepares and proposes. [I1][I3]\n\nThe AI Workbench can host or coordinate multiple workers behind Twin, including specialist agents, research agents, execution agents, verification agents, workflows and model calls. Twin may perform work itself or assign sub-work through governed agent/capability paths.\n\n## 8.4 AI continuity must survive model changes\n\nThe AI Workbench, Work state and AI Continuity Memory are durable platform concepts. A specific model is a replaceable reasoning provider.\n\nA model resolver should select by task profile, context requirement, reasoning effort, modality, latency, cost, policy and availability. The model contract should use stable profiles such as `fast`, `reasoning`, `code` or `specialized`, rather than hard-coding one vendor/model version into Twin. [I13]\n\n---\n\n# 9. Twin and Spine Agents\n\n## 9.1 Twin’s role\n\nTwin is the contextual human-facing cognitive participant. It can:\n\n- assemble authorized context;\n- retrieve Business Memory, Personal Context where authorized, AI Continuity Memory, history and evidence;\n- explain current state and changes;\n- identify risks, gaps and commitments;\n- prepare drafts, plans, reports, mutations and capability inputs;\n- propose actions and request approval;\n- monitor authorized execution outcomes.\n\nTwin cannot directly own organizational truth, self-approve consequential actions, bypass Governance, become the storage layer, or claim success before verification and reconciliation. These restrictions carry forward directly from the August canonical architecture. [I1]\n\n## 9.2 Spine Agents\n\nA **Spine Agent** is an AI worker operating inside the organization’s governed Work and context model. Every agent receives identity, tenant, purpose, owner, delegated authority, scopes, capability access, memory namespace, runtime/model profile, risk policy and audit identity.\n\nSpine Agents cooperate by reading and updating shared Work state and returning evidence, not by relying only on free-form agent-to-agent conversation.\n\n```text\nAgent A\n→ performs sub-work\n→ writes evidence / updates Work state\n→ handoff recorded\n→ Agent B reads same authorized Work context\n→ continues\n```\n\nThis is the AI equivalent of eliminating human context reconstruction.\n\n## 9.3 Agent Development Kit (ADK)\n\nADK is the developer/runtime abstraction for registering and invoking agents through governed platform contracts. It should describe skills, schemas, runtime requirements, tool bindings and execution interfaces, while authority remains with One Auth/Governance and canonical truth remains with governed Spine writers. [I3][I4]\n\nADK is not the organizational memory, policy engine or execution authority.\n\n---\n\n# 10. Experience Principles\n\nThe product should hide most platform complexity.\n\nA human should experience the following loop:\n\n```text\nOpen SpineWorkspace\n→ see what matters now\n→ open a customer/project/task/decision\n→ relevant cross-tool context is already assembled\n→ ask Twin or assign tedious work\n→ Twin/agents research and prepare\n→ review evidence and recommendation\n→ approve consequential action when required\n→ execution occurs\n→ verified result appears in the same work surface\n→ continue from the updated state\n```\n\nThe AI side should experience:\n\n```text\nI have an identity.\nI know my objective.\nI have authorized business context.\nI have continuity memory.\nI know the current Work state.\nI know which capabilities I can use.\nI know my authority.\nI can hand off work without losing context.\nI return evidence and outcomes.\nI can resume later.\n```\n\nThe architecture succeeds when users do not need to understand MCP Pool, Flow C, ADK, Hermes, Spine Cache or reconciliation IDs to complete normal work.\n\n---\n\n# 11. OODA - Internal Interaction Constitution\n\nOODA remains the internal interaction grammar, not necessarily a literal four-button interface on every screen. [I2][I12]\n\n| OODA phase | Canonical action | Meaning |\n|---|---|---|\n| Observe | **Store in Spine** | Capture a governed context/evidence/decision/note/artifact candidate. |\n| Orient | **Ask Your Twin** | Retrieve and explain active context. |\n| Decide | **Assign Your Twin** | Delegate an objective and request prepared work/proposal. |\n| Act | **Approve Twin’s Action** | Record human authority for consequential governed execution where approval is required. |\n\nThe important constitutional rule is that Twin does not own the consequential “Act” authority. Policy may permit low-risk automation, but consequential authority is always explicit in Governance.\n\nThe internal loop is continuous:\n\n```text\nObserve → Orient → Decide → Act → Outcome → Re-ingest → Verify → Reconcile → Observe again\n```\n\n---\n\n# 12. Projection and the UI Composition Pipeline\n\n## 12.1 Projection Engine\n\nProjection Engine remains the sole composer of versioned Workbench contracts. Gateways, BFF routes, UI modules and agents request authorized projections; they do not independently assemble canonical truth. [I1][I3]\n\nProjection inputs include tenant/workspace, user or agent identity, membership, role, department, industry, active entity, current Work, connected-system coverage, freshness, field permissions, available capabilities, provider health, preferences, governance and entitlements.\n\n## 12.2 Human UI pipeline\n\n```text\nBusiness Context Spine\n+ Personal Contextual Memory\n+ Role / Responsibility\n+ Current Work and Lifecycle\n+ Policy / Entitlements\n+ Connected Data Coverage\n+ Knowledge / Evidence\n+ Capabilities\n+ Preferences\n+ Freshness / Readiness\n        ↓\nProjection Engine\n        ↓\nVersioned Workbench Contract\n        ↓\nUI Composition\n        ↓\nHuman Workbench Surface\n```\n\nThis is how the product can remain stable while content, fields, actions and priorities adapt.\n\n## 12.3 AI context pipeline\n\n```text\nBusiness Context Spine\n+ AI Continuity Memory\n+ Objective\n+ Current Work State\n+ Evidence\n+ Authority\n+ Capabilities\n+ Runtime Health\n        ↓\nAI Context Assembly\n        ↓\nAI Workbench Context\n        ↓\nTwin / Spine Agent Runtime\n```\n\nHuman and AI therefore share the same underlying business reality without requiring identical representations.\n\n---\n\n# 13. Business Intent and Lifecycle Above the Tools\n\nSpineWorkspace should not begin conceptually with software applications. The organization exists to pursue outcomes.\n\n```text\nMission\n→ Objectives\n→ Goals\n→ KPIs\n→ Initiatives\n→ Work\n→ Decisions\n→ Actions\n→ Outcomes\n→ Learning\n```\n\nThe Business Context Spine links operating work back to this chain.\n\nOrganizations also operate through lifecycle transitions rather than static department silos alone:\n\n```text\nBusiness Objective\n→ Operating Lifecycle\n→ Event\n→ State Transition\n→ SOP / Process\n→ Activities\n→ Records / Evidence\n→ Human + AI Work\n→ Decision / Approval\n→ Execution\n→ Verification\n→ Memory\n→ Next State\n```\n\nDepartments, roles, pages and Twin actions are projections over this operating reality. A Sales view and a Finance view may see different aspects of the same lifecycle event without creating separate systems of truth.\n\n---\n\n# 14. IntegrateWise Platform - Complete Runtime Architecture\n\nThe IntegrateWise Platform sits underneath both Workbenches.\n\n```text\nExternal Ecosystem\n  SaaS · databases · files · MCP · AI providers · internal APIs · humans\n        ↓\nOne Auth-to-Ecosystem\n        ↓\nConfiguration Manager\n        ↓\nIntegration Manager\n        ↓\nDiscovery\n        ↓\nActivation Bridge\n        ↓\nGateway\n        ↓\nLoader Runtime\n        ├─ Flow A - Structured Operational\n        ├─ Flow B - Unstructured Context\n        ├─ Flow C - AI/Cognitive Continuity\n        └─ Flow D - Platform Binding/Control\n        ↓\nNormalizer / Triage\n        ↓\nGoverned Spine Writers\n        ↓\nBusiness Contextual Spine Fabric\n        ↓\nProjection / Context Assembly\n        ├─ Human Workbench\n        └─ AI Workbench\n        ↓\nTwin / Spine Agents\n        ↓\nCapability Discovery\n        ↓\nCapability Fabric\n        ↓\nGovernance\n        ↓\nHermes\n        ↓\nExecution Providers\n        ↓\nOutcome Event\n        ↓\nSync / Verification / Reconciliation\n        ↓\nGoverned Canonical Commit\n        ↓\nProjection Invalidation / Workbench Rehydration\n        ↓\nNext Work / Next OODA Loop\n```\n\nThis chain is the August canonical runtime expanded to include the final dual-Workbench and memory model. [I1]\n\n---\n\n# 15. Identity, Configuration, Integration, Discovery and Activation\n\n## 15.1 One Auth-to-Ecosystem\n\nOne Auth establishes a common organizational identity and delegation model for humans, Twin, agents, services, AI hosts, automations and API clients. It resolves user/agent identity, tenant, workspace, role, consent, scope, delegation and service-principal context. [I1][I3]\n\nOne Auth does not replace every provider OAuth credential. Provider credentials remain managed connection artifacts. One Auth provides the shared organizational authority context around them.\n\n## 15.2 Configuration Manager\n\nConfiguration Manager defines tenant structure, provider choices, policy, composition, memory, AI/model and synchronization choices. [I3]\n\n## 15.3 Integration Manager\n\nIntegration Manager owns connection lifecycle: OAuth, direct connectors, mappings, webhooks, subscriptions, discovery, health and sync policy. It must not write canonical business entities directly. [I1][I3]\n\n## 15.4 Discovery\n\nDiscovery has multiple forms:\n\n- provider and connector discovery;\n- object and schema discovery;\n- event discovery;\n- capability discovery;\n- MCP server/tool discovery;\n- agent discovery;\n- model/runtime discovery;\n- health and availability discovery.\n\nDiscovery answers **what exists**. It does not authorize execution.\n\n## 15.5 Activation Manager and Activation Bridge\n\n**Activation Manager** is the administrative/product surface used to control what becomes active.\n\n**Activation Bridge** is the runtime compiler that converts configuration, identity, role, department, connected data, policy, capability and memory settings into an active tenant/workspace definition. [I3]\n\n```text\nConfiguration\n+ Identity\n+ Connections\n+ Discovered Objects/Capabilities\n+ Base Spine\n+ Role / Department / Industry\n+ Policies / Entitlements\n+ Memory / AI / Sync Choices\n        ↓\nActivation Bridge\n        ↓\nCompiled Active Runtime Definition\n```\n\n---\n\n# 16. Ingestion, Four Flows, Normalization and Governed Writes\n\nThe outer world does not write canonical business truth directly.\n\n## 16.1 Gateway\n\nGateway is the tenant-aware ingress boundary for validation, tracing, rate limits and routing. [I1][I3]\n\n## 16.2 Loader Runtime\n\nLoader Runtime is the sole outer ingestion and canonical-write entry. It routes data through four flows. [I1][I3]\n\n**Flow A - Structured Operational:** entities, transactions, metrics, lifecycle changes, provider events and structured relationships.\n\n**Flow B - Unstructured Context:** documents, messages, email, meetings, transcripts, files, chunks, embeddings/search representations and evidence.\n\n**Flow C - AI and Cognitive Continuity:** Twin sessions, AI proposals, candidate memory/knowledge, synthesis and promotion candidates.\n\n**Flow D - Platform Binding and Control:** identity, configuration, connectors, capabilities, policy, execution, sync and observability state.\n\n## 16.3 Normalizer and Triage\n\nNormalizer handles deterministic parsing, validation, mapping, resolution, deduplication and entity preparation. Triage handles ambiguous, AI-originated, conversational and knowledge candidates, preparing them for governed promotion. [I1][I3]\n\nTriage classifies. Governance authorizes. Governed Writers commit.\n\n## 16.4 Governed Spine Writers\n\nCanonical writes enforce tenant scope, schema, policy, provenance, evidence, idempotency and atomicity. Neither an agent nor an execution runtime writes canonical truth directly. [I1][I3]\n\n---\n\n# 17. State-Plane Separation\n\nThe logical architecture must preserve state boundaries even when one physical database hosts multiple tables.\n\n| Plane | Purpose |\n|---|---|\n| **Business Context Spine** | Durable organizational operating truth and continuity. |\n| **Personal Contextual Memory** | Human-specific working continuity. |\n| **AI Continuity Memory** | Twin/agent working continuity. |\n| **Spine Cache** | Disposable hydration/acceleration state. |\n| **Knowledge** | Retrievable semantic representations linked to evidence. |\n| **Blobs** | Raw files, payloads, exports, attachments and evidence artifacts. |\n| **Session Logs** | Conversation, model/tool-call and interaction lifecycle. |\n| **Audit Logs** | Identity, authority, approval, model/agent, capability, execution and outcome lineage. |\n| **Sync State** | Cursors, checkpoints, retries, pending mutations, DLQ and conflicts. |\n| **Config State** | Compiled tenant/provider/policy/composition/sync choices. |\n| **Ephemeral Runtime** | Locks, leases, scratch state, temporary context and rate limits. |\n\nSpine Cache can always be rebuilt from canonical state. Cache never becomes truth. Knowledge representations must retain evidence links. Raw sessions are evidence/history; only governed promotion creates durable organizational memory. [I1][I10]\n\n---\n\n# 18. Capability Fabric - The Semantic Execution Layer\n\nCapability Fabric is the provider-neutral execution language between intent and implementation. [I6]\n\nA user or Twin should think in business capabilities such as `prepare_renewal`, `schedule_review`, `update_project_state` or `send_followup`, not in raw provider endpoints.\n\nCapability Fabric resolves how authorized intent can be performed through route families including:\n\n- tool-to-tool;\n- memory fetch;\n- MCP;\n- agent-to-agent;\n- API connector;\n- API wrapper/function;\n- local execution;\n- AI execution;\n- browser, workflow or human execution where needed. [I1][I3]\n\nEvery executable capability declares a version, input/output schema, authority scope, risk, execution mode, sync mode, idempotency, evidence requirements, provider routes, health, timeout, retry, compensation and verification behavior. [I1]\n\nThe responsibility split is:\n\n```text\nTwin / Workbench      = what the user is trying to achieve\nCapability Discovery = what executable options exist\nCapability Fabric    = how it could be done\nGovernance           = whether it may be done and under whose authority\nHermes               = how approved execution is coordinated reliably\nReconciliation       = whether reality actually changed as intended\n```\n\n---\n\n# 19. Governance and Human Authority\n\nGovernance is a cross-cutting authority boundary, not merely a single UI screen or one step in a linear workflow.\n\nGovernance evaluates:\n\n- who or what requested the action;\n- tenant and organizational scope;\n- human or agent role;\n- delegated authority;\n- capability and target;\n- risk and destructive potential;\n- data sensitivity;\n- approval policy;\n- evidence requirements;\n- audit obligations.\n\nThe canonical outcomes remain:\n\n```text\nALLOW\nDENY\nREQUIRE APPROVAL\nDELEGATE / ALLOW WITH BOUNDED AUTHORITY\n```\n\nHuman governance does not mean a human must approve every low-risk automated operation. It means the organization defines what AI may do automatically, what requires explicit approval and what may never be delegated.\n\nThe August architecture’s non-negotiable rule remains: Twin cannot self-approve consequential action or bypass Governance. [I1]\n\n---\n\n# 20. Hermes and Execution\n\nHermes starts after an execution plan has been approved or policy-allowed. It coordinates dispatch, waits, retries, timeouts, observations, recovery/compensation, evidence capture, verification steps and reconciliation workflows. [I1][I3]\n\nExecution providers can include APIs, MCP tools, agents, browser runtimes, workflows, local execution, AI models or human tasks.\n\nHermes is not the AI brain. It does not decide whether execution is allowed and it does not own canonical business truth.\n\nHistorical code includes orchestration paths and direct `spine.write`-style semantics that should be treated as implementation drift. The final contract is stricter: execution produces outcome events/evidence, and governed writes occur only after the appropriate re-ingestion, verification and reconciliation path. [I7]\n\n---\n\n# 21. Execution Is Not Complete Until Reality Reconciles\n\nA provider’s `200 OK`, tool success flag or agent completion message is an **Outcome Event**, not automatically a verified business outcome. [I1][I3]\n\nThe canonical continuity closure is:\n\n```text\nIntent\n→ Proposal / Command\n→ Governance Decision\n→ Authorized Execution Plan\n→ Hermes Execution\n→ Provider Outcome\n→ Outcome Event\n→ Re-ingestion\n→ Verification\n→ Expected vs Actual Comparison\n→ Reconciliation\n→ Governed Canonical Commit\n→ Projection Invalidation\n→ Human + AI Workbench Rehydration\n→ Next OODA Loop\n```\n\nThis is a defining product property. Humans and AI do not merely receive a success message; they continue from a verified updated business state.\n\nEvery continuity run retains traceability such as `trace_id`, `correlation_id`, `causation_id`, `event_id`, `approval_id`, `capability_run_id`, `execution_id`, `idempotency_key`, `verification_id`, `reconciliation_id` and `continuity_run_id` where applicable.\n\n---\n\n# 22. The Common Coordination Fabric - “One Channel” Correctly Defined\n\nThe “one channel” thesis does not mean every person and agent must use one literal chat application.\n\nIt means every participating surface converges on the same coordination model:\n\n```text\nHuman Workbench\nEmail\nChat / Collaboration\nMobile\nSource Application\nExternal AI Host\nMCP Client\nAgent\nWebhook\nAPI\n        ↓\nIdentity\n        ↓\nAuthorized Context\n        ↓\nWork / Event\n        ↓\nAuthority\n        ↓\nCapability\n        ↓\nExecution\n        ↓\nEvidence\n        ↓\nReconciliation\n        ↓\nBusiness Context Spine\n```\n\nMany interaction surfaces; one continuity substrate.\n\n---\n\n# 23. MCP, MCP Pool, Continuity Bridge and Distribution\n\nThese concepts must remain distinct. [I3][I4]\n\n## 23.1 IW Spine Network MCP\n\nThe hosted remote MCP boundary exposes provider-neutral IntegrateWise resources and tools to approved external AI surfaces. It can provide Spine queries, context projections, history/relationships, knowledge/memory retrieval, capability discovery, proposal submission, governed execution requests and execution/reconciliation status.\n\nMCP tools do not receive direct storage credentials. They call versioned platform APIs and governed capability paths. [I4]\n\n## 23.2 MCP Pool\n\nMCP Pool is the inward-facing tenant registry of approved external MCP servers/tools, their schemas, trust profile, authorization references, health and delegated scopes. It is principally an enterprise/Customer Zero control concept, not the user-facing product. [I3][I4][I14]\n\n## 23.3 Continuity Bridge\n\n**IntegrateWise - Continuity Bridge** is the distribution/access product for external AI hosts. It opens governed context and capability access without making MCP itself the product. [I4]\n\nDistribution surfaces can include ChatGPT, Claude, Perplexity, direct MCP clients, embedded enterprise applications, SDK/ADK integrations, provider marketplaces and direct APIs. All must bind to the same identity, tenancy, Spine, projection, capability, governance and audit contracts. [I4]\n\n---\n\n# 24. Onboarding - From Blank State to Useful Work\n\nOnboarding does not hand the user an empty workspace to configure manually. The existing doctrine is: onboarding creates a Spine Context, hydrates the Spine and then computes useful projections. [I5]\n\nThe final lifecycle is:\n\n```text\nIdentity\n→ Organization / Role / Responsibility\n→ Goals and Operating Context\n→ Connect Reality\n→ Discovery\n→ Configuration\n→ Activation\n→ Initial Hydration\n→ Business Context Spine\n→ Personal Contextual Memory Initialization\n→ AI Continuity / Twin Activation\n→ Capability Activation\n→ Projection\n→ SpineWorkspace\n```\n\nThe first useful experience should already contain real context from connected systems, clear coverage/readiness state, relevant Work and a functioning Twin. Missing data should appear as readiness/freshness gaps over the mandatory operating contract, not as a malformed reduced product.\n\n---\n\n# 25. Platform Console and Administrative Experience\n\nNormal users live primarily in SpineWorkspace. Authorized operators need a Platform Console for managing the substrate.\n\nRepresentative control areas include:\n\n- Integration Manager and Connector Marketplace;\n- Activation Manager;\n- Capability Manager and capability health;\n- MCP Pool and external AI surfaces;\n- AI Models / model routing profiles;\n- Knowledge, Business Memory, Personal/AI memory policy;\n- pipelines and synchronization;\n- Governance and approval policy;\n- agent registry / ADK controls;\n- observability, audit and trace explorer;\n- organizations, users, roles and permissions;\n- security, API keys, billing and entitlements;\n- deployments and release status.\n\nThe Platform Console is an operator/admin product surface, not a competing daily work destination.\n\n---\n\n# 26. Security, Privacy and Trust Invariants\n\nThe following are architectural stop-ship rules:\n\n- no cross-tenant data or context leakage;\n- no external request reaches internal services without tenant-aware identity validation;\n- no model or agent owns canonical organizational truth;\n- no agent directly writes canonical business truth;\n- no AI system can self-mint consequential human approval;\n- no MCP tool receives raw storage authority;\n- no private Personal Contextual Memory item becomes organizational memory without an explicit governed share/promotion path;\n- no AI Continuity Memory inference becomes organizational memory without Triage/Governance/governed write;\n- no provider success signal is treated as completed business state before verification/reconciliation;\n- every agent and execution route has an auditable identity, scope and authority envelope;\n- deletion/export/retention behavior must respect tenant policy and applicable user rights;\n- sensitive evidence and provenance must remain traceable without overexposing private content in projections.\n\nThe governance direction is consistent with the 2026 market, where ServiceNow AI Control Tower, Workday Agent System of Record and MuleSoft Agent Fabric all emphasize agent discovery, identity, permissions, approvals, governance, audit and cross-system control. [E5][E9][E10]\n\n---\n\n# 27. Customer Zero and Go-Live Doctrine\n\nIntegrateWise must operate IntegrateWise itself. Customer Zero is the first real tenant, not a demo architecture. [I2][I3]\n\nCustomer Zero should preserve the operating history of the company: product, architecture, code, decisions, tasks, funding/GTM work, connectors, documents, incidents, releases, AI sessions, agent work, approvals and outcomes.\n\nThe minimum end-to-end launch proof remains:\n\n```text\nOne Auth\n→ controlled connectors\n→ Initial Hydration / Flow A-B-C-D\n→ valid Base Spine\n→ Human Workbench projection\n→ AI Workbench/Twin context\n→ proposal\n→ Governance approval or bounded policy allow\n→ Capability Fabric route\n→ Hermes execution\n→ provider outcome\n→ re-ingestion\n→ verification and reconciliation\n→ visible Human + AI Workbench rehydration\n```\n\nUntil this loop is demonstrated with telemetry, rollback, security and operational support, the release classification should remain Customer Zero / controlled beta rather than broad GA. [I1]\n\n---\n\n# 28. Implementation Alignment and Known Drift\n\nThe August codebase alignment document reported 30 services against a smaller canonical plane model and identified consolidation gaps. [I7] This document does not pretend those gaps are already resolved.\n\nKey alignment work remains:\n\n- consolidate loader/normalizer behavior into the canonical Pipeline boundary;\n- consolidate fragmented Twin runtime services into a coherent Twin/AI Workbench runtime;\n- create or harden Configuration Manager and Activation Bridge;\n- maintain clear separation of Spine, Spine Cache, Blobs, Business Memory, Personal Memory, AI Memory, Session Logs and Audit Logs even if physically co-located;\n- consolidate agent registry/workflow semantics into Capability Fabric and ADK boundaries;\n- keep Governance separate from Hermes execution;\n- move direct provider/writeback behavior behind outcome, verification, reconciliation and governed writer contracts;\n- ensure gateway/ADK middleware cannot silently bypass Governance or create implicit approval;\n- treat legacy n8n/product-plane orchestration or direct `spine.write` semantics as migration evidence rather than final doctrine.\n\nReadiness must be evidence-based across at least: implemented, wired, deployed and verified end-to-end. Presence of code or a Wrangler manifest is not proof of production readiness. [I6][I7]\n\n---\n\n# 29. Market Context and Intended Differentiation\n\nThis section is external research, not the source of canonical product semantics.\n\nThe market is converging on several pieces of the same enterprise problem:\n\n- **OpenAI Frontier**: business context, institutional memory, agent execution, identity/permissions and improvement loops. [E1]\n- **Asana**: humans and agents working from the same plan/context/governance. [E3]\n- **Microsoft**: agents increase execution capacity while humans direct and own outcomes. [E2]\n- **MuleSoft Agent Fabric**: discover, orchestrate, govern and observe agents/MCP across ecosystems. [E5]\n- **Glean Enterprise Graph**: organization-wide context plus personal graphs feeding AI and actions. [E6]\n- **Atlassian Teamwork Graph**: connected people, goals, work, code, content and decisions made available across agent surfaces. [E7]\n- **Palantir Ontology**: operational semantic model, decision lineage and human-agent workflows. [E8]\n- **ServiceNow AI Control Tower / Workday ASOR**: centralized agent lifecycle, identity, governance, approvals, monitoring and audit. [E9][E10]\n\nSpineWorkspace should therefore avoid claiming that “shared context,” “agent governance,” “enterprise graph” or “human-agent teamwork” is individually unique.\n\nThe intended differentiation is the **combined operating model**:\n\n1. a self-organizing primary Human Workbench;\n2. a first-class AI Workbench for Twin and Spine Agents;\n3. a shared Business Context Spine owned by the organization;\n4. separate Personal Contextual Memory and AI Continuity Memory;\n5. Work as the durable unit of human-agent handoff;\n6. provider-neutral Capability Fabric and model/runtime replaceability;\n7. human authority separated from AI cognition and execution coordination;\n8. execution closure through re-ingestion, verification, reconciliation and rehydration;\n9. one coordination fabric across many user, AI, API and source-system surfaces.\n\nThat combination is the product thesis to prove in Customer Zero and customer deployments.\n\n---\n\n# 30. Canonical Product Formula\n\n```text\nSpineWorkspace\n=\nShared Business Context and Organizational Continuity\n+\nHuman Workbench + Personal Contextual Memory\n+\nAI Workbench + AI Continuity Memory\n+\nShared Work State\n+\nTwin + Spine Agents\n+\nProjection and Context Assembly\n+\nCapability Fabric\n+\nHuman/Policy Governance\n+\nHermes Execution\n+\nVerification and Reconciliation\n+\nContinuous Rehydration\n```\n\nThe platform formula underneath is:\n\n```text\nIntegrateWise Platform\n=\nOne Auth\n+ Configuration\n+ Integration Manager\n+ Discovery\n+ Activation\n+ Gateway / Loader / Four Flows\n+ Normalizer / Triage / Governed Writers\n+ Business Context Spine Fabric\n+ Knowledge / Evidence / Memory / Cache / Events\n+ Projection / Human UI / AI Context Assembly\n+ Model Routing / ADK / Agents\n+ Capability Fabric / Governance / Hermes\n+ Sync / Verification / Reconciliation\n+ Audit / Observability / Security / Tenancy\n+ Distribution through Workbench, Continuity Bridge, MCP, APIs and SDKs\n```\n\n---\n\n# 31. Final Master System Map\n\n```text\n                         ORGANIZATION\n              Mission · Objectives · Goals · KPIs\n                              │\n                              ▼\n                 BUSINESS CONTEXT SPINE\n        Shared Truth · Work · Relationships · Decisions\n       Evidence · Knowledge · History · Organizational Memory\n                              │\n              ┌───────────────┴───────────────┐\n              │                               │\n              ▼                               ▼\n       HUMAN WORKBENCH                   AI WORKBENCH\n       Primary Product                   AI Operations\n              │                               │\n              ▼                               ▼\n   PERSONAL CONTEXTUAL                 AI CONTINUITY\n        MEMORY                            MEMORY\n              │                               │\n              └──────────── SHARED WORK ──────┘\n                              │\n                       HUMAN ↔ TWIN\n                              │\n                        SPINE AGENTS\n                              │\n                       AGENT HANDOFFS\n                              │\n                              ▼\n                   CAPABILITY DISCOVERY\n                              ↓\n                    CAPABILITY FABRIC\n                              ↓\n                        GOVERNANCE\n                              ↓\n                          HERMES\n                              ↓\n       API · MCP · Agent · Browser · Workflow · AI · Human\n                              ↓\n                           OUTCOME\n                              ↓\n                SYNC · VERIFY · RECONCILE\n                              ↓\n                    BUSINESS CONTEXT SPINE\n                              ↓\n           MEMORY / KNOWLEDGE / CONTINUITY UPDATE\n                              ↓\n                    NEW AUTHORIZED PROJECTIONS\n                              ↓\n              HUMAN + AI WORKBENCH REHYDRATE\n                              ↓\n                          NEXT WORK\n```\n\nUnder the entire experience sit One Auth, Configuration Manager, Integration Manager, Connector Marketplace, Discovery, Activation Bridge, Gateway, Loader, Flow A/B/C/D, Normalizer, Triage, Governed Writers, Spine Cache, Knowledge, Blobs/Evidence, events/queues, model routing, ADK, agent registry/runtime, IW Spine Network MCP, MCP Pool, Capability Fabric, Governance, Hermes, Sync, Verification, Reconciliation, audit, observability, security, tenancy, billing/entitlements and the developer platform.\n\n---\n\n# 31A. Supersession Map - August 1 Baseline to August 31 Founder Canon\n\n| August 1 baseline | August 31 Founder Canon |\n|---|---|\n| IntegrateWise Workbench as daily product name | **SpineWorkspace** is the product; **Human Workbench** is its primary user operating surface |\n| Twin as the main AI-side product concept | **AI Workbench** is the AI operating environment; Twin is the human-facing cognitive coworker within it |\n| Twin Memory broadly described as durable user/Twin continuity | **Personal Contextual Memory** and **AI Continuity Memory** are explicitly separate first-class scopes |\n| Adaptive Spine includes memory/continuity generally | **Business Context Spine / Organizational Memory** is the shared organizational continuity scope; personal and AI continuity stay separate |\n| Workbench projection is primarily user-facing | Projection/context composition is explicitly **dual-sided**: Human Workbench projection and AI Workbench context |\n| Agent-to-agent route is a Capability Fabric path | **Spine Agents** are elevated into the operating model and coordinate through durable Work state and evidence |\n| OODA defined as Workbench interaction grammar | OODA is retained as **internal operating grammar**; the user experience stays natural and task-centric |\n| Platform/product/experience are three profiles | The final documentation order becomes **Experience → Product → Shared Context/Memory → Human/AI operating model → Platform → Execution/Continuity → Implementation** |\n| Architecture freeze is canonical | August 1 is now **implementation baseline** where not superseded; August 31 founder decisions are product authority |\n\nThis table is the migration guide for updating repository canon without accidentally reviving stale terminology.\n\n\n# 32. Canonical Vocabulary\n\n| Term | Final meaning |\n|---|---|\n| **IntegrateWise** | Infrastructure platform for connected human-AI work and organizational continuity. |\n| **SpineWorkspace** | Primary product and shared work environment. |\n| **Human Workbench** | Primary user-facing operating surface inside SpineWorkspace. |\n| **AI Workbench** | AI-side operating environment for Twin and Spine Agents. |\n| **Business Contextual Spine Fabric** | Shared organizational context, truth, work, evidence, history and continuity substrate. |\n| **Business Context Memory / Organizational Memory** | Durable organization-owned memory that has passed the appropriate governance/promotion boundary. |\n| **Personal Contextual Memory** | User-bound personal work continuity, private by default. |\n| **AI Continuity Memory** | Twin/agent working continuity; not canonical business truth. |\n| **Work** | Durable unit of human-AI coordination and handoff. |\n| **Twin** | Contextual human-facing cognitive co-worker. |\n| **Spine Agent** | Governed AI worker operating on Work and authorized Spine context. |\n| **Projection Engine** | Sole composer of authorized versioned Workbench/context contracts. |\n| **One Auth-to-Ecosystem** | Identity, tenant, consent, scope, delegation and service-principal authority context. |\n| **Integration Manager** | Connection lifecycle, OAuth, mappings, webhooks, discovery and sync policy. |\n| **Activation Manager** | Administrative surface for activating tenant capabilities/context. |\n| **Activation Bridge** | Runtime compiler of configuration, connections, identity, context, policy and capabilities. |\n| **Continuity Bridge** | Distribution/access boundary for external AI/application surfaces. |\n| **IW Spine Network MCP** | Hosted outward MCP boundary for IntegrateWise. |\n| **MCP Pool** | Inward tenant registry of approved MCP servers/tools. |\n| **ADK** | Agent Development Kit and governed agent runtime contract. |\n| **Capability Fabric** | Provider-neutral registry/resolver for how authorized intent can be performed. |\n| **Governance** | Authority boundary: allow, deny, require approval or bounded delegation. |\n| **Hermes** | Coordinator of approved execution and its operational lifecycle. |\n| **Outcome Event** | Observed provider result, not automatically verified truth. |\n| **Verification/Reconciliation** | Expected-vs-actual closure that determines whether business reality changed as intended. |\n| **Continuity Run** | Traceable lifecycle from intent through execution, outcome, reconciliation and rehydration. |\n| **OODA** | Internal Observe-Orient-Decide-Act product/continuity grammar. |\n\nRetired/constrained concepts: “AI Orchestrator” as a monolith; “Spine database” as the product definition; direct agent canonical writes; provider success as final truth; Continuity Bridge as the full product; MCP as the core data plane; a blank manually-built workspace as onboarding.\n\n---\n\n# 33. Product Acceptance Tests\n\nA customer-facing SpineWorkspace release should prove that:\n\n1. A user can authenticate, bind to a tenant and connect controlled systems.\n2. Initial hydration produces a valid Business Context Spine rather than an empty shell.\n3. Human Workbench composes useful cross-tool context from the Spine.\n4. Personal Contextual Memory persists the user’s working continuity without silently becoming organizational truth.\n5. AI Workbench/Twin receives authorized business context plus AI Continuity Memory.\n6. Twin can explain current work with evidence and prepare an action/proposal.\n7. A Spine Agent can take a subtask with identity, Work state, context and authority, then hand off without losing continuity.\n8. Capability Fabric can resolve a provider-neutral capability to an executable route.\n9. Governance can allow, deny or require approval based on identity/risk/policy.\n10. Hermes executes only an authorized plan and returns outcome evidence.\n11. The provider outcome is re-ingested, verified and reconciled.\n12. The Business Context Spine updates only through governed canonical writes.\n13. Both Human Workbench and AI Workbench rehydrate from the verified new state.\n14. The full chain is reconstructable through trace, approval, capability, execution, evidence and reconciliation lineage.\n15. A model, connector or agent can be replaced without losing the organization’s continuity record.\n\nIf the product cannot close this loop, the platform is not yet embodied in the product experience.\n\n---\n\n# 34. Final One-Sentence Definitions\n\n**SpineWorkspace:**\n\n> SpineWorkspace is a self-organizing shared workspace where humans and AI work from the same governed business context, each with its own continuity memory, so humans can focus on judgment and responsibility while AI handles context assembly, preparation, coordination and permitted execution.\n\n**IntegrateWise:**\n\n> IntegrateWise is the infrastructure platform underneath SpineWorkspace that connects the organization’s systems, preserves business context and continuity, projects the right context to humans and AI, and coordinates governed capability execution through verification and reconciliation.\n\n**The doctrine:**\n\n> **Humans govern. AI helps. Spine preserves continuity.**\n\n---\n\n# Appendix A - Research and Authority Basis\n\n## Founder-authority sources\n\n- **[F1]** Founder decisions and consolidation conversation, 31 August 2026: Human Workbench as primary product; first-class AI Workbench; separate Personal Contextual Memory and AI Continuity Memory; shared Business Context Spine/organizational memory; Spine Agents/shared Work; first-class user experience; internal UI/AI pipelines and OODA; full underlying platform/execution retained in-product.\n- **[F2]** Late-August SpineWorkspace master-system consolidation and visual direction, including the separation of SpineWorkspace (product) from IntegrateWise (infrastructure platform).\n\n## Internal / project sources\n\n- **[I1]** `docs/architecture/CANONICAL_PLATFORM_ARCHITECTURE.md`, IntegrateWise live repository, v3.0.0, freeze 2026-08-01.\n- **[I2]** `docs/architecture/PRODUCT_ARCHITECTURE.md`, v4.0.0, freeze 2026-08-01.\n- **[I3]** `docs/architecture/CANONICAL_GLOSSARY.md`, freeze 2026-08-01.\n- **[I4]** `docs/architecture/DISTRIBUTION_AND_MARKETPLACE.md`, freeze 2026-08-01.\n- **[I5]** `docs/architecture/ONBOARDING_FLOW.md`, canonical onboarding doctrine, downstream of August architecture.\n- **[I6]** `docs/architecture/CAPABILITY_FABRIC.md`, current capability architecture / readiness doctrine.\n- **[I7]** `docs/architecture/CODEBASE_ALIGNMENT_SPEC.md`, active service-to-plane alignment plan.\n- **[I8]** `docs/architecture/USER_SYSTEM_JOURNEY_BLUEPRINT.md`, historical/as-built journey evidence, downstream of current canon.\n- **[I9]** `Design Spine Fabric Architecture.txt`, project working paper: Spine Fabric, Work, Handover, MCP Pool and continuity.\n- **[I10]** `IntegrateWise Product Structure.txt`, project working paper: continuity ontology, namespace separation, resolver, projection.\n- **[I11]** `MCP Routing Implementation Review.txt`, project working paper: Projection Engine, Workbench, OODA, Capability Fabric, Governance, Hermes.\n- **[I12]** `AI-Action-Buttons (2).md`, project working paper: OODA and four canonical interaction actions.\n- **[I13]** `One Model Versus Routing.txt`, project working paper: adaptive model routing and model-profile abstraction.\n- **[I14]** `MCP_POOL_SETUP.md`, Customer Zero MCP Pool working implementation notes.\n- **[I15]** Founder-provided SpineWorkspace master system diagram, 28 August 2026, used as visual consolidation reference.\n\n## External research - category and market validation\n\nExternal research was re-checked on 31 August 2026. It is used to validate market direction - shared enterprise context, human-agent work, governance, execution and organizational learning - and is not used to invent missing IntegrateWise architecture.\n\n- **[E1] OpenAI Frontier (current 2026 product framing).** Official OpenAI materials describe Business Context connecting enterprise systems so AI coworkers can use the same information people do and build durable institutional memory, with Agent Execution plus explicit permissions and auditing.\n- **[E2] Microsoft 2026 Work Trend Index, 5 May 2026.** Official Microsoft research frames the emerging model as agents taking on more execution while humans direct work, make calls and own outcomes; it also argues that organizations need repeatable human handoffs, evaluation infrastructure and learning systems that capture work signals.\n- **[E3] Asana, Operating System for Human-Agent Teams, 4 June 2026.** Asana's official announcement emphasizes humans and agents working from the same plan, with the same context and under the same governance - market validation for shared work/context, not a definition of SpineWorkspace.\n- **[E4] Asana State of Work Innovation / State of AI at Work.** https://asana.com/resources/state-of-work-innovation and https://asana.com/resources/state-of-ai-work - busywork, information-flow and work-design research.\n- **[E5] MuleSoft Agent Fabric.** https://docs.mulesoft.com/general/agent-fabric-overview - discovery, orchestration, governance and observability for agents/MCP.\n- **[E6] Glean Enterprise Context / Enterprise Graph.** https://www.glean.com/platform/enterprise-context and https://www.glean.com/enterprise-context/enterprise-graph - enterprise and personal graph context for AI.\n- **[E7] Atlassian Teamwork Graph.** https://www.atlassian.com/platform/teamwork-graph - context across people, goals, work, content and connected apps for human/agent experiences.\n- **[E8] Palantir Ontology.** https://www.palantir.com/docs/foundry/ontology/why-ontology - evolving operational representation, decisions and decision lineage for humans/agents.\n- **[E9] ServiceNow AI Control Tower.** https://www.servicenow.com/products/ai-control-tower.html - AI asset discovery, governance, permissions, security and lifecycle management.\n- **[E10] Workday Agent System of Record.** Workday administration documentation - centralized agent registration, permissions, monitoring, governance and cross-system interaction.\n- **[E11] Okta Businesses at Work 2026.** https://www.okta.com/ja-jp/newsroom/press-releases/okta-businesses-at-work2026/ - application proliferation across organizations.\n\n---\n\n# Appendix B - Suggested Canonical Repository Set\n\nThe repository should converge from many overlapping architecture files into a controlled set where a single top-level canon owns definitions and downstream documents explain implementation details.\n\n```text\ndocs/canonical/\n  00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md\n  01-PRODUCT-AND-EXPERIENCE.md\n  02-BUSINESS-CONTEXT-SPINE.md\n  03-HUMAN-WORKBENCH-AND-PERSONAL-MEMORY.md\n  04-AI-WORKBENCH-TWIN-AGENTS-AND-AI-MEMORY.md\n  05-WORK-CONTINUITY-AND-HANDOFF.md\n  06-IDENTITY-CONFIG-INTEGRATION-DISCOVERY-ACTIVATION.md\n  07-INGESTION-FOUR-FLOWS-AND-GOVERNED-WRITES.md\n  08-PROJECTION-UI-AND-CONTEXT-COMPOSITION.md\n  09-CAPABILITY-FABRIC-AND-ADK.md\n  10-GOVERNANCE-AUTHORITY-AND-APPROVAL.md\n  11-HERMES-EXECUTION-AND-PROVIDERS.md\n  12-SYNC-VERIFICATION-RECONCILIATION.md\n  13-MEMORY-KNOWLEDGE-EVIDENCE-AND-PRIVACY.md\n  14-MCP-CONTINUITY-BRIDGE-MARKETPLACE-SDK.md\n  15-SECURITY-TENANCY-AUDIT-OBSERVABILITY.md\n  16-ONBOARDING-CUSTOMER-ZERO-AND-GO-LIVE.md\n  17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md\n  18-CANONICAL-GLOSSARY.md\n  contracts/\n  adr/\n  archive/\n```\n\n`00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md` should be the only document allowed to redefine the architecture. All other files must declare whether they are canonical, downstream implementation specifications, evidence/readiness reports or archived history.\n\n---\n\n# Appendix C - Founder Freeze Decisions - 31 August 2026\n\nFor the next canonical repository freeze, the following founder decisions are treated as resolved. They supersede older product framing where conflict exists:\n\n1. **Product brand:** SpineWorkspace.\n2. **Company/platform brand:** IntegrateWise.\n3. **Primary human product:** Human Workbench inside SpineWorkspace.\n4. **AI-side operating environment:** AI Workbench.\n5. **Human AI interface:** Twin.\n6. **Specialized AI workers:** Spine Agents operating on shared Work state.\n7. **Shared organization-owned continuity:** Business Context Spine / Organizational Memory.\n8. **Human continuity:** Personal Contextual Memory, private by default.\n9. **AI continuity:** AI Continuity Memory, separate from canonical truth.\n10. **Shared coordination object:** Work, backed by context, authority, evidence and lineage.\n11. **Context assembly:** Projection Engine / authorized context contracts; no UI or agent independently reconstructs truth.\n12. **AI routing:** model-profile resolver; no model version is part of the durable product contract.\n13. **Agent runtime:** ADK + governed agent contracts.\n14. **Capability selection:** Capability Discovery + Capability Fabric.\n15. **Authority:** Governance.\n16. **Execution coordination:** Hermes.\n17. **Completion:** only after outcome re-ingestion, verification and reconciliation.\n18. **MCP outward:** IW Spine Network MCP.\n19. **MCP inward:** MCP Pool.\n20. **External AI distribution:** IntegrateWise - Continuity Bridge.\n21. **Physical storage:** implementation detail beneath the logical Spine contract and deployment ADR.\n22. **Public user experience:** infrastructure complexity is hidden unless the user is an authorized platform operator.\n23. **Internal UI pipeline:** Projection Engine → Workbench Contract → UI Composition is part of the product but not a normal-user concept.\n24. **Internal AI pipeline:** Business Context + AI Continuity + Work + Evidence + Authority + Capabilities → AI Context → Twin/Agents is part of the product but not a normal-user concept.\n25. **OODA:** retained as internal operating grammar rather than a requirement that the interface expose four literal controls everywhere.\n26. **Authority precedence:** 31 August founder decisions override the 1 August repository freeze on product/experience semantics until the repository is updated.\n\n"}