Canon

SpineWorkspace

Canonical Product, Experience, Context, AI and Platform Architecture

IntegrateWise Infrastructure Platform
Version: 6.0.0 - Founder Canon
Date: 31 August 2026
Status: Founder-authoritative canonical consolidation; supersedes the 1 August 2026 product framing where explicitly stated
Scope: SpineWorkspace product, Human Workbench, AI Workbench, shared Business Context Spine, Personal Contextual Memory, AI Continuity Memory, Twin, Spine Agents, user experience, UI/AI context pipelines, OODA, platform infrastructure, capability execution, governance, continuity, distribution, implementation alignment and go-live doctrine.

One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.

Humans govern. AI helps. Spine preserves continuity.

0. Document Authority, Source Precedence and Supersession

This document is the 31 August 2026 Founder Canon. It does not merely restate the repository freeze from 1 August 2026. It incorporates the founder decisions made after that freeze and treats those decisions as the highest authority for product meaning, experience architecture and the human-AI operating model.

0.1 Source precedence

When sources disagree, use this order:

Founder decisions dated 31 August 2026 and the latest project conversations - highest authority for product, experience, memory boundaries, Human Workbench, AI Workbench and the human-AI operating model.
Late-August SpineWorkspace consolidation decisions and master-system visual - authoritative design direction where they elaborate the founder decisions.
1 August 2026 GitHub canonical freeze - implementation baseline and retained technical contracts where not superseded. The repository still shows 39d48073fcac6d805a28a5a854910513d22cf1fa as the latest canonical architecture freeze.
Earlier canonical/downstream architecture documents and code - evidence of implementation, migration state and historical design.
External 2026 market research - validation of the category and design pressures only. It does not define IntegrateWise or SpineWorkspace.

This precedence exists specifically to prevent a later founder decision from being overwritten by an older repository document simply because the repository has not yet been updated.

0.2 What the August 1 freeze still contributes

The 1 August architecture remains the technical baseline for contracts that the founder decisions did not replace: One Auth-to-Ecosystem, Configuration Manager, Integration Manager, Activation Bridge, Gateway, Loader Runtime, Flow A/B/C/D, Normalizer/Triage, Governed Spine Writers, Base Spine, Projection Engine, Capability Fabric, Governance, Hermes, Sync/Verification/Reconciliation, Continuity Bridge, IW Spine Network MCP, MCP Pool, ADK, traceability, Customer Zero and evidence-based readiness. [I1][I3][I4]

0.3 What this Founder Canon supersedes

This document supersedes the August 1 framing in the following product-level areas:

Primary product identity. The product is SpineWorkspace. IntegrateWise is the infrastructure/platform powering it.
Two first-class work environments. The system contains a Human Workbench and an AI Workbench operating over the same organizational business context.
Human Workbench primacy. Human Workbench is the primary daily product for users. Platform machinery stays largely invisible unless the user is an authorized operator.
AI Workbench. AI has a first-class working environment over business context. It is not merely a chat panel, an API payload or the Twin itself.
Three continuity scopes. Shared Business Context / Organizational Memory, Personal Contextual Memory and AI Continuity Memory are distinct in purpose, authority and lifecycle.
Twin vs AI Workbench. Twin is the human-facing contextual AI coworker operating within the AI Workbench; Twin is not the complete AI operating environment.
Spine Agents. Specialized agents operate as governed organizational actors with identity, authority, capability access, Work state, evidence and continuity.
Shared Work is the coordination medium. Humans and agents hand off through durable Work/context/evidence state rather than re-explaining the organization in conversation.
Experience is first class. UI composition, AI context composition and OODA are internal product machinery. Users should experience work that already carries context rather than needing to understand the machinery.
No monolithic AI Orchestrator. Cognition, model routing, agent runtime, capability resolution, authority and execution remain separated across Twin, model/inference routing, ADK, Capability Fabric, Governance and Hermes.
Verified closure. Provider success is not completion. The loop closes only after re-ingestion, verification, reconciliation, governed Spine update and rehydration of both Workbenches.

Where a prior document conflicts with any item above, this Founder Canon wins.

0A. Founder Decision Register - 31 August 2026

The following decisions are the explicit basis for this revision and must be treated as constitutional product decisions rather than optional interpretation. [F1]

Decision	Canonical consequence
Workbench is the primary product for users.	Human Workbench is the main daily surface and the product must be experience-first.
There is also an AI Workbench.	AI receives its own first-class operating environment over business context, not merely a chat session.
Humans have Personal Contextual Memory.	User continuity is independently scoped and does not automatically become organization truth.
AI has its own continuing memory.	AI Continuity Memory persists AI working continuity across turns, model changes and agent handoffs.
Human memory and AI memory are separate.	Neither memory scope may be silently merged with the other.
Both operate on shared Spine business memory/context.	Business Context Spine / Organizational Memory is the common organizational substrate for authorized humans and AI.
Spine Agents must operate and work together.	Agents are governed organizational actors and coordinate through shared Work, context, evidence and handoff state.
Platform must be fully represented.	Product architecture must include identity, connectivity, ingestion, projection, agent runtime, capabilities, governance, execution and continuity.
Experience and user experience are first class.	Product documentation begins with the user experience and only then explains the underlying architecture.
UI pipeline and AI pipeline are internal.	Projection/UI composition and AI context/runtime composition are part of the product but should not burden the normal user.
OODA is internal operating grammar.	Observe-Orient-Decide-Act governs the loop while the user experiences natural work actions.
The underlying execution remains inside the product.	Capability Fabric, Governance, Hermes, providers, verification and reconciliation are integral even when invisible to the end user.

Constitutional memory rule

User thought
≠
AI inference
≠
Organizational truth

A Personal Contextual Memory item remains personal unless deliberately shared/promoted. An AI Continuity Memory item remains AI working continuity unless promoted through the appropriate Triage/Governance/write path. Organizational Memory is durable business memory only after the organization accepts it into the governed Business Context Spine.

Constitutional product rule

SPINEWORKSPACE
=
Human Workbench
+
AI Workbench
+
Shared Business Context
+
Separate Human and AI Continuity
+
Governed Work and Execution

The infrastructure exists to make this experience coherent, continuous and trustworthy.

1. Executive Definition

1.1 SpineWorkspace

SpineWorkspace is one product with two first-class operating sides: the Human Workbench for people and the AI Workbench for Twin and Spine Agents. They are separate working environments over the same organizational Business Context Spine. Each carries its own continuity memory, and neither side owns organizational truth by itself.

SpineWorkspace is a self-organizing shared work environment in which humans and AI operate over the same governed business context, while each retains its own continuity memory.

Humans use the Human Workbench to understand, prioritize, collaborate, decide, approve and remain accountable. AI uses the AI Workbench to assemble context, research, analyze, plan, prepare, coordinate, monitor and execute work that policy allows. Twin is the contextual co-worker closest to the human; Spine Agents can perform specialized work behind it. Both sides operate over the same organizational business reality.

The user should experience a narrow, direct product even though the platform underneath is broad: the relevant information is already assembled; the current work already has history and evidence; the Twin can prepare difficult or repetitive work; approvals appear when authority requires them; and verified outcomes return to the same work surface. This carries forward the August product principle that “work already knows its context.” [I2]

1.2 IntegrateWise

IntegrateWise is the infrastructure platform that connects the organization’s software ecosystem, preserves governed business context and continuity, composes SpineWorkspace for humans and AI, and coordinates authorized work across APIs, MCP, agents, workflows, models, local runtimes and human routes.

IntegrateWise is not the daily destination for most users. It is the infrastructure substrate that makes the SpineWorkspace experience possible.

1.3 The Core Thesis

Organizations do not run inside a single software tool. Their business is distributed across CRM, ERP, support, email, chat, calendar, files, documents, project systems, engineering systems, finance applications, databases, internal APIs and increasingly AI systems and agents.

Historically, the human became the hidden integration and context layer: searching, switching tabs, copying information, reconciling conflicting states and remembering why a decision was made. AI embedded separately inside each application repeats the same fragmentation at machine speed. An AI attached only to one tool understands only that tool; an agent without persistent context or continuity must reconstruct the situation on every run.

The platform thesis is therefore:

Neither humans nor AI should have to reconstruct the organization every time they need to work.

And the durability doctrine is:

Tools are replaceable. Models are replaceable. Agents are replaceable. Organizational continuity is not.

2. Why This Product Exists

2.1 Software fragmentation became work fragmentation

The modern enterprise already operates across a large application estate. Okta’s 2026 Businesses at Work reporting showed that large enterprises averaged 259 applications, while even smaller organizations continued to add tools. [E11] Asana’s work research reports that knowledge workers spend a majority of their time on “work about work” such as searching for information, coordinating, switching tools and chasing status; its State of Work Innovation reported 53% of time on busywork and only 12% of workers saying new information flows quickly across departments. [E4]

The architectural problem is not simply “too many apps.” The deeper problem is that the meaning of the business is distributed between them.

A customer renewal, for example, may be spread across CRM fields, support cases, meeting notes, contract files, finance records, Slack messages, product usage, email and a manager’s memory. None of those systems independently contains the complete operating context.

2.2 AI inherits the same fragmentation

Adding an AI assistant to every SaaS application does not create one organizational intelligence. It creates many intelligent fragments. Each assistant sees a local slice, has a different memory boundary, uses different permissions and usually cannot preserve a durable, governed record of the organization’s evolving decisions and outcomes.

The 2026 market is converging on the need for shared enterprise context. OpenAI Frontier describes “Business Context” connecting enterprise systems so AI coworkers can use the same information people do and build durable institutional memory. [E1] Atlassian describes Teamwork Graph as a living map of people, goals, code, content and decisions that gives agents context across tools. [E7] Glean similarly combines organization-wide context with personal graphs. [E6] Palantir’s Ontology emphasizes an evolving operational representation and decision lineage accessible to both humans and agents. [E8]

SpineWorkspace takes the same problem seriously but frames the product around shared work and continuity between humans and AI, rather than around search, graph, agent management or integration alone.

2.3 Human authority remains central

The emergence of agents does not eliminate human responsibility. Microsoft’s 2026 Work Trend Index frames the emerging organization as one where agents take on more execution while humans have more room to direct work, make calls and own outcomes. [E2] Asana’s 2026 human-agent product direction similarly emphasizes humans and agents working from the same plan and context under shared governance. [E3]

SpineWorkspace therefore does not position AI as an unrestricted autonomous replacement for the organization. It treats AI as a digital teammate that can perform context assembly, research, preparation, coordination, repetitive work, monitoring and permitted execution, while humans retain judgment, accountability and control over consequential decisions.

3. The Final Product Hierarchy

The complete system has three levels that must remain distinct. The product hierarchy below reflects the 31 August founder decision rather than the older 'IntegrateWise Workbench' naming freeze.

Level	Canonical meaning
SpineWorkspace	The product and daily working experience.
Spine Context & Continuity System	The shared Business Context Spine plus Personal Contextual Memory and AI Continuity Memory.
IntegrateWise Platform	The infrastructure, connectivity, activation, intelligence, governance, execution and continuity machinery underneath.

Inside SpineWorkspace are two first-class operating environments:

Human Workbench	AI Workbench
Primary user-facing product surface	AI-side operating environment
Human-readable and attention-oriented	Agent-readable and context-oriented
Understand, prioritize, decide, collaborate, approve	Understand, research, analyze, plan, prepare, coordinate, monitor
Uses Personal Contextual Memory	Uses AI Continuity Memory
Receives role/responsibility projections	Receives task/agent/authority projections
Human owns accountability	AI owns execution state, not business accountability

They share the same business reality but do not share every private or runtime memory item.

3A. Experience Contract - What the User Sees and What the Product Hides

The user should not have to understand the architecture in order to benefit from it.

Human-visible experience

A normal user should experience:

Open SpineWorkspace
→ see what matters now
→ enter current work
→ find the relevant business history and evidence already assembled
→ ask or assign Twin when useful
→ review prepared work / recommendation / proposal
→ decide or approve when authority is required
→ continue working
→ see the verified result return to the same context

The user should not be forced to understand MCP Pool, ADK, Flow C, model routing, queue semantics, reconciliation identifiers, Spine Cache or the execution topology.

AI-visible experience

Twin and Spine Agents should experience:

I have an identity
→ I know my objective
→ I have the authorized business context
→ I have my AI continuity memory
→ I know the current Work state
→ I know the evidence
→ I know my authority
→ I know which capabilities are available
→ I can hand work to another authorized agent without losing continuity
→ I can return evidence and resume later

The product absorbs the complexity for both sides.

Internal experience machinery

The following are product internals, not user concepts:

Projection Engine
Workbench Contract
UI Composition
AI Context Builder
Model Resolver
ADK / Agent Runtime
Capability Discovery
Capability Fabric
Governance
Hermes
Events / Queues
Sync
Verification
Reconciliation
OODA state transitions

They are still part of the product architecture because the user experience depends on them.

4. The Three Continuity and Memory Scopes

The final architecture deliberately separates three types of continuity.

4.1 Business Context Memory - organizational and shared

Business Context Memory belongs to the organization. It is the shared, governed continuity substrate used by every authorized human, Twin and agent.

It includes:

mission, objectives, goals, KPIs and initiatives;
organizations, teams, people, roles and responsibilities;
customers, accounts, partners, vendors, products, projects and assets;
work, tasks, commitments, lifecycle states and dependencies;
relationships between entities and work;
events, changes, signals and temporal history;
communications, meetings, documents and artifacts where policy allows;
decisions, rationale, approvals and authority lineage;
knowledge, evidence, provenance and source references;
policies, capabilities and execution eligibility;
expected outcomes, actual outcomes, verification and reconciliation state;
durable organizational memory and lessons that have passed the promotion/governance boundary.

It answers: What does the organization know, what is true enough to operate on, what is happening, what was decided, and what happened next?

4.2 Personal Contextual Memory - human continuity

Personal Contextual Memory belongs to the human’s working context, subject to enterprise privacy, compliance and retention policy. It exists because a human carries important continuity that should not automatically become company truth.

Examples include personal notes, drafts, reminders, priorities, bookmarks, private working knowledge, what the user was investigating, unfinished thoughts, personal task ordering, preferences, recurring work patterns and context the user wants available across sessions.

Personal Contextual Memory is private by default. Sharing or promoting an item into organizational memory is an explicit governed transition, not an automatic side effect of writing a note.

The Human Workbench therefore assembles:

Human Workbench Context
=
Authorized Business Context
+ Personal Contextual Memory
+ Current Work
+ Current Interaction Context
+ Policy and Capabilities

4.3 AI Continuity Memory - Twin and agent continuity

AI Continuity Memory is the AI-side continuity layer. It exists so Twin and Spine Agents do not restart from zero on every turn, model change, session or handoff. Operationally it is scoped to the AI participant/runtime; governance, retention and legal ownership remain governed by tenant policy.

It can hold prior assignment state, working summaries, unresolved questions, current plans, active hypotheses, tool/capability state, agent handoff context, prior observations, pending verification, interaction preferences and model-independent continuity information.

AI Continuity Memory is not organizational truth. An AI-generated inference, summary or hypothesis becomes organizational memory only after the appropriate Triage, Governance and governed-write path.

The AI Workbench therefore assembles:

AI Workbench Context
=
Authorized Business Context
+ AI Continuity Memory
+ Current Objective
+ Current Work State
+ Evidence
+ Authority
+ Available Capabilities

The August platform architecture already separated Adaptive Spine, Twin Memory, Knowledge, Session Logs, Audit Logs, Cache, Sync State and ephemeral runtime. This document turns that separation into an explicit product-level contract. [I1][I3]

4A. Dual-Workbench Context Model

The two Workbenches share organizational context but receive different projections and different continuity augmentation.

Human Active Context
=
Business Context Projection
+ Personal Contextual Memory
+ Current Work
+ Current Interaction Context
+ Authorized Knowledge/Evidence
+ Policy
+ Capabilities

AI Active Context
=
Business Context Projection
+ AI Continuity Memory
+ Current Objective
+ Current Work State
+ Evidence
+ Authority Envelope
+ Available Capabilities
+ Agent Runtime State

The invariant is:

Shared business reality; separate participant continuity; governed promotion between scopes.

This is the core reason the Human Workbench and AI Workbench can collaborate without collapsing privacy, inference and organizational truth into one memory store.

5. Business Contextual Spine Fabric

5.1 Definition

The Business Contextual Spine Fabric is the tenant-scoped system of organizational operating context, continuity and governed state. It is not merely a database and it is not an ESB.

The closest ESB analogy is that it provides a common coordination substrate across many systems. The analogy stops there. A traditional integration bus primarily transports, routes and transforms messages. The Spine Fabric preserves the semantic and temporal context needed for humans and AI to understand work, decisions, evidence, authority and outcomes over time.

The July architecture correction explicitly rejected the N×M “ESB hub” metaphor and reframed the Spine as a governed canonical context network: tools connect once, and governed context becomes reusable. [I1]

5.2 Logical domains

The logical Business Context Spine carries three coupled domains from the August freeze, expanded by this document’s three-memory separation: [I1]

Operational Truth. Entities, fields, relationships, lifecycle state, work state, decisions, approvals, expected outcomes, source ownership and reconciliation status.

Knowledge and Evidence. Documents, chunks, embeddings/search representations, citations, attachments, source artifacts and evidence references.

Business Memory and Continuity. Continuity runs, commitments, decisions, synthesized organizational context, promotion state, temporal history and organizational memory.

Personal Contextual Memory and AI Continuity Memory remain separate scoped stores or namespaces even when they use the same physical infrastructure.

5.3 Logical truth before physical storage

The product architecture freezes the logical Spine contract, not one vendor-specific database. The August architecture explicitly allows the physical implementation to use Postgres/D1, object storage, vector/search, event stores, caches and queues underneath the logical contract. [I1]

This resolves older internal documentation conflicts that alternately treated D1 or Postgres/Neon as the single physical source of truth. The final rule is:

The Business Context Spine is the canonical logical authority. Physical storage authority is an implementation/deployment ADR and must not redefine product semantics.

5.4 Mandatory Base Spine and additive expansion

Every tenant receives a valid mandatory Base Spine. The Spine is not generated only from whichever connectors a customer happens to install. Role, department, industry, connector and tenant context extend the Base Spine additively. [I1][I3]

Effective Spine
=
Mandatory Base Spine
∪ Department Expansion
∪ Industry Expansion
∪ Role Expansion
∪ Connector Expansion
∪ Tenant Expansion
∪ Contextual Expansion

No expansion may remove tenancy, provenance, authority, evidence, lifecycle, sync or reconciliation contracts.

6. Work Is the Shared Unit of Human-AI Coordination

Human and AI collaboration must not rely on endless conversational handoffs. The central coordination object is Work.

Every meaningful work item should carry a durable identity and enough state to allow a different human, Twin, agent or provider to continue without re-explaining the entire situation.

A Work object should conceptually bind:

work_id
objective
business context references
owner / responsible human
current executor
state and lifecycle
subtasks and dependencies
evidence
commitments
proposals
policy / authority envelope
available capabilities
expected outcome
actual outcome
handoff history
trace and continuity identifiers

The operating rule is:

No participating worker begins meaningful work without a Spine-derived authorized context and Work identity.

This applies whether the worker is a human, Twin, Spine Agent, ADK runtime, workflow or execution provider. Earlier Spine Fabric work already established shared Work state and continuity as the handoff mechanism rather than chat alone. [I9][I11]

7. Human Workbench - The Primary Product Experience

7.1 Definition

The Human Workbench is the primary daily product surface inside SpineWorkspace. It is not a dashboard, a database UI, a role-specific isolated SaaS app, or a chatbot with integrations.

The Workbench composes the fields, records, relationships, knowledge, evidence, communications, work, capabilities, approvals and Twin context relevant to the user’s role and active situation. The August product architecture already established that the same Base Spine can project differently for Sales, Customer Success, Support, Marketing, Finance, Engineering or a founder. [I2]

7.2 Stable shell, adaptive work

Navigation stays stable enough to be learnable. The work surface adapts.

A representative information architecture is:

Home;
My Work: Inbox, Tasks, Queue, Approvals, Notifications, Recent, Favorites;
Communications: Activity, Email, Calendar, Meetings, Chat, Calls, Shared Documents;
Personal: Notes, Personal Knowledge, Brainstorming, Activity and permitted personal utilities;
Work: adaptive role/department/lifecycle projections;
Platform/Administration for authorized operators only.

The platform should adapt visibility, default routes, views, fields, actions and capabilities without making the global product taxonomy unstable. [I2]

7.3 Self-organizing Workbench

Self-organization is a technical composition rule, not a marketing metaphor.

Effective Human Workbench
=
Mandatory Workbench Standard
+ Business Context Projection
+ Personal Contextual Memory
+ Role and Responsibility
+ Department and Industry Context
+ Active Lifecycle and Current Work
+ Connected Data Coverage
+ Knowledge and Evidence
+ Available Capabilities
+ Governance and Entitlements
+ User Preferences
+ Freshness and Readiness

The user should not have to create every database, design every view, map every tool, build every dashboard or repeatedly explain the same context to AI. The system discovers, activates, hydrates and projects the operating environment.

7.4 Tables, views, pages and operational surfaces

SpineWorkspace can expose multiple form factors over the same context:

Tables for structured operational data;
Views for filtered, grouped and role-routed lenses;
Pages/Docs for narrative, planning, linked context and evidence;
Boards for state and lifecycle;
Queues for action-ready work;
Calendar/Timeline for time projections;
Canvas for free-form operational composition;
Entity 360-style projections for cross-system business objects;
Twin for contextual reasoning and preparation.

The form factor does not own truth. The projection contract does.

8. AI Workbench - The AI Operating Environment

8.1 Definition

The AI Workbench is the machine-side operating environment in which Twin and Spine Agents perform business work over the shared Business Context Spine.

It does not need to appear to the customer as a separate visible app. It is first-class architecturally because an AI worker needs a stable operational environment just as a human does.

8.2 What the AI Workbench contains

A complete AI Workbench context can include:

active objective;
assigned Work record and current state;
authorized Business Context Bundle;
relevant Business Memory;
AI Continuity Memory;
relevant entities and relationships;
evidence and provenance;
current plan and subtasks;
dependencies and blockers;
agent roster and agent state;
available capabilities and provider health;
authority/delegation envelope;
proposals and pending approvals;
execution state;
expected versus observed outcomes;
verification, exception and handoff state.

8.3 Twin versus AI Workbench

Twin is not the entire AI Workbench. Twin is the contextual co-worker closest to the human: it retrieves, reasons, explains, prepares and proposes. [I1][I3]

The AI Workbench can host or coordinate multiple workers behind Twin, including specialist agents, research agents, execution agents, verification agents, workflows and model calls. Twin may perform work itself or assign sub-work through governed agent/capability paths.

8.4 AI continuity must survive model changes

The AI Workbench, Work state and AI Continuity Memory are durable platform concepts. A specific model is a replaceable reasoning provider.

A model resolver should select by task profile, context requirement, reasoning effort, modality, latency, cost, policy and availability. The model contract should use stable profiles such as fast, reasoning, code or specialized, rather than hard-coding one vendor/model version into Twin. [I13]

9. Twin and Spine Agents

9.1 Twin’s role

Twin is the contextual human-facing cognitive participant. It can:

assemble authorized context;
retrieve Business Memory, Personal Context where authorized, AI Continuity Memory, history and evidence;
explain current state and changes;
identify risks, gaps and commitments;
prepare drafts, plans, reports, mutations and capability inputs;
propose actions and request approval;
monitor authorized execution outcomes.

Twin cannot directly own organizational truth, self-approve consequential actions, bypass Governance, become the storage layer, or claim success before verification and reconciliation. These restrictions carry forward directly from the August canonical architecture. [I1]

9.2 Spine Agents

A Spine Agent is an AI worker operating inside the organization’s governed Work and context model. Every agent receives identity, tenant, purpose, owner, delegated authority, scopes, capability access, memory namespace, runtime/model profile, risk policy and audit identity.

Spine Agents cooperate by reading and updating shared Work state and returning evidence, not by relying only on free-form agent-to-agent conversation.

Agent A
→ performs sub-work
→ writes evidence / updates Work state
→ handoff recorded
→ Agent B reads same authorized Work context
→ continues

This is the AI equivalent of eliminating human context reconstruction.

9.3 Agent Development Kit (ADK)

ADK is the developer/runtime abstraction for registering and invoking agents through governed platform contracts. It should describe skills, schemas, runtime requirements, tool bindings and execution interfaces, while authority remains with One Auth/Governance and canonical truth remains with governed Spine writers. [I3][I4]

ADK is not the organizational memory, policy engine or execution authority.

10. Experience Principles

The product should hide most platform complexity.

A human should experience the following loop:

Open SpineWorkspace
→ see what matters now
→ open a customer/project/task/decision
→ relevant cross-tool context is already assembled
→ ask Twin or assign tedious work
→ Twin/agents research and prepare
→ review evidence and recommendation
→ approve consequential action when required
→ execution occurs
→ verified result appears in the same work surface
→ continue from the updated state

The AI side should experience:

I have an identity.
I know my objective.
I have authorized business context.
I have continuity memory.
I know the current Work state.
I know which capabilities I can use.
I know my authority.
I can hand off work without losing context.
I return evidence and outcomes.
I can resume later.

The architecture succeeds when users do not need to understand MCP Pool, Flow C, ADK, Hermes, Spine Cache or reconciliation IDs to complete normal work.

11. OODA - Internal Interaction Constitution

OODA remains the internal interaction grammar, not necessarily a literal four-button interface on every screen. [I2][I12]

OODA phase	Canonical action	Meaning
Observe	Store in Spine	Capture a governed context/evidence/decision/note/artifact candidate.
Orient	Ask Your Twin	Retrieve and explain active context.
Decide	Assign Your Twin	Delegate an objective and request prepared work/proposal.
Act	Approve Twin’s Action	Record human authority for consequential governed execution where approval is required.

The important constitutional rule is that Twin does not own the consequential “Act” authority. Policy may permit low-risk automation, but consequential authority is always explicit in Governance.

The internal loop is continuous:

Observe → Orient → Decide → Act → Outcome → Re-ingest → Verify → Reconcile → Observe again

12. Projection and the UI Composition Pipeline

12.1 Projection Engine

Projection Engine remains the sole composer of versioned Workbench contracts. Gateways, BFF routes, UI modules and agents request authorized projections; they do not independently assemble canonical truth. [I1][I3]

Projection inputs include tenant/workspace, user or agent identity, membership, role, department, industry, active entity, current Work, connected-system coverage, freshness, field permissions, available capabilities, provider health, preferences, governance and entitlements.

12.2 Human UI pipeline

Business Context Spine
+ Personal Contextual Memory
+ Role / Responsibility
+ Current Work and Lifecycle
+ Policy / Entitlements
+ Connected Data Coverage
+ Knowledge / Evidence
+ Capabilities
+ Preferences
+ Freshness / Readiness
        ↓
Projection Engine
        ↓
Versioned Workbench Contract
        ↓
UI Composition
        ↓
Human Workbench Surface

This is how the product can remain stable while content, fields, actions and priorities adapt.

12.3 AI context pipeline

Business Context Spine
+ AI Continuity Memory
+ Objective
+ Current Work State
+ Evidence
+ Authority
+ Capabilities
+ Runtime Health
        ↓
AI Context Assembly
        ↓
AI Workbench Context
        ↓
Twin / Spine Agent Runtime

Human and AI therefore share the same underlying business reality without requiring identical representations.

13. Business Intent and Lifecycle Above the Tools

SpineWorkspace should not begin conceptually with software applications. The organization exists to pursue outcomes.

Mission
→ Objectives
→ Goals
→ KPIs
→ Initiatives
→ Work
→ Decisions
→ Actions
→ Outcomes
→ Learning

The Business Context Spine links operating work back to this chain.

Organizations also operate through lifecycle transitions rather than static department silos alone:

Business Objective
→ Operating Lifecycle
→ Event
→ State Transition
→ SOP / Process
→ Activities
→ Records / Evidence
→ Human + AI Work
→ Decision / Approval
→ Execution
→ Verification
→ Memory
→ Next State

Departments, roles, pages and Twin actions are projections over this operating reality. A Sales view and a Finance view may see different aspects of the same lifecycle event without creating separate systems of truth.

14. IntegrateWise Platform - Complete Runtime Architecture

The IntegrateWise Platform sits underneath both Workbenches.

External Ecosystem
  SaaS · databases · files · MCP · AI providers · internal APIs · humans
        ↓
One Auth-to-Ecosystem
        ↓
Configuration Manager
        ↓
Integration Manager
        ↓
Discovery
        ↓
Activation Bridge
        ↓
Gateway
        ↓
Loader Runtime
        ├─ Flow A - Structured Operational
        ├─ Flow B - Unstructured Context
        ├─ Flow C - AI/Cognitive Continuity
        └─ Flow D - Platform Binding/Control
        ↓
Normalizer / Triage
        ↓
Governed Spine Writers
        ↓
Business Contextual Spine Fabric
        ↓
Projection / Context Assembly
        ├─ Human Workbench
        └─ AI Workbench
        ↓
Twin / Spine Agents
        ↓
Capability Discovery
        ↓
Capability Fabric
        ↓
Governance
        ↓
Hermes
        ↓
Execution Providers
        ↓
Outcome Event
        ↓
Sync / Verification / Reconciliation
        ↓
Governed Canonical Commit
        ↓
Projection Invalidation / Workbench Rehydration
        ↓
Next Work / Next OODA Loop

This chain is the August canonical runtime expanded to include the final dual-Workbench and memory model. [I1]

15. Identity, Configuration, Integration, Discovery and Activation

15.1 One Auth-to-Ecosystem

One Auth establishes a common organizational identity and delegation model for humans, Twin, agents, services, AI hosts, automations and API clients. It resolves user/agent identity, tenant, workspace, role, consent, scope, delegation and service-principal context. [I1][I3]

One Auth does not replace every provider OAuth credential. Provider credentials remain managed connection artifacts. One Auth provides the shared organizational authority context around them.

15.2 Configuration Manager

Configuration Manager defines tenant structure, provider choices, policy, composition, memory, AI/model and synchronization choices. [I3]

15.3 Integration Manager

Integration Manager owns connection lifecycle: OAuth, direct connectors, mappings, webhooks, subscriptions, discovery, health and sync policy. It must not write canonical business entities directly. [I1][I3]

15.4 Discovery

Discovery has multiple forms:

provider and connector discovery;
object and schema discovery;
event discovery;
capability discovery;
MCP server/tool discovery;
agent discovery;
model/runtime discovery;
health and availability discovery.

Discovery answers what exists. It does not authorize execution.

15.5 Activation Manager and Activation Bridge

Activation Manager is the administrative/product surface used to control what becomes active.

Activation Bridge is the runtime compiler that converts configuration, identity, role, department, connected data, policy, capability and memory settings into an active tenant/workspace definition. [I3]

Configuration
+ Identity
+ Connections
+ Discovered Objects/Capabilities
+ Base Spine
+ Role / Department / Industry
+ Policies / Entitlements
+ Memory / AI / Sync Choices
        ↓
Activation Bridge
        ↓
Compiled Active Runtime Definition

16. Ingestion, Four Flows, Normalization and Governed Writes

The outer world does not write canonical business truth directly.

16.1 Gateway

Gateway is the tenant-aware ingress boundary for validation, tracing, rate limits and routing. [I1][I3]

16.2 Loader Runtime

Loader Runtime is the sole outer ingestion and canonical-write entry. It routes data through four flows. [I1][I3]

Flow A - Structured Operational: entities, transactions, metrics, lifecycle changes, provider events and structured relationships.

Flow B - Unstructured Context: documents, messages, email, meetings, transcripts, files, chunks, embeddings/search representations and evidence.

Flow C - AI and Cognitive Continuity: Twin sessions, AI proposals, candidate memory/knowledge, synthesis and promotion candidates.

Flow D - Platform Binding and Control: identity, configuration, connectors, capabilities, policy, execution, sync and observability state.

16.3 Normalizer and Triage

Normalizer handles deterministic parsing, validation, mapping, resolution, deduplication and entity preparation. Triage handles ambiguous, AI-originated, conversational and knowledge candidates, preparing them for governed promotion. [I1][I3]

Triage classifies. Governance authorizes. Governed Writers commit.

16.4 Governed Spine Writers

Canonical writes enforce tenant scope, schema, policy, provenance, evidence, idempotency and atomicity. Neither an agent nor an execution runtime writes canonical truth directly. [I1][I3]

17. State-Plane Separation

The logical architecture must preserve state boundaries even when one physical database hosts multiple tables.

Plane	Purpose
Business Context Spine	Durable organizational operating truth and continuity.
Personal Contextual Memory	Human-specific working continuity.
AI Continuity Memory	Twin/agent working continuity.
Spine Cache	Disposable hydration/acceleration state.
Knowledge	Retrievable semantic representations linked to evidence.
Blobs	Raw files, payloads, exports, attachments and evidence artifacts.
Session Logs	Conversation, model/tool-call and interaction lifecycle.
Audit Logs	Identity, authority, approval, model/agent, capability, execution and outcome lineage.
Sync State	Cursors, checkpoints, retries, pending mutations, DLQ and conflicts.
Config State	Compiled tenant/provider/policy/composition/sync choices.
Ephemeral Runtime	Locks, leases, scratch state, temporary context and rate limits.

Spine Cache can always be rebuilt from canonical state. Cache never becomes truth. Knowledge representations must retain evidence links. Raw sessions are evidence/history; only governed promotion creates durable organizational memory. [I1][I10]

18. Capability Fabric - The Semantic Execution Layer

Capability Fabric is the provider-neutral execution language between intent and implementation. [I6]

A user or Twin should think in business capabilities such as prepare_renewal, schedule_review, update_project_state or send_followup, not in raw provider endpoints.

Capability Fabric resolves how authorized intent can be performed through route families including:

tool-to-tool;
memory fetch;
MCP;
agent-to-agent;
API connector;
API wrapper/function;
local execution;
AI execution;
browser, workflow or human execution where needed. [I1][I3]

Every executable capability declares a version, input/output schema, authority scope, risk, execution mode, sync mode, idempotency, evidence requirements, provider routes, health, timeout, retry, compensation and verification behavior. [I1]

The responsibility split is:

Twin / Workbench      = what the user is trying to achieve
Capability Discovery = what executable options exist
Capability Fabric    = how it could be done
Governance           = whether it may be done and under whose authority
Hermes               = how approved execution is coordinated reliably
Reconciliation       = whether reality actually changed as intended

19. Governance and Human Authority

Governance is a cross-cutting authority boundary, not merely a single UI screen or one step in a linear workflow.

Governance evaluates:

who or what requested the action;
tenant and organizational scope;
human or agent role;
delegated authority;
capability and target;
risk and destructive potential;
data sensitivity;
approval policy;
evidence requirements;
audit obligations.

The canonical outcomes remain:

ALLOW
DENY
REQUIRE APPROVAL
DELEGATE / ALLOW WITH BOUNDED AUTHORITY

Human governance does not mean a human must approve every low-risk automated operation. It means the organization defines what AI may do automatically, what requires explicit approval and what may never be delegated.

The August architecture’s non-negotiable rule remains: Twin cannot self-approve consequential action or bypass Governance. [I1]

20. Hermes and Execution

Hermes starts after an execution plan has been approved or policy-allowed. It coordinates dispatch, waits, retries, timeouts, observations, recovery/compensation, evidence capture, verification steps and reconciliation workflows. [I1][I3]

Execution providers can include APIs, MCP tools, agents, browser runtimes, workflows, local execution, AI models or human tasks.

Hermes is not the AI brain. It does not decide whether execution is allowed and it does not own canonical business truth.

Historical code includes orchestration paths and direct spine.write-style semantics that should be treated as implementation drift. The final contract is stricter: execution produces outcome events/evidence, and governed writes occur only after the appropriate re-ingestion, verification and reconciliation path. [I7]

21. Execution Is Not Complete Until Reality Reconciles

A provider’s 200 OK, tool success flag or agent completion message is an Outcome Event, not automatically a verified business outcome. [I1][I3]

The canonical continuity closure is:

Intent
→ Proposal / Command
→ Governance Decision
→ Authorized Execution Plan
→ Hermes Execution
→ Provider Outcome
→ Outcome Event
→ Re-ingestion
→ Verification
→ Expected vs Actual Comparison
→ Reconciliation
→ Governed Canonical Commit
→ Projection Invalidation
→ Human + AI Workbench Rehydration
→ Next OODA Loop

This is a defining product property. Humans and AI do not merely receive a success message; they continue from a verified updated business state.

Every continuity run retains traceability such as trace_id, correlation_id, causation_id, event_id, approval_id, capability_run_id, execution_id, idempotency_key, verification_id, reconciliation_id and continuity_run_id where applicable.

22. The Common Coordination Fabric - “One Channel” Correctly Defined

The “one channel” thesis does not mean every person and agent must use one literal chat application.

It means every participating surface converges on the same coordination model:

Human Workbench
Email
Chat / Collaboration
Mobile
Source Application
External AI Host
MCP Client
Agent
Webhook
API
        ↓
Identity
        ↓
Authorized Context
        ↓
Work / Event
        ↓
Authority
        ↓
Capability
        ↓
Execution
        ↓
Evidence
        ↓
Reconciliation
        ↓
Business Context Spine

Many interaction surfaces; one continuity substrate.

23. MCP, MCP Pool, Continuity Bridge and Distribution

These concepts must remain distinct. [I3][I4]

23.1 IW Spine Network MCP

The hosted remote MCP boundary exposes provider-neutral IntegrateWise resources and tools to approved external AI surfaces. It can provide Spine queries, context projections, history/relationships, knowledge/memory retrieval, capability discovery, proposal submission, governed execution requests and execution/reconciliation status.

MCP tools do not receive direct storage credentials. They call versioned platform APIs and governed capability paths. [I4]

23.2 MCP Pool

MCP Pool is the inward-facing tenant registry of approved external MCP servers/tools, their schemas, trust profile, authorization references, health and delegated scopes. It is principally an enterprise/Customer Zero control concept, not the user-facing product. [I3][I4][I14]

23.3 Continuity Bridge

IntegrateWise - Continuity Bridge is the distribution/access product for external AI hosts. It opens governed context and capability access without making MCP itself the product. [I4]

Distribution surfaces can include ChatGPT, Claude, Perplexity, direct MCP clients, embedded enterprise applications, SDK/ADK integrations, provider marketplaces and direct APIs. All must bind to the same identity, tenancy, Spine, projection, capability, governance and audit contracts. [I4]

24. Onboarding - From Blank State to Useful Work

Onboarding does not hand the user an empty workspace to configure manually. The existing doctrine is: onboarding creates a Spine Context, hydrates the Spine and then computes useful projections. [I5]

The final lifecycle is:

Identity
→ Organization / Role / Responsibility
→ Goals and Operating Context
→ Connect Reality
→ Discovery
→ Configuration
→ Activation
→ Initial Hydration
→ Business Context Spine
→ Personal Contextual Memory Initialization
→ AI Continuity / Twin Activation
→ Capability Activation
→ Projection
→ SpineWorkspace

The first useful experience should already contain real context from connected systems, clear coverage/readiness state, relevant Work and a functioning Twin. Missing data should appear as readiness/freshness gaps over the mandatory operating contract, not as a malformed reduced product.

25. Platform Console and Administrative Experience

Normal users live primarily in SpineWorkspace. Authorized operators need a Platform Console for managing the substrate.

Representative control areas include:

Integration Manager and Connector Marketplace;
Activation Manager;
Capability Manager and capability health;
MCP Pool and external AI surfaces;
AI Models / model routing profiles;
Knowledge, Business Memory, Personal/AI memory policy;
pipelines and synchronization;
Governance and approval policy;
agent registry / ADK controls;
observability, audit and trace explorer;
organizations, users, roles and permissions;
security, API keys, billing and entitlements;
deployments and release status.

The Platform Console is an operator/admin product surface, not a competing daily work destination.

26. Security, Privacy and Trust Invariants

The following are architectural stop-ship rules:

no cross-tenant data or context leakage;
no external request reaches internal services without tenant-aware identity validation;
no model or agent owns canonical organizational truth;
no agent directly writes canonical business truth;
no AI system can self-mint consequential human approval;
no MCP tool receives raw storage authority;
no private Personal Contextual Memory item becomes organizational memory without an explicit governed share/promotion path;
no AI Continuity Memory inference becomes organizational memory without Triage/Governance/governed write;
no provider success signal is treated as completed business state before verification/reconciliation;
every agent and execution route has an auditable identity, scope and authority envelope;
deletion/export/retention behavior must respect tenant policy and applicable user rights;
sensitive evidence and provenance must remain traceable without overexposing private content in projections.

The governance direction is consistent with the 2026 market, where ServiceNow AI Control Tower, Workday Agent System of Record and MuleSoft Agent Fabric all emphasize agent discovery, identity, permissions, approvals, governance, audit and cross-system control. [E5][E9][E10]

27. Customer Zero and Go-Live Doctrine

IntegrateWise must operate IntegrateWise itself. Customer Zero is the first real tenant, not a demo architecture. [I2][I3]

Customer Zero should preserve the operating history of the company: product, architecture, code, decisions, tasks, funding/GTM work, connectors, documents, incidents, releases, AI sessions, agent work, approvals and outcomes.

The minimum end-to-end launch proof remains:

One Auth
→ controlled connectors
→ Initial Hydration / Flow A-B-C-D
→ valid Base Spine
→ Human Workbench projection
→ AI Workbench/Twin context
→ proposal
→ Governance approval or bounded policy allow
→ Capability Fabric route
→ Hermes execution
→ provider outcome
→ re-ingestion
→ verification and reconciliation
→ visible Human + AI Workbench rehydration

Until this loop is demonstrated with telemetry, rollback, security and operational support, the release classification should remain Customer Zero / controlled beta rather than broad GA. [I1]

28. Implementation Alignment and Known Drift

The August codebase alignment document reported 30 services against a smaller canonical plane model and identified consolidation gaps. [I7] This document does not pretend those gaps are already resolved.

Key alignment work remains:

consolidate loader/normalizer behavior into the canonical Pipeline boundary;
consolidate fragmented Twin runtime services into a coherent Twin/AI Workbench runtime;
create or harden Configuration Manager and Activation Bridge;
maintain clear separation of Spine, Spine Cache, Blobs, Business Memory, Personal Memory, AI Memory, Session Logs and Audit Logs even if physically co-located;
consolidate agent registry/workflow semantics into Capability Fabric and ADK boundaries;
keep Governance separate from Hermes execution;
move direct provider/writeback behavior behind outcome, verification, reconciliation and governed writer contracts;
ensure gateway/ADK middleware cannot silently bypass Governance or create implicit approval;
treat legacy n8n/product-plane orchestration or direct spine.write semantics as migration evidence rather than final doctrine.

Readiness must be evidence-based across at least: implemented, wired, deployed and verified end-to-end. Presence of code or a Wrangler manifest is not proof of production readiness. [I6][I7]

29. Market Context and Intended Differentiation

This section is external research, not the source of canonical product semantics.

The market is converging on several pieces of the same enterprise problem:

OpenAI Frontier: business context, institutional memory, agent execution, identity/permissions and improvement loops. [E1]
Asana: humans and agents working from the same plan/context/governance. [E3]
Microsoft: agents increase execution capacity while humans direct and own outcomes. [E2]
MuleSoft Agent Fabric: discover, orchestrate, govern and observe agents/MCP across ecosystems. [E5]
Glean Enterprise Graph: organization-wide context plus personal graphs feeding AI and actions. [E6]
Atlassian Teamwork Graph: connected people, goals, work, code, content and decisions made available across agent surfaces. [E7]
Palantir Ontology: operational semantic model, decision lineage and human-agent workflows. [E8]
ServiceNow AI Control Tower / Workday ASOR: centralized agent lifecycle, identity, governance, approvals, monitoring and audit. [E9][E10]

SpineWorkspace should therefore avoid claiming that “shared context,” “agent governance,” “enterprise graph” or “human-agent teamwork” is individually unique.

The intended differentiation is the combined operating model:

a self-organizing primary Human Workbench;
a first-class AI Workbench for Twin and Spine Agents;
a shared Business Context Spine owned by the organization;
separate Personal Contextual Memory and AI Continuity Memory;
Work as the durable unit of human-agent handoff;
provider-neutral Capability Fabric and model/runtime replaceability;
human authority separated from AI cognition and execution coordination;
execution closure through re-ingestion, verification, reconciliation and rehydration;
one coordination fabric across many user, AI, API and source-system surfaces.

That combination is the product thesis to prove in Customer Zero and customer deployments.

30. Canonical Product Formula

SpineWorkspace
=
Shared Business Context and Organizational Continuity
+
Human Workbench + Personal Contextual Memory
+
AI Workbench + AI Continuity Memory
+
Shared Work State
+
Twin + Spine Agents
+
Projection and Context Assembly
+
Capability Fabric
+
Human/Policy Governance
+
Hermes Execution
+
Verification and Reconciliation
+
Continuous Rehydration

The platform formula underneath is:

IntegrateWise Platform
=
One Auth
+ Configuration
+ Integration Manager
+ Discovery
+ Activation
+ Gateway / Loader / Four Flows
+ Normalizer / Triage / Governed Writers
+ Business Context Spine Fabric
+ Knowledge / Evidence / Memory / Cache / Events
+ Projection / Human UI / AI Context Assembly
+ Model Routing / ADK / Agents
+ Capability Fabric / Governance / Hermes
+ Sync / Verification / Reconciliation
+ Audit / Observability / Security / Tenancy
+ Distribution through Workbench, Continuity Bridge, MCP, APIs and SDKs

31. Final Master System Map

                         ORGANIZATION
              Mission · Objectives · Goals · KPIs
                              │
                              ▼
                 BUSINESS CONTEXT SPINE
        Shared Truth · Work · Relationships · Decisions
       Evidence · Knowledge · History · Organizational Memory
                              │
              ┌───────────────┴───────────────┐
              │                               │
              ▼                               ▼
       HUMAN WORKBENCH                   AI WORKBENCH
       Primary Product                   AI Operations
              │                               │
              ▼                               ▼
   PERSONAL CONTEXTUAL                 AI CONTINUITY
        MEMORY                            MEMORY
              │                               │
              └──────────── SHARED WORK ──────┘
                              │
                       HUMAN ↔ TWIN
                              │
                        SPINE AGENTS
                              │
                       AGENT HANDOFFS
                              │
                              ▼
                   CAPABILITY DISCOVERY
                              ↓
                    CAPABILITY FABRIC
                              ↓
                        GOVERNANCE
                              ↓
                          HERMES
                              ↓
       API · MCP · Agent · Browser · Workflow · AI · Human
                              ↓
                           OUTCOME
                              ↓
                SYNC · VERIFY · RECONCILE
                              ↓
                    BUSINESS CONTEXT SPINE
                              ↓
           MEMORY / KNOWLEDGE / CONTINUITY UPDATE
                              ↓
                    NEW AUTHORIZED PROJECTIONS
                              ↓
              HUMAN + AI WORKBENCH REHYDRATE
                              ↓
                          NEXT WORK

Under the entire experience sit One Auth, Configuration Manager, Integration Manager, Connector Marketplace, Discovery, Activation Bridge, Gateway, Loader, Flow A/B/C/D, Normalizer, Triage, Governed Writers, Spine Cache, Knowledge, Blobs/Evidence, events/queues, model routing, ADK, agent registry/runtime, IW Spine Network MCP, MCP Pool, Capability Fabric, Governance, Hermes, Sync, Verification, Reconciliation, audit, observability, security, tenancy, billing/entitlements and the developer platform.

31A. Supersession Map - August 1 Baseline to August 31 Founder Canon

August 1 baseline	August 31 Founder Canon
IntegrateWise Workbench as daily product name	SpineWorkspace is the product; Human Workbench is its primary user operating surface
Twin as the main AI-side product concept	AI Workbench is the AI operating environment; Twin is the human-facing cognitive coworker within it
Twin Memory broadly described as durable user/Twin continuity	Personal Contextual Memory and AI Continuity Memory are explicitly separate first-class scopes
Adaptive Spine includes memory/continuity generally	Business Context Spine / Organizational Memory is the shared organizational continuity scope; personal and AI continuity stay separate
Workbench projection is primarily user-facing	Projection/context composition is explicitly dual-sided: Human Workbench projection and AI Workbench context
Agent-to-agent route is a Capability Fabric path	Spine Agents are elevated into the operating model and coordinate through durable Work state and evidence
OODA defined as Workbench interaction grammar	OODA is retained as internal operating grammar; the user experience stays natural and task-centric
Platform/product/experience are three profiles	The final documentation order becomes Experience → Product → Shared Context/Memory → Human/AI operating model → Platform → Execution/Continuity → Implementation
Architecture freeze is canonical	August 1 is now implementation baseline where not superseded; August 31 founder decisions are product authority

This table is the migration guide for updating repository canon without accidentally reviving stale terminology.

32. Canonical Vocabulary

Term	Final meaning
IntegrateWise	Infrastructure platform for connected human-AI work and organizational continuity.
SpineWorkspace	Primary product and shared work environment.
Human Workbench	Primary user-facing operating surface inside SpineWorkspace.
AI Workbench	AI-side operating environment for Twin and Spine Agents.
Business Contextual Spine Fabric	Shared organizational context, truth, work, evidence, history and continuity substrate.
Business Context Memory / Organizational Memory	Durable organization-owned memory that has passed the appropriate governance/promotion boundary.
Personal Contextual Memory	User-bound personal work continuity, private by default.
AI Continuity Memory	Twin/agent working continuity; not canonical business truth.
Work	Durable unit of human-AI coordination and handoff.
Twin	Contextual human-facing cognitive co-worker.
Spine Agent	Governed AI worker operating on Work and authorized Spine context.
Projection Engine	Sole composer of authorized versioned Workbench/context contracts.
One Auth-to-Ecosystem	Identity, tenant, consent, scope, delegation and service-principal authority context.
Integration Manager	Connection lifecycle, OAuth, mappings, webhooks, discovery and sync policy.
Activation Manager	Administrative surface for activating tenant capabilities/context.
Activation Bridge	Runtime compiler of configuration, connections, identity, context, policy and capabilities.
Continuity Bridge	Distribution/access boundary for external AI/application surfaces.
IW Spine Network MCP	Hosted outward MCP boundary for IntegrateWise.
MCP Pool	Inward tenant registry of approved MCP servers/tools.
ADK	Agent Development Kit and governed agent runtime contract.
Capability Fabric	Provider-neutral registry/resolver for how authorized intent can be performed.
Governance	Authority boundary: allow, deny, require approval or bounded delegation.
Hermes	Coordinator of approved execution and its operational lifecycle.
Outcome Event	Observed provider result, not automatically verified truth.
Verification/Reconciliation	Expected-vs-actual closure that determines whether business reality changed as intended.
Continuity Run	Traceable lifecycle from intent through execution, outcome, reconciliation and rehydration.
OODA	Internal Observe-Orient-Decide-Act product/continuity grammar.

Retired/constrained concepts: “AI Orchestrator” as a monolith; “Spine database” as the product definition; direct agent canonical writes; provider success as final truth; Continuity Bridge as the full product; MCP as the core data plane; a blank manually-built workspace as onboarding.

33. Product Acceptance Tests

A customer-facing SpineWorkspace release should prove that:

A user can authenticate, bind to a tenant and connect controlled systems.
Initial hydration produces a valid Business Context Spine rather than an empty shell.
Human Workbench composes useful cross-tool context from the Spine.
Personal Contextual Memory persists the user’s working continuity without silently becoming organizational truth.
AI Workbench/Twin receives authorized business context plus AI Continuity Memory.
Twin can explain current work with evidence and prepare an action/proposal.
A Spine Agent can take a subtask with identity, Work state, context and authority, then hand off without losing continuity.
Capability Fabric can resolve a provider-neutral capability to an executable route.
Governance can allow, deny or require approval based on identity/risk/policy.
Hermes executes only an authorized plan and returns outcome evidence.
The provider outcome is re-ingested, verified and reconciled.
The Business Context Spine updates only through governed canonical writes.
Both Human Workbench and AI Workbench rehydrate from the verified new state.
The full chain is reconstructable through trace, approval, capability, execution, evidence and reconciliation lineage.
A model, connector or agent can be replaced without losing the organization’s continuity record.

If the product cannot close this loop, the platform is not yet embodied in the product experience.

34. Final One-Sentence Definitions

SpineWorkspace:

SpineWorkspace is a self-organizing shared workspace where humans and AI work from the same governed business context, each with its own continuity memory, so humans can focus on judgment and responsibility while AI handles context assembly, preparation, coordination and permitted execution.

IntegrateWise:

IntegrateWise is the infrastructure platform underneath SpineWorkspace that connects the organization’s systems, preserves business context and continuity, projects the right context to humans and AI, and coordinates governed capability execution through verification and reconciliation.

The doctrine:

Humans govern. AI helps. Spine preserves continuity.

Appendix A - Research and Authority Basis

Founder-authority sources

[F1] Founder decisions and consolidation conversation, 31 August 2026: Human Workbench as primary product; first-class AI Workbench; separate Personal Contextual Memory and AI Continuity Memory; shared Business Context Spine/organizational memory; Spine Agents/shared Work; first-class user experience; internal UI/AI pipelines and OODA; full underlying platform/execution retained in-product.
[F2] Late-August SpineWorkspace master-system consolidation and visual direction, including the separation of SpineWorkspace (product) from IntegrateWise (infrastructure platform).

Internal / project sources

[I1] docs/architecture/CANONICAL_PLATFORM_ARCHITECTURE.md, IntegrateWise live repository, v3.0.0, freeze 2026-08-01.
[I2] docs/architecture/PRODUCT_ARCHITECTURE.md, v4.0.0, freeze 2026-08-01.
[I3] docs/architecture/CANONICAL_GLOSSARY.md, freeze 2026-08-01.
[I4] docs/architecture/DISTRIBUTION_AND_MARKETPLACE.md, freeze 2026-08-01.
[I5] docs/architecture/ONBOARDING_FLOW.md, canonical onboarding doctrine, downstream of August architecture.
[I6] docs/architecture/CAPABILITY_FABRIC.md, current capability architecture / readiness doctrine.
[I7] docs/architecture/CODEBASE_ALIGNMENT_SPEC.md, active service-to-plane alignment plan.
[I8] docs/architecture/USER_SYSTEM_JOURNEY_BLUEPRINT.md, historical/as-built journey evidence, downstream of current canon.
[I9] Design Spine Fabric Architecture.txt, project working paper: Spine Fabric, Work, Handover, MCP Pool and continuity.
[I10] IntegrateWise Product Structure.txt, project working paper: continuity ontology, namespace separation, resolver, projection.
[I11] MCP Routing Implementation Review.txt, project working paper: Projection Engine, Workbench, OODA, Capability Fabric, Governance, Hermes.
[I12] AI-Action-Buttons (2).md, project working paper: OODA and four canonical interaction actions.
[I13] One Model Versus Routing.txt, project working paper: adaptive model routing and model-profile abstraction.
[I14] MCP_POOL_SETUP.md, Customer Zero MCP Pool working implementation notes.
[I15] Founder-provided SpineWorkspace master system diagram, 28 August 2026, used as visual consolidation reference.

External research - category and market validation

External research was re-checked on 31 August 2026. It is used to validate market direction - shared enterprise context, human-agent work, governance, execution and organizational learning - and is not used to invent missing IntegrateWise architecture.

[E1] OpenAI Frontier (current 2026 product framing). Official OpenAI materials describe Business Context connecting enterprise systems so AI coworkers can use the same information people do and build durable institutional memory, with Agent Execution plus explicit permissions and auditing.
[E2] Microsoft 2026 Work Trend Index, 5 May 2026. Official Microsoft research frames the emerging model as agents taking on more execution while humans direct work, make calls and own outcomes; it also argues that organizations need repeatable human handoffs, evaluation infrastructure and learning systems that capture work signals.
[E3] Asana, Operating System for Human-Agent Teams, 4 June 2026. Asana's official announcement emphasizes humans and agents working from the same plan, with the same context and under the same governance - market validation for shared work/context, not a definition of SpineWorkspace.
[E4] Asana State of Work Innovation / State of AI at Work. https://asana.com/resources/state-of-work-innovation and https://asana.com/resources/state-of-ai-work - busywork, information-flow and work-design research.
[E5] MuleSoft Agent Fabric. https://docs.mulesoft.com/general/agent-fabric-overview - discovery, orchestration, governance and observability for agents/MCP.
[E6] Glean Enterprise Context / Enterprise Graph. https://www.glean.com/platform/enterprise-context and https://www.glean.com/enterprise-context/enterprise-graph - enterprise and personal graph context for AI.
[E7] Atlassian Teamwork Graph. https://www.atlassian.com/platform/teamwork-graph - context across people, goals, work, content and connected apps for human/agent experiences.
[E8] Palantir Ontology. https://www.palantir.com/docs/foundry/ontology/why-ontology - evolving operational representation, decisions and decision lineage for humans/agents.
[E9] ServiceNow AI Control Tower. https://www.servicenow.com/products/ai-control-tower.html - AI asset discovery, governance, permissions, security and lifecycle management.
[E10] Workday Agent System of Record. Workday administration documentation - centralized agent registration, permissions, monitoring, governance and cross-system interaction.
[E11] Okta Businesses at Work 2026. https://www.okta.com/ja-jp/newsroom/press-releases/okta-businesses-at-work2026/ - application proliferation across organizations.

Appendix B - Suggested Canonical Repository Set

The repository should converge from many overlapping architecture files into a controlled set where a single top-level canon owns definitions and downstream documents explain implementation details.

docs/canonical/
  00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md
  01-PRODUCT-AND-EXPERIENCE.md
  02-BUSINESS-CONTEXT-SPINE.md
  03-HUMAN-WORKBENCH-AND-PERSONAL-MEMORY.md
  04-AI-WORKBENCH-TWIN-AGENTS-AND-AI-MEMORY.md
  05-WORK-CONTINUITY-AND-HANDOFF.md
  06-IDENTITY-CONFIG-INTEGRATION-DISCOVERY-ACTIVATION.md
  07-INGESTION-FOUR-FLOWS-AND-GOVERNED-WRITES.md
  08-PROJECTION-UI-AND-CONTEXT-COMPOSITION.md
  09-CAPABILITY-FABRIC-AND-ADK.md
  10-GOVERNANCE-AUTHORITY-AND-APPROVAL.md
  11-HERMES-EXECUTION-AND-PROVIDERS.md
  12-SYNC-VERIFICATION-RECONCILIATION.md
  13-MEMORY-KNOWLEDGE-EVIDENCE-AND-PRIVACY.md
  14-MCP-CONTINUITY-BRIDGE-MARKETPLACE-SDK.md
  15-SECURITY-TENANCY-AUDIT-OBSERVABILITY.md
  16-ONBOARDING-CUSTOMER-ZERO-AND-GO-LIVE.md
  17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md
  18-CANONICAL-GLOSSARY.md
  contracts/
  adr/
  archive/

00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md should be the only document allowed to redefine the architecture. All other files must declare whether they are canonical, downstream implementation specifications, evidence/readiness reports or archived history.

Appendix C - Founder Freeze Decisions - 31 August 2026

For the next canonical repository freeze, the following founder decisions are treated as resolved. They supersede older product framing where conflict exists:

Product brand: SpineWorkspace.
Company/platform brand: IntegrateWise.
Primary human product: Human Workbench inside SpineWorkspace.
AI-side operating environment: AI Workbench.
Human AI interface: Twin.
Specialized AI workers: Spine Agents operating on shared Work state.
Shared organization-owned continuity: Business Context Spine / Organizational Memory.
Human continuity: Personal Contextual Memory, private by default.
AI continuity: AI Continuity Memory, separate from canonical truth.
Shared coordination object: Work, backed by context, authority, evidence and lineage.
Context assembly: Projection Engine / authorized context contracts; no UI or agent independently reconstructs truth.
AI routing: model-profile resolver; no model version is part of the durable product contract.
Agent runtime: ADK + governed agent contracts.
Capability selection: Capability Discovery + Capability Fabric.
Authority: Governance.
Execution coordination: Hermes.
Completion: only after outcome re-ingestion, verification and reconciliation.
MCP outward: IW Spine Network MCP.
MCP inward: MCP Pool.
External AI distribution: IntegrateWise - Continuity Bridge.
Physical storage: implementation detail beneath the logical Spine contract and deployment ADR.
Public user experience: infrastructure complexity is hidden unless the user is an authorized platform operator.
Internal UI pipeline: Projection Engine → Workbench Contract → UI Composition is part of the product but not a normal-user concept.
Internal AI pipeline: Business Context + AI Continuity + Work + Evidence + Authority + Capabilities → AI Context → Twin/Agents is part of the product but not a normal-user concept.
OODA: retained as internal operating grammar rather than a requirement that the interface expose four literal controls everywhere.
Authority precedence: 31 August founder decisions override the 1 August repository freeze on product/experience semantics until the repository is updated.