{"slug":"canonical/FOUNDER-FINAL-ARCHITECTURE-2026-09-04","title":"Founder Final Architecture","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/FOUNDER-FINAL-ARCHITECTURE-2026-09-04.md","bytes":27427,"description":"Definitive architectural lock, plane layer hierarchy, and component ownership.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n\n**Canonical product:** SpineWorkspace\n**Platform:** IntegrateWise\n**Core substrate:** Spine Fabric\n**Operating doctrine:** **Humans govern. AI helps. Spine preserves continuity.**\n\nThis is the consolidated end state supported by the Founder Canon and the current Spine architecture records. The Founder Canon establishes SpineWorkspace as the product, IntegrateWise as the infrastructure platform, and the shared Business Context Spine as the organizational context over which the Human and AI Workbenches operate. \n\n---\n\n## 1. Final Product 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 human and AI continuity.**\n\n```text\n                         INTEGRATEWISE\n                       Infrastructure Platform\n                                │\n                                ▼\n                         SPINEWORKSPACE\n                       Customer Work Environment\n                                │\n                 ┌──────────────┴──────────────┐\n                 │                             │\n                 ▼                             ▼\n          HUMAN WORKBENCH                AI WORKBENCH\n                 │                             │\n                 └──────────────┬──────────────┘\n                                │\n                         SHARED BUSINESS\n                            CONTEXT\n                                │\n                                ▼\n                           SPINE FABRIC\n                                │\n             ┌──────────────────┼──────────────────┐\n             │                  │                  │\n             ▼                  ▼                  ▼\n       ORGANIZATIONAL      PERSONAL           AI CONTINUITY\n          MEMORY           MEMORY              MEMORY\n```\n\nThe important distinction is:\n\n* **Spine Fabric** is not another application.\n* **Human Workbench** is not another truth store.\n* **AI Workbench** is not another business system.\n* **Twin** is not the organizational source of truth.\n* **MCP** is not the Spine.\n* **Agents** are not the Spine.\n* **Connectors** do not define the canonical business model by themselves.\n\nThe Spine is the governed contextual substrate from which work is assembled and into which verified organizational state returns.\n\n---\n\n# 2. The Complete System Loop\n\nThe complete operating model is:\n\n```text\nGTM / CUSTOMER\n      │\n      ▼\nCONNECTORS\n      │\n      ▼\nSOURCE SYSTEMS\n      │\n      ▼\nINGESTION\n      │\n      ▼\nNORMALIZATION\n      │\n      ▼\nTRIAGE\n      │\n      ├──────────────► KNOWN SCHEMA\n      │\n      └──────────────► PROMOTION QUEUE\n                              │\n                              ▼\n                       HUMAN / GOVERNED REVIEW\n                              │\n                              ▼\n                       SCHEMA PROMOTION\n                              │\n                              ▼\n                        SPINE FABRIC\n                              │\n             ┌────────────────┼────────────────┐\n             ▼                ▼                ▼\n       ORGANIZATIONAL    ROLE PROJECTION    CONTINUITY\n          CONTEXT\n             │                │\n             └────────────────┘\n                      │\n                      ▼\n                HUMAN WORKBENCH\n                      │\n                      ▼\n              CONTEXT ASSEMBLY\n                      │\n              ┌───────┴────────┐\n              ▼                ▼\n            HUMAN             TWIN\n                               │\n                               ▼\n                         AI WORKBENCH\n                               │\n                         ┌─────┴─────┐\n                         ▼           ▼\n                       WORK       CAPABILITY\n                                     │\n                          ┌──────────┼──────────┐\n                          ▼          ▼          ▼\n                         MCP        REST       A2A\n                          │          │          │\n                          └──────────┼──────────┘\n                                     ▼\n                                GOVERNANCE\n                                     │\n                                     ▼\n                                  EXECUTE\n                                     │\n                                     ▼\n                              SOURCE SYSTEMS\n                                     │\n                                     ▼\n                                  OUTCOME\n                                     │\n                                     ▼\n                               RE-INGESTION\n                                     │\n                          ┌──────────┴──────────┐\n                          ▼                     ▼\n                       VERIFY                RECONCILE\n                          │                     │\n                          └──────────┬──────────┘\n                                     ▼\n                               UPDATE SPINE\n                                     │\n                                     ▼\n                              REFRESH PROJECTION\n                                     │\n                                     ▼\n                                  NEXT WORK\n```\n\nThe architecture records explicitly describe this closed loop from connector ingestion through Spine, projection, Work, capability execution, source-system outcome, re-ingestion, verification and reconciliation. \n\n---\n\n# 3. Spine Fabric: What It Actually Contains\n\nThe Spine Fabric is the **shared organizational context and continuity substrate**.\n\nIt needs to represent enough of the business that people and AI can perform real work without rebuilding context from individual applications every time.\n\nAt the conceptual level:\n\n```text\nSPINE FABRIC\n│\n├── Tenant / Organization\n├── People\n├── Roles\n├── Teams\n├── Departments\n├── Business Domains\n├── Customers / Accounts\n├── Contacts\n├── Leads / Opportunities\n├── Products / Services\n├── Projects\n├── Contracts\n├── Orders\n├── Invoices\n├── Assets\n├── Cases / Tickets\n├── Communications\n├── Meetings / Calendar Events\n├── Documents\n├── Knowledge\n├── Decisions\n├── Tasks\n├── Work\n├── Goals\n├── KPIs\n├── Events\n├── Activities\n├── Relationships\n├── Evidence\n├── Source References\n├── Provenance / Lineage\n├── Capabilities\n├── Policies\n├── Approvals\n├── Execution State\n└── Continuity State\n```\n\nThe exact domain objects are hydrated according to the tenant's connected systems and business needs rather than requiring every organization to instantiate every possible object.\n\nThe current tenant-schema material establishes the principle that the tenant Spine contains **business entities, object fields, roles and goals**, with connectors hydrating the schema and role-based projections determining what users can access. \n\n---\n\n# 4. The Missing Logical Layer: Connector → Mapping → Spine\n\nThis is the key architectural relationship.\n\nA connector does **not** simply dump source records into Spine.\n\nThe actual path is:\n\n```text\nSOURCE OBJECT\n     │\n     ▼\nCONNECTOR RESOURCE\n     │\n     ▼\nUNIVERSAL CONNECTOR OBJECT\n     │\n     ▼\nSOURCE → SPINE MAPPING\n     │\n     ├── Entity mapping\n     ├── Field mapping\n     ├── Relationship mapping\n     ├── Identity mapping\n     ├── Semantic transformation\n     ├── Type conversion\n     ├── Status/value mapping\n     └── Provenance mapping\n     │\n     ▼\nCANONICAL SPINE OBJECT\n     │\n     ▼\nSPINE RECORD\n```\n\nTherefore every connector needs a **mapping contract**.\n\nFor example:\n\n```text\nSalesforce.Account\n        │\n        ├── Id              → Customer.source_id\n        ├── Name            → Customer.name\n        ├── OwnerId         → Customer.owner_id\n        ├── Industry        → Customer.industry\n        ├── Type            → Customer.lifecycle_type\n        └── ParentId        → Customer.parent_customer_id\n```\n\nAnother connector may represent the same business concept differently:\n\n```text\nHubSpot.Company\n        │\n        ├── companyId       → Customer.source_id\n        ├── name            → Customer.name\n        ├── owner           → Customer.owner_id\n        └── lifecycleStage  → Customer.lifecycle_type\n```\n\nThe Spine therefore has:\n\n> **One canonical business model, many connector representations.**\n\nThis is what prevents every new connector from creating another incompatible internal data model.\n\n---\n\n# 5. Connector Schema Hydration\n\nConnector ingestion follows a controlled pipeline.\n\n```text\nConnector\n   │\n   ▼\nDiscover\n   │\n   ▼\nRead resource/object metadata\n   │\n   ▼\nMap to universal connector model\n   │\n   ▼\nCompare against Spine schema\n   │\n   ├── Known entity\n   ├── Known field\n   ├── Known relationship\n   ├── Known identity\n   │\n   └── Unknown / changed\n            │\n            ▼\n          TRIAGE\n            │\n      ┌─────┴─────┐\n      ▼           ▼\n   Safe          Review\n   mapping       required\n      │           │\n      │           ▼\n      │     Promotion Queue\n      │           │\n      │           ▼\n      │       Approval\n      │           │\n      └─────┬─────┘\n            ▼\n       Spine Schema\n            │\n            ▼\n       Canonical Data\n```\n\nThe existing architecture specifically defines the **promotion queue** for unknown objects or fields and uses approved promotion to extend the tenant schema while maintaining continuity. \n\nThis means schema evolution is itself part of Spine continuity.\n\n---\n\n# 6. Source Truth vs Spine Truth\n\nThe system must distinguish:\n\n### Source systems\n\nThey remain authoritative for their own operational transactions.\n\nExamples:\n\n```text\nCRM       → customer/account transaction state\nERP       → financial transaction state\nTicketing → case state\nHRIS      → employee state\nGit       → source-code state\n```\n\n### Spine\n\nSpine becomes the **governed cross-system business context**.\n\nIt provides:\n\n* canonical representation;\n* relationships across systems;\n* organizational context;\n* evidence;\n* lineage;\n* history;\n* work state;\n* continuity;\n* projections;\n* context for humans and AI.\n\nTherefore:\n\n> **Spine does not replace every source system. It connects their meaning into a governed business context.**\n\n---\n\n# 7. Organizational Memory\n\nOrganizational Memory is the durable organizational knowledge that has crossed the appropriate governance boundary.\n\n```text\nSOURCE DATA\n    │\n    ▼\nINGESTION\n    │\n    ▼\nTRIAGE\n    │\n    ▼\nEVIDENCE\n    │\n    ▼\nCANONICAL SPINE\n    │\n    ▼\nORGANIZATIONAL MEMORY\n```\n\nIt can contain:\n\n* business facts;\n* decisions;\n* relationships;\n* historical state;\n* approved knowledge;\n* evidence;\n* operational patterns;\n* completed Work;\n* verified outcomes.\n\nThe Founder Canon distinguishes Business Context / Organizational Memory from Personal Contextual Memory and AI Continuity Memory. \n\n---\n\n# 8. Three Memory Boundaries\n\nThe final architecture must preserve these boundaries:\n\n| Memory                         | Owner                 | Purpose                                | Canonical business truth? |\n| ------------------------------ | --------------------- | -------------------------------------- | ------------------------- |\n| **Organizational Memory**      | Tenant / organization | Shared business context and continuity | **Yes**                   |\n| **Personal Contextual Memory** | User                  | Individual working context             | **No**                    |\n| **AI Continuity Memory**       | Twin / AI             | AI working continuity                  | **No**                    |\n\n```text\n                  SPINE\n                   │\n       ┌───────────┴───────────┐\n       │                       │\n ORGANIZATIONAL           PROJECTION\n    MEMORY                    │\n                               │\n                    ┌──────────┴──────────┐\n                    ▼                     ▼\n               HUMAN MEMORY         AI CONTINUITY\n```\n\nPersonal and AI memory may influence context assembly, but neither silently becomes organizational truth.\n\n---\n\n# 9. Role-Based Projection\n\nThe Spine is not exposed directly to every user.\n\nInstead:\n\n```text\nSPINE\n  │\n  ▼\nAUTHORITY\n  │\n  ▼\nROLE\n  │\n  ▼\nPOLICY\n  │\n  ▼\nPROJECTION REGISTRY\n  │\n  ▼\nROLE-SPECIFIC PROJECTION\n  │\n  ▼\nUSER WORKBENCH\n```\n\nA projection defines:\n\n* permitted entities;\n* permitted fields;\n* permitted relationships;\n* row-level access;\n* actions;\n* visibility;\n* KPI visibility;\n* Work visibility;\n* evidence visibility;\n* sensitive-field masking;\n* capability availability.\n\nThis is how the same organizational Spine can serve:\n\n```text\nCEO\nSales\nFinance\nSupport\nHR\nEngineering\nOperations\nMarketing\nAdmin\nAI\n```\n\nwithout creating separate truth stores.\n\n---\n\n# 10. Human Workbench\n\nThe Human Workbench is the primary human operating surface.\n\nThe user sees the **work**, not the infrastructure.\n\nThe canonical frontend structure established in the project material is:\n\n```text\nBUSINESS CONTEXT\n      │\n      ▼\nPROJECTION\n      │\n      ▼\nHUMAN WORKBENCH\n      │\n      ├── Today\n      ├── Communications\n      ├── Organization Memory\n      └── Work\n            ├── Domain\n            ├── KPI\n            ├── Entity\n            ├── Work\n            ├── Decisions\n            └── Operations\n```\n\n\n\n---\n\n# 11. AI Workbench\n\nThe AI Workbench is the operating environment for the user's Twin and AI agents.\n\n```text\nTWIN WORKBENCH\n│\n├── Context\n├── Active Work\n├── Plan\n├── Agents\n├── Tools\n├── Execution\n└── Results\n```\n\n\n\nThe AI Workbench receives **assembled context**, rather than unrestricted access to the entire tenant database.\n\n---\n\n# 12. Context Assembly\n\nThis is the bridge between the two Workbenches.\n\n```text\n                         SPINE\n                           │\n               ┌───────────┼───────────┐\n               ▼           ▼           ▼\n             ROLE        WORK         KPI\n           CONTEXT      CONTEXT      CONTEXT\n               │           │           │\n               └───────────┼───────────┘\n                           ▼\n                    CONTEXT ASSEMBLER\n                           │\n              ┌────────────┴────────────┐\n              ▼                         ▼\n       HUMAN WORKBENCH             AI WORKBENCH\n              │                         │\n              ▼                         ▼\n            USER                       TWIN\n```\n\nThe result is:\n\n> **Human and AI work from the same governed business context, but receive different projections appropriate to their role and operating environment.**\n\n---\n\n# 13. Twin, Coworker and Agents\n\nThe architecture should keep these concepts distinct.\n\n### Twin\n\nThe user's primary AI work partner.\n\n### Coworker\n\nThe contextual companion that helps assemble active context and communication.\n\n### Spine Agents\n\nSpecialized agents that perform bounded work through approved capabilities.\n\n```text\n                         TWIN\n                          │\n                 ┌────────┼────────┐\n                 ▼        ▼        ▼\n             Context    Plan     Work\n                          │\n                          ▼\n                     SPINE AGENTS\n                          │\n                          ▼\n                  CAPABILITY FABRIC\n```\n\nThe Twin is not itself another organizational authority.\n\n---\n\n# 14. Work Is the Coordination Primitive\n\nThe key unit shared by humans and AI is **Work**.\n\n```text\nGOAL\n  │\n  ▼\nWORK\n  │\n  ├── Human\n  ├── Twin\n  ├── Agent\n  ├── Context\n  ├── Plan\n  ├── Evidence\n  ├── Approval\n  ├── Capability\n  ├── Execution\n  ├── Outcome\n  └── Continuity\n```\n\nA Work record should therefore carry enough state to answer:\n\n* What business goal does this support?\n* Who owns it?\n* What entity/domain does it concern?\n* What is the current state?\n* What context was used?\n* What decision was made?\n* What AI participated?\n* What capabilities were invoked?\n* What approvals were required?\n* What actually executed?\n* What was the source-system result?\n* What evidence proves the outcome?\n* What remains unresolved?\n\nThis makes Work the durable bridge between human activity and AI activity.\n\n---\n\n# 15. Goals and KPIs\n\nGoals are not simply dashboard labels.\n\nThey are the business objectives against which Work is organized.\n\n```text\nBUSINESS GOAL\n     │\n     ├── Owner\n     ├── Scope\n     ├── Time horizon\n     ├── Status\n     ├── Priority\n     ├── Target\n     ├── Baseline\n     ├── Current value\n     ├── Variance\n     └── KPIs\n             │\n             ├── Definition\n             ├── Source\n             ├── Formula\n             ├── Current value\n             ├── Target\n             ├── Trend\n             └── Evidence\n```\n\nThe tenant schema already establishes **goals and KPIs** as first-class parts of the business context model. \n\n---\n\n# 16. Capability Fabric\n\nThe Spine determines **context and authority**.\n\nThe Capability Fabric determines **what can be done**.\n\n```text\nSPINE\n │\n ├── Context\n ├── Policy\n ├── Work\n └── Authority\n        │\n        ▼\nCAPABILITY FABRIC\n        │\n        ├── MCP\n        ├── REST\n        ├── Connector\n        ├── Workflow\n        ├── Tool\n        └── Agent capability\n```\n\nThe architecture explicitly separates Spine continuity/state from runtime components that consume and mutate that state through governed interfaces. \n\n---\n\n# 17. Tool Categories\n\nCapabilities should be represented by what they can accomplish, not merely by vendor names.\n\n```text\nCAPABILITY\n│\n├── Read\n│   ├── Search\n│   ├── Retrieve\n│   ├── Query\n│   └── Inspect\n│\n├── Create\n│   ├── Record\n│   ├── Document\n│   ├── Task\n│   └── Work\n│\n├── Update\n│   ├── Record\n│   ├── Status\n│   └── Relationship\n│\n├── Communicate\n│   ├── Email\n│   ├── Message\n│   └── Notification\n│\n├── Coordinate\n│   ├── Calendar\n│   ├── Assignment\n│   └── Handoff\n│\n├── Execute\n│   ├── Workflow\n│   ├── Transaction\n│   └── Automation\n│\n└── Analyze\n    ├── KPI\n    ├── Forecast\n    ├── Compare\n    └── Diagnose\n```\n\nThe important abstraction is:\n\n> **Capability = what the system is allowed and able to do. Execution = how that capability is performed.**\n\n---\n\n# 18. MCP, REST and A2A\n\nThese are communication mechanisms, not competing sources of truth.\n\n| Mechanism     | Role                                  |\n| ------------- | ------------------------------------- |\n| **MCP**       | AI ↔ tools/resources                  |\n| **REST**      | System/service ↔ system/service       |\n| **A2A**       | Agent ↔ agent/Twin contextual handoff |\n| **Connector** | External application ↔ IntegrateWise  |\n| **Spine**     | Shared governed business context      |\n\nThe architecture explicitly positions MCP Pool as capability resolution rather than context ownership. \n\n---\n\n# 19. Governance\n\nNo capability should execute merely because an agent can discover it.\n\n```text\nWORK\n │\n ▼\nINTENT\n │\n ▼\nCAPABILITY RESOLUTION\n │\n ▼\nPOLICY CHECK\n │\n ▼\nRISK / APPROVAL CHECK\n │\n ├── No approval required ───────┐\n │                               │\n └── Approval required           │\n          │                      │\n          ▼                      │\n       HUMAN                     │\n       APPROVAL                  │\n          │                      │\n          └──────────┬───────────┘\n                     ▼\n                 EXECUTION\n```\n\nThe project material explicitly requires approval metadata, policy enforcement, immutable execution plans after approval and auditability. \n\n---\n\n# 20. Execution and Write-Back\n\nThe AI does not directly mutate Spine or source systems.\n\n```text\nTWIN / AGENT\n     │\n     ▼\nPROPOSE\n     │\n     ▼\nPLAN\n     │\n     ▼\nGOVERN\n     │\n     ▼\nAPPROVE\n     │\n     ▼\nCAPABILITY\n     │\n     ▼\nEXECUTE\n     │\n     ▼\nSOURCE SYSTEM\n     │\n     ▼\nOUTCOME\n```\n\nThe existing acceptance material explicitly prohibits Twin from directly writing to Spine and requires governed capability execution. \n\n---\n\n# 21. Reconciliation\n\nExecution is not completion.\n\nCompletion occurs only after the external result is verified.\n\n```text\nINTENDED ACTION\n      │\n      ▼\nEXECUTION\n      │\n      ▼\nSOURCE OUTCOME\n      │\n      ▼\nRE-INGEST\n      │\n      ▼\nVERIFY\n      │\n      ▼\nRECONCILE\n      │\n      ├── Match\n      │     │\n      │     ▼\n      │   COMPLETE\n      │\n      └── Mismatch\n            │\n            ▼\n        OPEN ISSUE\n```\n\nThe source material explicitly requires the external outcome to be verified, re-ingested, reconciled and reflected back into Spine before completion is treated as true. \n\n---\n\n# 22. Continuity\n\nContinuity is the mechanism that prevents the organization from repeatedly reconstructing its state.\n\n```text\nSOURCE\n  ↓\nINGEST\n  ↓\nSPINE\n  ↓\nPROJECTION\n  ↓\nWORK\n  ↓\nEXECUTION\n  ↓\nOUTCOME\n  ↓\nRE-INGEST\n  ↓\nVERIFY\n  ↓\nRECONCILE\n  ↓\nSPINE\n  ↓\nNEW PROJECTION\n  ↓\nNEXT WORK\n```\n\nThat loop is the core reason Spine exists.\n\n---\n\n# 23. The Complete Data Model Relationship\n\nThe architecture can therefore be reduced to:\n\n```text\nTENANT\n │\n ├── PEOPLE\n │     └── ROLES\n │\n ├── DOMAINS\n │     └── ENTITIES\n │           └── OBJECTS\n │                 └── FIELDS\n │\n ├── GOALS\n │     └── KPIs\n │\n ├── WORK\n │     ├── Context\n │     ├── Decision\n │     ├── Evidence\n │     ├── Capability\n │     ├── Approval\n │     ├── Execution\n │     └── Outcome\n │\n ├── MEMORY\n │     ├── Organizational\n │     ├── Personal\n │     └── AI Continuity\n │\n ├── CONNECTORS\n │     └── MAPPINGS\n │\n ├── CAPABILITIES\n │     └── EXECUTORS\n │\n └── PROJECTIONS\n       └── ROLE / POLICY / USER\n```\n\n---\n\n# 24. The Architectural Boundary\n\nThe cleanest formulation is:\n\n> **Connectors bring external reality into the system. Mapping translates that reality into the canonical Spine model. Triage governs schema evolution. Spine preserves organizational context and continuity. Projection determines what each participant can see. Work coordinates human and AI activity. Capability Fabric determines what can be done. Governance determines whether it may be done. Execution changes external reality. Reconciliation establishes what actually happened.**\n\nThat is the missing logical chain between **connector → schema → Spine → projection → Work → capability → source → Spine**.\n\n---\n\n# 25. Final SpineWorkspace Contract\n\n```text\n                    ONE WORKSPACE\n                         │\n          ┌──────────────┴──────────────┐\n          │                             │\n       HUMAN                           AI\n     WORKBENCH                    AI WORKBENCH\n          │                             │\n          └──────────────┬──────────────┘\n                         │\n                    SHARED WORK\n                         │\n                         ▼\n                  ONE SPINE FABRIC\n                         │\n       ┌─────────────────┼─────────────────┐\n       │                 │                 │\n       ▼                 ▼                 ▼\n ORGANIZATIONAL      PROJECTION       CONTINUITY\n   CONTEXT\n       │\n       ▼\n  CAPABILITY FABRIC\n       │\n       ▼\n   GOVERNANCE\n       │\n       ▼\n    EXECUTION\n       │\n       ▼\n SOURCE SYSTEMS\n       │\n       ▼\n     OUTCOME\n       │\n       ▼\n RE-INGEST / VERIFY / RECONCILE\n       │\n       ▼\n      SPINE\n```\n\n## Final system statement\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. IntegrateWise connects the organization's software ecosystem, translates external system data into a canonical business context, governs schema evolution, projects the appropriate context to each participant, enables humans and AI to coordinate through durable Work and approved capabilities, and continuously verifies and reconciles execution back into the Spine.**\n\nAnd the final architectural doctrine remains:\n\n> **The Workbench is one. The Spine is one. The Projection is many.**\n\n> **Humans govern. AI helps. Spine preserves continuity.**\n\nThis keeps the product, data model, connector architecture, human/AI interaction model, capability system, governance and continuity loop as **one coherent system rather than a collection of separately evolving subsystems**. The Founder Canon explicitly frames SpineWorkspace around the shared Business Context Spine, Human Workbench, AI Workbench and distinct continuity scopes. \n"}