Canon

SpineWorkspace Canonical Operating Model

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

Humans govern. AI helps. Spine preserves continuity.

This document is the integrated, human-approved statement of the SpineWorkspace operating model,
consolidated from the founder source corpus listed in the frontmatter. Where the Founder Canon
(2026-08-31) and later founder records (2026-09-03/04) govern, they win; this document organizes
their content into one readable operating model. It is target-operating-model: it states what
the product is, not what the code yet implements. The delta between this model and the repository
is measured — evidence-only — in
17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md.

Document classes: this tree distinguishes current implementation, target operating model
(this document), accepted invariant (the laws in §14 and the ADRs), open question, and
planned capability. Claims below are model claims; implementation status lives in the register.

1. The one-sentence ontology

SpineWorkspace is a human–AI work coordination environment centered on Business Context, with
Spine Fabric providing contextual business memory and operational continuity, the Human
Workbench providing the human operating surface, the AI Workbench (Twin + Spine Agents) providing
the AI operating surface, and the IntegrateWise platform providing governed connectivity,
communication, capability and execution.

Founder framing (load-bearing): "We are not solving the memory problem for AI only — humans
are the core actors who need one working surface without juggling and context switching. From
tools we extract the context and business context." The model therefore splits into two paths:

System path — sources feed Loader → Normalizer → Triage → Spine → Projection → Governance →
Hermes → providers → re-ingestion → reconciliation → Spine. It preserves truth and moves it
safely.
User path — one human enters one Workbench, sees a role-projected view of current work,
with the Twin assisting inside the work. It reduces context switching.

Core loop in one line: data from connected tools comes to the Spine, is projected into the
workspace, and approved actions and events go back to the tools and return as reconciled truth.

2. Product hierarchy and naming

Level	Meaning
IntegrateWise	Company and infrastructure platform (`integratewise.ai`).
SpineWorkspace	The product and daily working experience (`spineworkspace.com`).
Spine Context & Continuity System	Business Context Spine + Personal Contextual Memory + AI Continuity Memory.
Human Workbench	Primary user-facing operating surface.
AI Workbench	AI-side operating environment hosting Twin and Spine Agents.

Never call IntegrateWise the product; never call SpineWorkspace the company. The dual-domain rule
(integratewise.ai company/platform · spineworkspace.com product) is frozen.

3. ONEAUTH — host-controlled entry and trust boundary

OneAuth is the single entry into the ecosystem and the first thing that executes for any
principal — human, Twin, agent, service, external AI host, automation or API client. It resolves:
user/agent identity, organization, workspace, host identity, roles and permissions, existing
host connections, allowed connector projections, available plugins, available MCP capabilities,
and activation policy.

OneAuth establishes the trust boundary before anything is installed, projected, synchronized
or executed. Host Identity + Host Connections + Organization Policy + User Entitlements = IntegrateWise Workspace Access.
OneAuth does not copy provider credentials. Provider credentials remain managed connection
artifacts owned by the host or Integration Manager; OneAuth supplies the shared organizational
authority context around them.
Deployment model — create once, deploy anywhere. One canonical Workbench runtime deploys
into multiple hosts (ChatGPT, web, Slack, Microsoft surfaces, embedded customer applications,
desktop shells, customer-hosted environments, marketplaces, agent hosts). The active host
contributes its authorized identity, tools and interaction model; domain logic is built once and
hosts are adapters. No host-specific forks of domain logic, Projection Engine logic or canonical
schemas.

4. DISCOVERY — eight forms, bootstrap contract, never authorization

Discovery has eight first-class forms: provider/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. Its output becomes the
workspace bootstrap contract that onboarding consumes. Host capabilities enter the runtime
only through explicit mechanisms — host-declared capability context, tool-result handoff,
workflow-level orchestration, explicit IntegrateWise connection, or installation manifest — and
expected availability is never proof of actual runtime access.

5. HOST-FIRST CAPABILITY ROUTING

Every request is classified before routing:

RequestScope: host-local | entity | continuity | cross-system | governance | write
completenessExpectation: local | best-available | canonical
requiresSpineEnrichment / requiresGovernance flags

Capabilities are modeled on two sides:

HostCapability — exposed by the active host under current user/workspace permissions;
availability: confirmed | declared | unknown (declared is never proof of access).
SpineCapability — canonical context or IntegrateWise-managed capability;
freshness: live | synced | historical; authority: system-of-record | canonical | derived;
adapter: nango | mcp | native.

Read precedence (default):

1. Confirmed host-native live capability
2. Spine canonical context
3. IntegrateWise-managed live connector
4. Spine Cache or historical Spine data
5. Request connection
6. Unavailable

The resolver MAY combine routes (Gmail host-native while Salesforce and Slack come from the
Spine). Write precedence (default): resolve canonical target and policy → create proposal →
determine allowed execution routes → prefer confirmed host-native execution when
policy-approved → otherwise IntegrateWise Capability Fabric → capture execution receipt →
normalize and reconcile → rehydrate Workbench and Spine Cache.

A ConnectionBinding maps a host connection, a canonical principal, and an optional
IntegrateWise integration. Governing principle: Host-first access. Spine-complete context.
Policy-governed execution. Canonical reconciliation.

6. CONNECTOR PROJECTIONS — managed connectors, never copies

IntegrateWise connectors are projections of connectors the host (or Integration Manager)
already owns — one connection supports multiple workloads without duplicating the provider
credential:

Host Connector
   ├── Workbench read projection
   ├── Loader synchronization projection
   ├── Twin search projection
   └── Approved write projection

Each connector projection carries: provider identity, connection reference, available resources,
allowed scopes, read/search/event/write capabilities, approval requirements, retention policy,
data classification, rate limits and revocation state. Boundaries: no unnecessary host refresh
tokens, no ownership of the source system, no replacement of the host connector manager, no
permissions wider than the host allows. The Connector Marketplace first discovers eligible
tenant connections and offers connection reuse; new systems are activated additively.

7. MARKETPLACES — three catalogs, one control surface

Catalog	Exposes	Key rule
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
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
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

Strict responsibility separation: Marketplace (discovery, publication, installation, trust) ·
MCP Pool (runtime registration, routing, sessions, health, isolation) · Capability Manager
(stable business capability mapping and authorization) · Governance (approval and policy
enforcement) · Orchestrator/Hermes (controlled invocation and completion).

8. ACTIVATION HUB — seven gated stages

Authenticate → Resolve Organization → Discover Host Connections → Select Connector
Projections → Install Plugins → Install MCP Capabilities → Configure Product Package
→ Hydrate Spine → Activate Workbench

Identity activation — authenticate, resolve host/org/workspace, apply entitlements.
Ecosystem discovery — host connections, connector projections, approved plugins/MCP.
Connection activation — select connections, review scopes, create projections, test
connectivity, set synchronization policy.
Package activation — resolve capabilities, initialize Spine Cache, establish Business
Context, register tools, configure orchestration.
Spine hydration — load, normalize, resolve entities, build relationships, establish
provenance, validate freshness.
Workbench activation — role views, domain plugins, initial pages, activate Twin, test
proposals and approvals.
Readiness confirmation — connections healthy · Spine operational · tools available · Twin
grounded · governance active · Workbench ready.

Onboarding doctrine: onboarding converts identity, marketplace selections and host capabilities
into a working workspace — blank state → useful work. Missing data appears as
readiness/freshness gaps over the mandatory operating contract, never as a reduced product.

9. PRODUCT PACKAGE — the workspace runtime kernel

ADK · Spine Cache · Orchestrator/Hermes · Cognitive Capability · Tool Capability ·
Continuity · Business Context · Discovery Engine · Connected Tools · Spine Network

ADK — agent contracts and runtime primitives; never determines access (only effective
capabilities granted by the Capability Manager).
Spine Cache — read-optimized, policy-filtered, LLM-readable projection; the default agent
read surface; the Spine remains the authority and the cache is always rebuildable.
Orchestrator/Hermes — intent → plan → policy check → approval → execute → verify →
reconcile; never bypasses connectors, policies or the Spine.
Cognitive Capability = understand, reason, generate, propose. Tool Capability = read,
write, invoke, execute. Formally distinct. Every tool capability declares input/output
contract, provider, risk level, side-effect classification, approval rule, retry policy,
idempotency behavior, audit requirement and reconciliation method.
Continuity — broader than memory: what happened + why + who decided + what remains open +
what should happen next; context follows the ongoing work.
Business Context — converts technical records into organizational meaning.
Discovery Engine — outputs the workspace bootstrap contract (§4).
Connected Tools — Discovered Tool → Capability Mapping → Scope Evaluation → Role Evaluation → Governance Evaluation → Effective Connected Tool. A connected tool is not
automatically usable.
Spine Network — the navigable relationship graph (entities, source identities,
relationships, connections, capabilities, tools, documents, knowledge, memory, signals,
decisions, actions) — the bridge between structured truth and the capabilities that act on it.

10. SPINE FABRIC — context substrate, never a copy

The Spine is not a database and not an ESB. It is a governed canonical context network: tools
connect once, and governed context becomes reusable — eliminating point-to-point connection
growth and the isolated-desert outcome. Source systems remain authoritative for their own
operational transactions; the Spine is the governed cross-system business context that connects
their meaning.

Four continuity primitives — everything derives from them: Event (timestamped, immutable,
causally linked) · Entity (persists across time) · Relationship (connects entities,
events, evidence, outcomes) · Synthesis (meaning emerged from repeated or combined
continuity).

Nine logical domains: Identity (tenants, users, teams, roles, permissions, policies) · Entity
(customers, contacts, accounts, projects, products, assets, vendors, employees) · Work (tasks,
work_items, queues, approvals, assignments, escalations, SLAs) · Communication (email threads,
calendar, meetings, chat, calls) · Knowledge (documents, notes, knowledge base, brainstorm
sessions, learning artifacts) · Memory (user_memory, work_memory, org_memory, conversation_memory,
agent_memory — HITL-gated) · Capability (connectors, mcp_tools, apis, ai_models, automations,
pipelines) · Governance (approval_records, audit_log, security_events, compliance_records,
policies) · Platform (billing, deployments, api_keys, observability, admin_actions).

Six storage layers: Postgres/D1 (structured truth anchor) · Redis/KV (hot state, sub-100ms,
not truth) · R2 (blobs linked by reference, never queried directly) · Conversational store (raw
channel events; classify → extract → promote) · Vector/pgvector (semantic intelligence; hybrid
cosine + BM25 + RRF) · Agent memory (durable per-scope state, HITL-gated writes).

Eleven state planes (preserved even when physically co-located): Business Context Spine ·
Personal Contextual Memory · AI Continuity Memory · Spine Cache · Knowledge · Blobs · Session
Logs · Audit Logs · Sync State · Config State · Ephemeral Runtime.

Standard envelope on every tenant-owned table: id, tenant_id, workspace_id, version, status, created_at, created_by, updated_at, updated_by, trace_id, correlation_id, metadata — canonical
fields as typed columns; additive domain/connector attributes in versioned JSONB under a
registered schema module; secrets only as vault references; append-only event/audit/version
tables.

Effective Spine (additive-only):

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

No expansion may remove tenancy, provenance, authority, evidence, lifecycle, sync or
reconciliation contracts. Missing data is coverage/readiness state, not a removed contract.

Ingestion chain: Gateway (tenant-aware ingress) → Loader Runtime (sole outer ingestion and
canonical-write entry; preserves source identity, provenance, evidence, replay; four flows: A
structured, B unstructured, C AI continuity, D platform binding — Flow D first, always) →
Normalizer (deterministic validation/mapping/dedup) → Schema Synthesis → Entity Resolution
(Salesforce Account + Stripe Customer + HubSpot Company → canonical Account) → Relationship and
Event linking → Domain mapping → Triage → Governed Spine Writers.

Triage doctrine: Triage classifies. Governance decides. The Pipeline promotes. Spine owns
organizational memory. Twin consumes the governed result. Triage classifies, links, dedupes,
detects conflicts/ambiguity, evaluates materiality/sensitivity/freshness/completeness, proposes
memory scope, stages candidates and routes review. Triage never becomes a canonical writer.

11. PROJECTION — sole composer, dual-sided

The Projection Engine is the sole producer of versioned SharedWorkbench contracts. Gateways,
BFF routes, UI modules and agents request authorized projections; none independently assemble
canonical truth or read physical stores. Resolution formula: Role × Department × Industry × Connector Category × Active Context × Policy.

Role Workbench grammar: twelve role workbenches (Founder→Strategic Objective, Customer
Success→Account, Sales→Opportunity, Support→Ticket, Project Management→Project,
Marketing→Campaign, Business Operations→Process, Technology→Service, HR→Employee, Finance→Invoice,
Legal→Contract, Personal→Personal Task) with genuinely role-specific entity sets; a shared
16-section grammar (Home/Role Brief, My Work, Primary-Entity Portfolio, Entity 360,
Pipeline/Queue, Timeline, Calendar, Communications, Documents & Knowledge, Signals & Risks,
Approvals, Planning Canvas, Reports & Metrics, Automation & Playbooks, Recent Work, click-triggered
Twin Detail); 13 shared UI primitives, each with exactly one backend owner (Governance owns the
approval block; the Twin Runtime is restricted to read and propose).

Click → context → Twin: 64 click contexts per role (16 sections × open/row/edit/assign) map
to an Active Context Bundle, loaded records, a retrieval query, an OODA stage, expected Twin
output, mutation type, approval requirement and persistence mode. Four interaction primitives:
Store in Spine · Ask Twin · Assign Twin · Approve Twin Action — only the last reaches Hermes
and a provider. The Twin is a click-triggered contextual panel, never a permanent sidebar. The UI
tuner proposes versioned projection patches; it never rewrites components.

12. DUAL WORKBENCHES, THREE MEMORIES, COWORKER

Invariant: shared business reality; separate participant continuity; governed promotion between
scopes.

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

Personal Contextual Memory — the human's working continuity; private by default; only the
owner may cite it; promotion to organizational memory is an explicit governed transition.
AI Continuity Memory — Twin/agent working continuity across turns, model changes, sessions
and handoffs; never organizational truth.
Coworker — the contextual companion between active Workbench use and the Twin: observes
active work, gathers context, retrieves relevant information, supports communication, keeps
human/Twin context aligned. Not a second authority.
Twin — one bounded Twin per user; understands, contextualizes, triages, allocates, plans/
proposes, delegates, executes through governed capabilities, verifies, reports, adapts. OODA
(Observe→Orient→Decide→Act) is the internal grammar; the user experiences Store in Spine / Ask
Twin / Assign Twin / Approve Twin Action.
Spine Agents — governed organizational actors with identity, tenant, purpose, owner,
delegated authority, scopes, capability access, memory namespace, runtime/model profile, risk
policy and audit identity. They cooperate by reading and updating shared Work state and
returning evidence — Agent A performs sub-work → writes evidence → handoff recorded → Agent B
reads the same authorized Work context and continues.
Model independence — the model is a replaceable reasoning provider selected by stable
profiles (fast, reasoning, code, specialized); no model version is part of the durable
contract.

13. WORK, CAPABILITY, GOVERNANCE, HERMES, CLOSURE

Work is the durable coordination unit — work_id, objective, business-context references,
owner/responsible human, current executor, state and lifecycle, subtasks/dependencies, evidence,
commitments, proposals, policy/authority envelope, available capabilities, expected outcome,
actual outcome, handoff history, trace and continuity identifiers.

No participating worker begins meaningful work without a Spine-derived authorized context and
Work identity. — applies to humans, Twin, Spine Agents, ADK runtimes, workflows and providers.

Context Packages — agents receive a bounded package (tenant, work, purpose, relevant
entities/state, constraints, authority, allowed capabilities, evidence, freshness, sensitivity,
expiry, provenance), never unrestricted organizational memory.

Communication protocols: MCP = AI ↔ tool/resource/capability interoperability.
ACP = Agent ↔ Agent / Agent ↔ Twin through governed work/context handoff, carrying Work ID,
Task ID, sender/recipient, capability, context reference, authority scope, constraints, expected
output, evidence requirements, status, result, attribution, correlation/causation IDs. Neither
MCP nor ACP grants authority. The Active Context Bundle carries actor, host
(type/session/capabilities-observed-at), entities, relationships, continuity, commitments,
signals, decisions, evidence, available actions, policy and a completeness level
(host-local | partial | canonical with missing systems named).

Execution chain:

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

Governance outcomes: ALLOW · DENY · REQUIRE APPROVAL · DELEGATE / ALLOW WITH BOUNDED
AUTHORITY. Confidence never grants authority. The Twin cannot self-approve consequential action
or bypass Governance. Hermes starts only after a plan is approved or policy-allowed; it does
not decide allowance and never owns canonical truth. Traceability: trace_id, correlation_id,
causation_id, event_id, approval_id, capability_run_id, execution_id, idempotency_key,
verification_id, reconciliation_id, continuity_run_id.

14. THE BRIDGE — many surfaces, one continuity substrate

The "one channel" thesis does not mean one literal chat application. It means every participating
surface — Human Workbench, email, chat, mobile, source applications, external AI hosts, MCP
clients, agents, webhooks, APIs — converges on the same coordination model:

… → Identity → Authorized Context → Work/Event → Authority → Capability → Execution
→ Evidence → Reconciliation → Business Context Spine

The Bridge is the governed communication substrate carrying messages, context references,
decisions, approvals, agent handoffs and execution signals. Every Bridge message carries or
resolves to: tenant, principal, sender, recipient, Work ID, task ID, communication type,
purpose, context reference, capability reference, authority context, source channel,
correlation/causation IDs, timestamp, provenance, sensitivity, status. Channels: human
(Workbench chat, Slack, email, Teams, meetings, calls), agent (ACP, work handoff, context
reference, agent result, escalation), system (API, webhook, event bus, workflow event, MCP,
connector event). Communication-derived content becomes organizational memory only via evidence →
triage → candidate → governance → promotion. An approval received through Slack must be converted
to a verified, immutable approval event — a Slack reaction alone is never an authority bypass.
The Bridge is not a memory store, not a canonical database, not a Slack/email replacement, not an
authority bypass.

15. MEMORY PROMOTION AND KNOWLEDGE EVOLUTION

Actual State → Event → Evidence → Context → Interpretation → Triage → Candidate
→ Governance → Organizational Memory → Updated Spine → Future Context

Knowledge emerges from processed outcomes, not from raw data or raw model output.
User thought ≠ AI inference ≠ Organizational truth. Personal and AI memory may inform context
assembly; neither silently becomes organizational truth. Spine Cache can always be rebuilt;
cache never becomes truth.

16. GTM, CUSTOMER ZERO AND GO-LIVE

Wedge: Account Success / Customer Success — initial market India SMB SaaS (20–200 employees,
5–20 CSMs, ~USD 5k–50k ACV, HubSpot/Freshworks/Zoho/Freshdesk/Jira/Slack estates),
no replacement of existing systems. Tier B: digital/IT services. Tier C: operations-heavy SMB.

Customer Zero: IntegrateWise operates IntegrateWise on the same substrate — the first real
tenant, preserving the company's own operating history. Lifecycle-first: a company runs through
recurring lifecycle events (Company lifecycle → operating lifecycle → event → state transition →
SOP → activities → records/evidence → AI preparation → human decision/approval → capability
execution → verification → memory → next event), not through department silos.

Go-live: development → CI/contract tests → Customer Zero → CZ evidence → version freeze →
clean external tenant → plugin/MCP submission ready → public publication. Until the full chain is
demonstrated with telemetry, rollback, security and operational support, release classification
remains Customer Zero / controlled beta — packaging, manifests or declared tools never prove
operational readiness.

17. TWENTY CANONICAL LAWS

IntegrateWise is the company; SpineWorkspace is the product.
Business Context is the core product concern.
Spine Fabric is contextual business memory and operational continuity.
One canonical organizational reality; many governed projections.
AI never directly reads or writes canonical Spine.
AI operates in a bounded Operational Sandbox.
Work is the primary coordination unit.
Work Allocation determines who/what performs each part of Work.
Every user has one bounded Twin.
Coworker gathers active context and supports communication.
Triage never becomes a canonical writer.
Capability defines what; Execution Fabric defines how.
Governance controls consequential mutation.
ACP communicates work/context; it does not grant authority.
MCP is a tool/resource/capability interoperability mechanism.
Source execution must return through re-ingestion and reconciliation.
Memory informs organizational truth; it does not silently become organizational truth.
Organizational Memory is published only through governed promotion.
Personal/reversible adaptation may auto-tune; shared/consequential change requires governance.
IntegrateWise Platform remains substrate, not a second Workbench.

These laws are individually recorded as ADRs 2026-09-04-04 … 2026-09-04-13 where they carry
implementation consequence (see adr/).

18. ACCEPTANCE TESTS (product embodiment)

A release proves the model when: a user authenticates, binds to a tenant and connects controlled
systems · initial hydration produces a valid Business Context Spine, not an empty shell · the
Human Workbench composes useful cross-tool context · Personal Contextual Memory persists without
silently becoming organizational truth · the AI Workbench receives authorized context plus AI
Continuity Memory · the Twin explains current work with evidence and prepares a proposal · a
Spine Agent takes a subtask with identity, Work state, context and authority and hands off without
losing continuity · the Capability Fabric resolves a provider-neutral capability to an executable
route · Governance allows/denies/requires-approval/delegates by identity, risk and policy ·
Hermes executes only an authorized plan and returns outcome evidence · the provider outcome is
re-ingested, verified and reconciled · the Spine updates only through governed writes · both
Workbenches rehydrate from verified state · the chain is reconstructable through lineage IDs · a
model, connector or agent can be replaced without losing the organization's continuity record.

19. Open questions and controlled ambiguities

Tracked in 17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md
(open-questions section) and the source-corpus provenance record. Known controlled ambiguities as
of this version: physical store split (D1 vs Neon per the four-plane hybrid ADR) beneath the
logical contract; unified OneAuth entry resolution vs distributed gateway middleware; A2A/ACP
transport implementation; Coworker runtime actor naming (restored as a concept by
ADR-2026-09-04-03; carried today by the Collaboration Log Agent).