{"slug":"canonical/FOUNDER-FINAL-GOAL-2026-09-04","title":"Founder Final Goal","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/FOUNDER-FINAL-GOAL-2026-09-04.md","bytes":26094,"description":"The ultimate product and business destination for IntegrateWise and SpineWorkspace.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n\n## 1. Final goal\n\n> **SpineWorkspace is the shared business workspace where humans and AI work toward the same business goals using the same governed organizational context, while each retains its own continuity, permissions, responsibilities and working environment.**\n\nThe foundational product relationship is:\n\n```text\nINTEGRATEWISE\nInfrastructure / Platform\n        │\n        ▼\nSPINEWORKSPACE\nShared Business Workspace\n        │\n        ├───────────────────────┐\n        ▼                       ▼\nHUMAN WORKBENCH           AI WORKBENCH\n        │                       │\n        │                    TWIN / AGENTS\n        │                       │\n        └───────────┬───────────┘\n                    ▼\n              SHARED WORK\n                    │\n                    ▼\n          BUSINESS CONTEXT SPINE\n                    │\n       ┌────────────┼────────────┐\n       ▼            ▼            ▼\n ORGANIZATIONAL   PERSONAL     AI CONTINUITY\n   MEMORY         MEMORY         MEMORY\n```\n\nThe Founder Canon establishes the governing principle:\n\n> **Humans govern. AI helps. Spine preserves continuity.** \n\nThe architectural rule is:\n\n> **The Workbench is one. The Spine is one. The Projection is many.**\n\nThe core Spine remains stable; projections vary according to role, industry, department, connector availability, active context and policy. \n\n---\n\n# 2. What the Spine actually is\n\nThe **Spine Fabric** is the tenant-scoped organizational context and continuity substrate.\n\nIt is not:\n\n* the CRM\n* the ERP\n* the AI model\n* MCP\n* an agent runtime\n* a UI\n* a connector\n* a second source system\n\nIt is the **governed representation of the organization's operational context**, with provenance, relationships, work state, evidence, continuity and capabilities.\n\nFor Customer Zero, the Spine can represent:\n\n```text\nOrganization\n├── People\n├── Teams\n├── Roles\n├── Customers / Accounts\n├── Contacts\n├── Products\n├── Projects\n├── Initiatives\n├── Deals\n├── Contracts\n├── Orders\n├── Tickets\n├── Incidents\n├── Tasks\n├── Work\n├── Goals\n├── KPIs / Metrics\n├── Risks\n├── Signals\n├── Decisions\n├── Approvals\n├── Policies\n├── Communications\n├── Documents\n├── Knowledge\n├── Evidence\n├── Events\n├── Activities\n├── Connectors\n├── Capabilities\n├── Agents / Twins\n├── Conversations\n├── Handoffs\n├── Continuity checkpoints\n└── Execution / reconciliation state\n```\n\nThis is consistent with the existing tenant model, which defines Organization, User/Actor, DigitalTwin, Goal, WorkItem, Task, Decision/Approval, Proposal/Plan, Evidence, KPI/Metric, Policy/Rule, Capability/Tool and AuditLog as major shared-context objects. \n\n---\n\n# 3. The critical logical layer: connector → mapping → Spine\n\nThis is the part that must not remain implicit.\n\nA connector does **not** simply dump provider records into Spine.\n\nThe actual flow is:\n\n```text\nCONNECTED SYSTEM\n      │\n      ▼\nCONNECTOR\n      │\n      ├── Authentication\n      ├── Schema discovery\n      ├── Capability discovery\n      ├── Source object discovery\n      └── Source events / records\n      │\n      ▼\nINGESTION\n      │\n      ▼\nCANONICAL MAPPER\n      │\n      ├── Source object → Spine entity\n      ├── Source field  → Spine field\n      ├── Source ID     → canonical reference\n      ├── Relationships → Spine relationships\n      └── Transformations\n      │\n      ▼\nVALIDATION / TRIAGE\n      │\n      ├── Valid known mapping\n      ├── Duplicate / conflict\n      ├── Unknown field\n      ├── Unknown object\n      ├── Unknown relationship\n      └── Candidate schema extension\n      │\n      ▼\nPROMOTION QUEUE\n      │\n      ├── Auto-promotable\n      └── Human review\n      │\n      ▼\nGOVERNED SPINE WRITE\n      │\n      ▼\nSPINE FABRIC\n      │\n      ├── Canonical state\n      ├── Source provenance\n      ├── Evidence\n      ├── Events\n      └── Continuity\n      │\n      ▼\nPROJECTION ENGINE\n      │\n      ▼\nUSER / TWIN / AGENT CONTEXT\n```\n\nThe existing architecture explicitly separates canonical mapping, validation, the Spine Write Bus and Projection Engine. Connectors and Twin do not directly mutate canonical storage. \n\n---\n\n# 4. Connector schema hydration\n\nThe Spine is **adaptive**, but not uncontrolled.\n\nWhen a connector is installed:\n\n```text\nConnector\n   ↓\nCategory\n   ↓\nSchema Module\n   ↓\nSource entities / fields\n   ↓\nCanonical mappings\n   ↓\nValidation\n   ↓\nPromotion if necessary\n   ↓\nSpine schema hydration\n   ↓\nProjection availability\n```\n\nFor example:\n\n```text\nSalesforce Account\n        │\n        ├── Name\n        ├── Industry\n        ├── Owner\n        ├── ARR\n        └── Renewal Date\n                │\n                ▼\n        Canonical Account\n                │\n        ├── account.name\n        ├── account.industry\n        ├── account.owner\n        ├── account.arr\n        └── account.renewal_date\n```\n\nLikewise:\n\n```text\nHubSpot Company ────────┐\nDynamics Account ───────┼──► Canonical Account\nSalesforce Account ─────┘\n```\n\nThe universal schema already defines source-to-Spine mapping fields such as `destination_field`, transformation rules, required status, AI suggestion state, confidence and approval. \n\n---\n\n# 5. Four primary ingestion flows\n\nThe canonical material distinguishes four flows rather than treating all connector data identically. \n\n## Flow A — Structured business data\n\n```text\nCRM\nERP\nFinance\nITSM\nHR\nProject systems\nBilling\nMarketing\nAnalytics\n```\n\nProduces:\n\n**Entities + typed tuples**\n\nExamples:\n\n```text\nAccount\nDeal\nTicket\nEmployee\nInvoice\nProject\nTask\n```\n\nand:\n\n```text\nARR\nhealth_score\nrenewal_date\npriority\nstatus\namount\nowner\n```\n\nFlow A is strongly typed at the schema level.\n\n---\n\n## Flow B — Unstructured context\n\n```text\nEmail\nSlack\nMeetings\nCall transcripts\nDocuments\nPDFs\nPPTX\nNotes\nAttachments\nMessages\nContracts\nSupport conversations\n```\n\nProduces:\n\n```text\nChunks\nEmbeddings\nEvidence\nSource links\nConversational context\n```\n\nThis feeds organizational retrieval and context assembly rather than becoming indiscriminately flattened into structured business tables. \n\n---\n\n## Flow C — AI continuity\n\nAI-generated:\n\n```text\nObservations\nProposals\nPlans\nReasoning outputs\nHandover context\nSession conclusions\n```\n\nremain within AI continuity until they qualify for organizational promotion.\n\n---\n\n## Flow D — Authentication / authority\n\nIdentity and authorization establish:\n\n```text\nWho\n↓\nWhich tenant\n↓\nWhich workspace\n↓\nWhich role\n↓\nWhich permissions\n↓\nWhich capabilities\n↓\nWhich data\n↓\nWhich actions\n```\n\nThis prevents context from being separated from authority.\n\n---\n\n# 6. Triage and promotion\n\nThe key principle is:\n\n> **Not everything ingested becomes organizational truth.**\n\nIncoming information is classified:\n\n```text\nRAW\n ↓\nPARSED\n ↓\nNORMALIZED\n ↓\nTRIAGED\n ↓\nCANDIDATE\n ↓\nREVIEW\n ├── REJECTED\n └── APPROVED\n        ↓\n     PROMOTED\n        ↓\n     CANONICAL\n```\n\nThe promotion queue contains fields including:\n\n```text\nqueue_id\nmemory_item_id\nmemory_scope\nmemory_type\nsubject_refs\ncanonical_domain\ncanonical_entity_type\nproposed_by\nproposed_at\nconfidence\norigin\npromotion_status\nreviewed_by\nreviewed_at\nrejection_reason\ncommitted_at\ncanonical_record_id\ncanonical_version\n```\n\nThis provides the bridge between **information that exists** and **information the organization has decided to preserve as shared continuity**. \n\n---\n\n# 7. The Spine data model\n\nThe Spine should therefore be understood as several related domains.\n\n## Identity and organization\n\n```text\ntenants\norganizations\nusers\nteams\nroles\npermissions\nworkspaces\nmemberships\n```\n\n## Business context\n\n```text\naccounts\ncontacts\ncustomers\nproducts\nservices\ncontracts\ndeals\norders\nprojects\ninitiatives\n```\n\n## Work\n\n```text\ngoals\nwork_items\ntasks\nsteps\ndependencies\nassignments\nhandoffs\nwork_status\nwork_history\n```\n\n## Intelligence\n\n```text\nsignals\nrisks\ninsights\nrecommendations\nproposals\nplans\ndecisions\n```\n\n## Metrics\n\n```text\nkpis\nmetric_definitions\nmetric_values\ntargets\nthresholds\nsla_definitions\nmeasurements\n```\n\n## Knowledge and evidence\n\n```text\ndocuments\nknowledge_items\nchunks\nsource_links\nevidence\ncitations\npolicies\nrunbooks\n```\n\n## Communication\n\n```text\nmessages\nconversations\nmeetings\nactivities\ncommunications\nattachments\n```\n\n## Integration\n\n```text\nconnectors\nconnections\nsource_objects\nsource_records\nfield_mappings\nwebhooks\nsync_jobs\nsync_state\n```\n\nThe connector itself remains responsible for connectivity; the Spine owns the normalized organizational representation.\n\nThe universal connector model already includes tenant, provider, authentication type, category, status, version, manifest, MCP status and MCP endpoint metadata.\n\n---\n\n# 8. Provenance is part of the Spine\n\nEvery meaningful canonical value must be traceable.\n\nConceptually:\n\n```text\nSpine Field\n    │\n    ├── source_connector\n    ├── source_system\n    ├── source_object\n    ├── source_record\n    ├── source_field\n    ├── source_timestamp\n    ├── ingested_at\n    ├── mapping_version\n    ├── evidence_ref\n    └── confidence / classification\n```\n\nThis gives the Twin and human user an answer to:\n\n> **Where did this come from?**\n\nThe retrieval contract similarly requires record reference, source reference, locator, score components, classification, freshness, permission decision and index version. \n\n---\n\n# 9. Role-based projection\n\nThe Spine does **not** become a different database for each role.\n\nInstead:\n\n```text\nONE SPINE\n   +\nROLE\n   +\nDEPARTMENT\n   +\nINDUSTRY\n   +\nCONNECTORS\n   +\nACTIVE CONTEXT\n   +\nPOLICY\n   ↓\nPROJECTION\n```\n\nThe Projection Engine produces:\n\n```text\nNavigation\nViews\nFields\nKPIs\nTables\nBoards\nTimelines\nForms\nActions\nEvidence\nTwin context\n```\n\nThis is the core reason the same underlying Account can appear differently for:\n\n```text\nAccount Executive\nSales Manager\nCRO\n```\n\nor:\n\n```text\nCSM\nCS Manager\nVP Customer Success\n```\n\nThe role determines the job; the department determines the domain; permissions determine authority; the projection determines what is surfaced. \n\n---\n\n# 10. Initial role/access projection\n\nThe access chain is:\n\n```text\nUSER\n ↓\nMEMBERSHIP\n ↓\nROLE\n ↓\nPERMISSION SET\n ↓\nRESOURCE\n ↓\nACTION\n ↓\nSCOPE\n```\n\nPermission actions include:\n\n```text\nread\nwrite\nexecute\napprove\n```\n\nwith scopes such as:\n\n```text\ntenant\nworkspace\nown\n```\n\nThe role model includes department, permissions, capability grants and projection manifest. \n\nTherefore:\n\n```text\nRole ≠ UI\nRole → Projection policy\n```\n\n---\n\n# 11. Organizational memory\n\n**Spine Fabric = organizational memory**, but organizational memory has structure.\n\nIt contains:\n\n### Operational truth\n\n```text\nWhat is true now?\n```\n\n### Historical continuity\n\n```text\nWhat happened?\n```\n\n### Organizational knowledge\n\n```text\nWhat do we know?\n```\n\n### Decisions\n\n```text\nWhat did we decide?\nWhy?\n```\n\n### Evidence\n\n```text\nWhat supports it?\n```\n\n### Intent\n\n```text\nWhat are we trying to accomplish?\n```\n\n### Work state\n\n```text\nWhat is currently being done?\n```\n\nThis is why the Spine is more than a normalized connector database.\n\n---\n\n# 12. Three memory boundaries\n\nThe architecture must keep three memories separate.\n\n| Memory                    | Owner          | Purpose                                                     |\n| ------------------------- | -------------- | ----------------------------------------------------------- |\n| **Organizational Memory** | Tenant / Spine | Shared business truth and durable organizational continuity |\n| **Personal Memory**       | User           | User-specific preferences, context and personal continuity  |\n| **AI Continuity Memory**  | Twin / AI      | Task/session-specific AI continuity                         |\n\nThe project material explicitly defines these three scopes.\n\nThe important rule is:\n\n```text\nPersonal ≠ Organizational\nAI continuity ≠ Organizational truth\n```\n\nAI observations can become organizational knowledge only through the governed promotion path.\n\n---\n\n# 13. SpineWorkspace Human Workbench\n\nThe Human Workbench is the primary product surface.\n\nIt should answer:\n\n```text\nWhat matters?\nWhat is my goal?\nWhat needs attention?\nWhat work is mine?\nWhat changed?\nWhat decision is needed?\nWhat can I do next?\nWhat is my Twin preparing?\n```\n\nThe user should not need to understand:\n\n```text\nMCP\nR2\nVectorize\nloader\nnormalizer\nschema mapper\nHermes\nagent runtime\nmodel routing\n```\n\nunless their role explicitly requires those capabilities.\n\n---\n\n# 14. AI Workbench / Twin\n\nThe AI Workbench is the environment where the Twin operates over the same business context.\n\nThe Twin does not receive arbitrary connector payloads.\n\nIt receives an **Active Context Bundle** assembled from authorized Spine state, memory, evidence and current work.\n\n```text\nUser / Work\n      ↓\nActive Context\n      ↓\nProjection\n      ↓\nContext Assembly\n      ↓\nTwin\n```\n\nThe Twin then reasons about:\n\n```text\nGoal\nWork\nContext\nHistory\nSignals\nEvidence\nPolicies\nAvailable capabilities\n```\n\nThe Twin is therefore:\n\n> **Cognition over governed, assembled context.**\n\nIt is not another database.\n\n---\n\n# 15. Human + Twin interaction\n\nThe fundamental unit is **Work**, not chat.\n\n```text\nBUSINESS GOAL\n      ↓\nWORK\n      ↓\nHUMAN + TWIN\n      ↓\nCONTEXT\n      ↓\nPROPOSAL / PLAN\n      ↓\nHUMAN DECISION\n      ↓\nEXECUTION\n      ↓\nOUTCOME\n```\n\nThe Twin may:\n\n* observe\n* summarize\n* prepare\n* recommend\n* draft\n* analyze\n* plan\n* identify risks\n* assemble context\n* request approval\n* hand work to another agent\n\nThe human remains the authority boundary for governed consequences.\n\n---\n\n# 16. Capability Fabric\n\nA capability is not simply a tool name.\n\nIt describes **what can be accomplished and under what constraints**.\n\nExamples:\n\n```text\nread_customer\nupdate_customer\ncreate_task\nsend_email\nschedule_meeting\nquery_database\nrun_test\ncreate_pull_request\ndeploy_application\nrollback_deployment\nupdate_ticket\ncreate_invoice\n```\n\nCapabilities have:\n\n```text\ncategory\noperation\ninput schema\noutput schema\nrequired permissions\nrisk level\napproval requirement\ntenant availability\nconnector dependency\nexecution mechanism\n```\n\nThe capability can then be implemented through:\n\n```text\nMCP\nREST\nA2A\nworkflow\nconnector API\nlocal filesystem\nbrowser\nGit\ndatabase\n```\n\nSo:\n\n> **Capability = what may be done.**\n> **MCP/REST/A2A = how communication reaches it.**\n\n---\n\n# 17. Tool categories\n\nThe Spine should understand tool capabilities by category rather than hard-code individual vendors.\n\n### Business systems\n\n```text\nCRM\nERP\nFinance\nBilling\nHR\nSupport\nITSM\nMarketing\nAnalytics\n```\n\n### Productivity\n\n```text\nEmail\nCalendar\nDocuments\nChat\nMeetings\nKnowledge\n```\n\n### Engineering\n\n```text\nGit\nCode\nCI/CD\nCloud\nInfrastructure\nDatabases\nMonitoring\n```\n\n### Interaction\n\n```text\nBrowser\nREST\nMCP\nA2A\nWebhook\n```\n\n### Local/runtime\n\n```text\nFilesystem\nTerminal\nShell\nDevelopment environment\n```\n\nThe provider can change without changing the business capability contract.\n\n---\n\n# 18. Communication architecture\n\n```text\n                  SPINEWORKSPACE\n                         │\n                Context / Work\n                         │\n            ┌────────────┼────────────┐\n            │            │            │\n           MCP          REST          A2A\n            │            │            │\n      Tool/resource   Service/API   Agent\n            │            │            │\n            └────────────┼────────────┘\n                         ▼\n                  Capability Fabric\n                         │\n                         ▼\n                     Governance\n                         │\n                         ▼\n                      Hermes\n                         │\n                         ▼\n                 Connector / Runtime\n                         │\n                         ▼\n                  Source System\n```\n\nMCP is therefore **one communication mechanism inside the capability/runtime architecture**, not the Spine itself. The architecture documents explicitly establish this distinction. \n\n---\n\n# 19. Workflow and writeback\n\nThe reverse path is as important as ingestion.\n\n### Human\n\n```text\nHuman action\n ↓\nProjection API\n ↓\nAuthorization\n ↓\nGoverned Writer\n ↓\nSpine\n ↓\nEvent\n ↓\nSource write\n ↓\nReceipt\n ↓\nRe-ingestion\n ↓\nReconciliation\n ↓\nProjection refresh\n```\n\n### Twin\n\n```text\nTwin\n ↓\nProposal\n ↓\nGovernance\n ↓\nApproval\n ↓\nExecution Plan\n ↓\nHermes\n ↓\nCapability\n ↓\nSource System\n ↓\nOutcome\n ↓\nVerification\n ↓\nReconciliation\n ↓\nSpine\n ↓\nNew Context\n```\n\nThe canonical architecture specifies this write path and prohibits browser, Twin, connector and projection components from bypassing governed writes.\n\n---\n\n# 20. Continuity\n\nContinuity is the complete closed loop:\n\n```text\nINTENT\n  ↓\nGOAL\n  ↓\nWORK\n  ↓\nCONTEXT\n  ↓\nACTION\n  ↓\nOUTCOME\n  ↓\nEVIDENCE\n  ↓\nVERIFICATION\n  ↓\nRECONCILIATION\n  ↓\nSPINE UPDATE\n  ↓\nNEW PROJECTION\n  ↓\nNEXT WORK\n```\n\nThis is what makes Spine different from a static data warehouse.\n\nThe system remembers not merely:\n\n> \"Account X has ARR = $2M\"\n\nbut also:\n\n```text\nwhy it matters\nwhat changed\nwho owns it\nwhat was attempted\nwhat was decided\nwhat evidence exists\nwhat remains unresolved\nwhat should happen next\n```\n\n---\n\n# 21. KPI model\n\nKPIs belong to the **business goal and work context**, not merely to dashboards.\n\nA KPI should support fields such as:\n\n```text\nkpi_id\ntenant_id\ngoal_id\nwork_item_id\nname\ndescription\nmetric_type\nformula\nunit\ncurrency\naggregation\nsource_entities\nsource_fields\ncurrent_value\nbaseline_value\ntarget_value\nminimum_value\nmaximum_value\nthreshold\ndirection\nstatus\nvariance\nvariance_pct\ntrend\nperiod\nperiod_start\nperiod_end\nforecast_value\nconfidence\nowner_id\ndepartment\nrole_visibility\nsla\nfreshness\nlast_calculated_at\nsource_ref\nevidence_ref\nversion\n```\n\nThen:\n\n```text\nGOAL\n ↓\nKPI\n ↓\nCURRENT STATE\n ↓\nTARGET\n ↓\nVARIANCE\n ↓\nSIGNALS\n ↓\nWORK\n ↓\nACTION\n```\n\nThis makes KPIs operational rather than decorative.\n\n---\n\n# 22. Business-goal interaction\n\nA goal should carry enough structure for both human and AI work:\n\n```text\ngoal_id\ntenant_id\nname\ndescription\nobjective\nowner\ndepartment\npriority\nstatus\nstart_date\ntarget_date\nsuccess_definition\nkpi_ids\nrelated_work_ids\nrelated_entities\nrisks\ndependencies\nconstraints\nrequired_capabilities\nrequired_approvals\nactive_context\nevidence\ncreated_by\nupdated_by\nversion\n```\n\nThen the Twin can reason:\n\n> What is preventing this goal from being achieved?\n\nrather than merely:\n\n> What information is in the CRM?\n\n---\n\n# 23. Work as the human-AI coordination object\n\nThe durable coordination object is:\n\n```text\nWork\n```\n\nA Work record should connect:\n\n```text\nGoal\n ↓\nWork Item\n ↓\nTasks\n ↓\nPeople\n ↓\nTwin / Agents\n ↓\nContext\n ↓\nCapabilities\n ↓\nDecisions\n ↓\nApprovals\n ↓\nEvidence\n ↓\nOutcomes\n```\n\nThis allows:\n\n```text\nHuman starts work\n       ↓\nTwin prepares\n       ↓\nHuman reviews\n       ↓\nTwin executes permitted portions\n       ↓\nHuman approves consequence\n       ↓\nSystem writes back\n       ↓\nOutcome reconciles\n       ↓\nWork closes\n       ↓\nContinuity preserved\n```\n\n---\n\n# 24. Final enterprise Spine architecture\n\n```text\n                              TENANT\n                                │\n                 ┌──────────────┴──────────────┐\n                 │                             │\n             IDENTITY                     CONFIGURATION\n                 │                             │\n       Users / Roles / Policy          Industry / Connectors\n                 │                             │\n                 └──────────────┬──────────────┘\n                                ▼\n                         CONNECTOR FABRIC\n                                │\n                    ┌───────────┼───────────┐\n                    ▼           ▼           ▼\n                Discovery    Ingestion   Capabilities\n                    │           │           │\n                    └───────────┼───────────┘\n                                ▼\n                      NORMALIZATION / TRIAGE\n                                │\n                     ┌──────────┴──────────┐\n                     │                     │\n                Known mapping         New / uncertain\n                     │                     │\n                     │              PROMOTION QUEUE\n                     │                     │\n                     │               REVIEW / APPROVE\n                     │                     │\n                     └──────────┬──────────┘\n                                ▼\n                       GOVERNED SPINE WRITE\n                                │\n                                ▼\n                         ┌──────────────┐\n                         │  SPINE FABRIC │\n                         └──────────────┘\n                                │\n       ┌────────────────────────┼─────────────────────────┐\n       ▼                        ▼                         ▼\n BUSINESS CONTEXT          ORGANIZATIONAL             CONTINUITY\n   STRUCTURE                  MEMORY                    STATE\n       │                        │                         │\n       └────────────────────────┼─────────────────────────┘\n                                ▼\n                       PROJECTION ENGINE\n                                │\n               ┌────────────────┴────────────────┐\n               ▼                                 ▼\n       HUMAN WORKBENCH                    AI WORKBENCH\n               │                                 │\n          Role projection                    Twin / Agents\n               │                                 │\n               └────────────────┬────────────────┘\n                                ▼\n                              WORK\n                                │\n                       CONTEXT ASSEMBLY\n                                │\n                       CAPABILITY FABRIC\n                                │\n                           GOVERNANCE\n                                │\n                             HERMES\n                                │\n                       MCP / REST / A2A\n                                │\n                         SOURCE SYSTEMS\n                                │\n                      OUTCOME / VERIFICATION\n                                │\n                       RE-INGEST / RECONCILE\n                                │\n                                ▼\n                           SPINE UPDATE\n                                │\n                                ▼\n                       NEW PROJECTION\n                                │\n                                ▼\n                           NEXT WORK\n```\n\n---\n\n# 25. What is actually shared between Human and AI\n\nThey share:\n\n```text\nBusiness goals\nWork\nAuthorized business context\nRelevant entities\nKPIs\nSignals\nEvidence\nDecisions\nPolicies\nApproved outcomes\nOrganizational continuity\n```\n\nThey do **not** automatically share:\n\n```text\nPersonal memory\nPrivate user context\nAI ephemeral reasoning\nUnauthorized data\nUnapproved actions\nRaw connector credentials\n```\n\nThat distinction is fundamental.\n\n---\n\n# 26. Final system contract\n\nThe complete SpineWorkspace contract is therefore:\n\n> **Connect the organization's software. Discover its schemas and capabilities. Map source data into a governed tenant Spine. Hydrate the Spine as new domains and connectors become available. Preserve provenance, evidence and organizational continuity. Compose role- and context-specific projections from that Spine. Give humans and their Twins the same authorized business context for the same work. Let the Twin prepare, reason and propose. Let capabilities perform governed actions through MCP, REST, A2A and other runtime mechanisms. Write approved outcomes back to source systems. Re-ingest, verify and reconcile the result. Preserve the resulting state as organizational continuity and project the next work.**\n\nThat is the **end-to-end Spine Fabric for an enterprise organization**.\n\nAnd the product-level abstraction remains deliberately simple:\n\n> **One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.**\n\nThe platform underneath can be extremely sophisticated; the user's experience should remain centered on **goals, context, work, decisions and outcomes**. \n"}