{"slug":"canonical/FOUNDER-ARCHITECTURE-FLOW-2026-09-04","title":"Founder Architecture Flow","section":"canonical","sectionLabel":"Canon","status":"canon","type":"long-form","path":"canonical/FOUNDER-ARCHITECTURE-FLOW-2026-09-04.md","bytes":195898,"description":"Complete visual and operational flow from external SaaS ingestion to Workbench UI and AI Twin.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> From: https://chatgpt.com/g/g-p-69ff5004949881918e9c45b51e437475/c/6a99d5c4-36ec-83ee-887d-6ba8dce195a6\n\n# you asked\n\nmessage time: 2026-09-04 01:47:06\n\nINITIAL SPINE SCHEMA FOR TENANT ORG TOOLS TO SPINE INGESTION INITIAL ROLE-BASED PROJECTION VIEWS FOR ROLES AND ACCESS ORGANIZATIONAL MEMORY - SPINE FABRIC HOW THE SPINE SCHEMA IS HYDRATED BASED ON THE CONNECTOR - TRIAGE INVOLVES - PROMOTION QUEUE AND CONTINUITY PROJECTIONS ON USER WORKBENCH - SPINEWORKBENCH - TWIN + COWORKER (CONTEXT ASSEMBLY) + A2A, MCP AND REST COMMS PERSONAL MEMORY - USER PROJECTIONS ON AI WORKBENCH - TWIN WORKBENCH AGENTIC MEMORY - AI HUMAN + AI INTERACTION ON TASK AND WORKS - TOOL CAPABILITIES AND INTERACTIONS WORKFLOWS AND SYNC BACK TO SOURCE '\n\n---\n\n# chatgpt response\n\nYour sequence is the right way to assemble the architecture. I would make it the **canonical tenant-to-work loop**, with one important distinction: **Spine schema, projection, memory, AI Workbench, and execution are different layers of the same system—not separate products or truth stores.**\n\nThe current founder canon already freezes the relevant boundaries: Business Context Spine / Organizational Memory, Personal Contextual Memory, AI Continuity Memory, Work, Projection Engine, Twin/AI Workbench, Capability Fabric, Governance, Hermes, and re-ingestion/reconciliation. \n\n# Canonical SpineWorkspace operating flow\n\n```text\n TENANT ORGANIZATION\n │\n ▼\n 1. INITIAL SPINE SCHEMA\n │\n Tenant Business Context Model\n │\n ┌─────────────┴─────────────┐\n │ │\n Core entities Relationships\n Work Authority\n People Evidence\n Communications Events\n Knowledge Capabilities\n │\n ▼\n 2. CONNECTED TOOLS\n CRM · ERP · Email · Docs\n Chat · Calendar · GitHub\n SaaS · APIs · MCP · etc.\n │\n ▼\n 3. TOOLS → SPINE INGESTION\n │\n Flow A / B / C / D\n │\n ▼\n Loader / Normalizer\n │\n ▼\n TRIAGE\n │\n ┌─────────────┼─────────────┐\n │ │ │\n classify link/dedupe prioritize\n │ │ │\n └─────────────┼─────────────┘\n ▼\n SPINE HYDRATION\n │\n operational business context/state\n │\n ┌────────────────┼────────────────┐\n │ │ │\n ▼ ▼ ▼\n Evidence Knowledge Memory Intake\n```\n\n## 4. Initial role-based projection\n\nOnce the Spine has sufficient context:\n\n```text\n BUSINESS CONTEXT SPINE\n │\n ▼\n PROJECTION ENGINE\n │\n ┌────────────────┼────────────────┐\n │ │ │\n Role Department Industry\n │ │ │\n └────────────────┼────────────────┘\n │\n Permission / RBAC\n │\n ▼\n AUTHORIZED PROJECTION\n │\n ▼\n HUMAN WORKBENCH\n```\n\nThis means the tenant does **not** receive a Sales schema, Engineering schema, Finance schema, etc.\n\nThere is one organizational Spine.\n\nThe Projection Engine produces the appropriate view of that Spine for:\n\n```text\nRole × Department × Industry × Authority × Context\n```\n\nThat is consistent with the canonical rule that context assembly belongs to the Projection Engine/authorized context contracts rather than being independently reconstructed by UI or agents. \n\n---\n\n# 5. SpineWorkbench\n\nThe Human Workbench is the first operational projection of the hydrated Spine.\n\n```text\n SPINEWORKSPACE\n │\n ▼\n HUMAN WORKBENCH\n │\n ┌─────────────────┼─────────────────┐\n │ │ │\n Work Records Knowledge\n Tasks Tables Documents\n Views Pages Evidence\n Canvas Entities Context\n │ │ │\n └─────────────────┼─────────────────┘\n │\n ▼\n ACTIVE CONTEXT\n │\n ▼\n TWIN / COWORKER\n```\n\nThe important point is that **the Twin does not independently discover the organization's context**.\n\nThe Workbench interaction establishes the context.\n\n---\n\n# 6. Twin + Coworker = contextual AI work layer\n\nThe Twin is the human-facing AI coworker inside the AI Workbench model defined by the founder canon. \n\nIts context is assembled from:\n\n```text\nBusiness Context Spine\n+\nCurrent Work\n+\nSelected entity\n+\nUser authority\n+\nRelevant organizational memory\n+\nPersonal contextual memory\n+\nAI continuity memory\n+\nEvidence\n+\nAvailable capabilities\n+\nCurrent conversation/session\n```\n\nConceptually:\n\n```text\nHuman\n │\n │ selects / asks / assigns\n ▼\nHuman Workbench\n │\n ▼\nContext Assembly\n │\n ├── Business Context\n ├── Work\n ├── Evidence\n ├── Personal Memory\n ├── AI Continuity\n └── Authority\n │\n ▼\nTwin / AI Workbench\n```\n\n---\n\n# 7. Communication fabric\n\nThe Twin and agents should then communicate through the governed communication/capability fabric:\n\n```text\n TWIN\n │\n ┌──────────┼──────────┐\n │ │ │\n A2A MCP REST\n │ │ │\n ▼ ▼ ▼\n Agents Tools APIs\n │ │ │\n └──────────┼──────────┘\n ▼\n CAPABILITY FABRIC\n```\n\nThese are **communication/execution mechanisms**, not competing sources of organizational truth.\n\nThe founder canon explicitly freezes:\n\n- Agent runtime → ADK + governed agent contracts\n- Capability selection → Capability Discovery + Capability Fabric\n- MCP outward → IW Spine Network MCP\n- MCP inward → MCP Pool\n- Authority → Governance\n- Execution coordination → Hermes. \n\n---\n\n# 8. Personal Memory, Organizational Memory, AI Memory\n\nThis is where your sequence needs three explicit branches.\n\n## Organizational memory\n\n```text\nTriage\n ↓\nMemory Evolution\n ↓\nPromotion Queue\n ↓\nHuman approval\n ↓\nOrganizational Memory\n ↓\nKnowledge / retrieval / future context\n```\n\nThe documented eight-layer memory pipeline places the Promotion Queue and human approval between AI-derived observations and durable organizational memory. \n\n## Personal contextual memory\n\n```text\nUser\n ↓\npersonal observations / preferences / context\n ↓\nPersonal Contextual Memory\n```\n\nPrivate by default.\n\n## AI continuity memory\n\n```text\nTwin / Agent\n ↓\nreasoning/session/continuity state\n ↓\nAI Continuity Memory\n```\n\nThis is **not organizational truth**.\n\nThe founder canon explicitly separates Personal Contextual Memory and AI Continuity Memory from the shared Business Context Spine. \n\nSo the model becomes:\n\n```text\n ┌──────────────────────────┐\n │ BUSINESS CONTEXT SPINE │\n │ Organizational Truth │\n └────────────┬─────────────┘\n │\n ┌─────────────┼─────────────┐\n │ │ │\n ▼ ▼ ▼\n Personal AI Continuity Knowledge\n Memory Memory\n USER AI\n```\n\n---\n\n# 9. Human + AI work\n\nNow everything converges around **Work**.\n\n```text\n WORK\n │\n ┌────────────┼────────────┐\n │ │ │\n Human Twin Agent\n │ │ │\n └────────────┼────────────┘\n │\n Shared context\n + authority\n + evidence\n + lineage\n │\n ▼\n Work execution\n```\n\nThe founder canon makes **Work** the shared coordination object between humans and AI, backed by context, authority, evidence and lineage. \n\nThis is the missing conceptual center if we only describe the system as “Spine → Twin → tools.”\n\n---\n\n# 10. Capability interaction\n\nWhen the Twin needs to do something:\n\n```text\nTwin\n ↓\nUnderstand Work\n ↓\nDetermine required capability\n ↓\nCapability Discovery\n ↓\nCapability Fabric\n ↓\nResolve implementation\n ↓\nGovernance\n ↓\nApproval if required\n ↓\nHermes\n ↓\nMCP / REST / Agent / Workflow / Provider\n ↓\nExternal action\n```\n\nThe Twin therefore **proposes and coordinates**.\n\nIt does not become an uncontrolled writer.\n\n---\n\n# 11. Sync back to source\n\nThis is essential to close the loop.\n\n```text\nExternal Action\n │\n ▼\nProvider Result\n │\n ▼\nRe-ingestion\n │\n ▼\nNormalization\n │\n ▼\nVerification\n │\n ▼\nReconciliation\n │\n ▼\nSpine Updated\n │\n ▼\nProjection Refresh\n │\n ▼\nHuman Workbench\n │\n ▼\nTwin receives new context\n```\n\nThe platform's documented rule is that outbound execution does **not** itself become truth; the result returns through the controlled data path and the Spine is refreshed. \n\n---\n\n# 12. The complete architecture in one diagram\n\nThis is the version I would now use as the **canonical conceptual diagram**:\n\n```text\n SPINEWORKSPACE\n │\n ▼\n ┌──────────────────┐\n │ TENANT / ORG │\n └────────┬─────────┘\n │\n ▼\n INITIAL SPINE SCHEMA\n │\n ▼\n CONNECTED BUSINESS TOOLS\n │\n ┌────────┼────────┐\n │ │ │\n Data Docs/Comms AI\n │ │ │\n └────────┼────────┘\n ▼\n INGESTION / LOADER\n │\n ▼\n NORMALIZATION\n │\n ▼\n TRIAGE\n │\n ┌───────────────┼───────────────┐\n │ │ │\n classify link/dedupe prioritize\n │ │ │\n └───────────────┼───────────────┘\n ▼\n BUSINESS CONTEXT\n SPINE FABRIC\n │\n ┌───────────────┼────────────────┐\n │ │ │\n Organizational Evidence Knowledge\n Memory\n │\n ├───────────────┐\n │ │\n Promotion Queue Continuity\n │ │\n Human approval context transfer\n │ │\n └───────┬───────┘\n ▼\n PROJECTION ENGINE\n │\n Role × Dept × Industry\n × Permission × Context\n │\n ▼\n HUMAN WORKBENCH\n │\n active work/context\n │\n ▼\n TWIN / AI WORKBENCH\n │\n ┌──────────┼──────────┐\n │ │ │\n Personal AI Business\n Memory Continuity Context\n │ Memory │\n └──────────┼───────────┘\n │\n ▼\n WORK\n │\n Human ⇄ Twin ⇄ Agents\n │\n ▼\n CAPABILITY FABRIC\n │\n ┌──────────┼───────────┐\n │ │ │\n MCP REST A2A\n │ │ │\n └──────────┼───────────┘\n ▼\n GOVERNANCE\n │\n ▼\n HERMES\n │\n ▼\n SOURCE SYSTEMS\n │\n ▼\n OUTCOME / EVENT\n │\n ▼\n RE-INGEST / VERIFY / RECONCILE\n │\n ▼\n BUSINESS CONTEXT\n │\n ▼\n NEW PROJECTION\n │\n ▼\n NEXT WORK\n │\n └───────────────► LOOP\n```\n\n## The three memory boundaries are therefore explicit\n\n```text\nSPINE\n= what the organization knows / what is operationally true\n\nPERSONAL MEMORY\n= what the individual carries across work\n\nAI CONTINUITY MEMORY\n= what the Twin/AI carries across reasoning and sessions\n```\n\nAnd the complete product loop is:\n\n> **Tools → Ingestion → Triage → Spine Fabric → Role/Authority Projection → Human Workbench → Context Assembly → Twin/AI Workbench → Work → Capability Fabric → Governance → Hermes → Source Systems → Re-ingestion → Verification → Reconciliation → Spine → new projections → next work.**\n\nThat is the architecture I would use as the top-level **SpineWorkspace operating model**. It incorporates the current founder freeze without introducing another product layer, another truth store, or another independent flow.\n\n---\n\n# you asked\n\nmessage time: 2026-09-04 01:48:54\n\nFINAL GOAL ALIGNMENT INCLUDING UI AND MARKETING WITH ALL SHELLS AND WORKSPACE FOR HUMAN AND AI SHARING WAT EVER MENTIONED ABOVE\n\n---\n\n# chatgpt response\n\n# FINAL GOAL ALIGNMENT — INTEGRATEWISE + SPINEWORKSPACE\n\nThis is the consolidated goal I would now treat as the **founder-level product, UI, architecture, and marketing alignment**.\n\nThe latest Founder Canon explicitly establishes **SpineWorkspace as the product**, **IntegrateWise as the infrastructure/platform**, with a **Human Workbench and AI Workbench operating over the same Business Context Spine**, while personal and AI continuity remain separately scoped. \n\n---\n\n# 1. The simplest definition\n\n> **SpineWorkspace is a shared workspace where humans and AI work together over the same governed business context and Work, while respecting their different boundaries, responsibilities and continuity.**\n\nAnd:\n\n> **IntegrateWise is the infrastructure platform that makes SpineWorkspace possible.**\n\nThe core idea is therefore:\n\n```text\n SPINEWORKSPACE\n The place where work happens\n │\n ▼\n SHARED WORKBENCH\n │\n ┌──────────┴──────────┐\n │ │\n HUMAN AI\n WORKBENCH WORKBENCH\n │ │\n └──────────┬──────────┘\n │\n SHARED BUSINESS\n CONTEXT\n │\n ▼\n SPINE FABRIC\n```\n\nThe user does **not** buy the Spine, MCP, Hermes, loaders, agents or databases.\n\nThe user gets a workspace where the right work, context, information and capabilities are already assembled.\n\n---\n\n# 2. The product hierarchy\n\nThis hierarchy should remain fixed.\n\n```text\nINTEGRATEWISE\nInfrastructure Platform\n │\n ▼\nSPINEWORKSPACE\nProduct / Workspace\n │\n ├──────────────────────┐\n │ │\n ▼ ▼\nHUMAN WORKBENCH AI WORKBENCH\n │ │\n └──────────┬───────────┘\n ▼\n SHARED WORK\n │\n ▼\n BUSINESS CONTEXT SPINE\n │\n ┌──────────┼──────────┐\n ▼ ▼ ▼\n Organizational Personal AI\n Memory Memory Continuity\n```\n\nThis is the constitutional product rule:\n\n> **SpineWorkspace = Human Workbench + AI Workbench + Shared Business Context + Separate Human and AI Continuity + Governed Work and Execution.** \n\n---\n\n# 3. What the customer sees\n\nThe customer sees **Workspace**, not platform machinery.\n\n## Common SpineWorkspace shell\n\nEvery user gets a stable, learnable shell.\n\n```text\nSPINEWORKSPACE\n│\n├── Home\n│\n├── My Work\n│ ├── Inbox\n│ ├── Tasks\n│ ├── My Queue\n│ ├── Approvals\n│ ├── Notifications\n│ ├── Recent Work\n│ └── Favorites\n│\n├── Communications\n│ ├── Activity Feed\n│ ├── Email\n│ ├── Calendar\n│ ├── Meetings\n│ ├── Chat\n│ ├── Calls\n│ └── Shared Documents\n│\n├── Personal\n│ ├── Notes\n│ ├── Knowledge Base\n│ ├── Brainstorming Sessions\n│ └── Activity\n│\n├── Work\n│ └── Adaptive Workbench\n│\n├── Platform\n│ └── Authorized operators only\n│\n└── Administration\n └── Authorized administrators only\n```\n\nThis stable shell is explicitly part of the current architecture: **navigation stays stable; Work adapts.** \n\n---\n\n# 4. Work is where the workspace becomes adaptive\n\nThe shell is common.\n\n**Work is not.**\n\nThe Work area is projected from:\n\n```text\nRole\n× Department\n× Industry\n× Responsibility\n× Permissions\n× Business Context\n× Connected Systems\n× Active Lifecycle\n× Current Work\n× Available Capabilities\n× Knowledge\n× Evidence\n× User Preferences\n× Freshness / Readiness\n```\n\nTherefore:\n\n```text\nFounder\n ↓\nExecutive Work\n\nSales\n ↓\nSales Work\n\nCustomer Success\n ↓\nCustomer Success Work\n\nEngineering\n ↓\nEngineering Work\n\nFinance\n ↓\nFinance Work\n```\n\nBut these are **projections over one Business Context**, not independent applications or databases.\n\nThe same Base Spine remains underneath them.\n\n---\n\n# 5. The Human Workbench\n\nThe Human Workbench is the **primary daily product experience**.\n\nIt is not:\n\n- a dashboard;\n- a CRM;\n- a database UI;\n- a document editor;\n- a chatbot;\n- a department-specific SaaS application.\n\nIt is the operational surface through which a person understands and moves work.\n\n\n\nIt can render:\n\n```text\nTables\nViews\nPages\nDocuments\nBoards\nQueues\nCalendar\nTimeline\nCanvas\nEntity views\nKnowledge\nEvidence\nApprovals\nWork\nTwin\n```\n\nAll of these are **projections**.\n\nThe UI does not own the underlying truth.\n\n---\n\n# 6. The AI Workbench\n\nThe AI Workbench is the corresponding machine-side operating environment.\n\nIt is first-class architecturally even when much of it is invisible to the human user.\n\n```text\nAI WORKBENCH\n│\n├── Objective\n├── Work\n├── Current Context\n├── Business Context\n├── AI Continuity\n├── Evidence\n├── Plan\n├── Subtasks\n├── Agents\n├── Capabilities\n├── Authority\n├── Approvals\n├── Execution\n├── Results\n├── Verification\n└── Handoff\n```\n\nThis is not merely:\n\n```text\nChatGPT\n+\ntools\n```\n\nIt is a persistent working environment for AI.\n\nThe current canon explicitly distinguishes **AI Workbench** from **Twin**: Twin is the contextual co-worker closest to the human, while the AI Workbench can coordinate broader agentic work. \n\n---\n\n# 7. Human and AI share the Workbench, but not everything\n\nThis is one of the most important final distinctions.\n\nThey share:\n\n```text\nBusiness Context\nWork\nOrganizational Memory\nEvidence\nRelationships\nGoals\nOperational state\nAuthorized capabilities\nGoverned context\n```\n\nThey do **not** automatically share:\n\n```text\nHuman private memory\nAI private continuity\nUnauthorized information\nUnapproved authority\nPrivate reasoning\nUnpromoted observations\n```\n\nTherefore:\n\n```text\n SHARED\n BUSINESS CONTEXT\n │\n ┌──────┴──────┐\n │ │\n HUMAN AI\n │ │\nPersonal Memory AI Continuity\n```\n\nThe constitutional memory rule remains:\n\n```text\nUser thought\n ≠\nAI inference\n ≠\nOrganizational truth\n```\n\nPersonal Contextual Memory and AI Continuity Memory do not silently become organizational memory. \n\n---\n\n# 8. Twin\n\nThe Twin is the human's **contextual AI co-worker**.\n\nThe human does not have to reconstruct the business context manually.\n\nThe interaction becomes:\n\n```text\nUser opens Work\n ↓\nUser selects something\n ↓\nWorkspace knows the context\n ↓\nTwin receives authorized context\n ↓\nTwin understands the Work\n ↓\nTwin researches / analyzes / prepares\n ↓\nTwin proposes next action\n ↓\nHuman decides / approves when required\n ↓\nCapability executes\n ↓\nResult returns\n ↓\nWorkspace updates\n```\n\nThe user experience therefore becomes **task-centric rather than AI-centric**.\n\nOODA remains an internal operating grammar rather than something the user must consciously operate as four buttons. \n\n---\n\n# 9. Spine Agents\n\nTwin does not have to do everything itself.\n\nIt can coordinate specialized **Spine Agents**.\n\n```text\n TWIN\n │\n ┌─────────┼─────────┐\n │ │ │\n Research Analysis Execution\n Agent Agent Agent\n │ │ │\n └─────────┼─────────┘\n │\n WORK\n │\n EVIDENCE\n │\n HANDOFF\n```\n\nThe important part is that agents do not communicate merely through ephemeral chat.\n\nThey coordinate through:\n\n```text\nWork\nContext\nEvidence\nAuthority\nHandoff\nContinuity\n```\n\nThat is why **Work is the durable unit of human-AI coordination and handoff**. \n\n---\n\n# 10. Spine Fabric\n\nThe Spine Fabric is the common organizational substrate.\n\nIt receives information from the connected business environment:\n\n```text\nCRM\nERP\nEmail\nCalendar\nChat\nDocuments\nSupport\nProjects\nGitHub\nBilling\nHR\nProduct\nIndustry systems\nAPIs\nMCP\n```\n\nThen:\n\n```text\nTools\n ↓\nIngestion\n ↓\nLoader\n ↓\nNormalization\n ↓\nTriage\n ↓\nSpine\n ↓\nProjection\n```\n\nTriage is important because ingestion is not automatically organizational memory.\n\nThe system distinguishes:\n\n```text\nraw information\n→ normalized information\n→ contextualized information\n→ candidate memory\n→ governed promotion\n→ organizational memory\n```\n\n---\n\n# 11. The Base Spine is always there\n\nEvery tenant begins with the mandatory Base Spine.\n\n```text\nBASE SPINE\n │\n ├── Business entities\n ├── Relationships\n ├── Work\n ├── People\n ├── Evidence\n ├── Provenance\n ├── Authority\n ├── Lifecycle\n ├── Governance\n └── Continuity\n```\n\nThen:\n\n```text\nBase Spine\n+\nIndustry\n+\nDepartment\n+\nRole\n+\nConnector\n+\nTenant\n+\nContext\n=\nEffective Spine\n```\n\nEverything is **additive**.\n\nNo role or connector creates its own reduced organizational universe.\n\n---\n\n# 12. Projection Engine\n\nThe Projection Engine is the boundary between the underlying system and the experience.\n\n```text\n SPINE\n │\n ▼\n PROJECTION ENGINE\n │\n ┌─────────┴─────────┐\n ▼ ▼\n HUMAN PROJECTION AI CONTEXT\n │ │\n ▼ ▼\n HUMAN WORKBENCH AI WORKBENCH\n```\n\nThis is deliberately **dual-sided**.\n\nIt composes:\n\n- what the human is authorized to see and work with;\n- what the Twin/Agent is authorized to reason over.\n\nThe UI and AI runtime should not independently reconstruct organizational truth. \n\n---\n\n# 13. Capabilities\n\nThe Twin does not directly \"know how to use every application.\"\n\nIt asks the Capability Fabric what can be done.\n\n```text\nTwin\n ↓\nRequired capability\n ↓\nCapability Discovery\n ↓\nCapability Fabric\n ↓\nApproved implementation\n ↓\nGovernance\n ↓\nExecution\n```\n\nPossible execution mechanisms include:\n\n```text\nMCP\nREST\nAPI\nTool-to-tool\nAgent-to-agent\nWorkflow\nLocal execution\nProvider adapter\n```\n\nMCP is therefore **one mechanism inside the capability architecture**, not the product's central identity.\n\nThe canonical vocabulary defines Capability Fabric as the provider-neutral resolver for how authorized intent can be performed. \n\n---\n\n# 14. Governance\n\nGovernance sits between intent and consequential action.\n\n```text\nHuman / Twin / Agent\n │\n ▼\n CAPABILITY\n │\n ▼\n GOVERNANCE\n │\n ┌────┼────┐\n ▼ ▼ ▼\n Allow Deny Approval\n │\n ▼\n Hermes\n```\n\nThis preserves the human authority boundary:\n\n```text\nHuman\n= judgment + accountability + consequential approval\n\nAI\n= reasoning + preparation + coordination + permitted execution\n```\n\nThe product is therefore not promising unrestricted autonomous AI.\n\n---\n\n# 15. Hermes and execution\n\nOnce an action is authorized:\n\n```text\nGovernance\n ↓\nHermes\n ↓\nCapability implementation\n ↓\nMCP / REST / Agent / Workflow / Provider\n ↓\nExternal system\n```\n\nBut execution is not the end.\n\n---\n\n# 16. The closed continuity loop\n\nThe complete system must close the loop:\n\n```text\nSOURCE SYSTEMS\n │\n ▼\nINGESTION\n │\n ▼\nNORMALIZATION\n │\n ▼\nTRIAGE\n │\n ▼\nSPINE\n │\n ▼\nPROJECTION\n │\n ▼\nWORKBENCH\n │\n ▼\nTWIN / AI WORKBENCH\n │\n ▼\nWORK\n │\n ▼\nCAPABILITY\n │\n ▼\nGOVERNANCE\n │\n ▼\nHERMES\n │\n ▼\nEXECUTION\n │\n ▼\nSOURCE SYSTEM\n │\n ▼\nRE-INGESTION\n │\n ▼\nVERIFY\n │\n ▼\nRECONCILE\n │\n ▼\nGOVERNED SPINE UPDATE\n │\n ▼\nRE-PROJECTION\n │\n ▼\nWORKBENCH\n │\n ▼\nNEXT WORK\n```\n\nThis is **continuity**.\n\nA provider saying \"success\" is not automatically organizational truth. The result must return through the verification/reconciliation path. \n\n---\n\n# 17. The full UI model\n\nFrom the user's perspective:\n\n```text\n SPINEWORKSPACE\n │\n ┌─────────────┴─────────────┐\n │ │\n COMMON SHELL WORKSPACE\n │ │\n ┌────────┼────────┐ ┌───────┴───────┐\n │ │ │ │ │\n Home My Work Personal HUMAN AI\n │ │ │ WORKBENCH WORKBENCH\n │ │ │ │ │\n │ │ │ └───────┬───────┘\n │ │ │ │\n └────────┴────────┴──────────────────┤\n ▼\n SHARED WORK\n │\n BUSINESS CONTEXT\n │\n TWIN\n │\n CAPABILITIES\n │\n GOVERNANCE\n │\n EXECUTE\n```\n\nThe **common shell is stable**.\n\nThe **Work surface is adaptive**.\n\nThe **AI side is first-class**.\n\nThe **underlying platform remains mostly invisible**.\n\n---\n\n# 18. Platform shell\n\nThere is also an operator/admin side.\n\n```text\nPLATFORM\n│\n├── Integration Manager\n├── Connector Marketplace\n├── Activation Hub\n├── Capability Manager\n├── MCP Pool\n├── AI Models\n├── Knowledge\n├── Memory & Continuity\n├── Automation\n├── Pipelines\n├── Governance\n└── Observability\n```\n\nAnd:\n\n```text\nADMINISTRATION\n│\n├── Organizations\n├── Users\n├── Roles\n├── Permissions\n├── Audit\n├── Billing\n├── Deployments\n├── API Keys\n└── Security\n```\n\nThese are **platform/operator shells**, not what every normal user experiences.\n\n---\n\n# 19. Marketing architecture\n\nThe marketing story should **start with the workspace**, not the infrastructure.\n\n## Hero\n\n# **One Workspace. Shared Work. Human + AI.**\n\n> **SpineWorkspace brings your business work into one place, where people and AI work together over the same governed business context.**\n\nThen:\n\n> Stop switching between applications to find information, reconstruct context and move work forward.\n\n> SpineWorkspace connects the software your business already uses and brings the relevant context, work, knowledge, evidence and capabilities into one adaptive workbench.\n\n> Your Twin works alongside you—assembling context, communicating across systems and agents, preparing work and handling permitted execution—while organizational boundaries and human authority remain intact.\n\nThis is consistent with the current founder canon's experience-first direction and the older \"one workspace / connected workbench\" value proposition, while avoiding the outdated framing of the product itself as merely an AI workspace. \n\n---\n\n# 20. The marketing message hierarchy\n\n### Problem\n\n**Work is fragmented because business context is fragmented.**\n\n```text\nCRM\n+ Email\n+ Calendar\n+ Chat\n+ Documents\n+ Support\n+ Finance\n+ Projects\n+ Other SaaS\n```\n\nThe employee becomes the integration layer.\n\n### Product\n\n**SpineWorkspace is the place where the work comes together.**\n\n### Experience\n\n**One Workbench.**\n\n### AI\n\n**Your Twin works with you over that same business context.**\n\n### Infrastructure\n\n**IntegrateWise connects, normalizes, preserves, projects, governs and executes underneath.**\n\n### Outcome\n\n```text\nLess application switching\nLess context reconstruction\nLess repetitive coordination\nLess duplicated work\nMore continuity\nMore visibility\nMore leverage\n```\n\n---\n\n# 21. The customer should experience this\n\nInstead of:\n\n> \"Which app contains this?\"\n\nthe user experiences:\n\n> \"This is already here.\"\n\nInstead of:\n\n> \"Let me gather all the information before asking AI.\"\n\nthe user experiences:\n\n> \"My Twin already understands the Work.\"\n\nInstead of:\n\n> \"I need to update five systems.\"\n\nthe user experiences:\n\n> \"Prepare this for me.\"\n\nInstead of:\n\n> \"Did the AI actually finish it?\"\n\nthe user experiences:\n\n> \"The result is verified and the Workbench is updated.\"\n\nThat is the product.\n\n---\n\n# 22. What IntegrateWise is doing underneath\n\nThe infrastructure story can then be shown after the product story:\n\n```text\n SPINEWORKSPACE\n │\n Experience Layer\n │\n Human + AI Workbench\n │\n Shared Work\n │\n Business Context\n │\n SPINE FABRIC\n │\n ┌──────────────┼──────────────┐\n │ │ │\n Integration Intelligence Continuity\n │ │ │\n Ingestion Twin/Agents Memory\n Discovery Capability Evidence\n Activation Governance Reconciliation\n │ │ │\n └──────────────┼──────────────┘\n │\n Execution\n │\n Connected Applications\n```\n\nThe infrastructure enables the experience; it does not become the experience.\n\n---\n\n# 23. Final terminology map\n\n| Concept | Final meaning |\n|---|---|\n| **IntegrateWise** | Infrastructure platform/company |\n| **SpineWorkspace** | Product/shared workspace |\n| **Workspace** | Environment where business work happens |\n| **Shell** | Stable navigation and product structure |\n| **Human Workbench** | Primary human operating surface |\n| **AI Workbench** | AI-side operating environment |\n| **Shared Workbench** | The common work/context relationship between human and AI |\n| **Work** | Durable human-AI coordination unit |\n| **Twin** | Human-facing contextual AI co-worker |\n| **Spine Agent** | Governed specialized AI worker |\n| **Business Context Spine** | Shared organizational context/truth substrate |\n| **Organizational Memory** | Governed durable organizational knowledge |\n| **Personal Contextual Memory** | User-specific continuity |\n| **AI Continuity Memory** | AI-specific working continuity |\n| **Projection Engine** | Composes authorized human/AI context |\n| **Capability Fabric** | Resolves how authorized work can be performed |\n| **MCP** | One tool/resource communication mechanism |\n| **A2A** | Agent-to-agent communication/handoff |\n| **REST** | API communication mechanism |\n| **Governance** | Authority boundary |\n| **Hermes** | Approved execution coordination |\n| **Continuity** | Intent → work → execution → verification → reconciliation → rehydration |\n\nThese definitions are directly aligned with the latest canonical vocabulary. \n\n---\n\n# 24. Final founder-level architecture\n\n```text\n INTEGRATEWISE\n Platform / Infrastructure\n │\n ▼\n SPINEWORKSPACE\n Shared Business Workspace\n │\n ┌────────────────┴────────────────┐\n │ │\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n │ TWIN\n │ │\n └────────────────┬────────────────┘\n │\n SHARED WORK\n │\n BUSINESS CONTEXT SPINE\n │\n ┌───────────────┼────────────────┐\n │ │ │\n Organizational Evidence Continuity\n Memory\n │\n ┌───────┴────────┐\n │ │\n Personal AI Continuity\n Memory Memory\n │ │\n └───────┬────────┘\n │\n PROJECTION ENGINE\n │\n Context + Authority\n │\n CAPABILITY FABRIC\n │\n MCP / A2A / REST\n │\n GOVERNANCE\n │\n HERMES\n │\n EXECUTION\n │\n CONNECTED SYSTEMS\n │\n RE-INGESTION\n │\n VERIFY / RECONCILE\n │\n BACK TO THE SPINE\n │\n REPROJECT\n │\n NEXT WORK\n```\n\n## The final message\n\n> **SpineWorkspace is the shared workspace for human and AI work. It brings business context, work, knowledge, evidence and capabilities together in one adaptive workbench, while humans and AI operate within their own responsibilities, memory boundaries and authority.**\n\n> **The human works through the Human Workbench. The Twin and Spine Agents work through the AI Workbench. Both operate over the same governed Business Context and Work.**\n\n> **IntegrateWise is the infrastructure underneath—connecting systems, ingesting and normalizing information, preserving organizational continuity, projecting context, providing capabilities, enforcing governance, executing authorized work, and reconciling outcomes back into the Spine.**\n\nAnd the shortest expression of the entire vision:\n\n# **One Workspace. Shared Work. Human + AI.**\n\n**Humans govern. AI helps. Spine preserves continuity.**\n\n---\n\n# you asked\n\nmessage time: 2026-09-04 01:50:26\n\nEVERY PROJECTION CORRESPONDS TO TABLE TO FRONTEND AND BACKEND MAPPING AND HOW THE DIFFERENT MEMORY AND DB AND AI STORAGE AND MEDIA IS USED AND RETRIVED AND ALL\n\n---\n\n# chatgpt response\n\n# Canonical Projection → Table → Frontend → Backend → Storage → Memory → Retrieval Model\n\nThis is the missing layer that connects the **Spine schema** to the actual **SpineWorkspace UI**.\n\nThe key rule from the canonical material is:\n\n> **The frontend never reads a database or provider directly. Every surface is a projection delivered through the Projection Platform API. A projection can combine multiple canonical tables and storage layers; a sidebar label is never itself a database table.** \n\nSo the correct relationship is:\n\n```text\nUSER\n │\n ▼\nSPINEWORKSPACE SHELL\n │\n ▼\nPROJECTION\n │\n ├── View definition\n ├── Entity/table bindings\n ├── Fields\n ├── KPI definitions\n ├── Filters\n ├── Layout\n ├── Permissions\n ├── Capabilities\n ├── Memory scope\n └── Twin context\n │\n ▼\nPROJECTION PLATFORM API\n │\n ├── Identity\n ├── Tenant\n ├── Role\n ├── Department\n ├── Industry\n ├── Permissions\n ├── Connector availability\n ├── Cache\n └── Data retrieval\n │\n ▼\nSPINE FABRIC\n │\n ├── Structured truth\n ├── Operational state\n ├── Files/media\n ├── Conversations\n ├── Search/embeddings\n ├── Memory\n └── Evidence\n │\n ▼\nFRONTEND PROJECTION\n```\n\n---\n\n# 1. First: there is NOT one physical table per frontend projection\n\nThis distinction is important.\n\nFor example:\n\n```text\nFinance\n```\n\nis a projection.\n\nIt may read:\n\n```text\naccounts\ninvoices\npayments\nbudgets\nexpenses\napprovals\ncontracts\nsignals\nwork\ndocuments\n```\n\nIt does **not** mean:\n\n```text\nfinance_table\n```\n\nThe canonical schema explicitly states that role, department and industry are **projection dimensions**, not storage partitions, and that views are filters/layouts/column configurations over the same Spine entities. \n\nTherefore the actual contract is:\n\n```text\nProjection\n ↓\nProjection Binding\n ↓\nCanonical Entity / Table Family\n ↓\nFields\n ↓\nStorage layers\n ↓\nAPI response\n ↓\nFrontend component\n```\n\n---\n\n# 2. The Projection Binding Registry\n\nThis should be the master object connecting everything.\n\n```text\nProjectionBinding\n│\n├── projection_id\n├── view_id\n├── route\n├── role\n├── department\n├── industry\n│\n├── entity_types[]\n├── canonical_table_families[]\n├── fields[]\n├── kpis[]\n│\n├── read_endpoint\n├── write_capability\n├── governance_policy\n│\n├── memory_scope\n├── knowledge_sources\n├── media_sources\n├── search_collections\n│\n├── twin_context_definition\n├── freshness_policy\n├── cache_policy\n│\n├── connector_dependencies\n├── source_systems\n│\n├── reconciliation_rule\n└── projection_version\n```\n\nThe repository material specifically calls for this type of registry so that the chain is traceable:\n\n```text\ncanonical entity/table family\n→ operational read model\n→ projection contract\n→ Gateway route/service\n→ policy/field visibility\n→ frontend view\n→ capability/action\n→ invalidation/reconciliation\n```\n\n\n\n---\n\n# 3. The six storage layers\n\nThe Spine is not one database.\n\nThe current canonical storage model is:\n\n| Layer | Storage | What belongs there | Used for |\n|---|---|---|---|\n| **1** | Postgres / Neon or tenant operational DB according to the active Book-of-Record boundary | Structured entities, relationships, KPIs, work, governance, provenance | Canonical structured reads/writes |\n| **2** | Redis / KV | Hot state, session state, invalidation, connector state | Fast projection reads |\n| **3** | R2 | Files, PDFs, images, audio, video, exports, raw payloads | Media/document retrieval |\n| **4** | Conversational Store | Email, chat, transcripts, conversations, long-form interaction records | Conversation retrieval and extraction |\n| **5** | Vectorize / pgvector / AI Search | Embeddings and retrieval indexes | Semantic search |\n| **6** | Agent Memory / Durable Objects + cognitive storage | User, Work and AI continuity state | Twin/AI continuity |\n\nThe source material explicitly describes these as separate layers and says the five additional layers beyond structured storage cannot be represented as ordinary Coda/database tables. \n\n---\n\n# 4. How one record exists across the layers\n\nConsider:\n\n> **Customer renewal risk**\n\nIt can exist as:\n\n```text\nPostgres\n│\n└── account\n └── renewal_risk_level = high\n\nConversational Store\n│\n└── customer email / meeting transcript\n\nR2\n│\n└── contract.pdf / QBR.pdf / recording.mp3\n\nVectorize\n│\n└── embedded chunks from those sources\n\nsource_links\n│\n└── links account_signal → source document/chunk\n\nintelligence_evidence\n│\n└── which retrieved chunks supported the AI output\n\nAgent Memory\n│\n└── Twin's active continuity around this account\n```\n\nThese are **not six copies of the same truth**.\n\nThey are different representations serving different retrieval jobs.\n\n---\n\n# 5. Structured Spine → frontend\n\nFor structured data:\n\n```text\nPostgres\n ↓\nProjection Platform\n ↓\npolicy filtering\n ↓\nfield selection\n ↓\nKPI calculation\n ↓\nprojection JSON\n ↓\nfrontend table/card/canvas\n```\n\nExample:\n\n```text\naccount_tasks\n```\n\nmay provide:\n\n```text\nTask\nOwner\nStatus\nDue date\nPriority\nEntity\nPlaybook\nApproval\n```\n\nThe frontend receives only the fields defined by that projection.\n\nIt does not receive the raw table.\n\n---\n\n# 6. Redis / KV → frontend\n\nRedis/KV is **not business truth**.\n\nIt is used for:\n\n```text\nhot projections\nsession state\nconnector health\ninvalidation\nfeature flags\nfrequently accessed counts\n```\n\nThe canonical projection flow is:\n\n```text\nFrontend request\n ↓\nProjection Platform\n ↓\nRedis/KV\n │\n ├── HIT → return hot projection\n │\n └── MISS\n ↓\n Spine read\n ↓\n shape projection\n ↓\n cache result\n ↓\n frontend\n```\n\nThis is why the frontend can feel immediate without turning the cache into the source of truth.\n\nThe documented resolution chain explicitly checks the hot session state before falling back to Spine reads. \n\n---\n\n# 7. R2 → media and documents\n\nR2 is where the **actual bytes** live.\n\nExamples:\n\n```text\nPDF\nDOCX\nPPTX\nPNG\nJPG\nSVG\nMP3\nMP4\nCSV\nexports\nrecordings\nattachments\n```\n\nBut:\n\n```text\nFrontend\n ✕\nR2 direct\n```\n\nInstead:\n\n```text\nFrontend\n ↓\nProjection API\n ↓\nsource_links\n ↓\nauthorized media reference\n ↓\nsigned/controlled retrieval\n ↓\nR2\n```\n\nThe source-link layer is important because the Workbench should show:\n\n```text\ndisplay label\nthumbnail\npreview\nsource type\nsource page\ntimestamp\ndeep link\n```\n\nrather than exposing raw storage keys. \n\n---\n\n# 8. Conversational Store → conversation retrieval\n\nThis handles information such as:\n\n```text\nEmail\nChat\nMeeting transcript\nCall transcript\nCustomer conversation\nPortal submission\nAI conversation\n```\n\nFlow:\n\n```text\nSource\n ↓\nConversational Store\n ↓\nchunk / parse\n ↓\nentity extraction\n ↓\naction extraction\n ↓\nsignal detection\n ↓\nSpine promotion\n```\n\nExample:\n\n```text\nCustomer says in meeting:\n\n\"We are evaluating another platform.\"\n\n ↓\n\nmeeting transcript\n ↓\n\nchunk\n ↓\n\nsignal\n ↓\n\naccount risk\n ↓\n\nsource_links\n ↓\n\nPostgres structured signal\n```\n\nThe original conversation remains retrievable.\n\n---\n\n# 9. Vectorize / AI Search → semantic retrieval\n\nVector storage does **not replace the source document**.\n\nIt answers:\n\n> \"Which pieces of information are semantically relevant to this question?\"\n\nExample:\n\n```text\nUser clicks Account\n ↓\nTwin asks:\n\"What changed recently?\"\n ↓\nsemantic query\n ↓\nVector Search\n ↓\ntop K chunks\n ↓\nsource_links\n ↓\noriginal document\n```\n\nThe evidence chain records:\n\n```text\nchunk_id\nsimilarity_score\nBM25 score\nRRF score\nsource_link_id\n```\n\nso the AI result can be traced back to the actual source. \n\n---\n\n# 10. Agent / AI Memory\n\nAI memory is different again.\n\nThe source material identifies:\n\n```text\nUser Memory\nWork Memory\nOrg Memory\n```\n\nand separately describes agent/Twin continuity.\n\nThe critical rule is:\n\n```text\nAI memory\n ≠\norganizational truth\n```\n\nAI can remember:\n\n```text\nUser preference\nCurrent working context\nPrevious Twin interaction\nActive account\nCurrent work\nReasoning continuity\nLearned pattern\n```\n\nBut an AI observation that should become organizational knowledge goes through:\n\n```text\nAI observation\n ↓\nTriage\n ↓\nproposal\n ↓\ngovernance / HITL\n ↓\npromotion\n ↓\norganizational memory\n```\n\nThe source material explicitly requires HITL for AI-originated writes and preservation of provenance such as origin, confidence and approval. \n\n---\n\n# 11. Personal Memory\n\nPersonal memory is strictly scoped.\n\n```text\nUSER\n │\n └── Personal Memory\n ├── preferences\n ├── private notes\n ├── personal context\n ├── personal filters\n └── private continuity\n```\n\nIt can be used when assembling **that user's** context.\n\nIt does not automatically become:\n\n```text\nTeam memory\nOrganization memory\nAnother user's context\n```\n\nThe canonical memory boundary explicitly says personal memory can only be cited by the user who owns it. \n\n---\n\n# 12. Organizational Memory\n\nOrganizational memory is the opposite:\n\n```text\nTENANT\n │\n ▼\nORGANIZATIONAL MEMORY\n │\n ├── accepted facts\n ├── decisions\n ├── policies\n ├── learnings\n ├── patterns\n ├── commitments\n └── institutional knowledge\n```\n\nIt is created through governed promotion.\n\n```text\nRaw information\n ↓\nInterpretation\n ↓\nTriage\n ↓\nCandidate memory\n ↓\nApproval where required\n ↓\nOrganizational memory\n```\n\nThis prevents:\n\n> \"The AI said it\"\n\nfrom becoming:\n\n> \"The company knows it.\"\n\n---\n\n# 13. Evidence is another cross-cutting layer\n\nEvery meaningful AI-derived result needs to answer:\n\n> **Where did this come from?**\n\nThat is the purpose of:\n\n```text\nsource_links\n```\n\nand:\n\n```text\nintelligence_evidence\n```\n\nThe chain becomes:\n\n```text\nSOURCE\n │\n ├── email\n ├── meeting\n ├── PDF\n ├── image\n ├── recording\n ├── chat\n └── document\n │\n ▼\nSOURCE_LINK\n │\n ▼\nEMBEDDED CHUNK\n │\n ▼\nRETRIEVAL\n │\n ▼\nINTELLIGENCE_EVIDENCE\n │\n ▼\nAI OUTPUT\n │\n ▼\nWORKBENCH\n```\n\nThat means the Twin can say:\n\n```text\nThis risk was detected because:\n• customer email\n• QBR document\n• support conversation\n```\n\nrather than producing an unsupported statement.\n\n\n\n---\n\n# 14. Now map this to the frontend\n\n## Common shell\n\nThese are not domain-specific projections.\n\n### Home\n\n```text\nFrontend\n ↓\nhome projection\n ↓\nevents\n+ work\n+ approvals\n+ notifications\n+ calendar\n+ recent activity\n+ personal context\n```\n\n### My Work\n\n```text\nFrontend\n ↓\nwork projection\n ↓\nwork_items\n+ assignments\n+ approvals\n+ deadlines\n+ commitments\n+ calendar\n```\n\n### Inbox\n\n```text\nFrontend\n ↓\ninbox projection\n ↓\nemail\n+ chat\n+ notifications\n+ mentions\n+ CRM activity\n+ tickets\n+ approvals\n+ workflow events\n```\n\nThe Inbox therefore isn't an email table.\n\nIt is a **cross-source operational projection**. \n\n### Tasks\n\n```text\nFrontend\n ↓\ntask projection\n ↓\nwork_items\n+ tasks\n+ dependencies\n+ assignments\n+ SLA\n```\n\n### My Queue\n\n```text\nFrontend\n ↓\nqueue projection\n ↓\nwork\n+ approvals\n+ handoffs\n+ automation steps\n+ priority policy\n```\n\n### Approvals\n\n```text\nFrontend\n ↓\napproval projection\n ↓\napprovals\n+ memory proposals\n+ governance\n+ evidence\n```\n\n### Notifications\n\n```text\nFrontend\n ↓\nnotification projection\n ↓\nnotifications\n+ connector events\n+ workflow events\n+ security events\n+ Twin events\n```\n\nThe complete common shell is server-composed and filtered by identity, permissions, entitlement and freshness. \n\n---\n\n# 15. Communications mapping\n\n## Activity Feed\n\n```text\nspine_events\n+ timeline\n+ connector events\n+ work events\n+ execution events\n+ human activity\n+ AI activity\n```\n\n## Email\n\n```text\nemail_threads\n+ messages\n+ linked entities\n+ extracted actions\n+ source_links\n+ Twin context\n```\n\n## Calendar\n\n```text\ncalendar_events\n+ participants\n+ linked entities\n+ work\n+ meetings\n```\n\n## Meetings\n\n```text\nmeeting records\n+ transcripts\n+ decisions\n+ tasks\n+ commitments\n+ source_links\n+ memory candidates\n```\n\n## Chat\n\n```text\nchat_threads\n+ messages\n+ entities\n+ actions\n+ context\n```\n\n## Calls\n\n```text\ncall_records\n+ transcript\n+ recording\n+ entities\n+ actions\n+ sentiment\n```\n\n## Documents Shared\n\n```text\ndocument metadata\n+ R2 object\n+ source_links\n+ embeddings\n+ extracted entities\n+ knowledge\n```\n\nThe canonical shell specifically defines Communications as the place where information enters, leaves and becomes operational evidence. \n\n---\n\n# 16. Personal mapping\n\n### Notes\n\n```text\nPersonal projection\n ↓\nuser-scoped notes\n ↓\nstructured note metadata\n+\nR2 if attachment\n+\nVector search if indexed\n```\n\n### Knowledge Base\n\n```text\nKnowledge projection\n ↓\nknowledge entities\n+\ndocuments\n+\nembeddings\n+\nsource links\n```\n\n### Brainstorming Sessions\n\n```text\nconversation/session\n ↓\nbrainstorm record\n ↓\nentities\ndecisions\nlearnings\ncommitments\n ↓\ncandidate memory\n ↓\ntriage\n ↓\npromotion\n```\n\nThe source material explicitly describes brainstorming as capable of becoming user, organizational or agent memory depending on governed classification/promotion. \n\n### Activity\n\n```text\nspine_events\nWHERE actor_id = current_user\n```\n\nThis is user-scoped memory/activity, not a new operational truth table. \n\n---\n\n# 17. Work projections\n\nThis is where the domain-specific projections enter.\n\nThe currently registered projection family contains:\n\n```text\nfounder\nsales\ncs\nmarketing\nfinance\noperations\nproduct\nengineering\naccount-success\ntechnical-account-success\nbusiness-intelligence\ncampaigns\nknowledge-management\nrevops\nsupport\nbrandstore\nbook-of-records\nops\n```\n\nThe repository has enriched these projection manifests with real donor view inventories rather than treating each domain as an independent application. \n\nEach one is:\n\n```text\nsame Spine\n+\ndifferent entity emphasis\n+\ndifferent fields\n+\ndifferent KPIs\n+\ndifferent views\n+\ndifferent capabilities\n+\ndifferent permissions\n+\ndifferent Twin context\n```\n\n---\n\n# 18. Example: Sales projection\n\n```text\nSALES WORKBENCH\n │\n ▼\nProjection: sales\n │\n ├── Accounts\n ├── Contacts\n ├── Leads\n ├── Opportunities\n ├── Discovery\n ├── Proposals\n ├── Forecast\n └── Handoffs\n```\n\nBackend:\n\n```text\nsales projection\n ↓\naccounts\ncontacts\nleads\nopportunities\nactivities\nwork_items\nsignals\ncommunications\nknowledge\n```\n\nFrontend:\n\n```text\nDashboard\nPipeline\nAccounts\nLeads\nOpportunities\nForecast\nActivities\nHandoffs\n```\n\nTwin context when clicking an opportunity:\n\n```text\nopportunity\n+\naccount\n+\ncontact\n+\nrecent communications\n+\nopen work\n+\nsignals\n+\nrelevant documents\n+\nsemantic retrieval\n+\nauthorized memory\n```\n\nNot:\n\n```text\ngeneric AI chat\n```\n\n---\n\n# 19. Example: Finance projection\n\n```text\nFINANCE\n │\n ├── Invoices\n ├── Payments\n ├── Expenses\n ├── Budgets\n ├── Cash\n ├── Forecast\n ├── Vendors\n └── Approvals\n```\n\nPossible underlying structured sources:\n\n```text\nbilling records\ninvoice entities\npayment entities\nexpense entities\nbudget entities\napproval records\nwork items\ncontracts\n```\n\nAdditional storage:\n\n```text\nR2\n→ invoice PDFs\n→ contracts\n→ financial reports\n\nConversational Store\n→ finance emails\n→ approval conversations\n\nVector Search\n→ contracts\n→ policies\n→ financial documents\n\nMemory\n→ approved financial operating knowledge\n```\n\nFrontend:\n\n```text\nInvoice Queue\nPayment Calendar\nBudget vs Actual\nVendor Contracts\nApproval Queue\n```\n\nThese are views over the same underlying data, not five databases. The Finance Manager example in the schema documentation illustrates exactly this pattern. \n\n---\n\n# 20. Example: Customer Success\n\n```text\nCUSTOMER SUCCESS\n │\n ├── Accounts\n ├── Health\n ├── Success Plans\n ├── Adoption\n ├── Cases\n ├── Renewals\n ├── QBRs\n └── Commitments\n```\n\nStructured:\n\n```text\naccounts\naccount_contacts\naccount_health_logs\naccount_success_plans\naccount_tasks\naccount_signals\naccount_initiatives\n```\n\nDocuments:\n\n```text\nQBR deck\ncontract\ncustomer report\nmeeting recording\n```\n\nConversation:\n\n```text\nemails\nmeetings\ncalls\nsupport conversations\n```\n\nSearch:\n\n```text\naccount-related embeddings\nknowledge\nsimilar cases\ncustomer history\n```\n\nTwin:\n\n```text\nclick account\n ↓\nassemble account context\n ↓\nretrieve evidence\n ↓\nshow health explanation\n ↓\nshow relevant work\n ↓\npropose next action\n```\n\nThe Account Intelligence schema explicitly maps these layers and links health signals and Twin reasoning back to evidence. \n\n---\n\n# 21. Canvas is also a projection\n\nThis is important for the Coda/Notion/UI Bakery style you described.\n\nA canvas does not create a new database.\n\n```text\nCANVAS\n │\n ├── Section A → entity fields\n ├── Section B → related entities\n ├── Section C → table\n ├── Section D → knowledge\n ├── Section E → documents\n ├── Section F → signals\n ├── Section G → work\n └── Section H → Twin context\n```\n\nSo:\n\n```text\nCanvas\n ↓\nProjection API\n ↓\nmultiple Spine entities/tables\n ↓\nmultiple storage layers\n ↓\nassembled page\n```\n\nThis is why a record can contain:\n\n```text\nstructured fields\n+\nrelated table\n+\ndocument\n+\nimage\n+\ntimeline\n+\nknowledge\n+\nsignal\n+\nTwin\n```\n\nwithout duplicating the underlying data.\n\n---\n\n# 22. The Twin retrieval sequence\n\nWhen a user clicks an object:\n\n```text\nUSER CLICKS ENTITY\n ↓\nIDENTIFY\nentity_id\ntenant_id\nuser_id\nprojection\n ↓\nAUTHORIZE\n ↓\nLOAD STRUCTURED ENTITY\n ↓\nLOAD RELATED ENTITIES\n ↓\nLOAD ACTIVE WORK\n ↓\nLOAD RELEVANT MEMORY\n ↓\nLOAD KNOWLEDGE\n ↓\nSEMANTIC SEARCH\n ↓\nLOAD SOURCE LINKS\n ↓\nLOAD EVIDENCE\n ↓\nASSEMBLE ACTIVE CONTEXT\n ↓\nTWIN\n```\n\nThe result is:\n\n```text\nActiveContextBundle\n```\n\ncontaining the authorized information needed for that particular piece of Work.\n\n---\n\n# 23. Twin context is therefore assembled, not stored as one giant blob\n\n```text\n TWIN CONTEXT\n │\n ┌─────────────────┼─────────────────┐\n │ │ │\n Structured Documents Memory\n │ │ │\n Postgres R2 User/AI/Org\n │ │ │\n ├──────────┐ │ ┌──────────┤\n │ │ │ │ │\n Work/Entity Signals Search Evidence Conversation\n │ │ │ │ │\n └──────────┴──────┴──────┴──────────┘\n │\n ▼\n ACTIVE CONTEXT\n │\n ▼\n TWIN\n```\n\nThis is the correct implementation of the idea:\n\n> **Twin is not another database. Twin is cognition operating over assembled, governed context.**\n\n---\n\n# 24. Write path\n\nThe reverse path is equally important.\n\n### Human edit\n\n```text\nFrontend\n ↓\nProjection API\n ↓\nGovernance / authorization\n ↓\ngoverned writer\n ↓\nstructured Spine\n ↓\noutbox/event\n ↓\ncache invalidation\n ↓\nsource write-back if required\n ↓\nreconciliation\n ↓\nprojection refresh\n```\n\n### Twin proposal\n\n```text\nTwin\n ↓\nproposal\n ↓\nGovernance\n ↓\napproval if required\n ↓\ngoverned writer\n ↓\nSpine\n ↓\nsource_links / evidence\n ↓\noutbox\n ↓\nsource system\n ↓\nreceipt\n ↓\nre-ingestion\n ↓\nreconciliation\n ↓\nupdated projection\n```\n\nThe canonical material explicitly says the browser, Twin, connectors, public MCP, normalizer, Triage and Projection Engine do **not** directly write canonical storage; canonical promotion is through governed writers. \n\n---\n\n# 25. Connector hydration\n\nA connector doesn't simply create a separate mini-application.\n\nIt changes what the Spine can represent.\n\n```text\nCONNECTOR INSTALLED\n ↓\nConnector category\n ↓\nSchema Module\n ↓\nField/entity capability\n ↓\nIngestion mapping\n ↓\nSpine hydration\n ↓\nSearch/index updates\n ↓\nProjection recalculation\n ↓\nNew columns / records / signals\n ↓\nTwin context expands\n```\n\nThe connector schema material explicitly says connector installation can affect all six Spine layers and that views, signal categories, health calculations and Twin context adapt accordingly. \n\n---\n\n# 26. The complete frontend/backend/storage contract\n\nThis is the final mapping I would put into the architecture document:\n\n```text\n┌──────────────────────────────────────────────────────────────┐\n│ FRONTEND │\n│ │\n│ Shell → Surface → View → Table/Card/Canvas/Twin │\n└───────────────────────────┬──────────────────────────────────┘\n │\n ▼\n┌──────────────────────────────────────────────────────────────┐\n│ PROJECTION PLATFORM API │\n│ │\n│ Identity → Tenant → Role → Department → Industry │\n│ Permissions → Connector availability → Projection manifest │\n│ Cache → Query → Shape → Capability → Response │\n└───────────────────────────┬──────────────────────────────────┘\n │\n ▼\n┌──────────────────────────────────────────────────────────────┐\n│ SPINE FABRIC │\n│ │\n│ Structured │ Operational │ Knowledge │ Memory │ Evidence │\n└───────┬────────┬─────────┬──────────┬─────────┬─────────────┘\n │ │ │ │ │\n ▼ ▼ ▼ ▼ ▼\n SQL DB KV/D1 R2 Conversation Vector\n Store Search\n │ │ │ │ │\n └────────┴─────────┴──────────┴─────────┘\n │\n ▼\n CONTEXT ASSEMBLY\n │\n ┌───────────┴───────────┐\n │ │\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n └───────────┬───────────┘\n │\n TWIN\n │\n CAPABILITY FABRIC\n │\n GOVERNANCE\n │\n HERMES\n │\n SOURCE SYSTEMS\n │\n RE-INGEST / VERIFY\n │\n RECONCILIATION\n │\n SPINE\n```\n\n---\n\n# 27. The most important final rule\n\nEvery **visible thing** in SpineWorkspace should be traceable.\n\n```text\nFrontend\n ↓\nProjection\n ↓\nView\n ↓\nEntity\n ↓\nField\n ↓\nCanonical table\n ↓\nStorage layer\n ↓\nSource\n```\n\nAnd for AI:\n\n```text\nFrontend\n ↓\nTwin\n ↓\nContext\n ↓\nMemory / Search / Evidence\n ↓\nSource\n```\n\nAnd for execution:\n\n```text\nFrontend / Twin\n ↓\nIntent\n ↓\nCapability\n ↓\nGovernance\n ↓\nExecution\n ↓\nSource system\n ↓\nReceipt\n ↓\nRe-ingestion\n ↓\nReconciliation\n ↓\nSpine\n ↓\nProjection refresh\n```\n\nThat gives you the **complete spine-to-UI contract**:\n\n> **The table is not the projection. The projection defines how canonical entities and their supporting storage layers become a frontend experience. The backend assembles and authorizes it. Structured storage holds structured truth; R2 holds media; the conversational store holds long-form interaction data; vector search retrieves meaning; memory preserves scoped continuity; evidence connects intelligence back to sources; and the frontend receives only the resulting authorized projection.**\n\nThis is the level of mapping needed so that **every Workbench table, page, dashboard, board, calendar, canvas, communication surface and Twin interaction can be traced all the way down to the underlying Spine and all the way back to the original source.**\n\n---\n\n# you asked\n\nmessage time: 2026-09-04 01:51:45\n\nNOW ADD CONNECTOR FLOW AND INGESTION AND THE PIPELINE AND GTM FLOW, OR GO LIVE FLOW\n\n---\n\n# chatgpt response\n\n# Final Integrated Flow: Connector → Ingestion → Spine → Projection → Workbench → AI → GTM → Go-Live\n\nThe connector flow should now be added **before the projection/storage flow**, because connectors are what progressively turn a blank tenant into a useful, continuously operating SpineWorkspace.\n\nThe complete model is:\n\n```text\nMARKET / GTM\n ↓\nENTRY / ACTIVATION\n ↓\nIDENTITY + TENANT + WORKSPACE\n ↓\nCONNECTOR DISCOVERY\n ↓\nCONSENT + CONNECTION\n ↓\nCONNECTOR DISCOVERY\n ↓\nCATEGORY + MAPPING + CAPABILITY ACTIVATION\n ↓\nINGESTION PIPELINE\n ↓\nSPINE HYDRATION\n ↓\nMEMORY / KNOWLEDGE / EVIDENCE\n ↓\nPROJECTION ENGINE\n ↓\nHUMAN WORKBENCH\n ↕\nAI WORKBENCH / TWIN\n ↓\nWORK\n ↓\nCAPABILITY\n ↓\nGOVERNANCE\n ↓\nEXECUTION\n ↓\nSOURCE SYSTEM\n ↓\nSYNC / RE-INGESTION\n ↓\nRECONCILIATION\n ↓\nSPINE\n ↓\nWORKBENCH REHYDRATION\n ↓\nCONTINUOUS VALUE\n ↓\nEXPANSION / RETENTION\n```\n\nThe architecture documents distinguish **Flow D** as the prerequisite activation/control path and **Flows A, B and C** as the actual data/cognitive paths. \n\n---\n\n# 1. GTM → Customer Entry\n\nThere are **three marketplace/distribution surfaces**, but they have different jobs.\n\n| Entry | Purpose | What happens |\n|---|---|---|\n| **Plugin Marketplace** | External acquisition + embedded activation | User installs the IntegrateWise Spine Network Plugin |\n| **MCP Marketplace** | External acquisition + tool-first activation | MCP client connects to IntegrateWise |\n| **Connector Marketplace** | In-product activation + expansion | Existing workspace connects another business system |\n| **Direct Workbench** | Direct acquisition | User starts IntegrateWise directly |\n\nThe important distinction is:\n\n> **Plugin and MCP Marketplace bring the customer into IntegrateWise. Connector Marketplace expands the customer's connected operating environment.**\n\n\n\n---\n\n# 2. GTM → Workspace Activation\n\nThe customer journey becomes:\n\n```text\nCATEGORY / DEMAND\n ↓\nPlugin / MCP / Direct Workbench\n ↓\nIDENTITY\n ↓\nORGANIZATION\n ↓\nTENANT\n ↓\nWORKSPACE\n ↓\nGOALS + ROLE + RESPONSIBILITY\n ↓\nCONNECT REALITY\n ↓\nDISCOVER\n ↓\nCONFIGURE\n ↓\nACTIVATE\n```\n\nThe founder canon explicitly defines onboarding as:\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\n\n\nSo **onboarding is not account creation**.\n\nIt is:\n\n> **Blank tenant → connected operational environment → useful workspace.**\n\n---\n\n# 3. Connector Marketplace\n\nOnce the workspace exists:\n\n```text\nCONNECTOR MARKETPLACE\n ↓\nSelect Salesforce / Slack / Gmail / GitHub / Zendesk / etc.\n ↓\nCONNECT\n ↓\nOAuth / API / MCP / approved transport\n ↓\nCONSENT\n ↓\nSCOPES\n ↓\nTENANT BINDING\n ↓\nCONNECTION READY\n```\n\nThe connector does **not** immediately dump provider data into the Spine.\n\nIt first establishes the connector contract.\n\n---\n\n# 4. Connector Discovery\n\nThe connector then discovers:\n\n```text\nProvider\n│\n├── Objects\n├── Fields\n├── Types\n├── Constraints\n├── Events\n├── Webhooks\n├── Read operations\n├── Write operations\n├── MCP tools\n├── MCP resources\n├── Pagination\n├── Cursors\n├── Rate limits\n├── Account scope\n└── Region / environment\n```\n\nDiscovery produces **provider metadata**.\n\nIt does not yet change canonical business truth. \n\n---\n\n# 5. Connector Category Resolution\n\nThe provider is then classified.\n\n```text\nSalesforce\nHubSpot\nDynamics\n ↓\nCRM\n\nZendesk\nFreshdesk\n ↓\nSupport\n\nGmail\nSlack\n ↓\nCommunication\n\nStripe\nNetSuite\n ↓\nFinance / Billing\n\nGitHub\nLinear\n ↓\nProject / Engineering\n```\n\nThe crucial rule:\n\n> **Provider name identifies the source. Category determines the canonical contract.**\n\nSo Salesforce and HubSpot can populate the same canonical CRM structures. \n\n---\n\n# 6. Connector → Capability Activation\n\nThe category then activates the relevant platform behavior.\n\n```text\nCATEGORY\n ↓\nSEMANTIC / DOMAIN EXTENSION BUNDLE\n ↓\nCANONICAL ENTITIES\n ↓\nFIELDS\n ↓\nRELATIONSHIPS\n ↓\nDOCUMENT TYPES\n ↓\nSIGNAL TYPES\n ↓\nHEALTH METRICS\n ↓\nCAPABILITIES\n ↓\nPROJECTION HINTS\n```\n\nThe current architecture replaces the older physical \"Module Activator\" concept with **Semantic and Domain Extension Bundles**.\n\nActivation is idempotent and versioned. \n\n---\n\n# 7. Connector → Mapping\n\nNow provider fields are mapped into the canonical model.\n\n```text\nProvider object\n ↓\nCanonical entity\n ↓\nCanonical field\n ↓\nTransformation\n ↓\nType conversion\n ↓\nUnit / enum conversion\n ↓\nSource binding\n ↓\nSource priority\n ↓\nRead / write direction\n ↓\nConflict policy\n```\n\nFor example:\n\n```text\nSalesforce Account\n ↓\nCanonical Account\n\nHubSpot Company\n ↓\nCanonical Account\n\nZendesk Ticket\n ↓\nCanonical Work / Support Ticket\n\nSlack Message\n ↓\nConversation / Communication\n\nGoogle Calendar Event\n ↓\nMeeting / Event\n```\n\nUnmapped provider fields are routed for mapping review rather than silently becoming arbitrary Spine schema. \n\n---\n\n# 8. Connector → Flow Activation\n\nNow the connector determines which ingestion routes are armed.\n\n```text\n CONNECTOR\n │\n ┌────────────┼────────────┐\n │ │ │\n ▼ ▼ ▼\n FLOW A FLOW B FLOW C\n Structured Documents AI /\n Operations Comms Cognitive\n │ │ │\n └────────────┼────────────┘\n │\n ▼\n FLOW D\n Platform / activation\n```\n\n### Flow A\n\nStructured operational data.\n\n```text\nCRM\nERP\nBilling\nSupport\nHR\nProject\nTelemetry\n```\n\n### Flow B\n\nUnstructured operational information.\n\n```text\nEmail\nChat\nDocuments\nAttachments\nCalls\nMeeting transcripts\n```\n\n### Flow C\n\nAI/cognitive information.\n\n```text\nTwin observations\nAgent work\nInterpretations\nSignals\nProposals\nContinuity candidates\n```\n\n### Flow D\n\nConnector/control state.\n\n```text\nIdentity\nConsent\nConnection\nMapping\nSync\nHealth\nCapability\nPolicy\n```\n\nFlow D binds the connector to the tenant; it does not itself absorb business records. \n\n---\n\n# 9. The Ingestion Pipeline\n\nThis is the central data movement system.\n\n## Structured\n\n```text\nPROVIDER\n ↓\nTENANT GATE\n ↓\nLOADER\n ↓\nFLOW ROUTER\n ↓\nNORMALIZER\n ↓\nVALIDATOR\n ↓\nDEDUP / RELATIONSHIP RESOLUTION\n ↓\nGOVERNED SPINE WRITER\n ↓\nSPINE\n```\n\nThe current Loader Runtime performs bootstrap and continuous hydration through this boundary. \n\n---\n\n# 10. Document / Communication Pipeline\n\nFor Flow B:\n\n```text\nSOURCE\n ↓\nINGEST\n ↓\nPARSE\n ↓\nCLASSIFY\n ↓\nEXTRACT\n ↓\nENRICH\n ↓\nROUTE\n ↓\nGOVERN\n ↓\nPROMOTE\n```\n\nThe documented 8-stage pipeline is:\n\n> **Ingest → Parse → Classify → Extract → Enrich → Route → Govern → Promote.**\n\n\n\nThis means an email, PDF, meeting transcript or attachment does **not** simply become a Postgres record.\n\n---\n\n# 11. Media / Document Storage During Ingestion\n\nThe media path is:\n\n```text\nDocument / Attachment / Recording\n ↓\n R2\n │\n ├── original artifact\n ├── metadata\n └── retrieval reference\n ↓\n Parsing\n ↓\n Chunks\n ↓\n Embeddings\n ↓\n Vector Search\n ↓\n Source Links\n```\n\nSo:\n\n```text\nR2\n= artifact bytes\n\nConversational Store\n= long-form communications\n\nVector\n= semantic retrieval representation\n\nSpine\n= governed canonical representation / relationships\n\nsource_links\n= relationship between the representation and source\n```\n\nThis preserves the distinction between source material and derived representations.\n\n---\n\n# 12. Creamy Initial Hydration\n\nThe first sync is deliberately different from ongoing synchronization.\n\n```text\nCONNECTION READY\n ↓\nCREAMY LOAD\n ↓\nINITIAL ENTITY / DOCUMENT INGESTION\n ↓\nCANONICALIZATION\n ↓\nRELATIONSHIP BUILDING\n ↓\nINITIAL INDEXING\n ↓\nINITIAL PROJECTIONS\n ↓\nWORKSPACE READY\n```\n\nThe documented onboarding implementation invokes the real loader for **Creamy hydration**, rather than fabricating a job or simply seeding frontend data. \n\nThe goal is:\n\n> **The first time the user opens the workspace, it already contains useful business context.**\n\n---\n\n# 13. Then Breadth Hydration\n\nCreamy does not mean \"everything.\"\n\nThe next stage expands coverage.\n\n```text\nCREAMY\n ↓\nCore useful entities\n ↓\nBREADTH\n ↓\nMore entities / documents / relationships\n ↓\nFULL CONTINUOUS SYNC\n```\n\nThis avoids delaying first value while still allowing the Spine to become comprehensive over time.\n\nThe architecture describes this as:\n\n> creamy-layer initial hydration → breadth hydration → full ongoing continuity. \n\n---\n\n# 14. Continuous Sync\n\nAfter initial hydration:\n\n```text\nWEBHOOK\n │\nPOLL\n │\nSCHEDULE\n │\nDELTA\n │\nBATCH\n │\nSTREAM\n │\n ▼\nINGESTION\n ↓\nNORMALIZATION\n ↓\nSPINE UPDATE\n```\n\nThen:\n\n```text\nRedis invalidation\n ↓\nVector re-embedding\n ↓\nProjection refresh\n ↓\nTwin context refresh\n```\n\nThe older detailed connector algorithm explicitly describes Redis invalidation, vector re-embedding and view rebuilding as downstream effects of connector activation. \n\n---\n\n# 15. Connector Activation Changes the Entire Workspace\n\nThis is the important Capability Fabric behavior.\n\nAdding:\n\n```text\nZendesk\n```\n\ndoes not merely add:\n\n```text\nZendesk connector\n```\n\nIt can cause:\n\n```text\nSupport fields\n+\nSupport signals\n+\nSupport score\n+\nDocument types\n+\nPipeline rules\n+\nVector collections\n+\nTwin context\n+\nWorkbench columns\n+\nCapabilities\n```\n\nto become available.\n\nThe connector therefore **expands the operating model**, not merely the integration list.\n\nThe documented Fabric model describes this as classification → schema/domain activation → signal propagation → intelligence recalibration → governance. \n\n---\n\n# 16. Spine Hydration\n\nThe end result is:\n\n```text\n CONNECTED ECOSYSTEM\n │\n ┌─────────────┼─────────────┐\n │ │ │\n Structured Documents Cognitive\n │ │ │\n ▼ ▼ ▼\n Flow A Flow B Flow C\n │ │ │\n └─────────────┼─────────────┘\n ▼\n GOVERNED\n SPINE STATE\n```\n\nThe Spine now contains the organization's connected operational context.\n\n---\n\n# 17. Projection Generation\n\nThen:\n\n```text\nSPINE\n ↓\nPROJECTION ENGINE\n ↓\nRole\n× Department\n× Industry\n× Permissions\n× Connected capabilities\n× Current Work\n ↓\nWORKBENCH COMPOSITION\n```\n\nSo a connector changes what can be projected.\n\nExample:\n\n```text\nNo Support connector\n ↓\nNo support-specific operational projection\n\nZendesk connected\n ↓\nSupport context becomes available\n\nZendesk + CRM\n ↓\nCustomer + Support relationship\n\nZendesk + CRM + Product telemetry\n ↓\nCustomer + Support + Usage context\n```\n\n---\n\n# 18. Human Workbench\n\nThe user sees:\n\n```text\nHOME\nMY WORK\nINBOX\nTASKS\nQUEUE\nAPPROVALS\nCOMMUNICATIONS\nWORK\nPERSONAL\n```\n\nand inside Work:\n\n```text\nTABLE\nDETAIL\nBOARD\nDASHBOARD\nCANVAS\nTIMELINE\nFEED\nCALENDAR\n```\n\nThese are **projections**, not independent databases.\n\n---\n\n# 19. AI Workbench\n\nAt the same time:\n\n```text\n ACTIVE WORK\n ↓\n CONTEXT ASSEMBLY\n ↓\n ┌──────────┼──────────┐\n │ │ │\n Business Memory Evidence\n Context /Search\n │ │ │\n └──────────┼──────────┘\n ↓\n TWIN\n```\n\nThe Twin receives the context relevant to the current Work.\n\n---\n\n# 20. Memory Activation\n\nConnector data can feed multiple memory/retrieval paths.\n\n```text\n SPINE\n │\n ┌──────────────┼──────────────┐\n │ │ │\n Organizational Personal AI\n Memory Memory Continuity\n │ │ │\n │ │ │\n └──────────────┼──────────────┘\n │\n Context Assembly\n │\n ▼\n TWIN\n```\n\nBut the boundaries remain strict:\n\n```text\nPersonal Memory\n→ user scope\n\nAI Continuity\n→ AI scope\n\nOrganizational Memory\n→ governed organizational scope\n```\n\nAI-generated information does not automatically become organizational truth.\n\n---\n\n# 21. Work → Twin → Capability\n\nNow the customer actually uses the system.\n\n```text\nUSER\n ↓\nWORK\n ↓\nTWIN\n ↓\nUNDERSTAND\n ↓\nPROPOSE\n ↓\nCAPABILITY DISCOVERY\n ↓\nCAPABILITY RESOLUTION\n ↓\nGOVERNANCE\n```\n\nPossible capability paths:\n\n```text\nMCP\nREST\nAPI\nTool → Tool\nAgent → Agent\nWorkflow\nLocal execution\nAI execution\n```\n\nThe capability fabric determines **how** the approved work can be performed.\n\n---\n\n# 22. Governance → Execution\n\n```text\nTWIN PROPOSAL\n ↓\nGOVERNANCE\n ↓\n┌─────┼────────┐\n│ │ │\nALLOW DENY APPROVAL\n │\n ▼\n HUMAN APPROVES\n │\n ▼\n HERMES\n │\n ▼\n PROVIDER ACTION\n```\n\nThe system must never treat:\n\n```text\nAI said it succeeded\n```\n\nas:\n\n```text\nbusiness truth\n```\n\n---\n\n# 23. Source-System Writeback\n\nAfter execution:\n\n```text\nHermes\n ↓\nProvider\n ↓\nExternal system\n ↓\nProvider outcome\n ↓\nReceipt\n```\n\nThen the system re-enters the ingestion path.\n\n```text\nPROVIDER OUTCOME\n ↓\nRE-INGEST\n ↓\nVERIFY\n ↓\nRECONCILE\n ↓\nCANONICAL SPINE UPDATE\n```\n\nThe current architecture explicitly defines the end-to-end loop as external event → normalization → Spine → projection → Twin → human decision → capability execution → provider acceptance → reconciliation → verified Spine update. \n\n---\n\n# 24. Projection Rehydration\n\nOnly after reconciliation:\n\n```text\nVERIFIED SPINE STATE\n ↓\nCACHE INVALIDATION\n ↓\nVECTOR / SEARCH UPDATE\n ↓\nPROJECTION REBUILD\n ↓\nWORKBENCH REFRESH\n ↓\nTWIN CONTEXT REFRESH\n```\n\nThe user therefore sees the actual reconciled state.\n\nNot:\n\n```text\n\"Saved\"\n```\n\nwhile the provider is still pending.\n\nThe documented stop-ship rule is to show **Pending Sync** until reconciliation confirms the result. \n\n---\n\n# 25. Now the Complete Customer Lifecycle\n\nThis is the final combined flow:\n\n```text\n MARKET\n │\n ┌──────────────┼──────────────┐\n │ │ │\n Plugin MCP Direct\n Marketplace Marketplace Workbench\n │ │ │\n └──────────────┼──────────────┘\n ▼\n IDENTITY / TENANT\n │\n ▼\n WORKSPACE\n │\n ▼\n GOALS / ROLE\n │\n ▼\n CONNECTOR MARKETPLACE\n │\n ▼\n CONNECT SYSTEM\n │\n ▼\n CONSENT\n │\n ▼\n DISCOVERY\n │\n ▼\n CATEGORY RESOLUTION\n │\n ▼\n MAPPING / CAPABILITIES\n │\n ▼\n FLOW ACTIVATION\n │\n ┌─────────────┼─────────────┐\n │ │ │\n FLOW A FLOW B FLOW C\n Structured Documents AI/Cognitive\n │ │ │\n └─────────────┼─────────────┘\n ▼\n LOADER / PIPELINE\n │\n ▼\n CREAMY HYDRATION\n │\n ▼\n BREADTH HYDRATION\n │\n ▼\n BUSINESS CONTEXT SPINE\n │\n ┌─────────────┼─────────────┐\n │ │ │\n Evidence Memory Search\n │ │ │\n └─────────────┼─────────────┘\n ▼\n PROJECTION ENGINE\n │\n ┌────────────┴────────────┐\n │ │\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n └────────────┬────────────┘\n ▼\n WORK\n │\n HUMAN ↔ TWIN\n │\n ▼\n CAPABILITY FABRIC\n │\n ▼\n GOVERNANCE\n │\n ▼\n HERMES\n │\n ▼\n SOURCE SYSTEM\n │\n ▼\n RE-INGESTION\n │\n ▼\n VERIFY\n │\n ▼\n RECONCILIATION\n │\n ▼\n VERIFIED SPINE\n │\n ▼\n PROJECTION REFRESH\n │\n ▼\n HUMAN + AI REHYDRATE\n │\n ▼\n NEXT WORK\n │\n └──────────────►\n CONTINUITY\n```\n\n---\n\n# 26. GTM and Product Become One Flywheel\n\nThe GTM loop then becomes:\n\n```text\nDISCOVER\n ↓\nACTIVATE\n ↓\nCONNECT\n ↓\nHYDRATE\n ↓\nSEE VALUE\n ↓\nWORK\n ↓\nAPPROVE\n ↓\nOUTCOME\n ↓\nRECONCILE\n ↓\nMORE CONTEXT\n ↓\nMORE CAPABILITIES\n ↓\nMORE CONNECTORS\n ↓\nMORE WORK\n ↓\nRECURRING VALUE\n```\n\nThe canonical GTM metric is therefore:\n\n> **Time to first approved governed outcome**\n\nrather than:\n\n> number of connectors installed.\n\nThe GTM evidence model explicitly progresses from listing/install/activation to first grounded value, first approved proposal, first reconciled execution, and then expansion. \n\n---\n\n# 27. Go-Live is a separate promotion flow\n\nGTM activation should **not** be confused with production release.\n\nThe product/customer flow is:\n\n```text\nCustomer\n→ Connect\n→ Hydrate\n→ Work\n→ Outcome\n```\n\nThe engineering release flow is:\n\n```text\nDEVELOPMENT\n ↓\nCI / CONTRACT TESTS\n ↓\nDEVELOPMENT ARTIFACTS\n ↓\nCUSTOMER ZERO\n ↓\nCUSTOMER ZERO EVIDENCE\n ↓\nVERSION FREEZE\n ↓\nCLEAN EXTERNAL TENANT\n ↓\nPLUGIN / MCP SUBMISSION READY\n ↓\nPUBLIC PUBLICATION\n```\n\nThat is the frozen go-live sequence. \n\n---\n\n# 28. Five Go-Live Phases\n\n## Phase 1 — Shared Contracts\n\nFreeze:\n\n```text\nPublic tools\nResources\nUI intents\nDiscovery envelope\nTenant binding\nActivation profiles\n```\n\n## Phase 2 — Customer Zero Plugin\n\nProve:\n\n```text\nIdentity\nEmbedded UI\nHost composition\nDelegation\nProposal\nApproval\nExecution\nReconciliation\n```\n\n## Phase 3 — Customer Zero MCP + Workbench\n\nProve:\n\n```text\nOAuth\n19 tools\nBrowser launch\nOrdinary-client fallback\nDiscovery\nRBAC projections\n```\n\n## Phase 4 — Externalization\n\nInstall the **same artifacts** into a clean tenant.\n\nProve:\n\n```text\nDynamic tenant resolution\nCustomer-owned connections\nIsolation\nHydration\nWorkbench\n```\n\n## Phase 5 — Publication\n\nThen:\n\n```text\nVersion freeze\nPlugin publication\nMCP publication\nNew-tenant installation\nMonitoring\nRollback\nRevocation\nDeprecation\n```\n\nThese five phases are explicitly defined in the current go-live doctrine. \n\n---\n\n# 29. The final distinction: three flows\n\nYou now have three different flows that should appear together in the final architecture.\n\n## A. **Customer Activation Flow**\n\n```text\nMarket\n→ Identity\n→ Workspace\n→ Connector\n→ Consent\n→ Discovery\n→ Hydration\n→ Spine\n→ Projection\n→ Workbench\n```\n\n## B. **Continuity / Work Flow**\n\n```text\nSource\n→ Spine\n→ Projection\n→ Human\n→ Twin\n→ Work\n→ Capability\n→ Governance\n→ Hermes\n→ Source\n→ Reconciliation\n→ Spine\n→ Workbench\n```\n\n## C. **GTM / Go-Live Flow**\n\n```text\nDevelopment\n→ Customer Zero\n→ Evidence\n→ Version Freeze\n→ Clean Tenant\n→ Plugin/MCP Ready\n→ Publication\n→ New Customer\n→ Activation\n→ First Governed Outcome\n→ Expansion\n```\n\n---\n\n# 30. One unified final picture\n\n```text\n ┌───────────────────────────┐\n │ GO-TO-MARKET │\n │ Plugin · MCP · Direct │\n └─────────────┬─────────────┘\n │\n ▼\n ┌─────────────────────┐\n │ CUSTOMER ACTIVATION │\n │ Identity · Tenant │\n │ Workspace · Goals │\n └──────────┬──────────┘\n │\n ▼\n ┌─────────────────────┐\n │ CONNECTOR MARKETPLACE│\n └──────────┬──────────┘\n │\n ▼\n ┌─────────────────────────────┐\n │ CONNECTION + DISCOVERY │\n │ Consent · Schema · Events │\n │ Capabilities · Mapping │\n └──────────────┬──────────────┘\n │\n ▼\n ┌─────────────────────┐\n │ INGESTION PIPELINE │\n │ A · B · C · D │\n └──────────┬──────────┘\n │\n ┌──────────┴──────────┐\n ▼ ▼\n CREAMY LOAD CONTINUOUS SYNC\n │ │\n └──────────┬──────────┘\n ▼\n ┌──────────────────┐\n │ SPINE FABRIC │\n │ Truth · Evidence │\n │ Memory · Search │\n └────────┬─────────┘\n │\n ┌──────┴──────┐\n ▼ ▼\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n └──────┬──────┘\n ▼\n WORK\n │\n HUMAN ↔ TWIN\n │\n ▼\n CAPABILITY FABRIC\n │\n ▼\n GOVERNANCE\n │\n ▼\n HERMES\n │\n ▼\n SOURCE SYSTEMS\n │\n ▼\n RE-INGEST / VERIFY\n │\n ▼\n RECONCILIATION\n │\n ▼\n VERIFIED SPINE\n │\n ▼\n RE-PROJECTION\n │\n ▼\n HUMAN + AI CONTINUITY\n │\n ▼\n NEXT WORK\n │\n └──────────────►\n │\n MORE VALUE\n │\n MORE USAGE\n │\n MORE CONNECTORS\n │\n └──────► GTM EXPANSION\n```\n\n## Final product/GTM sentence\n\n> **IntegrateWise brings a customer's existing systems into one connected operational environment, turns that environment into a living Business Context Spine, projects the right work into each person's Workbench, gives the Twin and AI the same governed working context, enables approved capabilities to act across connected systems, and continuously reconciles the results back into the Spine—so every new connection and every completed piece of Work makes the workspace more useful.**\n\nThat is the complete **Connector → Ingestion → Pipeline → Spine → Projection → Human/AI Workbench → Execution → Reconciliation → GTM/Expansion → Go-Live** story, with the marketplace and release paths kept distinct.\n\n---\n\n# you asked\n\nmessage time: 2026-09-04 01:53:59\n\nEND TO END WRITEUP\n\n---\n\n# chatgpt response\n\n# SpineWorkspace — End-to-End Product, Platform, Connector, Ingestion, Memory, AI, Work, GTM and Go-Live Writeup\n\n**Canonical product:** SpineWorkspace \n**Infrastructure platform:** IntegrateWise \n**Operating doctrine:** **Humans govern. AI helps. Spine preserves continuity.**\n\nThe 31 August Founder Canon defines SpineWorkspace as the product and daily working environment, while IntegrateWise is the infrastructure underneath it. The product has a primary **Human Workbench**, a first-class **AI Workbench**, shared Business Context, separate human and AI continuity, durable Work, governed capabilities, and a closed execution/reconciliation loop. \n\n---\n\n# 1. What SpineWorkspace Is\n\nSpineWorkspace is a **self-organizing shared workspace where humans and AI work from the same governed business context**.\n\nIt brings together:\n\n- the organization's connected systems;\n- structured business data;\n- communications;\n- documents and media;\n- knowledge;\n- evidence;\n- organizational memory;\n- personal contextual memory;\n- AI continuity;\n- Work;\n- capabilities;\n- approvals;\n- Twin interactions;\n- Spine Agents;\n- execution;\n- verification;\n- reconciliation.\n\nThe user does not move between applications to reconstruct the business context.\n\nInstead:\n\n```text\n SPINEWORKSPACE\n │\n ┌───────────┴───────────┐\n │ │\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n │ │\n └───────────┬───────────┘\n │\n SHARED BUSINESS\n CONTEXT SPINE\n │\n ┌─────────────┼─────────────┐\n │ │ │\n Connected Memory Evidence\n Systems Knowledge & Search\n │ │ │\n └─────────────┼─────────────┘\n │\n WORK\n │\n HUMAN ↔ TWIN\n │\n CAPABILITY FABRIC\n │\n GOVERNANCE\n │\n HERMES\n │\n SOURCE SYSTEM\n │\n VERIFY / RECONCILE\n │\n ▼\n SPINE REHYDRATES\n```\n\nThe result is not another dashboard or another AI chatbot.\n\nIt is the **operating environment for human and AI work**. \n\n---\n\n# 2. The Three-Level Product Architecture\n\nThe system has three distinct levels.\n\n| Level | Meaning |\n|---|---|\n| **SpineWorkspace** | Product and daily working experience |\n| **Spine Context & Continuity System** | Shared Business Context Spine + Personal Contextual Memory + AI Continuity Memory |\n| **IntegrateWise Platform** | Connectivity, ingestion, intelligence, projection, capability, governance, execution and continuity infrastructure |\n\nThe Founder Canon explicitly establishes this separation. \n\nSo:\n\n```text\nSPINEWORKSPACE\n ↓\nthe customer experience\n\nSPINE CONTEXT & CONTINUITY\n ↓\nthe shared context and continuity substrate\n\nINTEGRATEWISE\n ↓\nthe infrastructure that makes it work\n```\n\n---\n\n# 3. The Customer Starts With a Blank Organization\n\nA new customer does not manually build a database.\n\nThe lifecycle begins with:\n\n```text\nIdentity\n ↓\nOrganization\n ↓\nRole / Responsibility\n ↓\nGoals / Operating Context\n ↓\nConnect Reality\n ↓\nDiscovery\n ↓\nConfiguration\n ↓\nActivation\n ↓\nInitial Hydration\n ↓\nBusiness Context Spine\n ↓\nPersonal Contextual Memory\n ↓\nAI Continuity\n ↓\nCapability Activation\n ↓\nProjection\n ↓\nSpineWorkspace\n```\n\nThe onboarding doctrine specifically defines this transition from **blank state to useful work**. The first useful workspace should already contain real context from connected systems, relevant Work, readiness information and a functioning Twin rather than an empty shell. \n\n---\n\n# 4. GTM: How the Customer Enters\n\nGTM begins outside the workspace.\n\nThere are multiple distribution surfaces, but they have different roles.\n\n## External acquisition\n\n### Plugin Marketplace\n\nBrings IntegrateWise into a compatible host through the **IW-Spine-Network Plugin**.\n\n### MCP Marketplace\n\nMakes the **IW-Spine-Network MCP** available to MCP clients.\n\n### Direct Workbench\n\nCustomer enters directly through the SpineWorkspace experience.\n\n## Internal expansion\n\n### Connector Marketplace\n\nThis exists **inside the product**.\n\nIt expands the customer's connected ecosystem after the workspace exists.\n\nTherefore:\n\n```text\nPlugin Marketplace ──┐\nMCP Marketplace ─────┼──► CUSTOMER ENTRY\nDirect Workbench ────┘\n │\n ▼\n SPINEWORKSPACE\n │\n ▼\n CONNECTOR MARKETPLACE\n │\n ▼\n MORE BUSINESS CONTEXT\n```\n\nThe locked GTM model distinguishes external distribution from in-product connector activation. \n\n---\n\n# 5. GTM Wedge → General Platform\n\nThe product itself is horizontal.\n\nA GTM wedge can target a specific function without turning the architecture into a function-specific application.\n\nFor example:\n\n```text\nPRODUCT\nSpineWorkspace\n\n ↓\n\nGTM WEDGE\nCustomer Success\n\n ↓\n\nBUYER\nHead / VP Customer Success\n\n ↓\n\nFIRST USE\nAccount Success Workbench\n\n ↓\n\nEXPANSION\nSales\nMarketing\nFinance\nOperations\nEngineering\nSupport\nFounder\n```\n\nThe important architectural rule is:\n\n> **Role specificity is runtime composition, not marketplace packaging.**\n\nThe same SpineWorkspace can compose different work environments based on role, responsibility, department, industry, connected systems and active Work.\n\n---\n\n# 6. One Connection Opens the Door\n\nThe customer connects a system.\n\nFor example:\n\n```text\nSalesforce\n```\n\nThe system does not merely create a Salesforce page.\n\nIt establishes a tenant-scoped connection into the IntegrateWise operating environment.\n\n```text\nCONNECTOR\n ↓\nConsent\n ↓\nIdentity / Tenant Binding\n ↓\nDiscovery\n ↓\nSchema / Capability Resolution\n ↓\nMapping\n ↓\nActivation\n ↓\nIngestion\n ↓\nSpine\n```\n\nThe connector becomes a doorway into the broader continuity system.\n\n---\n\n# 7. Connector Lifecycle\n\nThe complete connector lifecycle is:\n\n```text\nDiscover\n ↓\nSelect\n ↓\nConnect\n ↓\nAuthenticate\n ↓\nConsent\n ↓\nBind to Tenant / Workspace\n ↓\nDiscover Provider Schema\n ↓\nClassify Domain\n ↓\nResolve Canonical Model\n ↓\nMap Fields\n ↓\nActivate Capabilities\n ↓\nActivate Ingestion\n ↓\nInitial Hydration\n ↓\nHealth Check\n ↓\nContinuous Sync\n```\n\nThe **Integration Manager** owns connection lifecycle, OAuth, mappings, webhooks, discovery and sync policy. The **Activation Manager** manages tenant activation, while the **Activation Bridge** compiles the effective runtime configuration from identity, context, connections, policy and capabilities. \n\n---\n\n# 8. Discovery Is Not Ingestion\n\nThe connector first discovers what exists.\n\n```text\nProvider\n ↓\nObjects\nFields\nTypes\nRelationships\nEvents\nWebhooks\nOperations\nTools\nResources\nCapabilities\nLimits\n ↓\nDiscovery Result\n```\n\nDiscovery answers:\n\n> **What does this connected system provide?**\n\nIngestion answers:\n\n> **What business information should enter the Spine, and how should it become canonical context?**\n\nThis separation prevents provider-specific structures from becoming the product's underlying model.\n\n---\n\n# 9. Provider → Canonical Spine Mapping\n\nThe system is provider-neutral.\n\nFor example:\n\n```text\nSalesforce Account\n ↓\n Canonical Account\n\nHubSpot Company\n ↓\n Canonical Account\n```\n\nSimilarly:\n\n```text\nZendesk Ticket\n ↓\nSupport Work / Ticket\n\nGoogle Calendar Event\n ↓\nMeeting / Event\n\nSlack Message\n ↓\nCommunication\n\nGitHub Issue\n ↓\nWork / Engineering Context\n```\n\nThe provider is the source.\n\nThe Spine is the normalized organizational representation.\n\nThis is the **Normalize Once. Render Anywhere.** principle.\n\n---\n\n# 10. Connector Activation Changes Context\n\nConnecting a provider can activate more than data.\n\nIt can activate:\n\n- canonical entities;\n- fields;\n- relationships;\n- document types;\n- signal types;\n- health calculations;\n- capabilities;\n- projection fields;\n- Twin context;\n- search/indexing;\n- workflows;\n- operational views.\n\nTherefore:\n\n```text\nCONNECTOR\n ↓\nDOMAIN EXTENSION\n ↓\nCANONICAL MODEL\n ↓\nCAPABILITIES\n ↓\nSIGNALS\n ↓\nCONTEXT\n ↓\nPROJECTIONS\n```\n\nThe connector becomes part of the organization's operating context.\n\n---\n\n# 11. The Four Platform Flows\n\nThe architecture uses four major flows.\n\n## Flow A — Structured operational data\n\n```text\nProvider\n ↓\nConnector Runtime\n ↓\nLoader\n ↓\nNormalizer\n ↓\nValidation\n ↓\nCanonical Spine Writer\n ↓\nBusiness Context Spine\n```\n\nUsed for:\n\n- CRM;\n- ERP;\n- billing;\n- support;\n- project systems;\n- operational records;\n- structured provider objects.\n\n## Flow B — Documents and communications\n\n```text\nSource\n ↓\nIngest\n ↓\nParse\n ↓\nClassify\n ↓\nExtract\n ↓\nEnrich\n ↓\nRoute\n ↓\nGovern\n ↓\nPromote\n```\n\nThe canonical document pipeline is explicitly **Ingest → Parse → Classify → Extract → Enrich → Route → Govern → Promote**. \n\n## Flow C — AI / cognitive continuity\n\n```text\nHuman / Twin / Agent\n ↓\nObservation\n ↓\nInterpretation\n ↓\nEvidence\n ↓\nProposal / Work\n ↓\nTriage / Governance\n ↓\nMemory or governed write\n```\n\n## Flow D — platform activation/control\n\n```text\nIdentity\nConsent\nTenant\nConfiguration\nConnector\nDiscovery\nMapping\nCapabilities\nHealth\nSync\nPolicy\n```\n\nFlow D establishes and controls the runtime; it does not replace the business-data flows. \n\n---\n\n# 12. Initial Hydration\n\nThe first connection must produce useful context.\n\n```text\nCONNECTION READY\n ↓\nCREAMY INITIAL HYDRATION\n ↓\nCORE ENTITIES\n ↓\nRELATIONSHIPS\n ↓\nDOCUMENTS / COMMUNICATIONS\n ↓\nINDEXING\n ↓\nPROJECTIONS\n ↓\nWORKSPACE READY\n```\n\nThe purpose of the initial \"creamy\" layer is to make the workspace useful quickly rather than waiting for the entire provider ecosystem to be synchronized.\n\nThen:\n\n```text\nCreamy\n ↓\nBreadth\n ↓\nFull Continuous Hydration\n```\n\nThe canonical onboarding model explicitly calls for initial hydration followed by broader continuity. \n\n---\n\n# 13. Continuous Ingestion\n\nAfter the initial load, the Spine becomes continuously hydrated.\n\n```text\nWebhook\nPoll\nDelta\nCursor\nScheduled Sync\nBatch\nStream\n ↓\nConnector Runtime\n ↓\nLoader\n ↓\nNormalizer\n ↓\nCanonical Writer\n ↓\nSpine\n```\n\nThe Spine therefore does not become stale simply because the customer originally connected a provider.\n\n---\n\n# 14. The Spine Is the Shared Business Context\n\nThe Business Context Spine contains the organization's operational continuity.\n\nIt can include:\n\n- mission;\n- objectives;\n- goals;\n- KPIs;\n- teams;\n- people;\n- roles;\n- customers;\n- accounts;\n- vendors;\n- products;\n- projects;\n- assets;\n- Work;\n- tasks;\n- commitments;\n- lifecycle states;\n- dependencies;\n- events;\n- signals;\n- communications;\n- documents;\n- decisions;\n- approvals;\n- policies;\n- capabilities;\n- execution state;\n- evidence;\n- provenance;\n- organizational memory.\n\nThe canonical definition is:\n\n> **Business Context Memory belongs to the organization.**\n\nIt is the shared, governed continuity substrate available to authorized humans, Twin and agents. \n\n---\n\n# 15. Storage Is Layered\n\nThe logical Spine should not be confused with one physical database.\n\nThe system separates:\n\n```text\nSTRUCTURED TRUTH\n ↓\nStructured storage\n\nHOT / OPERATIONAL STATE\n ↓\nCache / state\n\nDOCUMENTS / MEDIA\n ↓\nObject storage\n\nCONVERSATIONS\n ↓\nConversation storage\n\nSEMANTIC RETRIEVAL\n ↓\nVector / search storage\n\nCONTINUITY\n ↓\nPersonal / AI / organizational memory systems\n```\n\nThe Founder Canon deliberately treats physical storage as an implementation detail beneath the logical Spine contract. \n\n---\n\n# 16. Media and Documents\n\nA document can have multiple representations.\n\nFor example:\n\n```text\ncustomer-qbr.pdf\n```\n\nmay exist as:\n\n```text\nOriginal artifact\n ↓\nObject storage\n\nMetadata\n ↓\nStructured Spine record\n\nParsed text\n ↓\nDocument chunks\n\nEmbeddings\n ↓\nVector search\n\nSource relationship\n ↓\nEvidence / source link\n\nExtracted information\n ↓\nCanonical entities / Work / signals\n```\n\nThese are not independent copies of business truth.\n\nThey serve different purposes.\n\n---\n\n# 17. Conversation Storage\n\nA meeting or email thread may contain information that has not yet become structured organizational truth.\n\nFor example:\n\n```text\nMeeting transcript\n ↓\nConversation storage\n ↓\nParsing\n ↓\nEntity extraction\n ↓\nCommitment extraction\n ↓\nSignal\n ↓\nEvidence\n ↓\nPossible Work\n ↓\nPossible memory promotion\n```\n\nThe original conversation remains available as evidence.\n\n---\n\n# 18. Semantic Retrieval\n\nSemantic search is not the source of truth.\n\nIt is a retrieval mechanism.\n\n```text\nUser / Twin Question\n ↓\nSemantic Query\n ↓\nVector / Search Index\n ↓\nRelevant Chunks\n ↓\nSource Links\n ↓\nOriginal Documents / Conversations\n ↓\nEvidence\n ↓\nContext\n```\n\nThis lets the Twin answer:\n\n> \"Why is this account considered at risk?\"\n\nusing retrieved evidence rather than an unsupported model inference.\n\n---\n\n# 19. Evidence and Provenance\n\nThe system maintains the relationship:\n\n```text\nSOURCE\n ↓\nSOURCE LINK\n ↓\nCHUNK / RECORD\n ↓\nRETRIEVAL\n ↓\nEVIDENCE\n ↓\nAI OUTPUT\n ↓\nWORK / PROPOSAL\n```\n\nThis is critical for enterprise trust.\n\nThe user should be able to move from an AI conclusion back toward the underlying evidence.\n\n---\n\n# 20. Three Memory Domains\n\nThe system has three different continuity scopes.\n\n## Organizational Memory\n\n```text\nOrganization\n ↓\nBusiness Context Spine\n ↓\nOrganizational Memory\n```\n\nShared, governed and available to authorized participants.\n\n## Personal Contextual Memory\n\n```text\nHuman\n ↓\nPersonal Contextual Memory\n```\n\nContains:\n\n- personal notes;\n- reminders;\n- priorities;\n- drafts;\n- bookmarks;\n- private working knowledge;\n- unfinished thoughts;\n- personal preferences;\n- personal work continuity.\n\nIt is private by default. \n\n## AI Continuity Memory\n\n```text\nTwin / Spine Agent\n ↓\nAI Continuity Memory\n```\n\nContains things such as:\n\n- prior assignment state;\n- working summaries;\n- unresolved questions;\n- current plans;\n- active hypotheses;\n- handoff context;\n- prior observations;\n- pending verification;\n- model-independent continuity.\n\nIt is **not organizational truth**. \n\n---\n\n# 21. Memory Promotion\n\nThe critical boundary is:\n\n```text\nAI Observation\n ↓\nTriage\n ↓\nGovernance\n ↓\nGoverned Writer\n ↓\nOrganizational Memory\n```\n\nTherefore:\n\n```text\nAI thought\n ≠\ncompany fact\n```\n\nand:\n\n```text\nPersonal note\n ≠\norganizational memory\n```\n\nuntil the appropriate governed transition occurs.\n\nThe Founder Canon explicitly requires that private personal memory and AI continuity do not silently become organizational truth. \n\n---\n\n# 22. Projection Is the Bridge to the UI\n\nThe frontend does not independently construct business truth.\n\nInstead:\n\n```text\nSPINE\n ↓\nPROJECTION ENGINE\n ↓\nAUTHORIZED PROJECTION\n ↓\nWORKBENCH CONTRACT\n ↓\nUI\n```\n\nThe Projection Engine is the sole composer of authorized, versioned Workbench/context contracts. \n\n---\n\n# 23. Every Projection Maps Back to Data\n\nA projection can contain many underlying sources.\n\nFor example:\n\n```text\nCUSTOMER SUCCESS ACCOUNT VIEW\n```\n\nmay combine:\n\n```text\nAccount\nContacts\nHealth\nOpen Work\nRenewal\nMeetings\nEmails\nSupport\nUsage\nDocuments\nSignals\nCommitments\nKnowledge\nEvidence\n```\n\nIt is therefore incorrect to think:\n\n```text\nAccount View = account_table\n```\n\nThe correct model is:\n\n```text\nAccount View\n ↓\nProjection\n ↓\nmultiple canonical entities\n ↓\nmultiple storage/retrieval layers\n ↓\none authorized UI contract\n```\n\n---\n\n# 24. Human Workbench\n\nThe Human Workbench is the primary daily product surface.\n\nIt can contain:\n\n```text\nHome\nMy Work\nInbox\nTasks\nQueue\nApprovals\nNotifications\nCommunications\nEmail\nCalendar\nMeetings\nChat\nCalls\nShared Documents\nPersonal\nNotes\nKnowledge\nBrainstorming\nWork\nDomain-specific projections\n```\n\nThe exact content adapts according to:\n\n```text\nRole\n+\nResponsibility\n+\nDepartment\n+\nIndustry\n+\nGoals\n+\nConnected Systems\n+\nCurrent Work\n+\nPermissions\n+\nCapabilities\n+\nPersonal Context\n```\n\nThe architecture explicitly defines this as a **self-organizing Workbench**, not a manually constructed collection of applications. \n\n---\n\n# 25. AI Workbench\n\nThe AI Workbench is the AI-side operating environment.\n\nIt assembles:\n\n```text\nAuthorized Business Context\n+\nAI Continuity Memory\n+\nCurrent Objective\n+\nCurrent Work\n+\nEvidence\n+\nAuthority\n+\nCapabilities\n+\nAgent Runtime State\n```\n\nThen:\n\n```text\nAI Workbench\n ↓\nTwin / Spine Agent\n```\n\nThe Twin is therefore **inside** the AI Workbench.\n\nThe Twin is not the whole AI Workbench.\n\n---\n\n# 26. Human + AI Work on the Same Work\n\nThe fundamental coordination unit is **Work**.\n\n```text\nHuman\n ↓\nWork\n ↓\nTwin\n ↓\nSpine Agent\n ↓\nCapability\n ↓\nExecution\n```\n\nEvery participant uses the same Work identity and authorized context.\n\nThe operating invariant is:\n\n> **No participating worker begins meaningful work without a Spine-derived authorized context and Work identity.** \n\nThis is what prevents human-to-AI handoff from becoming:\n\n```text\n\"Here is the whole story again...\"\n```\n\n---\n\n# 27. Twin Interaction\n\nThe user can ask:\n\n```text\nWhat needs my attention?\n\nPrepare me for my next meeting.\n\nWhat changed?\n\nWhat commitments are still open?\n\nWhat am I missing?\n\nPrepare the next step.\n\nShow me work ready for review.\n\nWhat needs my approval?\n```\n\nThe Twin resolves context from:\n\n```text\nBusiness Context\n+\nPersonal Context\n+\nWork\n+\nEvidence\n+\nAI Continuity\n+\nCapabilities\n+\nAuthority\n```\n\nThen it can:\n\n```text\nObserve\n ↓\nOrient\n ↓\nPrepare\n ↓\nPropose\n ↓\nRequest Approval\n```\n\nOODA remains an internal operating grammar rather than requiring the user interface to expose four literal controls everywhere. \n\n---\n\n# 28. Spine Agents\n\nA Spine Agent is a governed AI worker.\n\nIt operates with:\n\n```text\nIdentity\n+\nWork\n+\nContext\n+\nAuthority\n+\nCapabilities\n+\nEvidence\n+\nContinuity\n```\n\nIt can take a bounded subtask from the human/Twin.\n\n```text\nHuman\n ↓\nWork\n ↓\nTwin\n ↓\nSpine Agent\n ↓\nSubtask\n ↓\nResult\n ↓\nWork updated\n```\n\nThe handoff remains durable.\n\n---\n\n# 29. Capability Fabric\n\nThe Workbench/Twin determines:\n\n> **What needs to happen?**\n\nThe Capability Fabric determines:\n\n> **How can it happen?**\n\nThe capability may resolve to:\n\n```text\nREST\nMCP\nAPI\nTool\nAgent → Agent\nWorkflow\nLocal execution\nAI execution\n```\n\nThe provider is therefore replaceable.\n\nThe durable product contract is the capability, not the provider-specific implementation.\n\n---\n\n# 30. Governance\n\nBefore consequential execution:\n\n```text\nIntent\n ↓\nCapability\n ↓\nAuthority Check\n ↓\nGovernance\n```\n\nGovernance can:\n\n```text\nALLOW\nDENY\nREQUIRE APPROVAL\nBOUND DELEGATION\n```\n\nThe AI does not own authority.\n\nThe human/policy boundary does.\n\nThis is part of the Founder Canon's explicit authority model. \n\n---\n\n# 31. Hermes\n\nOnce an action is authorized:\n\n```text\nApproved Plan\n ↓\nHermes\n ↓\nExecution Route\n ↓\nProvider\n```\n\nHermes coordinates the approved execution lifecycle.\n\nThe system therefore separates:\n\n```text\nCognition\n ↓\nCapability\n ↓\nAuthority\n ↓\nExecution\n```\n\nrather than creating one monolithic \"AI orchestrator.\" \n\n---\n\n# 32. Execution Does Not Immediately Become Truth\n\nSuppose the Twin updates a CRM opportunity.\n\nThe flow is:\n\n```text\nTwin\n ↓\nProposal\n ↓\nHuman Approval\n ↓\nGovernance\n ↓\nHermes\n ↓\nCRM\n ↓\nProvider Outcome\n```\n\nAt this point:\n\n```text\nProvider said \"success\"\n```\n\ndoes **not** yet mean:\n\n```text\nBusiness truth changed\n```\n\nThe system must verify.\n\n---\n\n# 33. Re-ingestion and Reconciliation\n\nThe provider result comes back through the system:\n\n```text\nProvider Outcome\n ↓\nRe-ingestion\n ↓\nNormalization\n ↓\nVerification\n ↓\nExpected vs Actual\n ↓\nReconciliation\n ↓\nGoverned Spine Update\n ↓\nProjection Refresh\n```\n\nThe canonical completion condition is therefore:\n\n> **Outcome → Re-ingestion → Verification → Reconciliation → Spine update → Rehydration.**\n\nThe Founder Canon explicitly defines completion this way. \n\n---\n\n# 34. The Workspace Then Rehydrates\n\nOnce the Spine is updated:\n\n```text\nVerified Spine\n ↓\nProjection Engine\n ↓\nHuman Workbench\n +\nAI Workbench\n ↓\nUpdated Work\n ↓\nNext action\n```\n\nSo the loop is:\n\n```text\nWORK\n ↓\nAI / HUMAN\n ↓\nACTION\n ↓\nSOURCE SYSTEM\n ↓\nOUTCOME\n ↓\nRECONCILIATION\n ↓\nSPINE\n ↓\nMEMORY / EVIDENCE\n ↓\nPROJECTION\n ↓\nWORKBENCH\n ↓\nNEXT WORK\n```\n\nThat is the actual continuity loop.\n\n---\n\n# 35. Full Customer Operating Loop\n\nThe complete product lifecycle is:\n\n```text\nCUSTOMER\n │\n ▼\nIDENTITY\n │\n ▼\nTENANT / WORKSPACE\n │\n ▼\nGOALS / RESPONSIBILITY\n │\n ▼\nCONNECTORS\n │\n ▼\nDISCOVERY\n │\n ▼\nMAPPING / ACTIVATION\n │\n ▼\nINGESTION\n │\n ▼\nHYDRATION\n │\n ▼\nBUSINESS CONTEXT SPINE\n │\n ├───────────────┐\n │ │\n ▼ ▼\nMEMORY EVIDENCE\n │ │\n └───────┬───────┘\n ▼\n PROJECTION ENGINE\n │\n ┌────┴────┐\n ▼ ▼\n HUMAN WB AI WB\n │ │\n └────┬────┘\n ▼\n WORK\n │\n HUMAN ↔ TWIN\n │\n ▼\n CAPABILITY\n │\n ▼\n GOVERNANCE\n │\n ▼\n HERMES\n │\n ▼\n SOURCE SYSTEM\n │\n ▼\n OUTCOME\n │\n ▼\n RE-INGESTION\n │\n ▼\n VERIFICATION\n │\n ▼\n RECONCILIATION\n │\n ▼\n SPINE\n │\n ▼\n REHYDRATE\n │\n ▼\n NEXT WORK\n │\n └──────────► CONTINUITY\n```\n\n---\n\n# 36. GTM Becomes a Product Flywheel\n\nThe customer acquisition funnel connects directly to the operational loop:\n\n```text\nMARKET DEMAND\n ↓\nPLUGIN / MCP / DIRECT ENTRY\n ↓\nIDENTITY\n ↓\nWORKSPACE\n ↓\nCONNECTOR\n ↓\nHYDRATION\n ↓\nFIRST GROUNDED VALUE\n ↓\nFIRST APPROVED GOVERNED OUTCOME\n ↓\nRECONCILED EXECUTION\n ↓\nRECURRING WORK\n ↓\nMORE CONNECTORS\n ↓\nMORE CONTEXT\n ↓\nMORE CAPABILITIES\n ↓\nMORE VALUE\n ↓\nEXPANSION\n```\n\nThe canonical GTM metric is therefore:\n\n> **Time to first approved governed outcome**\n\nrather than simply:\n\n> installations.\n\nThe locked GTM model explicitly treats install as a diagnostic and grounded value, approval and reconciliation as the meaningful product progression. \n\n---\n\n# 37. Connector Expansion Is the Expansion Engine\n\nAfter the customer experiences value:\n\n```text\nOne connector\n ↓\nMore connectors\n ↓\nMore context\n ↓\nMore cross-system relationships\n ↓\nBetter projections\n ↓\nBetter Twin context\n ↓\nMore capabilities\n ↓\nMore Work\n```\n\nFor example:\n\n```text\nCRM\n +\nSupport\n +\nCalendar\n +\nCommunication\n +\nBilling\n +\nProduct Usage\n```\n\ncreates a much richer customer operating context than any one provider could supply.\n\nThe product becomes more useful as the organization's connected context becomes richer.\n\n---\n\n# 38. The Same System Serves Every Role\n\nThe underlying Spine remains shared.\n\nOnly the projection changes.\n\n```text\n BUSINESS CONTEXT SPINE\n │\n ┌───────────────────┼───────────────────┐\n │ │ │\n SALES CS FINANCE\n │ │ │\n Sales View CS View Finance View\n │ │ │\n └───────────────────┼───────────────────┘\n │\n SAME SPINE\n```\n\nSimilarly:\n\n```text\nFounder\nSales\nCustomer Success\nSupport\nMarketing\nFinance\nOperations\nEngineering\nProduct\n```\n\ndo not require separate products or separate canonical databases.\n\nThe projection adapts to the worker.\n\n---\n\n# 39. Customer Zero\n\nCustomer Zero is not a demo environment.\n\nIntegrateWise itself becomes the first real operating tenant.\n\nThe Customer Zero workspace should exercise:\n\n- product work;\n- architecture;\n- code;\n- decisions;\n- tasks;\n- GTM;\n- documents;\n- connectors;\n- incidents;\n- releases;\n- AI work;\n- approvals;\n- outcomes;\n- reconciliation;\n- organizational continuity.\n\nThe purpose is to prove that the same system intended for customers can operate the company itself.\n\n---\n\n# 40. Go-Live Is a Separate Promotion Train\n\nGTM gets the customer into the product.\n\nGo-live determines whether the product itself is ready for external production.\n\nThe canonical sequence is:\n\n```text\nSOURCE COMMIT\n ↓\nCI / CONTRACT TESTS\n ↓\nDEVELOPMENT ARTIFACTS\n ↓\nCUSTOMER ZERO PRIVATE INSTALLATION\n ↓\nCUSTOMER ZERO EVIDENCE\n ↓\nVERSION FREEZE\n ↓\nEXTERNAL CLEAN-TENANT TEST\n ↓\nPLUGIN / MCP SUBMISSION-READY\n ↓\nPUBLIC PUBLICATION\n```\n\nThis is a one-way promotion process. \n\n---\n\n# 41. Go-Live Phase 1 — Shared Contracts\n\nFreeze:\n\n```text\nPublic tools\nResources\nUI intents\nDiscovery envelope\nTenant binding\nActivation profiles\n```\n\nThe external surface must have a known, stable contract.\n\n---\n\n# 42. Go-Live Phase 2 — Customer Zero Plugin\n\nProve:\n\n```text\nIdentity\n+\nEmbedded UI\n+\nHost composition\n+\nDelegation\n+\nProposal\n+\nApproval\n+\nExecution\n+\nReconciliation\n```\n\nThe important test is not whether the plugin installs.\n\nIt is whether the full continuity loop works.\n\n---\n\n# 43. Go-Live Phase 3 — Customer Zero MCP + Workbench\n\nProve:\n\n```text\nOAuth\n+\n19 public tools\n+\nBrowser launch\n+\nOrdinary-client fallback\n+\nDiscovery-first composition\n+\nRBAC projections\n```\n\nThe MCP surface remains an access/distribution boundary into IntegrateWise rather than becoming the core business-data plane. \n\n---\n\n# 44. Go-Live Phase 4 — Externalization\n\nInstall the **same artifacts** into a clean tenant.\n\nProve:\n\n```text\nDynamic tenant resolution\n+\nCustomer-owned connections\n+\nIsolation\n+\nHydration\n+\nProjection\n+\nContinuity\n```\n\nNo customer should require a special architecture.\n\n---\n\n# 45. Go-Live Phase 5 — Publication\n\nThen:\n\n```text\nVersion Freeze\n ↓\nPlugin Publication\n ↓\nMCP Publication\n ↓\nNew Tenant Installation\n ↓\nMonitoring\n ↓\nRollback / Revocation / Deprecation\n```\n\nProduction is not considered complete merely because the public listing exists.\n\nThe release gates require real connector hydration, projection, governed execution, reconciliation, audit, isolation, rollback and operational evidence. \n\n---\n\n# 46. The Complete Architecture in One View\n\n```text\n MARKET\n │\n ┌───────────────┼────────────────┐\n │ │ │\n PLUGIN MCP DIRECT\n MARKETPLACE MARKETPLACE WORKBENCH\n │ │ │\n └───────────────┼────────────────┘\n ▼\n SPINEWORKSPACE\n │\n IDENTITY / TENANT / ROLE\n │\n ▼\n WORKSPACE READY\n │\n ▼\n CONNECTOR MARKETPLACE\n │\n ▼\n CONNECT / CONSENT\n │\n ▼\n DISCOVERY\n │\n ▼\n CONFIGURATION / MAPPING\n │\n ▼\n ACTIVATION\n │\n ┌─────────────┼─────────────┐\n │ │ │\n FLOW A FLOW B FLOW C\n STRUCTURED DOCUMENTS AI /\n OPERATIONS COMMUNICATIONS COGNITIVE\n │ │ │\n └─────────────┼─────────────┘\n │\n FLOW D\n CONTROL PLANE\n │\n ▼\n INGESTION PIPELINE\n │\n ┌─────────────┴─────────────┐\n ▼ ▼\n INITIAL LOAD CONTINUOUS SYNC\n │ │\n └─────────────┬─────────────┘\n ▼\n BUSINESS CONTEXT SPINE\n │\n ┌──────────────────┼──────────────────┐\n │ │ │\n ▼ ▼ ▼\n ORGANIZATIONAL PERSONAL AI\n MEMORY CONTEXTUAL CONTINUITY\n MEMORY\n │ │ │\n └──────────────────┼──────────────────┘\n │\n KNOWLEDGE / EVIDENCE\n │\n SEARCH / RETRIEVAL\n │\n ▼\n PROJECTION ENGINE\n │\n ┌──────────────┴──────────────┐\n ▼ ▼\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n │ TWIN\n │ SPINE AGENTS\n └──────────────┬──────────────┘\n ▼\n WORK\n │\n CAPABILITY FABRIC\n │\n GOVERNANCE\n │\n HERMES\n │\n ┌─────────────┼─────────────┐\n ▼ ▼ ▼\n API MCP AGENT\n │ │ │\n └─────────────┼─────────────┘\n ▼\n SOURCE SYSTEMS\n │\n OUTCOME\n │\n RE-INGESTION\n │\n VERIFY\n │\n RECONCILIATION\n │\n ▼\n VERIFIED BUSINESS CONTEXT\n │\n MEMORY / EVIDENCE\n │\n NEW PROJECTIONS\n │\n ┌──────────────┴──────────────┐\n ▼ ▼\n HUMAN REHYDRATES AI REHYDRATES\n │ │\n └──────────────┬──────────────┘\n ▼\n NEXT WORK\n │\n ▼\n CONTINUITY\n │\n ▼\n EXPANSION\n │\n ▼\n MORE CONNECTORS\n```\n\n---\n\n# 47. What the Frontend Actually Is\n\nThe frontend is not:\n\n```text\nReact\n ↓\nDatabase\n```\n\nIt is:\n\n```text\nUser\n ↓\nSpineWorkspace\n ↓\nProjection Contract\n ↓\nProjection API\n ↓\nAuthorized Spine Context\n ↓\nUI Composition\n```\n\nThe frontend therefore renders:\n\n- tables;\n- views;\n- pages;\n- boards;\n- queues;\n- timelines;\n- calendars;\n- canvases;\n- entity views;\n- communication surfaces;\n- approvals;\n- Twin interactions.\n\nBut all are manifestations of the same underlying context.\n\n---\n\n# 48. What the Backend Actually Is\n\nThe backend is not one monolithic AI server.\n\nIt is a set of platform authorities:\n\n```text\nOne Auth\nConfiguration\nIntegration Manager\nDiscovery\nActivation Bridge\nGateway\nLoader\nFlow A/B/C/D\nNormalizer\nTriage\nGoverned Writers\nSpine\nKnowledge\nMemory\nEvidence\nSearch\nProjection\nIntelligence\nModel Routing\nADK\nAgent Runtime\nCapability Fabric\nGovernance\nHermes\nSync\nVerification\nReconciliation\nAudit\nObservability\n```\n\nThe Founder Canon retains these platform capabilities while changing their relationship to the product: they are underneath SpineWorkspace, rather than competing with the primary user experience. \n\n---\n\n# 49. The Architectural Ownership Rule\n\nThe entire system can be reduced to:\n\n```text\nPRODUCT\nSpineWorkspace\n │\n ▼\nEXPERIENCE\nHuman Workbench + AI Workbench\n │\n ▼\nCONTEXT\nBusiness Context Spine\n │\n ├── Organizational Memory\n ├── Personal Contextual Memory\n └── AI Continuity Memory\n │\n ▼\nPROJECTION\nProjection Engine\n │\n ▼\nWORK\nHuman ↔ Twin ↔ Spine Agents\n │\n ▼\nCAPABILITY\nCapability Fabric\n │\n ▼\nAUTHORITY\nGovernance\n │\n ▼\nEXECUTION\nHermes\n │\n ▼\nREALITY\nConnected Source Systems\n │\n ▼\nCLOSURE\nRe-ingestion → Verification → Reconciliation\n │\n ▼\nCONTINUITY\nSpine → Memory → Projection → Next Work\n```\n\n---\n\n# 50. Final Product Doctrine\n\n### For the customer\n\n> **One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.**\n\n### For the architecture\n\n> **Shared business reality; separate participant continuity; governed promotion between scopes.**\n\n### For the execution model\n\n> **Intent → Capability → Governance → Hermes → Provider → Outcome → Re-ingestion → Verification → Reconciliation.**\n\n### For the product experience\n\n> **The human works in SpineWorkspace; the Twin works with the human; both operate from the same governed business context.**\n\n### For GTM\n\n> **Market → Entry → Workspace → Connect → Hydrate → First grounded value → First approved governed outcome → Recurring use → Expansion.**\n\n### For go-live\n\n> **Development → Customer Zero → Evidence → Version Freeze → Clean Tenant → Submission → Publication.**\n\n### Final definition\n\n> **SpineWorkspace is the shared operating environment where humans and AI work toward the same business goals through different workbenches, using the same governed Business Context Spine while maintaining separate personal and AI continuity. IntegrateWise is the infrastructure platform underneath that connects the organization's systems, hydrates and preserves its business context, assembles authorized projections and AI context, coordinates capabilities and governed execution, and closes every action through verification, reconciliation and continuous rehydration.**\n\nThe complete doctrine remains:\n\n> **Humans govern. AI helps. Spine preserves continuity.**\n\n---\n\n# you asked\n\nmessage time: 2026-09-04 01:56:11\n\nSTART WITH MAREKTING, \nSPINE WORKSPACE - COMPONENTS IN PLATFORM, WORKSPACE - HOW IT COMMUNICATES \nDOMAIN WORKBENCHES \nAI WORKBENCH \nSIDE BAR STRUCTURE \nFRONTEND AND BACKEND TABLES AND VIEWS \nPROJECTION REGISTRY \nWIRING \nGO LIVE\n\n---\n\n# chatgpt response\n\n# SpineWorkspace — End-to-End Canonical Product Writeup\n\n## 1. Marketing — The Product Starts Here\n\n### **SpineWorkspace**\n\n> **One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.**\n\nBusinesses do not work in one application.\n\nCustomer information lives in CRM. \nWork lives in project systems. \nCommunication lives in email and chat. \nDocuments live in drives. \nFinance lives elsewhere. \nOperational knowledge lives in people's heads. \nAnd increasingly, AI and agents operate across all of it.\n\nSpineWorkspace brings that distributed business reality into **one self-organizing workspace**.\n\nIt connects the organization's systems, builds a governed **Business Context Spine**, and projects the right context into the right workbench for each person and for AI.\n\nHumans and AI therefore work on the **same business Work**, from different operating environments, with shared organizational context but separate continuity.\n\n> **Humans govern. AI helps. Spine preserves continuity.**\n\nThe core promise is not \"another dashboard.\"\n\nIt is:\n\n> **Stop reconstructing your business every time you need to work.**\n\nThe workspace already knows the relevant context, history, relationships, evidence, Work and available capabilities.\n\n\n\n---\n\n# 2. What the Customer Buys\n\nThe customer sees **SpineWorkspace**.\n\nUnderneath it is the **IntegrateWise platform**.\n\n```text\nCUSTOMER\n │\n ▼\nSPINEWORKSPACE\n │\n ├── Human Workbench\n ├── AI Workbench\n ├── Domain Workbenches\n ├── Communications\n ├── Work\n └── Shared Business Context\n │\n ▼\n INTEGRATEWISE PLATFORM\n │\n ├── Identity\n ├── Configuration\n ├── Connectors\n ├── Ingestion\n ├── Spine Fabric\n ├── Memory\n ├── Knowledge\n ├── Projection\n ├── AI / Twin\n ├── Capabilities\n ├── Governance\n ├── Execution\n ├── Verification\n └── Reconciliation\n```\n\nIntegrateWise is therefore the **infrastructure platform underneath SpineWorkspace**, not the primary daily destination for ordinary users. \n\n---\n\n# 3. SpineWorkspace Components\n\nThe product has two first-class operating sides.\n\n## Human side\n\n```text\nHuman Workbench\n │\n ├── Home\n ├── My Work\n ├── Communications\n ├── Personal\n └── Domain Workbenches\n```\n\n## AI side\n\n```text\nAI Workbench\n │\n ├── Context\n ├── Active Work\n ├── Plans\n ├── Twin\n ├── Agents\n ├── Capabilities\n ├── Execution\n └── Results\n```\n\nBoth operate over:\n\n```text\n BUSINESS CONTEXT SPINE\n │\n ┌──────────────┼──────────────┐\n │ │ │\n Organizational Evidence Knowledge\n Memory\n │ │ │\n └──────────────┼──────────────┘\n │\n WORK\n │\n Human ↔ AI ↔ Agents\n```\n\nThe Human Workbench and AI Workbench are therefore **different working environments over the same organizational business reality**. \n\n---\n\n# 4. The Spine Fabric\n\nThe Spine Fabric is the center of the system.\n\nIt is not simply a database.\n\nIt is the governed representation of the organization's operational context.\n\n```text\nCONNECTED SYSTEMS\n │\n ▼\nINGESTION\n │\n ▼\nNORMALIZATION\n │\n ▼\nSPINE FABRIC\n │\n ├── Entities\n ├── Relationships\n ├── Work\n ├── Events\n ├── Signals\n ├── Decisions\n ├── Commitments\n ├── Evidence\n ├── Knowledge\n ├── History\n └── Organizational Memory\n```\n\nThe logical Spine may use multiple physical stores underneath it. Physical storage is an implementation detail; the logical Business Context Spine is the durable product contract. \n\n---\n\n# 5. How SpineWorkspace Communicates\n\nThere are two directions.\n\n## Human → AI\n\n```text\nHuman\n ↓\nWork\n ↓\nTwin\n ↓\nAI Workbench\n ↓\nContext Assembly\n ↓\nAI / Agent\n```\n\nThe human does not need to manually copy the relevant CRM records, emails, documents and previous decisions into a prompt.\n\nThe Work already carries its context.\n\n## AI → Human\n\n```text\nAI / Twin\n ↓\nObservation\n ↓\nAnalysis\n ↓\nProposal\n ↓\nWork\n ↓\nHuman\n ↓\nApprove / Reject / Modify\n```\n\nThe AI does not independently become the authority.\n\n## AI → System\n\n```text\nAI\n ↓\nCapability\n ↓\nGovernance\n ↓\nExecution\n ↓\nProvider\n ↓\nOutcome\n```\n\n## System → AI / Human\n\n```text\nProvider\n ↓\nRe-ingestion\n ↓\nVerification\n ↓\nReconciliation\n ↓\nSpine\n ↓\nProjection\n ↓\nHuman + AI\n```\n\nThat creates the closed continuity loop.\n\n---\n\n# 6. Work Is the Coordination Object\n\nChat is not the durable handoff mechanism.\n\n**Work is.**\n\nA Work item carries:\n\n```text\nWork\n├── Objective\n├── Context\n├── Participants\n├── Human responsibility\n├── AI responsibility\n├── Agent state\n├── Evidence\n├── Decisions\n├── Commitments\n├── Capabilities\n├── Approvals\n├── Execution state\n├── Provider state\n└── Continuity history\n```\n\nThe governing rule is:\n\n> **No participating worker begins meaningful work without a Spine-derived authorized context and Work identity.**\n\nThat applies to humans, Twin, Spine Agents, workflows and execution providers. \n\n---\n\n# 7. Domain Workbenches\n\nThe Human Workbench is the common shell.\n\nDomain Workbenches are **projections of the same Spine into a particular business operating context**.\n\nExamples:\n\n```text\nSales\nCustomer Success\nTechnical Account Success\nMarketing\nCampaigns\nFinance\nRevOps\nOperations\nProduct\nEngineering\nSupport\nKnowledge Management\nFounder\n```\n\nThe architecture's existing donor map includes these domain surfaces and their source applications. \n\nThe important distinction is:\n\n```text\nDOMAIN WORKBENCH\n ↓\nPROJECTION\n ↓\nCOMMON SPINE\n```\n\nnot:\n\n```text\nDOMAIN WORKBENCH\n ↓\nseparate database\n```\n\n---\n\n# 8. Example: Sales Workbench\n\nA Sales Workbench can project:\n\n```text\nPipeline\nAccounts\nContacts\nOpportunities\nActivities\nForecast\nDeal Risk\nTasks\nMeetings\nCommunications\nDocuments\nSignals\n```\n\nThe same account may simultaneously appear in:\n\n```text\nSales\nCustomer Success\nFinance\nSupport\nFounder\n```\n\nbecause these are different projections of the same underlying business context.\n\n---\n\n# 9. Example: Customer Success Workbench\n\n```text\nAccounts\nHealth\nRenewals\nUsage\nStakeholders\nQBRs\nOpen Work\nSupport\nBilling\nCommitments\nRisk\nExpansion\n```\n\nThe Twin can assemble the account context without requiring the CSM to manually search multiple systems.\n\nThe Projection Registry associates entities, widgets, capabilities and connectors with the projection. \n\n---\n\n# 10. Example: Finance Workbench\n\n```text\nRevenue\nInvoices\nPayments\nSubscriptions\nBurn\nExpenditure\nApprovals\nReconciliation\nForecast\n```\n\nAgain:\n\n```text\nFinance Projection\n ↓\nsame Business Context Spine\n```\n\nnot another Finance database.\n\n---\n\n# 11. AI Workbench\n\nThe AI Workbench is the machine-side equivalent of the Human Workbench.\n\nIt provides AI with:\n\n```text\nAuthorized Business Context\n+\nCurrent Work\n+\nAI Continuity Memory\n+\nEvidence\n+\nAuthority\n+\nCapabilities\n+\nExecution State\n```\n\nThe AI Workbench is therefore not simply:\n\n```text\nChatGPT + tools\n```\n\nIt is:\n\n```text\nAI OPERATING ENVIRONMENT\n │\n ├── Context\n ├── Work\n ├── Memory\n ├── Evidence\n ├── Twin\n ├── Agents\n ├── Capabilities\n ├── Governance\n └── Execution\n```\n\nThe Founder Canon explicitly establishes the AI Workbench as a first-class operating environment rather than merely a chat session. \n\n---\n\n# 12. Twin\n\nThe Twin is the AI worker closest to the human.\n\n```text\nUSER\n ↕\nTWIN\n ↓\nAI WORKBENCH\n ↓\nSPINE / MEMORY / EVIDENCE\n ↓\nSPINE AGENTS\n```\n\nThe Twin can:\n\n- understand current Work;\n- assemble context;\n- research;\n- analyze;\n- prepare;\n- recommend;\n- coordinate;\n- draft;\n- request approval;\n- delegate;\n- monitor;\n- execute authorized work.\n\nThe Twin does not own organizational truth.\n\n---\n\n# 13. Spine Agents\n\nSpecialized AI workers operate underneath the Twin.\n\n```text\nTwin\n │\n ├── Research Agent\n ├── Analysis Agent\n ├── Revenue Agent\n ├── Compliance Agent\n ├── Planning Agent\n └── Other governed Spine Agents\n```\n\nThey coordinate through:\n\n```text\nWork\n+\nContext\n+\nEvidence\n+\nAuthority\n+\nHandoff State\n```\n\nrather than independent conversations.\n\n---\n\n# 14. Sidebar Structure\n\nThe sidebar should expose **where the user works**, not every backend service.\n\n## Universal shell\n\n```text\nSPINEWORKSPACE\n│\n├── Home\n│\n├── My Work\n│ ├── Inbox\n│ ├── Tasks\n│ ├── Queue\n│ ├── Approvals\n│ └── Recent\n│\n├── Communications\n│ ├── Activity\n│ ├── Email\n│ ├── Calendar\n│ ├── Meetings\n│ ├── Chat\n│ └── Calls\n│\n├── Personal\n│ ├── Notes\n│ ├── Personal Knowledge\n│ └── Brainstorming\n│\n├── Work\n│ ├── Domain\n│ ├── KPI\n│ ├── Entity\n│ ├── Work\n│ ├── Decisions\n│ └── Operations\n│\n└── Platform\n └── Authorized administrative surfaces\n```\n\nThe existing architecture identifies the stable shell around Home, My Work, Communications, Personal and adaptive Work. \n\n### Global utilities\n\nThese should remain accessible everywhere rather than becoming ordinary sidebar destinations:\n\n```text\nGlobal Search\nTwin\nNotifications\nProfile\nCommand / Quick Actions\n```\n\n### Domain navigation\n\nThe Work section changes according to:\n\n```text\nRole\n+\nDepartment\n+\nIndustry\n+\nResponsibility\n+\nGoals\n+\nConnected Systems\n+\nCurrent Work\n+\nPermissions\n```\n\n---\n\n# 15. Frontend → Projection → Backend\n\nThe frontend must not independently reconstruct the business.\n\nThe canonical path is:\n\n```text\nFRONTEND\n ↓\nWORKBENCH ROUTE\n ↓\nPROJECTION REQUEST\n ↓\nPROJECTION ENGINE\n ↓\nAUTHORIZED PROJECTION\n ↓\nBACKEND DATA / CONTEXT\n ↓\nWORKBENCH RESPONSE\n ↓\nUI\n```\n\nThe Projection Engine is the authoritative composer of authorized, versioned Workbench/context contracts. \n\n---\n\n# 16. Frontend Surface Model\n\nA frontend surface can be represented as:\n\n```text\nSurface\n├── Route\n├── Workbench\n├── Projection\n├── Entity types\n├── Views\n├── Widgets\n├── Capabilities\n├── Twin modules\n├── Signals\n├── Connectors\n└── Permissions\n```\n\nFor example:\n\n```text\nCustomer Success\n │\n ▼\ncsm.accounts\n │\n ├── Account\n ├── Renewal\n ├── Task\n │\n ├── Account Grid\n ├── Renewal Summary\n └── Risk Summary\n │\n ├── account.update\n └── meeting.schedule\n```\n\nThat pattern is explicitly described in the Projection Registry working specification. \n\n---\n\n# 17. Backend Data Model\n\nThe backend should separate logical domains.\n\n```text\nTENANT\n├── organization\n├── users\n├── memberships\n├── roles\n└── permissions\n\nCONNECTION\n├── connectors\n├── connections\n├── credentials / secret references\n├── mappings\n├── sync state\n└── discovery\n\nSPINE\n├── canonical entities\n├── relationships\n├── events\n├── signals\n├── work\n├── decisions\n├── commitments\n└── provenance\n\nMEMORY\n├── organizational memory\n├── personal contextual memory\n└── AI continuity memory\n\nKNOWLEDGE\n├── documents\n├── chunks\n├── embeddings\n├── source links\n└── evidence\n\nPROJECTION\n├── projection definitions\n├── projection versions\n├── projection bindings\n├── view definitions\n└── widget composition\n\nCAPABILITY\n├── capability definitions\n├── providers\n├── routes\n├── permissions\n└── execution plans\n\nEXECUTION\n├── approvals\n├── execution runs\n├── outcomes\n├── verification\n├── reconciliation\n└── audit\n```\n\nThe physical schema can be implemented across the appropriate stores; the important boundary is the logical ownership of each data type.\n\n---\n\n# 18. Storage and Retrieval\n\nThe complete retrieval model is:\n\n```text\n REQUEST\n │\n ┌─────────────┼─────────────┐\n ▼ ▼ ▼\n Structured Search Memory\n Spine /Vector Stores\n │ │ │\n └─────────────┼─────────────┘\n ▼\n CONTEXT ASSEMBLY\n │\n ▼\n WORK / UI\n │\n ▼\n HUMAN / AI\n```\n\nDocuments and media follow:\n\n```text\nOriginal Artifact\n ↓\nObject Storage\n ↓\nMetadata\n ↓\nParsing\n ↓\nChunks\n ↓\nEmbeddings\n ↓\nSemantic Retrieval\n ↓\nEvidence\n```\n\nThe original artifact remains the source representation; vectors and derived records are retrieval/interpretation mechanisms.\n\n---\n\n# 19. Projection Registry\n\nThe Projection Registry becomes the contract between:\n\n```text\nBusiness Context\n ↓\nDomain\n ↓\nFrontend\n ↓\nAI Context\n```\n\nA projection definition should be able to describe:\n\n```text\nProjection\n├── ID\n├── Version\n├── Domain\n├── Audience\n├── Entities\n├── Views\n├── Widgets\n├── Connectors\n├── Signals\n├── Capabilities\n├── Twin Modules\n├── Policies\n├── Permissions\n└── Data dependencies\n```\n\nExample:\n\n```text\nprojection: csm.accounts\n\nentities:\n account\n renewal\n task\n\nviews:\n account_grid\n account_detail\n renewal_view\n risk_view\n\nwidgets:\n renewal_summary\n risk_summary\n health_card\n\ncapabilities:\n account.update\n meeting.schedule\n\nconnectors:\n salesforce\n slack\n\ntwin_modules:\n renewal_intelligence\n account_health\n```\n\nThis is what allows the UI to become **registry-driven rather than hardcoded**. \n\n---\n\n# 20. The Supporting Registries\n\nThe Projection Registry should not exist alone.\n\nThe architecture naturally converges toward:\n\n```text\nEntity Registry\nCapability Registry\nProjection Registry\nWidget Registry\nTwin Registry\nSignal Registry\nConnector Registry\nDepartment Registry\nRuntime Registry\n```\n\n## Entity Registry\n\nDefines:\n\n```text\nFields\nRelationships\nTimeline\nSignals\nKPIs\nCapabilities\nTwin Modules\nGovernance\nProjection Types\nWidgets\n```\n\n## Capability Registry\n\nDefines:\n\n```text\nInputs\nPermissions\nGovernance\nExecution Steps\nProviders\nRetry\nRollback\nEvidence\nTimeline Events\n```\n\n## Twin Registry\n\nDefines reusable intelligence modules.\n\n## Signal Registry\n\nNormalizes provider events into business meaning.\n\n```text\nSalesforce\n ↓\nOpportunity Closed\n ↓\nCanonical Signal\n ↓\nRevenue Increased\n```\n\nThe Twin understands the **signal**, not the provider.\n\n## Widget Registry\n\nReusable UI components.\n\n```text\nHealth Card\nRisk Card\nTimeline\nDecision Queue\nEvidence Viewer\nRelationship Graph\nActivity Feed\nMeeting Timeline\nTwin Recommendation\nKPI Card\n```\n\n## Connector Registry\n\nDefines:\n\n```text\nEntities\nCapabilities\nSignals\nTimeline Events\nKPIs\nRelationships\nAuthentication\nSync Policy\n```\n\nThese registry concepts are explicitly proposed in the project architecture material. \n\n---\n\n# 21. Wiring\n\nThe actual system wiring is:\n\n```text\nCONNECTOR\n ↓\nDISCOVERY\n ↓\nMAPPING\n ↓\nINGESTION\n ↓\nNORMALIZATION\n ↓\nTRIAGE\n ↓\nGOVERNED WRITE\n ↓\nSPINE\n ↓\nPROJECTION ENGINE\n ↓\nWORKBENCH\n```\n\nFor AI:\n\n```text\nWORK\n ↓\nPROJECTION\n ↓\nCONTEXT ASSEMBLY\n ↓\nAI WORKBENCH\n ↓\nTWIN\n ↓\nSPINE AGENT\n ↓\nCAPABILITY DISCOVERY\n ↓\nCAPABILITY RESOLUTION\n ↓\nGOVERNANCE\n ↓\nHERMES\n ↓\nPROVIDER\n```\n\nThen closure:\n\n```text\nPROVIDER\n ↓\nOUTCOME\n ↓\nRE-INGESTION\n ↓\nVERIFICATION\n ↓\nRECONCILIATION\n ↓\nSPINE\n ↓\nPROJECTION INVALIDATION\n ↓\nPROJECTION REBUILD\n ↓\nWORKBENCH REFRESH\n ↓\nTWIN REFRESH\n```\n\nThe implementation readiness material identifies this exact missing/proof-critical chain: Gateway → Capability Runtime → Governance → Hermes → Connector Runtime, followed by projection refresh and end-to-end validation. \n\n---\n\n# 22. Connector → Ingestion → Spine\n\nThe customer experience hides the machinery:\n\n```text\nUser:\n\"Connect Salesforce.\"\n```\n\nThe platform performs:\n\n```text\nSalesforce\n ↓\nOAuth / Consent\n ↓\nTenant Binding\n ↓\nDiscovery\n ↓\nObject / Field Mapping\n ↓\nConnector Classification\n ↓\nIngestion\n ↓\nNormalization\n ↓\nCanonical Spine\n ↓\nProjection\n```\n\nInitial hydration creates the first useful operating context.\n\nThen:\n\n```text\nInitial Hydration\n ↓\nBreadth Hydration\n ↓\nContinuous Sync\n```\n\nThe customer should experience:\n\n> **Connect → Assemble → Work**\n\nrather than:\n\n> Configure a database → build dashboards → manually import data → configure AI.\n\n---\n\n# 23. Triage and Memory Promotion\n\nNot everything entering the system becomes organizational memory.\n\nThe boundary is:\n\n```text\nSOURCE\n ↓\nINGEST\n ↓\nINTERPRET\n ↓\nTRIAGE\n ↓\nGOVERNANCE\n ↓\nPROMOTE\n```\n\nFor example:\n\n```text\nMeeting transcript\n ↓\nExtracted commitment\n ↓\nCandidate organizational fact\n ↓\nTriage\n ↓\nGovernance\n ↓\nBusiness Context Spine\n```\n\nLikewise:\n\n```text\nAI inference\n ≠\norganizational truth\n```\n\nand:\n\n```text\nPersonal note\n ≠\norganizational truth\n```\n\nThe three memory domains remain separate unless an explicit governed transition occurs. \n\n---\n\n# 24. OODA Is Internal\n\nThe system still operates using:\n\n```text\nObserve\n ↓\nOrient\n ↓\nDecide\n ↓\nAct\n```\n\nBut users should experience natural work interactions rather than four artificial AI buttons.\n\nFor example:\n\n```text\n\"Prepare my renewal review.\"\n\n\"Show me what changed.\"\n\n\"Draft the customer response.\"\n\n\"Handle the approved follow-up.\"\n\n\"Why is this account at risk?\"\n```\n\nOODA is the internal operating grammar.\n\nThe product experience remains Work-centric. \n\n---\n\n# 25. Governance and Execution\n\nEvery consequential action follows:\n\n```text\nIntent\n ↓\nCapability\n ↓\nAuthority\n ↓\nGovernance\n ↓\nApproval if required\n ↓\nExecution Plan\n ↓\nHermes\n ↓\nProvider\n```\n\nPossible governance results:\n\n```text\nALLOW\nDENY\nREQUIRE APPROVAL\nBOUNDED DELEGATION\n```\n\nThe AI can recommend.\n\nThe system can prepare.\n\nThe human or policy controls authority.\n\n---\n\n# 26. Verification and Reconciliation\n\nThis is what makes the architecture operational rather than merely conversational.\n\n```text\nAI says:\n\"Opportunity updated.\"\n```\n\nis not enough.\n\nThe system must establish:\n\n```text\nRequested State\n ↓\nProvider Action\n ↓\nProvider Outcome\n ↓\nRe-ingestion\n ↓\nActual State\n ↓\nCompare\n ↓\nReconcile\n ↓\nVerified Spine State\n```\n\nOnly then does the Workbench update.\n\nThe canonical completion condition requires outcome re-ingestion, verification and reconciliation before the new state becomes verified business context. \n\n---\n\n# 27. Go-Live\n\nGo-live is the final product validation and publication path.\n\n```text\nSOURCE COMMIT\n ↓\nCI / CONTRACT TESTS\n ↓\nDEVELOPMENT ARTIFACTS\n ↓\nCUSTOMER ZERO\n ↓\nCUSTOMER ZERO EVIDENCE\n ↓\nVERSION FREEZE\n ↓\nCLEAN EXTERNAL TENANT\n ↓\nPLUGIN / MCP SUBMISSION\n ↓\nPUBLICATION\n```\n\nThe frozen go-live doctrine explicitly requires this one-way promotion sequence. \n\n---\n\n# 28. Customer Zero\n\nCustomer Zero is the first real SpineWorkspace tenant.\n\nIt should operate the actual company using the same system:\n\n```text\nProduct\nCode\nArchitecture\nDecisions\nTasks\nDocumentation\nConnectors\nAI Work\nGTM\nOperations\nReleases\nContinuity\n```\n\nThis makes Customer Zero an operating reference implementation rather than a synthetic demo.\n\n---\n\n# 29. Go-Live Release Gates\n\nBefore external production:\n\n### Identity\n\n```text\nAuthentication\nTenant binding\nRBAC\nIsolation\n```\n\n### Connectivity\n\n```text\nReal connector\nConsent\nMapping\nHydration\nDelta sync\nHealth\nRevoke\n```\n\n### Workspace\n\n```text\nHuman Workbench\nDomain projections\nAI Workbench\nTwin\n```\n\n### AI\n\n```text\nContext assembly\nMemory retrieval\nEvidence\nProposal\nAgent handoff\n```\n\n### Execution\n\n```text\nCapability\nGovernance\nApproval\nHermes\nProvider\n```\n\n### Continuity\n\n```text\nOutcome\nRe-ingestion\nVerification\nReconciliation\nProjection refresh\n```\n\n### Operations\n\n```text\nAudit\nObservability\nRate limits\nRollback\nDeletion\nExport\nOffboarding\nRevocation\n```\n\nThe release gates explicitly treat missing evidence as stop-ship. \n\n---\n\n# 30. The Complete End-to-End Architecture\n\n```text\n MARKET\n │\n ▼\n SPINEWORKSPACE.COM\n │\n ┌──────────┼──────────┐\n ▼ ▼ ▼\n Plugin MCP Direct\n Marketplace Marketplace Entry\n │ │ │\n └──────────┼──────────┘\n ▼\n IDENTITY / TENANT\n │\n ▼\n WORKSPACE\n │\n ROLE / GOALS / CONTEXT\n │\n ▼\n CONNECTOR MARKETPLACE\n │\n ▼\n CONNECT / CONSENT\n │\n ▼\n DISCOVERY\n │\n ▼\n MAPPING / ACTIVATION\n │\n ▼\n INGESTION PIPELINE\n │\n ┌─────────────────┼─────────────────┐\n ▼ ▼ ▼\n STRUCTURED DOCUMENTS AI /\n FLOW A FLOW B COGNITIVE\n │ │ │\n └─────────────────┼─────────────────┘\n ▼\n TRIAGE\n │\n ▼\n GOVERNED SPINE WRITE\n │\n ▼\n BUSINESS CONTEXT SPINE\n │\n ┌─────────────────────┼─────────────────────┐\n ▼ ▼ ▼\n Organizational Personal AI\n Memory Contextual Continuity\n Memory Memory\n │ │ │\n └─────────────────────┼─────────────────────┘\n │\n KNOWLEDGE / EVIDENCE\n │\n SEARCH / RETRIEVAL\n │\n ▼\n PROJECTION REGISTRY\n │\n ▼\n PROJECTION ENGINE\n │\n ┌──────────────┴──────────────┐\n ▼ ▼\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n ┌────────┼────────┐ │\n ▼ ▼ ▼ ▼\n Sales CS Finance Twin\n Marketing Support RevOps │\n Product etc. ▼\n Spine Agents\n │ │\n └──────────────┬──────────────┘\n ▼\n WORK\n │\n HUMAN ↔ AI ↔ AGENTS\n │\n ▼\n CAPABILITY FABRIC\n │\n GOVERNANCE\n │\n APPROVAL\n │\n HERMES\n │\n PROVIDER / API / MCP\n │\n ▼\n SOURCE SYSTEM\n │\n OUTCOME\n │\n RE-INGESTION\n │\n VERIFICATION\n │\n RECONCILIATION\n │\n ▼\n VERIFIED SPINE\n │\n ┌────────────┴────────────┐\n ▼ ▼\n PROJECTION REFRESH AI CONTEXT REFRESH\n │ │\n └────────────┬────────────┘\n ▼\n NEXT WORK\n │\n ▼\n CONTINUITY\n │\n ▼\n MORE CONTEXT\n │\n ▼\n MORE CONNECTORS\n │\n ▼\n EXPANSION\n```\n\n---\n\n# 31. Final Product Architecture Formula\n\n```text\nSPINEWORKSPACE\n=\nHUMAN WORKBENCH\n+\nAI WORKBENCH\n+\nDOMAIN WORKBENCHES\n+\nSHARED BUSINESS CONTEXT\n+\nPERSONAL CONTEXTUAL MEMORY\n+\nAI CONTINUITY MEMORY\n+\nWORK\n+\nTWIN\n+\nSPINE AGENTS\n+\nPROJECTION ENGINE\n+\nCAPABILITY FABRIC\n+\nGOVERNANCE\n+\nHERMES\n+\nVERIFICATION\n+\nRECONCILIATION\n```\n\nAnd underneath:\n\n```text\nINTEGRATEWISE\n=\nIDENTITY\n+\nCONFIGURATION\n+\nINTEGRATION\n+\nDISCOVERY\n+\nACTIVATION\n+\nINGESTION\n+\nSPINE FABRIC\n+\nKNOWLEDGE\n+\nMEMORY\n+\nEVIDENCE\n+\nPROJECTION\n+\nAI RUNTIME\n+\nCAPABILITIES\n+\nGOVERNANCE\n+\nEXECUTION\n+\nSYNC\n+\nVERIFICATION\n+\nRECONCILIATION\n+\nAUDIT\n+\nOBSERVABILITY\n+\nDISTRIBUTION\n```\n\n---\n\n# 32. Final GTM → Product → Platform → Go-Live Story\n\n```text\nGTM\n│\n├── Discover\n├── Install / Enter\n└── Activate\n │\n ▼\nSPINEWORKSPACE\n│\n├── Identity\n├── Workspace\n├── Connectors\n└── First Context\n │\n ▼\nSPINE FABRIC\n│\n├── Ingest\n├── Normalize\n├── Govern\n├── Remember\n└── Retrieve\n │\n ▼\nWORKBENCH\n│\n├── Human\n├── Domain\n└── AI\n │\n ▼\nWORK\n│\n├── Human\n├── Twin\n└── Agents\n │\n ▼\nCAPABILITY\n│\n├── Resolve\n├── Govern\n└── Execute\n │\n ▼\nREAL WORLD\n│\n├── Provider\n├── Outcome\n└── External State\n │\n ▼\nCONTINUITY\n│\n├── Re-ingest\n├── Verify\n├── Reconcile\n├── Update Spine\n└── Refresh Workbench\n │\n ▼\nVALUE\n│\n├── More context\n├── More connected systems\n├── More capabilities\n└── More Work\n │\n ▼\nEXPANSION\n │\n ▼\nGO-LIVE / SCALE\n```\n\n## Final positioning\n\n> **SpineWorkspace is the shared operating environment where humans and AI work toward the same business goals through different workbenches, using the same governed Business Context Spine while maintaining separate human and AI continuity. IntegrateWise is the infrastructure platform underneath it, connecting the organization's software ecosystem, ingesting and governing business context, composing the right projections and AI context, enabling governed capabilities, executing approved work, and continuously reconciling reality back into the Spine.**\n\nThe architectural doctrine remains:\n\n> **Humans govern. AI helps. Spine preserves continuity.**\n\n---\n\n# chatgpt response\n\nWhat would you like me to produce from the uploaded material?\n\nI can continue the **SpineWorkspace canonical writeup** from the previous structure, with the next section focused on the exact **frontend/backend table mapping, Projection Registry, wiring, connector ingestion pipeline, and go-live flow**, or produce a consolidated final document.\n\n---\n\n# you asked\n\nmessage time: 2026-09-04 01:59:13\n\nEND TO END TECH SPEC AND DATA FLOW SPEC IN ALIGNED WITH GTM\n\n---\n\n# chatgpt response\n\n# SpineWorkspace — End-to-End Technical Specification & Data Flow Specification\n\n**Alignment:** SpineWorkspace product + IntegrateWise platform + GTM + connector ingestion + projection + Human Workbench + AI Workbench + governed execution + go-live.\n\n**Canonical principle:**\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\nThe 31 August Founder Canon is the primary product authority. The earlier platform contracts remain the implementation baseline where they are not superseded. \n\n---\n\n# 1. GTM → PRODUCT ENTRY\n\nSpineWorkspace has **three marketplace surfaces**, but they have different jobs.\n\n| Surface | GTM role | Result |\n|---|---|---|\n| **Plugin Marketplace** | External acquisition + embedded activation | IW-Spine-Network Plugin |\n| **MCP Marketplace** | External acquisition + tool-first activation | IW-Spine-Network MCP |\n| **Connector Marketplace** | In-product activation + expansion | Customer's connected systems |\n| **Direct Workbench** | Direct acquisition | SpineWorkspace tenant |\n\nPlugin and MCP marketplaces bring the customer into IntegrateWise.\n\nThe Connector Marketplace expands the customer's existing workspace.\n\nThe locked GTM sequence is:\n\n```text\nMARKET\n ↓\nPlugin / MCP / Direct Entry\n ↓\nIdentity\n ↓\nTenant\n ↓\nWorkspace\n ↓\nConnector\n ↓\nHydration\n ↓\nFirst Grounded Value\n ↓\nFirst Approved Governed Outcome\n ↓\nRecurring Work\n ↓\nMore Connectors\n ↓\nMore Context\n ↓\nExpansion\n```\n\nThis distinction is explicitly established in the GTM architecture: Plugin and MCP are acquisition channels; Connector Marketplace is the post-entry activation/expansion mechanism. \n\n---\n\n# 2. TENANT CREATION\n\nA new customer begins with an isolated tenant.\n\n```text\nIdentity\n ↓\nOrganization\n ↓\nTenant\n ↓\nUsers\n ↓\nRoles\n ↓\nPermissions\n ↓\nGoals / Operating Context\n ↓\nWorkspace\n```\n\n### Core tenant data\n\n```text\ntenant\norganization\nusers\nmemberships\nroles\npermissions\ntenant_config\ntenant_spine_config\n```\n\nThe tenant boundary is foundational: every subsequent connection, ingestion event, memory object, Work item, projection and execution belongs to a tenant-scoped context.\n\n---\n\n# 3. SPINEWORKSPACE SHELL\n\nThe user enters:\n\n```text\nSPINEWORKSPACE\n```\n\nThe stable shell contains:\n\n```text\nHome\n\nMy Work\n ├── Inbox\n ├── Tasks\n ├── Queue\n ├── Approvals\n ├── Recent\n └── Favorites\n\nCommunications\n ├── Activity\n ├── Email\n ├── Calendar\n ├── Meetings\n ├── Chat\n ├── Calls\n └── Shared Documents\n\nPersonal\n ├── Notes\n ├── Personal Knowledge\n └── Brainstorming\n\nWork\n └── Adaptive Domain Workbenches\n\nAdministration\n └── Authorized operator surfaces\n```\n\nThe shell is stable; the **Work** section is adaptive.\n\nThe Human Workbench is the primary daily product surface. \n\n---\n\n# 4. WORKBENCH COMPOSITION\n\nThe Workbench is not a database page.\n\nIt is a projection.\n\n```text\nRole\n+\nDepartment\n+\nIndustry\n+\nGoals\n+\nResponsibility\n+\nConnected Systems\n+\nPermissions\n+\nCurrent Work\n+\nBusiness Context\n+\nMemory\n+\nCapabilities\n ↓\nPROJECTION\n ↓\nWORKBENCH\n```\n\nTherefore:\n\n```text\nSales user\n ↓\nSales projection\n\nCS user\n ↓\nCustomer Success projection\n\nFinance user\n ↓\nFinance projection\n```\n\nwhile all remain connected to the same Business Context Spine.\n\nThe existing routing model explicitly defines role-driven columns, department-driven joins, industry-specific fields and connector-dependent field availability. \n\n---\n\n# 5. DOMAIN WORKBENCHES\n\nDomain Workbenches are **projections, not separate products**.\n\nPossible domains include:\n\n```text\nSales\nCustomer Success\nMarketing\nFinance\nOperations\nEngineering\nSupport\nProduct\nRevOps\nFounder / Executive\n```\n\nFor example:\n\n```text\nCUSTOMER SUCCESS\n ↓\nAccount\nHealth\nRenewal\nStakeholders\nMeetings\nSupport\nUsage\nCommitments\nTasks\nRisk\n```\n\nThe same Account can simultaneously appear in:\n\n```text\nSales\nCustomer Success\nFinance\nSupport\nExecutive\n```\n\nbecause those are different views over the same canonical context.\n\n---\n\n# 6. AI WORKBENCH\n\nAI has a separate first-class operating environment.\n\n```text\nAI WORKBENCH\n │\n ├── Authorized Context\n ├── Current Work\n ├── AI Continuity\n ├── Evidence\n ├── Twin\n ├── Spine Agents\n ├── Capabilities\n ├── Governance\n └── Execution\n```\n\nThe AI Workbench does not replace the Human Workbench.\n\nIt is the operating environment for:\n\n```text\nTwin\n+\nSpine Agents\n```\n\nBoth operate against the same organizational Business Context Spine while retaining separate continuity memory. \n\n---\n\n# 7. THE THREE MEMORY DOMAINS\n\n## 7.1 Organizational Memory\n\n```text\nBusiness Context Spine\n ↓\nOrganizational Memory\n```\n\nShared, governed business context.\n\n## 7.2 Personal Contextual Memory\n\n```text\nUser\n ↓\nPersonal Contextual Memory\n```\n\nPrivate user continuity.\n\n## 7.3 AI Continuity Memory\n\n```text\nTwin / Agent\n ↓\nAI Continuity Memory\n```\n\nAI working continuity across turns, model changes and agent handoffs.\n\nThe constitutional boundary is:\n\n```text\nUser thought\n ≠\nAI inference\n ≠\nOrganizational truth\n```\n\nNeither personal nor AI memory silently becomes organizational truth. \n\n---\n\n# 8. CONNECTOR MARKETPLACE\n\nOnce the workspace exists:\n\n```text\nConnector Marketplace\n ↓\nSelect Provider\n ↓\nConnect\n ↓\nOAuth / Consent\n ↓\nTenant Binding\n ↓\nDiscovery\n ↓\nMapping\n ↓\nActivation\n```\n\nExamples:\n\n```text\nSalesforce\nSlack\nGoogle Workspace\nSupport systems\nFinance systems\nEngineering systems\n```\n\nThe connector is not itself the product's business model.\n\nIt extends the Business Context available to the workspace.\n\n---\n\n# 9. CONNECTOR RUNTIME\n\nThe connector architecture contains a compatibility layer that routes connector operations toward loader, MCP and storage services.\n\nThe existing implementation defines:\n\n```text\nConnector\n ├── /api/v1/connector/*\n ├── /api/v1/loader/*\n ├── /nango/webhook\n ├── /tools\n ├── /invoke\n ├── /v1/mcp/*\n ├── /files/*\n └── /upload/*\n```\n\nThe Loader handles schema-driven onboarding/background sync, while Connector Sync handles scheduled and on-demand synchronization. \n\n---\n\n# 10. CONNECTOR DISCOVERY\n\nDiscovery establishes:\n\n```text\nProvider\n ↓\nObjects\n ↓\nFields\n ↓\nRelationships\n ↓\nEvents\n ↓\nCapabilities\n ↓\nAvailable operations\n```\n\nThe output becomes configuration rather than immediately becoming organizational truth.\n\n```text\nDISCOVERY\n ↓\nTENANT CONFIGURATION\n ↓\nINGESTION RULES\n ↓\nACTIVATION\n```\n\n---\n\n# 11. SOURCE → CANONICAL SPINE\n\nThe source system has provider-specific semantics.\n\nThe Spine uses canonical semantics.\n\n```text\nSalesforce Account\n ↓\nCanonical Account\n\nHubSpot Company\n ↓\nCanonical Account\n```\n\nLikewise:\n\n```text\nProvider Ticket\n ↓\nCanonical Support Work\n\nProvider Meeting\n ↓\nCanonical Meeting\n\nProvider Opportunity\n ↓\nCanonical Deal / Pipeline Context\n```\n\nThis is the point of normalization.\n\nThe Spine should not become a collection of provider-specific tables.\n\n---\n\n# 12. INGESTION PIPELINE\n\nThe ingestion path is:\n\n```text\nSOURCE\n ↓\nCONNECTOR\n ↓\nLOADER\n ↓\nPARSE\n ↓\nCLASSIFY\n ↓\nEXTRACT\n ↓\nENRICH\n ↓\nROUTE\n ↓\nGOVERN\n ↓\nPROMOTE\n ↓\nSPINE\n```\n\nThe canonical document/data pipeline is explicitly defined as an eight-stage process:\n\n```text\nIngest\n→ Parse\n→ Classify\n→ Extract\n→ Enrich\n→ Route\n→ Govern\n→ Promote\n```\n\n\n\n---\n\n# 13. INITIAL HYDRATION\n\nThe first synchronization is different from ongoing synchronization.\n\n```text\nCONNECTOR ACTIVATED\n ↓\nINITIAL / CREAMY SYNC\n ↓\nCORE ENTITIES\n ↓\nCORE RELATIONSHIPS\n ↓\nRELEVANT DOCUMENTS\n ↓\nKNOWLEDGE INDEX\n ↓\nBUSINESS CONTEXT\n ↓\nPROJECTIONS\n ↓\nWORKSPACE READY\n```\n\nThe Loader is specifically responsible for creamy onboarding sync, background sync and scheduled polling. \n\nThe goal is:\n\n> **Connect → Assemble → Work**\n\nrather than:\n\n> Connect → configure everything manually → wait → build workspace.\n\n---\n\n# 14. CONTINUOUS SYNC\n\nAfter initial hydration:\n\n```text\nWebhook\nPoll\nDelta\nCursor\nScheduled Sync\nManual Sync\n ↓\nConnector Sync\n ↓\nLoader\n ↓\nNormalizer\n ↓\nCanonical Writer\n ↓\nSpine\n```\n\nThe Connector Sync service provides scheduled and on-demand synchronization, using tenant configuration to determine what is synchronized. \n\n---\n\n# 15. NORMALIZATION\n\nNormalization converts source data into canonical business context.\n\n```text\nSOURCE OBJECT\n ↓\nIDENTIFY\n ↓\nMAP\n ↓\nNORMALIZE\n ↓\nRESOLVE ENTITY\n ↓\nATTACH PROVENANCE\n ↓\nCLASSIFY\n ↓\nCANONICAL OBJECT\n```\n\nThe canonical object should retain source lineage.\n\nConceptually:\n\n```text\nCanonical Account\n ├── source: Salesforce\n ├── source_record_id\n ├── observed_at\n ├── confidence\n └── source fields\n```\n\nThis allows the Spine to preserve business meaning without losing where information came from.\n\n---\n\n# 16. TRIAGE\n\nNot every incoming observation becomes durable organizational memory.\n\n```text\nIncoming Data\n ↓\nInterpretation\n ↓\nTriage\n ↓\nPromotion Queue\n ↓\nGovernance\n ↓\nCanonical Write\n```\n\nTriage decides what needs:\n\n```text\nAccept\nReject\nReview\nPromote\n```\n\nThis is particularly important for:\n\n- inferred facts;\n- extracted commitments;\n- AI-generated observations;\n- conflicting source values;\n- entity merges;\n- organizational memory candidates.\n\n---\n\n# 17. PROMOTION QUEUE\n\nThe Promotion Queue is the boundary between:\n\n```text\nOBSERVED / DERIVED\n```\n\nand:\n\n```text\nACCEPTED ORGANIZATIONAL CONTEXT\n```\n\nExample:\n\n```text\nMeeting transcript\n ↓\n\"Customer intends to renew.\"\n ↓\nCandidate commitment\n ↓\nTriage\n ↓\nHuman / policy validation\n ↓\nPromote\n ↓\nSpine\n```\n\nThe promotion boundary protects organizational truth.\n\n---\n\n# 18. SPINE FABRIC\n\nAfter governed promotion:\n\n```text\n SPINE\n │\n ┌──────────────┼──────────────┐\n ▼ ▼ ▼\n Entities Work Signals\n │ │ │\n ▼ ▼ ▼\n Relationships Decisions Events\n │ │ │\n └──────────────┼──────────────┘\n ▼\n Business Context\n │\n ▼\n Organizational Memory\n```\n\nThis is the shared business substrate.\n\n---\n\n# 19. KNOWLEDGE + MEDIA STORAGE\n\nDocuments/media are not treated like ordinary relational rows.\n\n```text\nSOURCE FILE\n ↓\nOBJECT STORAGE\n ↓\nMETADATA\n ↓\nPARSER\n ↓\nTEXT / STRUCTURE\n ↓\nCHUNKS\n ↓\nEMBEDDINGS\n ↓\nVECTOR / HYBRID INDEX\n```\n\nThe Knowledge service handles:\n\n- chunking;\n- embeddings;\n- vector search;\n- hybrid search;\n- session search.\n\nThe implementation notes D1/database bindings alongside Vectorize/search and AI services. \n\n---\n\n# 20. RETRIEVAL\n\nA user or Twin does not query every storage layer independently.\n\nInstead:\n\n```text\nQUESTION / WORK\n ↓\nCONTEXT ASSEMBLY\n ↓\nStructured Spine\n+\nKnowledge Search\n+\nEvidence\n+\nMemory\n+\nWork State\n ↓\nAUTHORIZED CONTEXT\n```\n\nThe retrieval result should preserve references back to the source.\n\n```text\nAI statement\n ↓\nEvidence\n ↓\nSource record/document\n```\n\nThis creates an evidence chain rather than unsupported generation.\n\n---\n\n# 21. PROJECTION REGISTRY\n\nThe Projection Registry defines how canonical context becomes a product view.\n\nA projection definition contains concepts such as:\n\n```text\nprojection_id\nversion\ndomain\naudience\nentities\nfields\nviews\nwidgets\nsignals\nconnectors\ncapabilities\npermissions\npolicies\nTwin modules\n```\n\nExample:\n\n```text\nprojection:\n csm.accounts\n\nentities:\n account\n renewal\n task\n\nviews:\n account_grid\n account_detail\n renewal_view\n risk_view\n\nwidgets:\n health_card\n renewal_summary\n risk_summary\n\ncapabilities:\n account.update\n meeting.schedule\n```\n\nThe existing Projection Registry specification uses this model and establishes projection IDs, versions, domains, entities, views, widgets, capabilities and connectors. \n\n---\n\n# 22. PROJECTION ENGINE\n\nThe request path is:\n\n```text\nUSER\n ↓\nWORKBENCH\n ↓\nProjection ID\n ↓\nProjection Engine\n ↓\nTenant\n ↓\nRole\n ↓\nPermissions\n ↓\nAvailable Connectors\n ↓\nAvailable Data\n ↓\nProjection\n ↓\nUI\n```\n\nThe important invariant is:\n\n> **No Workbench component reads directly from a database.**\n\nThe Projection Platform owns:\n\n- query;\n- permission checking;\n- cache strategy;\n- fallback;\n- projection composition.\n\nThis is explicitly established in the platform specification. \n\n---\n\n# 23. FRONTEND ↔ BACKEND DATA CONTRACT\n\nThe frontend should therefore map:\n\n```text\nROUTE\n ↓\nPROJECTION\n ↓\nVIEW\n ↓\nENTITY\n ↓\nFIELDS\n ↓\nCAPABILITIES\n```\n\nExample:\n\n```text\n/frontend/csm/accounts\n ↓\nprojection: csm.accounts\n ↓\nview: account_grid\n ↓\nentity: account\n ↓\nfields:\n name\n health_score\n renewal_date\n engagement\n risk\n ↓\ncapabilities:\n account.update\n meeting.schedule\n```\n\nThe UI does not know which provider supplied the fields.\n\n---\n\n# 24. TABLES AND VIEWS\n\nThe logical model should distinguish:\n\n### Canonical tables/entities\n\n```text\nAccount\nContact\nOpportunity\nDeal\nTask\nWork\nMeeting\nSignal\nDecision\nCommitment\nDocument\nEvidence\n```\n\n### Projection views\n\n```text\naccount_grid\naccount_detail\nrenewal_view\nrisk_view\npipeline_view\ntask_queue\napproval_queue\nmeeting_view\n```\n\n### UI widgets\n\n```text\nHealth Card\nRisk Card\nTimeline\nKPI Card\nEvidence Viewer\nRelationship Graph\nTwin Recommendation\nApproval Card\n```\n\nA table/view/widget is therefore a **projection artifact**, not an independent source of truth.\n\n---\n\n# 25. CONNECTOR-DEPENDENT PROJECTIONS\n\nConnector availability affects projection composition.\n\nFor example:\n\n```text\nSalesforce connected\n ↓\ncrm_stage available\n```\n\nNo Salesforce:\n\n```text\ncrm_stage\n ↓\nhidden / unavailable\n```\n\nSimilarly:\n\n```text\nTelemetry connector\n ↓\nadoption_tier\nfeature_adoption_score\n```\n\nThe Projection Platform determines what can actually be populated for that tenant. The documented routing model explicitly states that connector installation determines whether corresponding columns become available. \n\n---\n\n# 26. HUMAN CONTEXT ASSEMBLY\n\nA Human Workbench request becomes:\n\n```text\nUser\n ↓\nRole\n ↓\nProjection\n ↓\nAuthorized Spine Context\n ↓\nPersonal Contextual Memory\n ↓\nCurrent Work\n ↓\nRelevant Knowledge\n ↓\nEvidence\n ↓\nUI\n```\n\nThe human therefore sees the relevant business context without manually stitching it together.\n\n---\n\n# 27. AI CONTEXT ASSEMBLY\n\nAI receives a related but distinct context:\n\n```text\nWork\n ↓\nAuthorized Business Context\n ↓\nRelevant Evidence\n ↓\nAI Continuity Memory\n ↓\nCurrent Objective\n ↓\nCapabilities\n ↓\nAuthority\n ↓\nAI Workbench\n ↓\nTwin / Agent\n```\n\nPersonal memory is only included when authorized.\n\nAI continuity is not silently converted into organizational memory.\n\n---\n\n# 28. HUMAN ↔ TWIN\n\nThe coordination flow is:\n\n```text\nHUMAN\n ↓\nWORK\n ↓\nTWIN\n ↓\nCONTEXT ASSEMBLY\n ↓\nREASON / PREPARE\n ↓\nPROPOSAL\n ↓\nHUMAN REVIEW\n```\n\nExamples:\n\n```text\n\"Prepare my renewal review.\"\n\n\"What changed with this customer?\"\n\n\"Draft the follow-up.\"\n\n\"What commitments are still open?\"\n\n\"Prepare the next action.\"\n```\n\nThe user interacts naturally; OODA remains the internal operating grammar rather than a mandatory four-button UI. \n\n---\n\n# 29. TWIN → SPINE AGENT\n\nThe Twin can delegate specialized work.\n\n```text\nTwin\n ↓\nWork\n ↓\nSubtask\n ↓\nSpine Agent\n ↓\nContext\n ↓\nCapability\n ↓\nResult\n ↓\nWork\n```\n\nThe handoff contains:\n\n```text\nIdentity\nWork ID\nContext\nObjective\nAuthority\nEvidence\nExpected output\nContinuity state\n```\n\nThe agent therefore does not start from an empty conversation.\n\n---\n\n# 30. CAPABILITY FABRIC\n\nThe AI determines:\n\n> **What needs to happen?**\n\nThe Capability Fabric determines:\n\n> **Which approved capability can perform it?**\n\n```text\nIntent\n ↓\nCapability Registry\n ↓\nAvailable Provider\n ↓\nRoute\n```\n\nPossible transports include:\n\n```text\nREST\nMCP\nA2A\nAPI\nWorkflow\nAgent\n```\n\nThe architecture retains capability-driven routing rather than making the model/provider the business abstraction. \n\n---\n\n# 31. GOVERNANCE\n\nBefore consequential action:\n\n```text\nIntent\n ↓\nCapability\n ↓\nAuthority\n ↓\nPolicy\n ↓\nRisk\n ↓\nDecision\n```\n\nPossible results:\n\n```text\nALLOW\nDENY\nREQUIRE APPROVAL\nBOUNDED DELEGATION\n```\n\nThe implementation's Governance service handles policy, `canExecute`, proposal approval/rejection, audit and HITL queues. \n\n---\n\n# 32. APPROVAL\n\nFor a consequential action:\n\n```text\nTwin / Agent\n ↓\nProposal\n ↓\nHITL Queue\n ↓\nHuman\n ↓\nApprove / Reject\n ↓\nApproval Token\n```\n\nThe human remains accountable for the decision.\n\nThe system does not treat model output as authority.\n\n---\n\n# 33. EXECUTION\n\nOnce approved:\n\n```text\nApproved Work\n ↓\nCapability\n ↓\nExecution Plan\n ↓\nHermes / Runtime\n ↓\nProvider\n```\n\nFor example:\n\n```text\n\"Update Salesforce opportunity.\"\n\n ↓\n\naccount.update / opportunity.update\n\n ↓\n\nGovernance\n\n ↓\n\nExecution\n\n ↓\n\nSalesforce\n```\n\n---\n\n# 34. SOURCE SYSTEM OUTCOME\n\nThe source system becomes the external operational reality.\n\n```text\nEXECUTION\n ↓\nSALESFORCE\n ↓\nProvider outcome\n```\n\nBut the system still does not immediately assume that its intended state equals actual state.\n\n---\n\n# 35. RE-INGESTION\n\nThe outcome comes back through the normal data path.\n\n```text\nProvider\n ↓\nWebhook / Poll / Delta\n ↓\nLoader\n ↓\nNormalizer\n ↓\nSpine Pipeline\n```\n\nThe system now has:\n\n```text\nRequested State\n+\nActual Provider State\n```\n\n---\n\n# 36. VERIFICATION\n\n```text\nRequested\n vs\nActual\n ↓\nVerification\n```\n\nExamples:\n\n```text\nExpected opportunity stage = Closed Won\nActual opportunity stage = Closed Won\n ↓\nVerified\n```\n\nor:\n\n```text\nExpected = Closed Won\nActual = Proposal\n ↓\nMismatch\n ↓\nReconciliation / Exception\n```\n\n---\n\n# 37. RECONCILIATION\n\nOnly after verification/reconciliation does the system update durable context.\n\n```text\nProvider Outcome\n ↓\nVerification\n ↓\nReconciliation\n ↓\nGoverned Spine Update\n ↓\nProjection Refresh\n ↓\nAI Context Refresh\n```\n\nThis is the continuity contract.\n\nThe Founder Canon requires the full outcome → re-ingestion → verification → reconciliation → Spine update → rehydration chain. \n\n---\n\n# 38. CONTINUITY LOOP\n\nThe complete operational loop is:\n\n```text\n ┌───────────────┐\n │ CONNECTED │\n │ SYSTEMS │\n └───────┬───────┘\n ↓\n INGESTION\n ↓\n NORMALIZE\n ↓\n TRIAGE\n ↓\n PROMOTE\n ↓\n SPINE\n ↓\n PROJECTION\n ↓\n ┌──────────┴──────────┐\n ↓ ↓\n HUMAN WB AI WB\n ↓ ↓\n HUMAN TWIN\n └──────────┬──────────┘\n ↓\n WORK\n ↓\n CAPABILITY\n ↓\n GOVERNANCE\n ↓\n APPROVAL\n ↓\n EXECUTION\n ↓\n SOURCE SYSTEM\n ↓\n OUTCOME\n ↓\n RE-INGEST\n ↓\n VERIFY\n ↓\n RECONCILIATION\n ↓\n SPINE\n ↓\n REHYDRATE\n ↓\n NEXT WORK\n```\n\nThis is the technical expression of:\n\n> **Loop = execution becomes knowledge.**\n\n---\n\n# 39. FRONTEND/BACKEND/SOURCE MAPPING\n\nThe complete relationship is:\n\n| Product layer | Technical responsibility |\n|---|---|\n| Sidebar | Navigation / route |\n| Domain Workbench | Projection |\n| Table | Structured projection view |\n| Widget | Projection/UI component |\n| Work | Durable coordination state |\n| Twin | AI contextual worker |\n| AI Workbench | AI operating environment |\n| Projection Registry | UI/context contract |\n| Projection Engine | Authorized composition |\n| Spine | Canonical business context |\n| Memory | Continuity by scope |\n| Knowledge | Document/semantic retrieval |\n| Capability Registry | What can be executed |\n| Governance | Whether execution is allowed |\n| Hermes/runtime | How approved execution occurs |\n| Connector | Provider access |\n| Loader | Provider ingestion |\n| Normalizer | Canonicalization |\n| Triage | Promotion boundary |\n| Reconciliation | Actual-vs-expected closure |\n\n---\n\n# 40. END-TO-END GTM + TECHNICAL FLOW\n\n```text\nMARKET\n │\n ├── Plugin Marketplace\n ├── MCP Marketplace\n └── Direct Workbench\n │\n ▼\nIDENTITY\n │\n ▼\nTENANT\n │\n ▼\nSPINEWORKSPACE\n │\n ├── Human Workbench\n └── AI Workbench\n │\n ▼\n CONNECTOR MARKETPLACE\n │\n ▼\n CONNECT / CONSENT\n │\n ▼\n DISCOVERY\n │\n ▼\n MAPPING / ACTIVATION\n │\n ▼\n INGESTION\n │\n ▼\n NORMALIZE / TRIAGE\n │\n ▼\n BUSINESS CONTEXT SPINE\n │\n ┌────────┼────────┐\n ▼ ▼ ▼\n ORG MEM PERSONAL AI CONTINUITY\n │ │ │\n └────────┼────────┘\n ▼\n KNOWLEDGE / EVIDENCE\n │\n ▼\n PROJECTION REGISTRY\n │\n ▼\n PROJECTION ENGINE\n │\n ┌───────┴────────┐\n ▼ ▼\n HUMAN WB AI WB\n │ │\n │ TWIN\n │ │\n └───────┬────────┘\n ▼\n WORK\n │\n ▼\n SPINE AGENTS\n │\n ▼\n CAPABILITY FABRIC\n │\n ▼\n GOVERNANCE\n │\n ┌─────┴─────┐\n ▼ ▼\n ALLOW APPROVAL\n │ │\n └─────┬─────┘\n ▼\n HERMES\n │\n ▼\n SOURCE SYSTEMS\n │\n ▼\n OUTCOME\n │\n ▼\n RE-INGESTION\n │\n ▼\n VERIFICATION\n │\n ▼\n RECONCILIATION\n │\n ▼\n VERIFIED SPINE\n │\n ┌───────┴────────┐\n ▼ ▼\n HUMAN REHYDRATION AI REHYDRATION\n │ │\n └───────┬────────┘\n ▼\n NEXT WORK\n │\n ▼\n RECURRING VALUE\n │\n ▼\n MORE CONNECTORS\n │\n ▼\n EXPANSION\n```\n\n---\n\n# 41. GO-LIVE ARCHITECTURE\n\nGTM and production release are related but distinct.\n\n### GTM\n\n```text\nMarket\n ↓\nEntry\n ↓\nActivation\n ↓\nCustomer Value\n ↓\nExpansion\n```\n\n### Product Go-Live\n\n```text\nDevelopment\n ↓\nCustomer Zero\n ↓\nEvidence\n ↓\nVersion Freeze\n ↓\nClean Tenant\n ↓\nSubmission\n ↓\nPublication\n```\n\nThe frozen architecture defines go-live as a one-way promotion of the same verified artifacts from Development → Customer Zero → Customer Production. \n\n---\n\n# 42. CUSTOMER ZERO\n\nCustomer Zero proves the complete system with real operational usage.\n\nIt must exercise:\n\n```text\nIdentity\nTenant\nConnector\nHydration\nSpine\nProjection\nHuman Workbench\nAI Workbench\nTwin\nSpine Agents\nCapabilities\nGovernance\nApproval\nExecution\nRe-ingestion\nVerification\nReconciliation\nAudit\nContinuity\n```\n\nThe acceptance contract requires proving the complete loop rather than merely proving that individual services respond. \n\n---\n\n# 43. EXTERNAL TENANT VALIDATION\n\nAfter Customer Zero:\n\n```text\nCUSTOMER ZERO\n ↓\nEvidence\n ↓\nVersion Freeze\n ↓\nCLEAN TENANT\n ↓\nFresh Identity\n ↓\nFresh Connections\n ↓\nFresh Hydration\n ↓\nFresh Projections\n ↓\nFresh AI Context\n```\n\nThis proves that the product is genuinely tenant-aware rather than accidentally dependent on Customer Zero state.\n\n---\n\n# 44. MARKETPLACE PUBLICATION\n\nAfter the clean-tenant gates:\n\n```text\nIW-SPINE-NETWORK PLUGIN\n ↓\nPlugin Marketplace\n```\n\nand:\n\n```text\nIW-SPINE-NETWORK MCP\n ↓\nMCP Marketplace\n```\n\nThese are distribution artifacts.\n\nThey expose the same underlying platform contracts rather than separate business-data systems.\n\nThe documented model distinguishes the Plugin and MCP artifacts and their marketplace roles. \n\n---\n\n# 45. GO-LIVE STOP-SHIP CONDITIONS\n\nProduction should not proceed if any critical chain is unproven:\n\n```text\nNo tenant isolation\n → STOP\n\nNo real connector hydration\n → STOP\n\nNo valid projection\n → STOP\n\nAI has no authorized context\n → STOP\n\nAI can execute without governance\n → STOP\n\nExecution cannot be verified\n → STOP\n\nOutcome cannot reconcile\n → STOP\n\nAudit/evidence chain incomplete\n → STOP\n\nCustomer Zero only works with special state\n → STOP\n\nClean tenant fails\n → STOP\n```\n\nThe canonical acceptance tests specifically require authentication, hydration, projections, memory boundaries, AI context, evidence, agent handoff, capability resolution, governance, execution, reconciliation, rehydration and traceability. \n\n---\n\n# 46. THE FINAL TECHNICAL CONTRACT\n\nThe entire SpineWorkspace system can be reduced to these layers:\n\n```text\nL0 — MARKET / DISTRIBUTION\nPlugin\nMCP\nDirect\n\nL1 — WORKSPACE\nIdentity\nTenant\nHuman Workbench\nAI Workbench\nDomain Workbenches\n\nL2 — CONTEXT\nBusiness Context Spine\nOrganizational Memory\nPersonal Contextual Memory\nAI Continuity Memory\nKnowledge\nEvidence\n\nL3 — PROJECTION\nEntity Registry\nProjection Registry\nProjection Engine\nViews\nWidgets\nContext Assembly\n\nL4 — WORK\nHuman\nTwin\nSpine Agents\nWork\nHandoffs\nContinuity\n\nL5 — CAPABILITY / CONTROL\nCapability Registry\nRouting\nGovernance\nApproval\n\nL6 — EXECUTION\nHermes / Runtime\nMCP\nA2A\nREST\nProvider\n\nL7 — REALITY\nConnected Source Systems\nProvider Outcome\n\nL8 — CLOSURE\nRe-ingestion\nVerification\nReconciliation\nSpine Update\nProjection Refresh\nAI Refresh\n\nL9 — GO-TO-MARKET LOOP\nGrounded Value\nApproved Outcome\nRecurring Work\nConnector Expansion\nCustomer Expansion\n```\n\n---\n\n# 47. THE SINGLE SYSTEM VIEW\n\n```text\n GTM\n │\n Plugin / MCP / Direct Entry\n │\n ▼\n SPINEWORKSPACE\n │\n ┌──────────────┴──────────────┐\n │ │\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n Domain Workbenches Twin\n │ Spine Agents\n └──────────────┬──────────────┘\n │\n WORK\n │\n ┌─────────┴─────────┐\n │ │\n BUSINESS CONTINUITY\n CONTEXT MEMORY\n │ │\n └─────────┬─────────┘\n │\n PROJECTION\n │\n CAPABILITY\n │\n GOVERNANCE\n │\n EXECUTION\n │\n CONNECTORS\n │\n SOURCE SYSTEMS\n │\n OUTCOME\n │\n RE-INGESTION\n │\n VERIFY\n │\n RECONCILE\n │\n SPINE\n │\n REHYDRATION\n │\n WORK\n │\n VALUE\n │\n EXPANSION\n```\n\n## Final technical definition\n\n> **SpineWorkspace is the product surface. The Human Workbench and AI Workbench are its two first-class operating environments. Domain Workbenches are projections of the same Business Context Spine. The Projection Registry defines those projections and the Projection Engine composes them from authorized tenant context, role, permissions, connector availability, memory, evidence and Work. Connectors discover and ingest external systems through the governed ingestion pipeline, normalize provider data into canonical Spine context, and continuously rehydrate that context. Humans, Twin and Spine Agents work through durable Work identities. Capabilities resolve provider-neutral intent into governed execution through MCP, A2A, REST or other approved transports. Execution outcomes return through re-ingestion, verification and reconciliation before becoming verified Spine state, which then refreshes both human and AI work environments. GTM brings the customer into the workspace through Plugin, MCP or direct entry; Connector Marketplace expands the connected context; Customer Zero proves the full loop; and the same verified artifacts are promoted through clean-tenant validation into production.**\n\nThis preserves the central architectural boundary:\n\n> **Shared organizational context. Separate human and AI continuity. Governed promotion. Durable Work. Verified execution. Continuous rehydration.**"}