{"slug":"canonical/01-SPINEWORKSPACE-OPERATING-MODEL","title":"SpineWorkspace Canonical Operating Model","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/01-SPINEWORKSPACE-OPERATING-MODEL.md","bytes":30912,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\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\nThis document is the integrated, human-approved statement of the SpineWorkspace operating model,\nconsolidated from the founder source corpus listed in the frontmatter. Where the Founder Canon\n(2026-08-31) and later founder records (2026-09-03/04) govern, they win; this document organizes\ntheir content into one readable operating model. It is **target-operating-model**: it states what\nthe product is, not what the code yet implements. The delta between this model and the repository\nis measured — evidence-only — in\n[`17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md`](17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md).\n\n**Document classes:** this tree distinguishes *current implementation*, *target operating model*\n(this document), *accepted invariant* (the laws in §14 and the ADRs), *open question*, and\n*planned capability*. Claims below are model claims; implementation status lives in the register.\n\n---\n\n## 1. The one-sentence ontology\n\n> **SpineWorkspace is a human–AI work coordination environment centered on Business Context, with\n> Spine Fabric providing contextual business memory and operational continuity, the Human\n> Workbench providing the human operating surface, the AI Workbench (Twin + Spine Agents) providing\n> the AI operating surface, and the IntegrateWise platform providing governed connectivity,\n> communication, capability and execution.**\n\n**Founder framing (load-bearing):** *\"We are not solving the memory problem for AI only — humans\nare the core actors who need one working surface without juggling and context switching. From\ntools we extract the context and business context.\"* The model therefore splits into two paths:\n\n- **System path** — sources feed Loader → Normalizer → Triage → Spine → Projection → Governance →\n  Hermes → providers → re-ingestion → reconciliation → Spine. It preserves truth and moves it\n  safely.\n- **User path** — one human enters one Workbench, sees a role-projected view of current work,\n  with the Twin assisting inside the work. It reduces context switching.\n\n**Core loop in one line:** data from connected tools comes to the Spine, is projected into the\nworkspace, and approved actions and events go back to the tools and return as reconciled truth.\n\n## 2. Product hierarchy and naming\n\n| Level | Meaning |\n|---|---|\n| **IntegrateWise** | Company and infrastructure platform (`integratewise.ai`). |\n| **SpineWorkspace** | The product and daily working experience (`spineworkspace.com`). |\n| **Spine Context & Continuity System** | Business Context Spine + Personal Contextual Memory + AI Continuity Memory. |\n| **Human Workbench** | Primary user-facing operating surface. |\n| **AI Workbench** | AI-side operating environment hosting Twin and Spine Agents. |\n\nNever call IntegrateWise the product; never call SpineWorkspace the company. The dual-domain rule\n(`integratewise.ai` company/platform · `spineworkspace.com` product) is frozen.\n\n## 3. ONEAUTH — host-controlled entry and trust boundary\n\nOneAuth is the single entry into the ecosystem and the first thing that executes for any\nprincipal — human, Twin, agent, service, external AI host, automation or API client. It resolves:\nuser/agent identity, organization, workspace, **host identity**, roles and permissions, *existing\nhost connections*, allowed connector projections, available plugins, available MCP capabilities,\nand activation policy.\n\n- **OneAuth establishes the trust boundary before anything is installed, projected, synchronized\n  or executed.** `Host Identity + Host Connections + Organization Policy + User Entitlements =\n  IntegrateWise Workspace Access`.\n- **OneAuth does not copy provider credentials.** Provider credentials remain *managed connection\n  artifacts* owned by the host or Integration Manager; OneAuth supplies the shared organizational\n  authority context around them.\n- **Deployment model — create once, deploy anywhere.** One canonical Workbench runtime deploys\n  into multiple hosts (ChatGPT, web, Slack, Microsoft surfaces, embedded customer applications,\n  desktop shells, customer-hosted environments, marketplaces, agent hosts). The active host\n  contributes its authorized identity, tools and interaction model; domain logic is built once and\n  hosts are adapters. No host-specific forks of domain logic, Projection Engine logic or canonical\n  schemas.\n\n## 4. DISCOVERY — eight forms, bootstrap contract, never authorization\n\nDiscovery has eight first-class forms: provider/connector discovery · object and schema discovery\n· event discovery · capability discovery · MCP server/tool discovery · agent discovery ·\nmodel/runtime discovery · health and availability discovery.\n\n**Discovery answers what exists. It does not authorize execution.** Its output becomes the\n**workspace bootstrap contract** that onboarding consumes. Host capabilities enter the runtime\nonly through explicit mechanisms — host-declared capability context, tool-result handoff,\nworkflow-level orchestration, explicit IntegrateWise connection, or installation manifest — and\n*expected availability is never proof of actual runtime access*.\n\n## 5. HOST-FIRST CAPABILITY ROUTING\n\nEvery request is classified before routing:\n\n```text\nRequestScope: host-local | entity | continuity | cross-system | governance | write\ncompletenessExpectation: local | best-available | canonical\nrequiresSpineEnrichment / requiresGovernance flags\n```\n\nCapabilities are modeled on two sides:\n\n- **HostCapability** — exposed by the active host under current user/workspace permissions;\n  `availability: confirmed | declared | unknown` (declared is never proof of access).\n- **SpineCapability** — canonical context or IntegrateWise-managed capability;\n  `freshness: live | synced | historical`; `authority: system-of-record | canonical | derived`;\n  `adapter: nango | mcp | native`.\n\n**Read precedence (default):**\n\n```text\n1. Confirmed host-native live capability\n2. Spine canonical context\n3. IntegrateWise-managed live connector\n4. Spine Cache or historical Spine data\n5. Request connection\n6. Unavailable\n```\n\nThe resolver MAY combine routes (Gmail host-native while Salesforce and Slack come from the\nSpine). **Write precedence (default):** resolve canonical target and policy → create proposal →\ndetermine allowed execution routes → prefer confirmed host-native execution when\npolicy-approved → otherwise IntegrateWise Capability Fabric → capture execution receipt →\nnormalize and reconcile → rehydrate Workbench and Spine Cache.\n\nA **ConnectionBinding** maps a host connection, a canonical principal, and an optional\nIntegrateWise integration. Governing principle: **Host-first access. Spine-complete context.\nPolicy-governed execution. Canonical reconciliation.**\n\n## 6. CONNECTOR PROJECTIONS — managed connectors, never copies\n\nIntegrateWise connectors are **projections of connectors the host (or Integration Manager)\nalready owns** — one connection supports multiple workloads without duplicating the provider\ncredential:\n\n```text\nHost Connector\n   ├── Workbench read projection\n   ├── Loader synchronization projection\n   ├── Twin search projection\n   └── Approved write projection\n```\n\nEach connector projection carries: provider identity, connection reference, available resources,\nallowed scopes, read/search/event/write capabilities, approval requirements, retention policy,\ndata classification, rate limits and revocation state. Boundaries: no unnecessary host refresh\ntokens, no ownership of the source system, no replacement of the host connector manager, no\npermissions wider than the host allows. The Connector Marketplace **first discovers eligible\ntenant connections and offers connection reuse**; new systems are activated additively.\n\n## 7. MARKETPLACES — three catalogs, one control surface\n\n| Catalog | Exposes | Key rule |\n|---|---|---|\n| **Connector Marketplace** | Projections of host-owned connectors | Shared catalog metadata never means shared credentials or shared customer data; every live connection resolves inside the caller tenant and the centralized secret boundary |\n| **Plugin Marketplace** | Packaged workspace experiences (views, signals, automations, Twin instructions, report/page templates) per role/domain | Lifecycle: Discover → Review → Approve → Install → Configure → Activate → Upgrade → Disable → Remove; a plugin never receives automatic tool access |\n| **MCP Marketplace** | MCP servers, tools, resources, prompts with publisher, version, trust classification, capability mapping | Flow: select → review tools/permissions → org approval → register with MCP Pool → map tools to capabilities → apply workspace policy → expose allowed tools |\n\nStrict responsibility separation: **Marketplace** (discovery, publication, installation, trust) ·\n**MCP Pool** (runtime registration, routing, sessions, health, isolation) · **Capability Manager**\n(stable business capability mapping and authorization) · **Governance** (approval and policy\nenforcement) · **Orchestrator/Hermes** (controlled invocation and completion).\n\n## 8. ACTIVATION HUB — seven gated stages\n\n```text\nAuthenticate → Resolve Organization → Discover Host Connections → Select Connector\nProjections → Install Plugins → Install MCP Capabilities → Configure Product Package\n→ Hydrate Spine → Activate Workbench\n```\n\n1. **Identity activation** — authenticate, resolve host/org/workspace, apply entitlements.\n2. **Ecosystem discovery** — host connections, connector projections, approved plugins/MCP.\n3. **Connection activation** — select connections, review scopes, **create projections**, test\n   connectivity, set synchronization policy.\n4. **Package activation** — resolve capabilities, initialize Spine Cache, establish Business\n   Context, register tools, configure orchestration.\n5. **Spine hydration** — load, normalize, resolve entities, build relationships, establish\n   provenance, **validate freshness**.\n6. **Workbench activation** — role views, domain plugins, initial pages, activate Twin, test\n   proposals and approvals.\n7. **Readiness confirmation** — connections healthy · Spine operational · tools available · Twin\n   grounded · governance active · Workbench ready.\n\nOnboarding doctrine: onboarding converts identity, marketplace selections and host capabilities\ninto a working workspace — **blank state → useful work**. Missing data appears as\nreadiness/freshness gaps over the mandatory operating contract, never as a reduced product.\n\n## 9. PRODUCT PACKAGE — the workspace runtime kernel\n\n```text\nADK · Spine Cache · Orchestrator/Hermes · Cognitive Capability · Tool Capability ·\nContinuity · Business Context · Discovery Engine · Connected Tools · Spine Network\n```\n\n- **ADK** — agent contracts and runtime primitives; never determines access (only effective\n  capabilities granted by the Capability Manager).\n- **Spine Cache** — read-optimized, policy-filtered, LLM-readable projection; the **default agent\n  read surface**; the Spine remains the authority and the cache is always rebuildable.\n- **Orchestrator/Hermes** — intent → plan → policy check → approval → execute → verify →\n  reconcile; never bypasses connectors, policies or the Spine.\n- **Cognitive Capability** = understand, reason, generate, propose. **Tool Capability** = read,\n  write, invoke, execute. Formally distinct. Every tool capability declares input/output\n  contract, provider, risk level, side-effect classification, approval rule, retry policy,\n  idempotency behavior, audit requirement and reconciliation method.\n- **Continuity** — broader than memory: what happened + why + who decided + what remains open +\n  what should happen next; context follows the ongoing work.\n- **Business Context** — converts technical records into organizational meaning.\n- **Discovery Engine** — outputs the workspace bootstrap contract (§4).\n- **Connected Tools** — `Discovered Tool → Capability Mapping → Scope Evaluation → Role\n  Evaluation → Governance Evaluation → Effective Connected Tool`. **A connected tool is not\n  automatically usable.**\n- **Spine Network** — the navigable relationship graph (entities, source identities,\n  relationships, connections, capabilities, tools, documents, knowledge, memory, signals,\n  decisions, actions) — the bridge between structured truth and the capabilities that act on it.\n\n## 10. SPINE FABRIC — context substrate, never a copy\n\n**The Spine is not a database and not an ESB.** It is a governed canonical context network: tools\nconnect once, and governed context becomes reusable — eliminating point-to-point connection\ngrowth and the isolated-desert outcome. Source systems **remain authoritative for their own\noperational transactions**; the Spine is the governed cross-system business context that connects\ntheir meaning.\n\n**Four continuity primitives** — everything derives from them: **Event** (timestamped, immutable,\ncausally linked) · **Entity** (persists across time) · **Relationship** (connects entities,\nevents, evidence, outcomes) · **Synthesis** (meaning emerged from repeated or combined\ncontinuity).\n\n**Nine logical domains:** Identity (tenants, users, teams, roles, permissions, policies) · Entity\n(customers, contacts, accounts, projects, products, assets, vendors, employees) · Work (tasks,\nwork_items, queues, approvals, assignments, escalations, SLAs) · Communication (email threads,\ncalendar, meetings, chat, calls) · Knowledge (documents, notes, knowledge base, brainstorm\nsessions, learning artifacts) · Memory (user_memory, work_memory, org_memory, conversation_memory,\nagent_memory — HITL-gated) · Capability (connectors, mcp_tools, apis, ai_models, automations,\npipelines) · Governance (approval_records, audit_log, security_events, compliance_records,\npolicies) · Platform (billing, deployments, api_keys, observability, admin_actions).\n\n**Six storage layers:** Postgres/D1 (structured truth anchor) · Redis/KV (hot state, sub-100ms,\nnot truth) · R2 (blobs linked by reference, never queried directly) · Conversational store (raw\nchannel events; classify → extract → promote) · Vector/pgvector (semantic intelligence; hybrid\ncosine + BM25 + RRF) · Agent memory (durable per-scope state, HITL-gated writes).\n\n**Eleven state planes** (preserved even when physically co-located): Business Context Spine ·\nPersonal Contextual Memory · AI Continuity Memory · Spine Cache · Knowledge · Blobs · Session\nLogs · Audit Logs · Sync State · Config State · Ephemeral Runtime.\n\n**Standard envelope** on every tenant-owned table: `id, tenant_id, workspace_id, version, status,\ncreated_at, created_by, updated_at, updated_by, trace_id, correlation_id, metadata` — canonical\nfields as typed columns; additive domain/connector attributes in versioned JSONB under a\nregistered schema module; secrets only as vault references; append-only event/audit/version\ntables.\n\n**Effective Spine (additive-only):**\n\n```text\nEffective Spine = Mandatory Base Spine ∪ Department ∪ Industry ∪ Role ∪ Connector ∪ Tenant ∪ Contextual Expansion\n```\n\nNo expansion may remove tenancy, provenance, authority, evidence, lifecycle, sync or\nreconciliation contracts. Missing data is coverage/readiness state, not a removed contract.\n\n**Ingestion chain:** Gateway (tenant-aware ingress) → Loader Runtime (sole outer ingestion and\ncanonical-write entry; preserves source identity, provenance, evidence, replay; four flows: A\nstructured, B unstructured, C AI continuity, D platform binding — **Flow D first, always**) →\nNormalizer (deterministic validation/mapping/dedup) → Schema Synthesis → Entity Resolution\n(Salesforce Account + Stripe Customer + HubSpot Company → canonical Account) → Relationship and\nEvent linking → Domain mapping → **Triage** → Governed Spine Writers.\n\n**Triage doctrine:** *Triage classifies. Governance decides. The Pipeline promotes. Spine owns\norganizational memory. Twin consumes the governed result.* Triage classifies, links, dedupes,\ndetects conflicts/ambiguity, evaluates materiality/sensitivity/freshness/completeness, proposes\nmemory scope, stages candidates and routes review. Triage never becomes a canonical writer.\n\n## 11. PROJECTION — sole composer, dual-sided\n\nThe **Projection Engine is the sole producer of versioned SharedWorkbench contracts.** Gateways,\nBFF routes, UI modules and agents request authorized projections; none independently assemble\ncanonical truth or read physical stores. Resolution formula: `Role × Department × Industry ×\nConnector Category × Active Context × Policy`.\n\n**Role Workbench grammar:** twelve role workbenches (Founder→Strategic Objective, Customer\nSuccess→Account, Sales→Opportunity, Support→Ticket, Project Management→Project,\nMarketing→Campaign, Business Operations→Process, Technology→Service, HR→Employee, Finance→Invoice,\nLegal→Contract, Personal→Personal Task) with genuinely role-specific entity sets; a shared\n**16-section grammar** (Home/Role Brief, My Work, Primary-Entity Portfolio, Entity 360,\nPipeline/Queue, Timeline, Calendar, Communications, Documents & Knowledge, Signals & Risks,\nApprovals, Planning Canvas, Reports & Metrics, Automation & Playbooks, Recent Work, click-triggered\nTwin Detail); 13 shared UI primitives, each with exactly one backend owner (Governance owns the\napproval block; the Twin Runtime is restricted to read and propose).\n\n**Click → context → Twin:** 64 click contexts per role (16 sections × open/row/edit/assign) map\nto an Active Context Bundle, loaded records, a retrieval query, an OODA stage, expected Twin\noutput, mutation type, approval requirement and persistence mode. Four interaction primitives:\n**Store in Spine · Ask Twin · Assign Twin · Approve Twin Action** — only the last reaches Hermes\nand a provider. The Twin is a click-triggered contextual panel, never a permanent sidebar. The UI\ntuner proposes versioned projection patches; it never rewrites components.\n\n## 12. DUAL WORKBENCHES, THREE MEMORIES, COWORKER\n\n**Invariant: shared business reality; separate participant continuity; governed promotion between\nscopes.**\n\n```text\nHuman Active Context  = Business Context Projection + Personal Contextual Memory + Current Work\n                        + Current Interaction Context + Authorized Knowledge/Evidence + Policy + Capabilities\nAI Active Context     = Business Context Projection + AI Continuity Memory + Current Objective\n                        + Current Work State + Evidence + Authority Envelope + Available Capabilities\n                        + Agent Runtime State\n```\n\n- **Personal Contextual Memory** — the human's working continuity; private by default; only the\n  owner may cite it; promotion to organizational memory is an explicit governed transition.\n- **AI Continuity Memory** — Twin/agent working continuity across turns, model changes, sessions\n  and handoffs; never organizational truth.\n- **Coworker** — the contextual companion between active Workbench use and the Twin: observes\n  active work, gathers context, retrieves relevant information, supports communication, keeps\n  human/Twin context aligned. **Not a second authority.**\n- **Twin** — one bounded Twin per user; understands, contextualizes, triages, allocates, plans/\n  proposes, delegates, executes through governed capabilities, verifies, reports, adapts. OODA\n  (Observe→Orient→Decide→Act) is the internal grammar; the user experiences Store in Spine / Ask\n  Twin / Assign Twin / Approve Twin Action.\n- **Spine Agents** — governed organizational actors with identity, tenant, purpose, owner,\n  delegated authority, scopes, capability access, memory namespace, runtime/model profile, risk\n  policy and audit identity. They cooperate by reading and updating shared **Work** state and\n  returning evidence — Agent A performs sub-work → writes evidence → handoff recorded → Agent B\n  reads the same authorized Work context and continues.\n- **Model independence** — the model is a replaceable reasoning provider selected by stable\n  profiles (`fast`, `reasoning`, `code`, `specialized`); no model version is part of the durable\n  contract.\n\n## 13. WORK, CAPABILITY, GOVERNANCE, HERMES, CLOSURE\n\n**Work** is the durable coordination unit — `work_id`, objective, business-context references,\nowner/responsible human, current executor, state and lifecycle, subtasks/dependencies, evidence,\ncommitments, proposals, policy/authority envelope, available capabilities, expected outcome,\nactual outcome, handoff history, trace and continuity identifiers.\n\n> **No participating worker begins meaningful work without a Spine-derived authorized context and\n> Work identity.** — applies to humans, Twin, Spine Agents, ADK runtimes, workflows and providers.\n\n**Context Packages** — agents receive a bounded package (tenant, work, purpose, relevant\nentities/state, constraints, authority, allowed capabilities, evidence, freshness, sensitivity,\nexpiry, provenance), never unrestricted organizational memory.\n\n**Communication protocols:** **MCP** = AI ↔ tool/resource/capability interoperability.\n**ACP** = Agent ↔ Agent / Agent ↔ Twin through governed work/context handoff, carrying Work ID,\nTask ID, sender/recipient, capability, context reference, authority scope, constraints, expected\noutput, evidence requirements, status, result, attribution, correlation/causation IDs. *Neither\nMCP nor ACP grants authority.* The **Active Context Bundle** carries actor, host\n(type/session/capabilities-observed-at), entities, relationships, continuity, commitments,\nsignals, decisions, evidence, available actions, policy and a completeness level\n(`host-local | partial | canonical` with missing systems named).\n\n**Execution chain:**\n\n```text\nIntent → Proposal/Command → Governance Decision → Authorized Execution Plan → Hermes Execution\n→ Provider Outcome → Outcome Event → Re-ingestion → Verification → Expected-vs-Actual\n→ Reconciliation → Governed Canonical Commit → Projection Invalidation\n→ Human + AI Workbench Rehydration → Next Work\n```\n\n**Governance outcomes:** ALLOW · DENY · REQUIRE APPROVAL · DELEGATE / ALLOW WITH BOUNDED\nAUTHORITY. Confidence never grants authority. The Twin cannot self-approve consequential action\nor bypass Governance. **Hermes** starts only after a plan is approved or policy-allowed; it does\nnot decide allowance and never owns canonical truth. Traceability: trace_id, correlation_id,\ncausation_id, event_id, approval_id, capability_run_id, execution_id, idempotency_key,\nverification_id, reconciliation_id, continuity_run_id.\n\n## 14. THE BRIDGE — many surfaces, one continuity substrate\n\nThe \"one channel\" thesis does not mean one literal chat application. It means every participating\nsurface — Human Workbench, email, chat, mobile, source applications, external AI hosts, MCP\nclients, agents, webhooks, APIs — converges on the same coordination model:\n\n```text\n… → Identity → Authorized Context → Work/Event → Authority → Capability → Execution\n→ Evidence → Reconciliation → Business Context Spine\n```\n\nThe **Bridge** is the governed communication substrate carrying messages, context references,\ndecisions, approvals, agent handoffs and execution signals. Every Bridge message carries or\nresolves to: tenant, principal, sender, recipient, **Work ID**, task ID, communication type,\npurpose, context reference, capability reference, authority context, source channel,\ncorrelation/causation IDs, timestamp, provenance, sensitivity, status. Channels: human\n(Workbench chat, Slack, email, Teams, meetings, calls), agent (ACP, work handoff, context\nreference, agent result, escalation), system (API, webhook, event bus, workflow event, MCP,\nconnector event). Communication-derived content becomes organizational memory only via evidence →\ntriage → candidate → governance → promotion. An approval received through Slack must be converted\nto a verified, immutable approval event — a Slack reaction alone is never an authority bypass.\nThe Bridge is not a memory store, not a canonical database, not a Slack/email replacement, not an\nauthority bypass.\n\n## 15. MEMORY PROMOTION AND KNOWLEDGE EVOLUTION\n\n```text\nActual State → Event → Evidence → Context → Interpretation → Triage → Candidate\n→ Governance → Organizational Memory → Updated Spine → Future Context\n```\n\nKnowledge emerges from processed outcomes, not from raw data or raw model output.\n`User thought ≠ AI inference ≠ Organizational truth.` Personal and AI memory may inform context\nassembly; neither silently becomes organizational truth. Spine Cache can always be rebuilt;\ncache never becomes truth.\n\n## 16. GTM, CUSTOMER ZERO AND GO-LIVE\n\n**Wedge:** Account Success / Customer Success — initial market India SMB SaaS (20–200 employees,\n5–20 CSMs, ~USD 5k–50k ACV, HubSpot/Freshworks/Zoho/Freshdesk/Jira/Slack estates),\n**no replacement of existing systems**. Tier B: digital/IT services. Tier C: operations-heavy SMB.\n\n**Customer Zero:** IntegrateWise operates IntegrateWise on the same substrate — the first real\ntenant, preserving the company's own operating history. Lifecycle-first: a company runs through\nrecurring lifecycle events (Company lifecycle → operating lifecycle → event → state transition →\nSOP → activities → records/evidence → AI preparation → human decision/approval → capability\nexecution → verification → memory → next event), not through department silos.\n\n**Go-live:** development → CI/contract tests → Customer Zero → CZ evidence → version freeze →\nclean external tenant → plugin/MCP submission ready → public publication. Until the full chain is\ndemonstrated with telemetry, rollback, security and operational support, release classification\nremains Customer Zero / controlled beta — packaging, manifests or declared tools never prove\noperational readiness.\n\n## 17. TWENTY CANONICAL LAWS\n\n1. IntegrateWise is the company; SpineWorkspace is the product.\n2. Business Context is the core product concern.\n3. Spine Fabric is contextual business memory and operational continuity.\n4. One canonical organizational reality; many governed projections.\n5. AI never directly reads or writes canonical Spine.\n6. AI operates in a bounded Operational Sandbox.\n7. Work is the primary coordination unit.\n8. Work Allocation determines who/what performs each part of Work.\n9. Every user has one bounded Twin.\n10. Coworker gathers active context and supports communication.\n11. Triage never becomes a canonical writer.\n12. Capability defines what; Execution Fabric defines how.\n13. Governance controls consequential mutation.\n14. ACP communicates work/context; it does not grant authority.\n15. MCP is a tool/resource/capability interoperability mechanism.\n16. Source execution must return through re-ingestion and reconciliation.\n17. Memory informs organizational truth; it does not silently become organizational truth.\n18. Organizational Memory is published only through governed promotion.\n19. Personal/reversible adaptation may auto-tune; shared/consequential change requires governance.\n20. IntegrateWise Platform remains substrate, not a second Workbench.\n\nThese laws are individually recorded as ADRs 2026-09-04-04 … 2026-09-04-13 where they carry\nimplementation consequence (see `adr/`).\n\n## 18. ACCEPTANCE TESTS (product embodiment)\n\nA release proves the model when: a user authenticates, binds to a tenant and connects controlled\nsystems · initial hydration produces a valid Business Context Spine, not an empty shell · the\nHuman Workbench composes useful cross-tool context · Personal Contextual Memory persists without\nsilently becoming organizational truth · the AI Workbench receives authorized context plus AI\nContinuity Memory · the Twin explains current work with evidence and prepares a proposal · a\nSpine Agent takes a subtask with identity, Work state, context and authority and hands off without\nlosing continuity · the Capability Fabric resolves a provider-neutral capability to an executable\nroute · Governance allows/denies/requires-approval/delegates by identity, risk and policy ·\nHermes executes only an authorized plan and returns outcome evidence · the provider outcome is\nre-ingested, verified and reconciled · the Spine updates only through governed writes · both\nWorkbenches rehydrate from verified state · the chain is reconstructable through lineage IDs · a\nmodel, connector or agent can be replaced without losing the organization's continuity record.\n\n## 19. Open questions and controlled ambiguities\n\nTracked in [`17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md`](17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md)\n(open-questions section) and the source-corpus provenance record. Known controlled ambiguities as\nof this version: physical store split (D1 vs Neon per the four-plane hybrid ADR) beneath the\nlogical contract; unified OneAuth entry resolution vs distributed gateway middleware; A2A/ACP\ntransport implementation; Coworker runtime actor naming (restored as a concept by\nADR-2026-09-04-03; carried today by the Collaboration Log Agent).\n"}