<!-- DOCUMENT CLASS: INTERNAL | SOURCE: 02_INTEGRATEWISE_SPINEWORKSPACE_ARCHITECTURE_v3.2.md --> <!-- STATUS: SUPerseded by Founder Canon for product/experience semantics --> <!-- retained for implementation contracts and technical architecture details -->

IntegrateWise — SpineWorkspace Product and Platform Architecture

This document is superseded by the Founder Canon for product framing, terminology and experience architecture. See docs/canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md (31 August 2026) as the authoritative source. This file is retained for implementation contracts, technical architecture details and historical reference.

Status: RETAINED for technical contracts · Superseded for product framing
Version: 3.2 (human–AI work coordination, contextual business memory, Workbench IA and Bridge architecture)
Date: 2026-08-25 · doctrine updated; Part III remains a dated repository snapshot at commit 2187bc91
Supersedes: every other document in docs/architecture/ for technical contracts. See Appendix L.
Superseded by: docs/canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md for product/experience semantics.

---

How to read this document

This is the primary architecture document. SPEC_AMENDMENTS_v1.md
is its one canonical amendment and supersedes conflicting statements in this document.
Together they win over AGENTS.md, CLAUDE.md, and any file in docs/architecture/ not
listed as Retained in Appendix L.

Three parts, read in order or entered at any heading:

Part	Answers	Changes
I — Foundations	Why the system is shaped this way	Rarely. A change here is a major version.
II — The System	What each part owns and where the boundaries are	Slowly. Implementations improve; responsibilities do not move.
III — Reality	What is actually built, what has drifted, what is undecided	Continuously. Dated evidence, not aspiration.
Appendices	Exact tables, routes, bindings, contracts	With the code.

Reader map

Use this document as the single map; follow retained specifications only when a team needs
the lower-level contract named here.

Reader	Read first	Then use
Product and go-to-market	§1–§5, §11–§13, §16	The product/package boundary, marketplace roles and verified-versus-intended labels in Part III
Application engineering	§7–§12	Projection, context, capability and approval contracts; Appendices C–H for code entry points
Platform and data engineering	§6–§10, §14–§15	Store ownership, Flow D before A/B/C, ingestion, promotion, reconciliation and runtime profiles
Security and compliance	§2.2, §8.2a, §10, §14, §17	Tenant/consent boundary, least privilege, approval tokens, provenance, audit and release isolation
Operations and release	§17–§22	Verified deployment surface, drift register, stop-ship invariants and unresolved decisions

Evidence labels

Statements in Parts I and II are the governing doctrine / intended target unless marked
otherwise. Part III remains the repository-grounded implementation record from 2026-08-13 at commit 2187bc91; it is historical evidence and must not be mistaken for the current doctrine.
The following labels are used in diagrams and matrices:

Label	Meaning
LAW	Non-negotiable product or security invariant. Implementation must conform.
VERIFIED	Present in code, configuration or tests in this checkout. This does not by itself prove live deployment.
INTENDED	Required target contract, retained even when the complete runtime is not yet wired.
DRIFT	Present implementation contradicts or bypasses the target contract.
DECISION	The repository cannot safely settle the choice; named owner input is required.

Non-negotiable laws, in one page

0. Tier-0: Business Context Law. Business Context is the semantic foundation of SpineWorkspace. It connects organizational business reality to Work, Humans, AI, Agents, Memory, Knowledge, Capabilities, Communication, Decisions, Governance, Execution, Evidence, Continuity and Outcomes. Without Business Context, SpineWorkspace has no meaning. The Spine gives work its business context. If a feature cannot explain how it relates to Business Context, Work, or a Business Outcome, it does not yet have a meaningful place in SpineWorkspace.
1. Company/Product Law. IntegrateWise is the company. SpineWorkspace is the product.
   IntegrateWise provides the platform substrate; SpineWorkspace is what the customer uses to
   coordinate human–AI work.
2. Organization-to-Work Law. The organization defines goals, objectives, needs and
   standards. Those objectives cascade into domain- and role-aligned work without creating
   departmental copies of truth.
3. Spine Fabric Law. The Business Context Spine is THE semantic foundation. It IS the organization's memory — the connected representation of entities, work, state, relationships, events, decisions, evidence, provenance and memory. Without it, nothing in SpineWorkspace has meaning. Personal Contextual Memory and AI Continuity Memory are working continuities that serve Business Context; they are not equal peers to it.
4. Canonical Truth Law. The canonical Spine is owned and governed by the organization.
   AI does not read or write canonical storage directly.
5. AI Sandbox Law. AI operates only on a bounded, tenant-, user-, role-, task- and
   policy-scoped operational sandbox derived from Spine Fabric and current execution context.
   Sandbox state is working material, not canonical truth.
6. Projection Law. Humans see shared organizational truth through role-, domain-,
   responsibility- and permission-aware projections. A projection is a view of shared truth,
   never a new source of truth.
7. Work Law. Work, not the task or application, is the primary unit of coordination. A
   piece of work may contain tasks, decisions, communications, approvals, research, execution,
   exceptions and outcomes across people, AI and systems.
8. Work Allocation Law. SpineWorkspace continuously determines who or what should perform
   each part of work — human, Twin, agent, system or human + AI — using capability,
   responsibility, authority, risk, context, urgency, cost and need.
9. Twin Law. Each user receives a bounded Twin as their AI work partner within the AI Workbench. The Twin reasons, coordinates, delegates and monitors work over Business Context, but never owns canonical truth or authority. The AI Workbench is the machine-side operating environment; Twin is the human-facing cognitive participant within it.
10. Coworker Law. The Coworker is the contextual companion that observes the user's active
    work surface and interaction, assembles relevant context, supports communication and keeps
    the user's work and Twin context aligned without becoming a second authority.
11. Capability Law. A capability describes what can be done; the Execution Fabric determines
    how it is performed. APIs, MCP, workflows, agents and provider tools are implementations,
    not business capabilities themselves.
12. Governance Law. Authority, policy, risk, evidence, approval and accountability are
    evaluated before consequential mutation. Confidence never grants authority.
13. Reconciliation Law. External execution is not complete when a provider returns success.
    The observed result must be re-ingested, reconciled and reflected back into the governed
    operational model.
14. Continuity Law. Work remains coherent across time, people, tools, AI hosts and domains
    through bounded continuity, not through unrestricted sharing of memory or credentials.
15. Platform Law. IntegrateWise's platform is broad underneath and narrow at the product
    surface. It supplies identity, connectivity, AI, execution, communication, governance,
    infrastructure and metering; it does not become a second Workbench.

System boundary — target contract

flowchart TD
  Org["Organization: goals · objectives · needs · standards"] --> WG["Work Graph: goals → work → entities → dependencies → outcomes"]
  Systems["CRM · ERP · Email · Chat · Docs · BI · Billing · other systems"] --> Conn["IntegrateWise Connectivity"]
  Conn --> Spine["SPINE FABRIC<br/>Contextual Business Memory + Operational Continuity"]
  Org --> Spine
  Spine --> Proj["Role / Domain / Responsibility Projection"]
  Proj --> WB["USER WORKBENCH<br/>Human operational surface"]
  Spine --> Sandbox["AI OPERATIONAL SANDBOX<br/>bounded, task-scoped, policy-filtered"]
  User["Human"] --> WB
  WB --> Work["Shared Work"]
  Sandbox --> Twin["USER TWIN<br/>AI work partner"]
  Twin --> Work
  Coworker["COWORKER<br/>context + communication companion"] --> WB
  Coworker --> Sandbox
  Work --> Allocate["WORK ALLOCATION<br/>Who/what should do what now?"]
  Allocate --> Human["Human"]
  Allocate --> AI["Twin / Agent"]
  Allocate --> System["System / Workflow"]
  AI --> Cap["Capability Fabric"]
  Human --> Cap
  Cap --> Gov["Governance"]
  Gov --> Exec["Execution Fabric<br/>MCP · APIs · workflows · agents · ADK"]
  Exec --> Systems
  Systems --> Reconcile["Outcome + Reconciliation"]
  Reconcile --> Spine
  Spine --> Proj
  Spine -. "never direct" .-> Twin
  Platform["IntegrateWise Platform<br/>Identity · Connectivity · AI · Execution · Communication · Governance · Infrastructure · Metering"] -. "substrate / control" .-> Conn
  Platform -.-> Gov
  Platform -.-> Exec

The central product loop is:

ORGANIZATIONAL GOAL / NEED
          ↓
       WORK GRAPH
          ↓
   SHARED BUSINESS CONTEXT
          ↓
    CONTEXT ASSEMBLY
          ↓
     WORK ALLOCATION
          ↓
     HUMAN + AI WORK
          ↓
        DECIDE
          ↓
       EXECUTE
          ↓
       VERIFY
          ↓
    RECONCILE OUTCOME
          ↓
   UPDATE CONTINUITY
          ↓
        NEXT WORK

The platform runtime is subordinate to this product loop. Configuration, ingestion, projection,
capability resolution, governance, execution, reconciliation and promotion exist to make the
human–AI work loop reliable.

A note on what this document is for. IntegrateWise accumulated 94 architecture
documents totalling 265,000 words. Sixteen were declared canonical. Six had "canonical" in
the filename. That is not a documentation problem — it is an architectural risk, because a
system whose architecture cannot be held in one head is a system whose invariants will be
violated by accident. The purpose of consolidating is to make the invariants cheap to
know.

---

Part I — Foundations

1. The problem this architecture solves

1.0 Company, product and differentiator

Name	Canonical meaning	Never use it to mean
IntegrateWise	The company and platform builder/operator	The customer-facing product, a workbench, a database or an AI agent
SpineWorkspace	The customer product: a human–AI work coordination environment grounded in Spine Fabric	The company, a raw database viewer, an integration-only product or an autonomous agent platform
Spine Fabric	The contextual business memory and operational continuity substrate inside SpineWorkspace	A single database, unrestricted data lake, AI memory store or public MCP
Workbench	The human-facing operational surface where role-specific work is understood and progressed	A separate departmental product
Twin	The bounded AI work partner assigned to a user	A generic chatbot or autonomous authority
Coworker	The contextual companion that assembles active-screen context and supports communication between human, Twin and systems	A second Twin, source-of-truth service or execution authority
AI Operational Sandbox	The bounded working dataset exposed to AI for a specific user/work/task	Canonical Spine, organizational truth or a write target
Platform	The IntegrateWise substrate providing identity, connectivity, AI, execution, communication, governance, infrastructure and operational metering	A second customer Workbench

1.1 The fundamental business problem

Organizations do not lack software. They lack continuity of work across software.
Business needs and objectives are distributed across people, departments, applications,
communication channels, documents, workflows and increasingly multiple AI systems. Each system
contains a partial operational view. Humans compensate by becoming the integration layer.

AI introduces a second, deeper problem:

Given the objective, context, capability, responsibility, authority, risk and current state,
who or what should perform each part of the work?

The industry is moving from task automation to a work-allocation problem. The meaningful unit is
not "what can AI automate?" but:

How should humans and AI share the work required to achieve the organization's goals?

SpineWorkspace exists to solve that problem.

1.2 Organizational model: goals become coordinated work

The organization is the top-level source of intent:

ORGANIZATION
   │
   ├── Goals
   ├── Objectives
   ├── Needs
   ├── Standards
   ├── Policies
   └── Operating priorities
            │
            ▼
       BUSINESS WORK
            │
      ┌─────┼───────────┐
      ▼     ▼           ▼
   Domain  Role       Responsibility
      │     │           │
      └─────┼───────────┘
            ▼
       INDIVIDUAL WORK
            │
            ▼
      HUMAN + AI SHARING
            │
            ▼
         OUTCOMES
            │
            ▼
      BUSINESS PERFORMANCE

The same organizational data is therefore available to many participants through different
projections. Role, department, domain and responsibility determine what is relevant and what
may be done, not which copy of the data exists.

1.3 The Work Graph

The Work Graph is the connected representation of organizational work. It relates:

• organizational goals and objectives
• domains, teams and responsibilities
• people and roles
• work and tasks
• business entities
• dependencies and blockers
• decisions and approvals
• capabilities and assignments
• human and AI participants
• communications and evidence
• executions and outcomes

A task is a component of work. A work item may span multiple systems, people, agents and
communications while remaining one continuity thread.

1.4 The architectural bet

The response is not to replace the systems where business work already happens, nor to attach a
separate assistant to every silo. IntegrateWise provides the substrate that connects those
systems into Spine Fabric. SpineWorkspace then projects the relevant organizational context into
the human Workbench and a bounded AI sandbox so humans and AI can operate on the same work without
sharing the same authority.

This creates a strict separation:

ORGANIZATIONAL TRUTH
        │
        ▼
   SPINE FABRIC
        │
        ├──────────────► Human Projection ──► Workbench
        │
        └──────────────► AI Operational Sandbox ──► Twin / Agents

Human and AI share WORK and CONTEXT.
They do not share unrestricted authority.

1.5 The value chain

Shared Context
      +
Human Capability
      +
AI Capability
      +
Correct Work Allocation
      +
Governed Execution
      +
Operational Continuity
      ↓
More Work Completed
      +
Shorter Cycle Time
      +
Higher Consistency
      +
Lower Operational Waste
      +
Better Decisions
      ↓
Improved Business Outcomes
      ↓
Potentially Higher Profitability

Profitability is an outcome, not a product guarantee. SpineWorkspace improves the operating
conditions that can produce it.

1.6 Four failure modes

Failure	Root cause	SpineWorkspace response
Fragmentation	Work and context scattered across systems	Spine Fabric + Connectivity
Human API	People manually bridge systems and explain context	Workbench + Coworker + Capability Fabric
AI amnesia / divergence	AI starts from a partial or stale view	Context Assembly + AI Operational Sandbox
Babysitting	AI can suggest but cannot carry governed work to completion	Work Allocation + Governance + Execution Fabric + Reconciliation

1.1 Contextual business memory is the product foundation

Spine Fabric is the core contextual business memory layer of SpineWorkspace. It converges fragmented operational context from the systems an organization already uses, preserves provenance and continuity, and provides governed projections for humans and AI.

The organization has one canonical operational reality. Users see role/domain/responsibility projections of that reality. AI does not own or directly mutate canonical Spine; it operates in the bounded Operational Sandbox.

Organization → Goals / Needs → Work
                         ↓
                    Connectivity
                         ↓
                  Spine Fabric
                    /       \
          Canonical Spine   Operational Sandbox
                 |                 |
          Projections           Twin / Agents
                 |                 |
          User Workbench     Twin Workbench
                 \                 /
                  ------ Shared Work ------
                           ↓
                      Execution
                           ↓
                      Reconcile
                           ↓
                         Spine

1.2 Triage and organizational memory

Triage is the cognitive intake boundary for Flow C. It classifies, links, evaluates conflicts and stages candidates. Triage never becomes the canonical writer. Organizational memory is produced only through the governed promotion path.

The authoritative sequence is:

evidence → triage → staging → human/governed review → promotion → organizational memory → projection

See TRIAGE_ORG_MEMORY_CANONICAL.md for the detailed contract.

2. Five commitments, and what each costs

Every durable property of this system follows from five decisions. Each is a genuine
trade-off, taken deliberately.

2.1 Truth lives outside the applications

Canonical operational state is assembled from connected systems into a store the
organisation owns, with provenance on every field.

Buys: cross-system questions become answerable; AI reasoning has ground to stand on;
the switching cost is accumulated verified memory rather than data hostage-taking.
Costs: an ingestion and reconciliation burden that never ends, and a permanent
consistency question — the Spine is eventually consistent with source systems, never
instantaneously. Every projection therefore carries freshness state, and "unknown" is a
legitimate answer the system must be able to give.

2.2 Governance is architecture, not policy

Proposal → approval → execution → audit is the physics of the system. No approval token,
no external mutation. This is not a setting, a middleware, or a default that can be turned
off; the execution path has no branch that skips it.

Buys: AI can be pointed at consequential work, because it structurally cannot act
alone. Regulation moves toward this posture, not away from it.
Costs: latency and friction on every consequential action, and a permanent design
tension with "just automate it." The tension is the product. Where it becomes intolerable,
the answer is narrower pre-authorised capabilities with thresholds — never a bypass.

2.3 Deterministic and adaptive systems are separated

Pipelines, synchronisation, normalisation and validation are deterministic. Reasoning,
planning, triage and learning are adaptive. They are different runtimes with different
authority, and the boundary between them is a hard one.

Buys: the parts that must be reproducible are reproducible. An AI failure degrades
suggestion quality; it cannot corrupt truth.
Costs: two systems where one might have seemed sufficient, and the discipline to keep
resisting "the model can just do the normalisation."

The corollary — confidence never grants authority — is the most frequently attacked
invariant in the system. A 0.99-confidence proposal and a 0.55-confidence proposal require
the identical approval to become real. Confidence describes evidence quality. It is an
input to human judgement, never a substitute for it.

2.4 One surface, composed per role

There is one Workbench. Role and department select the operational composition; the
tenant's activated industry schema supplies vocabulary, fields, relationships and policy
context within that composition. Industry never creates a separate product, separate
domain, separate database or separate navigation model.

Buys: cross-functional work stays possible — one account, one person, one decision,
visible from every relevant angle without copying truth. New roles are configuration.
Costs: the projection layer carries real complexity, and there is constant pressure to
"just build a Sales app." Yielding once produces the fragmentation the product exists to
remove.

2.5 The Twin is a participant, not an authority

Each user receives one bounded Twin. The Twin is the user's AI work partner for the role,
domain and responsibilities attached to that user instance. It does not need to be a universal
enterprise agent. It needs the capabilities, context and domain workspaces required by the user
it serves.

The Twin can:

• understand the user's current work
• assemble and reason over the AI Operational Sandbox
• decompose work into bounded assignments
• delegate to domain agents and workflows
• prepare drafts, analyses and proposals
• monitor assigned work and dependencies
• coordinate communications
• request human decisions and approvals
• verify outcomes and surface exceptions

The Twin cannot:

• query canonical Spine storage directly
• promote its own output to canonical truth
• change authority or policy
• bypass Governance
• silently assume human responsibility

The trust boundary is structural: the Twin reasons over a sandbox projection of Spine Fabric,
not over canonical storage itself.

Buys: human–AI collaboration inside the work rather than chat beside it, with bounded
responsibility and a consistent user-specific AI partner.
Costs: more explicit context assembly and execution plumbing, and less apparent autonomy in
demos. The boundary is intentional.

2.6 OneAuth → Total Continuity

One connection per host. Entire ecosystem discovers. No N×M re-connections.

Today, every host (ChatGPT, Claude, DIA, etc.) requires its own set of OAuth connections.
If ChatGPT is connected to 50 apps and Claude is connected to 50 apps, the user must
authenticate separately for each host × each app. This is N×M complexity.

IntegrateWise targets this with OneAuth: one identity and consent entry per host that binds
the principal to an IntegrateWise tenant, creates or resolves the tenant workspace and its
tenant-specific Spine schema/profile, then discovers eligible host connections. Discovery
does not inherit every host grant automatically. Each projected connector remains subject
to provider support, grant visibility, consent, tenant binding, RBAC and least privilege.
When a host cannot expose a reusable grant, IntegrateWise must request a normal scoped
connection or report the connector unavailable; it must never imply access it does not hold.

Host A (ChatGPT: 50 apps) → OneAuth → Spine → Discovery → 50 connectors projected
Host B (Claude: 50 apps)   → Same OneAuth → Same Spine → 50 more connectors projected
Host C (DIA: 3 apps)       → Same OneAuth → Same Spine → 3 more connectors projected

Total: 3 hosts, 103 apps, 3 connections (not 309)

Buys: eligible connections can be discovered once per host and reused through one tenant
authority boundary; Workbench, Twin and permitted agents receive consistent bounded context.
Work performed in different AI environments can contribute Flow C continuity candidates and
approved outcomes to the same tenant Spine rather than remaining isolated.
Costs: hosts expose different identity and grant capabilities, so reuse is conditional and
must fail closed. The security boundary remains per tenant, principal, connector, scope and
operation — never merely “the host is trusted.”

3. The kernel vocabulary

Version 3 introduces the terminology required by the human–AI work-coordination model. These
terms are the architectural primitives; implementation technologies must map into them rather
than becoming new product concepts.

Term	Definition	Owner
ORGANIZATION	The tenant-level operating system of goals, needs, standards, policies, domains and responsibilities	Spine / Governance
GOAL	A desired organizational result that gives work its purpose	Organization
WORK	Coordinated activity moving an objective toward an outcome across humans, AI and systems	SpineWorkspace
WORK GRAPH	Connected representation of goals, work, entities, people, dependencies, decisions, capabilities, executions and outcomes	Spine Fabric
CONTEXT	The relevant state required to understand current work and choose the next action	Context Assembly
MEMORY	Retained interpreted knowledge derived from observations, outcomes and prior work, with provenance and scope	Spine Fabric
SPINE FABRIC	Contextual business memory and operational continuity layer holding governed organizational truth and producing bounded projections	Spine Fabric
PROJECTION	A role-, domain-, responsibility-, subject- and policy-scoped view of shared Spine Fabric state	Projection Engine
WORKBENCH	The human-facing operational surface for understanding, deciding and progressing work	Product
TWIN	A user-specific, non-authoritative AI work partner that reasons, coordinates and delegates within its scope	Intelligence
COWORKER	A contextual companion that gathers active-surface context and supports communication and continuity between human, Twin and systems	Experience / Continuity
AI SANDBOX	Bounded operational working state exposed to AI; never canonical truth and never an unrestricted database surface	Continuity / Gateway
WORK ALLOCATION	Continuous determination of who or what should perform each work component	Twin / Governance
CAPABILITY	A declared business operation that can be read, derived or mutated through governed execution	Capability Fabric
GOVERNANCE	Authority, policy, risk, evidence, approval and accountability determining what may happen	Governance
EXECUTION FABRIC	The runtime mechanisms that perform capabilities: workflows, APIs, MCP, agents, ADK and provider tools	Execution
HERMES	The orchestration runtime that plans, sequences, tracks and reconciles governed execution	Execution
RECONCILIATION	Verification that intended work and observed external state agree, or are explicitly unresolved	Sync / Spine
CONTINUITY	Preservation and bounded transfer of relevant work context across time, people, systems and AI environments	Bridge
OUTCOME	The observed result of work that can close a work item and become new governed organizational state	Spine

The key distinctions are:

WHAT ARE WE TRYING TO ACHIEVE?     → GOAL
WHAT NEEDS TO HAPPEN?               → WORK
HOW IS IT CONNECTED?               → WORK GRAPH
WHAT DOES THE HUMAN/AI NEED NOW?   → CONTEXT
WHO SHOULD DO IT?                  → WORK ALLOCATION
WHAT CAN BE DONE?                  → CAPABILITY
MAY IT BE DONE?                    → GOVERNANCE
HOW IS IT DONE?                    → EXECUTION FABRIC
DID IT ACTUALLY HAPPEN?            → RECONCILIATION
WHAT DID WE LEARN / RETAIN?        → MEMORY
HOW DOES IT REMAIN COHERENT?       → CONTINUITY

4. The architectural laws

#	Law	Statement	What it prevents
1	Company/Product Law	IntegrateWise is the company; SpineWorkspace is the product	Naming and ownership ambiguity
2	Organization-to-Work Law	Goals and needs cascade into work; work remains connected across roles and domains	Departmental silos and orphan tasks
3	Spine Fabric Law	Contextual business memory is the shared continuity substrate	Rebuilding context in every application
4	Canonical Separation Law	AI never receives direct canonical Spine access	AI becoming a source-of-truth authority
5	Sandbox Law	AI operates only on bounded operational sandbox state	Unrestricted AI access to organizational truth
6	Projection Law	Role/domain projections are views of shared truth, not copies	Department-specific databases and duplicated truth
7	Work Allocation Law	Work is continuously divided according to capability, responsibility, authority, risk and need	Blind automation or manual-only execution
8	Twin Law	Every user gets a bounded AI work partner within the user's role/domain scope	One universal autonomous agent owning the enterprise
9	Coworker Law	Active-screen context and communication are assembled without creating a second authority	Context loss and duplicate AI surfaces
10	Capability Law	Capability defines what can be done; implementation defines how	Tool-specific product coupling
11	Governance Law	Consequential effects require policy and the applicable authority/approval	Confidence-based or client-side authorization
12	Execution Law	All external effects traverse the governed Execution Fabric	Provider/API bypasses
13	Reconciliation Law	An action is not complete until its outcome is observed and reconciled	False success and duplicate execution
14	Continuity Law	Context follows work across time and boundaries, subject to policy	Re-briefing and fragmented AI sessions
15	Product–Platform Law	Broad underneath; narrow at the surface	Platform implementation vocabulary leaking into product UX

These laws replace the prior eight-law vocabulary lock. This is a major architecture revision
because the primary unit is now explicitly work allocation between humans and AI, with Spine Fabric
as the contextual business memory foundation.

5. What is frozen, and what may change

Change	Version impact
New kernel concept	Major
New runtime step	Major
New doctrine or law	Minor
New capability type	Minor
Implementation improvement	Patch
New projection	Patch
New role composition	Patch

Frozen: the product doctrine, the kernel vocabulary, the organizational-to-work model, the Spine Fabric trust boundary, the human/AI work-allocation model, the runtime sequence, the entity contract, and the Capability/Execution Fabric model.

Not frozen: every implementation detail beneath them. The runtime sequence is an ordering
of responsibilities, not an instruction for how many services implement it. Merging or
splitting services is a patch as long as the ordering and the ownership hold.

---

Part II — The System

6. The system planes

The architecture is best understood as five cooperating planes. The planes separate the human
experience, contextual truth, adaptive intelligence, governed execution and platform substrate.

┌──────────────────────────────────────────────────────────────────┐
│ EXPERIENCE                                                        │
│ User Workbench · Twin Workbench · Coworker · role/domain views   │
├──────────────────────────────────────────────────────────────────┤
│ CONTEXT                                                           │
│ Spine Fabric · Projections · Context Assembly · AI Sandbox       │
├──────────────────────────────────────────────────────────────────┤
│ INTELLIGENCE                                                      │
│ Twin · Domain Agents · Reasoning · Planning · Learning           │
│ adaptive, non-authoritative                                      │
├──────────────────────────────────────────────────────────────────┤
│ EXECUTION                                                         │
│ Capability Fabric · Governance · Execution Fabric · Hermes       │
│ governed effects only                                            │
├──────────────────────────────────────────────────────────────────┤
│ INTEGRATEWISE PLATFORM SUBSTRATE                                  │
│ Identity · Connectivity · Communication · Infrastructure        │
│ tenancy · security · observability · metering                     │
└──────────────────────────────────────────────────────────────────┘

Spine Fabric is the contextual center. It is not merely a foundation storage plane. It is
the business-memory and continuity substrate from which human projections and AI sandbox context
are derived.

The Experience plane is where the human works. The User Workbench and Twin Workbench are
separate surfaces because the human operational view and the AI agentic working environment have
different interaction grammars. The Twin remains associated with the user and their work rather
than becoming an enterprise-wide autonomous authority.

The Context plane protects the boundary between organizational truth and AI working state.
Humans consume policy-filtered projections. AI consumes a bounded operational sandbox.

The Intelligence plane reasons, plans, allocates and learns. It has no direct canonical write
authority.

The Execution plane is the only path to external effects, and it is governed.

The IntegrateWise platform substrate supplies the cross-cutting infrastructure needed by all
of the above. It is not itself a customer Workbench.

7. The runtime sequence

The architecture has two related sequences. The first is the SpineWorkspace Work Operating
Loop — the product story. The second is the platform runtime — the infrastructure that makes
the product loop reliable.

7.1 SpineWorkspace Work Operating Loop

Organization Goal / Need
        ↓
      Work Graph
        ↓
  Shared Business Context
        ↓
   Context Assembly
        ↓
    Work Allocation
        ↓
 Human + Twin + Systems
        ↓
       Decide
        ↓
      Execute
        ↓
       Verify
        ↓
    Reconcile Outcome
        ↓
 Update Continuity / Memory
        ↓
      Next Work

7.2 Platform runtime

Configuration → Identity / Tenant Binding → Connectivity → Ingestion
→ Normalization → Spine Fabric → Projection / Context Assembly
→ Workbench / AI Sandbox → Capability → Governance
→ Execution Fabric / Hermes → Provider → Outcome
→ Re-ingestion → Reconciliation → Promotion / Continuity

The platform sequence must serve the work loop, not replace it. The distinction is important:
OODA is a reasoning grammar inside the Twin; the Work Operating Loop is the product's top-level
operating model.

Stage	Owns
Organization	Goals, objectives, needs, standards and policies
Work Graph	Relationships between work, entities, people, dependencies and outcomes
Context Assembly	Relevant context for a specific user/work interaction
Work Allocation	Human/AI/system responsibility for the next work component
Workbench	Human decision and operational interaction
Twin Workbench	AI reasoning, planning, delegation and monitoring
Capability Fabric	What operations are available
Governance	Whether an operation is permitted and under whose authority
Execution Fabric	How an authorized operation is performed
Reconciliation	Whether the intended effect actually occurred
Spine Fabric	Durable contextual business memory and continuity

8. Truth

8.1 Spine Fabric has a canonical layer and bounded operational layers

Spine Fabric is the product's contextual business memory substrate. It contains a protected
canonical layer plus bounded operational projections and working-state stores. These are not
interchangeable.

The critical security distinction is not merely storage technology; it is who is allowed to
see which representation.

Representation	Canonical Spine	Operational Spine / Sandbox	Edge / session state
Answers	What is governed organizationally true?	What is needed to operate current work?	What is needed for the current interaction?
Holds	Canonical entities, relationships, decisions, evidence, provenance, lifecycle and approved outcomes	Bounded projections, active context, sync state, working records, task context and execution state	Sessions, hot projections, idempotency, temporary working memory
Lifecycle	Durable, versioned, governed	High-churn, bounded, rebuildable	Expiring
Written by	Governed Spine promotion only	Owning operational services through governed contracts	Runtime services
Read by human	Role/domain projections	Workbench and operational services	Workbench/runtime
Read by AI	Never directly	Yes, only through the AI Operational Sandbox contract	Yes, when policy permits
Governance	Canonical authority	Policy and scope boundary	Runtime scope
If lost	Reconstruct from governed source evidence or fail closed	Rehydrate from Spine/source systems	Recompute

Operational Spine is the state of the machine. Canonical Spine is the state of the
business. That formulation resolves a conflation that has caused repeated confusion: the
seven operational entity types are first-class runtime objects, not a cache of anything
canonical. A SyncJob has no counterpart in Neon it could be a projection of. It is simply
a different kind of fact, with a different lifecycle and no need of a governance gate.

The edge cache is the third thing, and it is the one that must never be mistaken for either.

The operational store is a cache and a staging boundary. If an operational record matters
after its expiry, it must be promoted through the governed path. It must not be retained
merely because it happens to exist in a cache — and expiry itself never confers truth.

Aging is not promotion. This is worth stating separately because it has been proposed
repeatedly. D1/KV expiry removes or rebuilds bounded state. Canonical promotion is
evidence-, schema-, provenance-, policy- and authority-driven. A record does not become true
by surviving.

8.2 Storage ownership

Store	Owns	Never
Neon (Fortress)	Canonical entities, relationships, lineage, connector metadata, schema mappings, work, governance, audit, promoted outcomes	—
R2	Files, attachments, raw payloads, exports, immutable evidence bytes	Canonical structured truth
Vectorize / AI Search	Derived embeddings and retrieval indexes	Truth
AI Operational Sandbox	Read-optimised, policy-filtered, task-scoped working projection assembled from Spine Fabric	Canonical truth, unrestricted access or a write target
D1	Active context, idempotency, runtime indexes, projection snapshots	Independent record
KV	Sessions, hot projections, connector state, invalidation	Truth
Credential wall (Nango)	Tenant-owned OAuth/API credentials	— the Spine stores opaque references only

8.2a Canonical Spine is never directly exposed to AI

Canonical Spine is never queried by an LLM, Twin, agent or external AI host. No model receives
raw canonical rows, unrestricted SQL, unrestricted GraphQL or an unrestricted MCP resource over
canonical storage.

Instead, the AI Operational Sandbox is assembled for a specific user, role, domain, work
item and interaction. It may contain:

• policy-visible entity summaries
• current work state and related entities
• relevant documents and communications
• provenance and freshness indicators
• approved organizational memory relevant to the work
• bounded tool results
• current execution state
• prior Twin/agent working state that remains within scope

The sandbox is a working representation, not canonical truth. It may be incomplete, stale or
uncertain, and those states must be explicit.

Canonical Spine Fabric
        │
        ├──► Human Projection ──► User Workbench
        │
        └──► AI Context Assembly ──► AI Operational Sandbox ──► Twin / Agents

                         X
                         │
                    NO DIRECT ACCESS
                         │
                  Canonical Spine

This is the strongest form of the Memory and Authority laws: AI reasons over context derived
from truth; AI does not become a reader or writer of truth by virtue of being intelligent.

8.2b The store assignment rule

Six stores, one rule for choosing between them:

Numbers you aggregate go to Postgres. Everything else goes to the store that matches its
shape — and none of those stores is truth.

Data class	Store
Entity structured fields · KPI aggregations · counts · status · relationships · approval state · provenance	Neon Postgres
Long-form text · semantic search · similar-entity matching · Twin context retrieval · duplicate detection	Vectorize / AI Search
Attachments · invoice and contract PDFs · images and media · raw email bodies · exports	R2
Bounded active context · idempotency · projection snapshots · runtime indexes	D1
Session cache · hot projections · connector health · SLA and build flags · feature flags · invalidation	KV
Twin conversation runtime · per-subject active context · agent working memory	Durable Objects

Durable Objects are the sixth store and were previously unnamed. They hold the live
working state of a reasoning session — the Twin's conversation, the active context for one
account, an agent's in-flight working memory. That state is real, it is scoped, and it is
not truth: it expires, and anything in it that should survive must be promoted through the
governed path like anything else.

A caution on "Postgres/D1." Those two are not interchangeable and must never be written
as one tier. Neon is canonical. D1 holds a bounded, rebuildable projection of it. A KPI
may be computed into D1 as a cache; a KPI may not live in D1 as its record. The same
applies to "live entity state" in KV — a cached current value is fine, an authoritative one
is a violation of §8.1.

8.2c Memory is interpreted truth, in four scopes

Memory is neither canonical nor operational. It is interpreted — derived from canonical
facts and session evidence, carrying confidence and provenance. That is precisely why it
needs a governance gate that neither Spine requires: an entity is observed, but a memory is
concluded.

Scope	Boundary	Governance	Store
Personal	One user. Hard boundary — no other principal reads it, including the org's own Twin acting for someone else	User owns it; no approval needed	personal_memory
Agent	One agent or Twin instance within one tenant. Working state, learned routing, tool outcomes	Not directly promotable; must pass triage as evidence	agent_memory
Conversational	One session or thread. Ephemeral working context	Decays; never promoted directly	conversational_memory
Organisational	Tenant-wide interpreted truth	Governed: staging → approved → published	org_memory

Context, Memory and Continuity are deliberately different. Context is what is relevant now;
Memory is what has been retained from before; Continuity is what keeps the work coherent across
time and boundaries. Together they form the contextual business memory model of Spine Fabric.

Scope only ever widens through promotion, and promotion is always governed.
Conversational and Agent memory are evidence, not truth. Personal memory never widens at
all — it can only be cited by the user who owns it.

That last rule is stronger than a privacy preference. If personal memory could be promoted,
every private note becomes a candidate for organisational truth, and the hard boundary that
makes the scope usable at all disappears.

8.2c-i Triage classifies. The Promotion Gate governs.

Evidence                       Interpretation          Truth
────────                       ──────────────          ─────
conversational_memory  ┐
agent_memory           ├──► TRIAGE ──► candidate ──► PROMOTION GATE ──► org_memory
session events         │    classify                 govern             staging → approved
canonical entities     ┘
                                                          │
                                        personal_memory ──┘  never promoted;
                                                             widened only by its owner

These are two responsibilities and they must not merge. A classifier that can also approve
is not a gate. Triage may receive, validate, classify, redact, deduplicate, link,
quarantine and stage. It may not decide that unverified material has become organisational
truth; it decides only where a candidate goes for review.

Automation may reach staging. It may never reach approved. This is the defensible
middle between "every extraction needs a human" and "high confidence auto-stages": the
system does the sorting, a human does the deciding, and material sitting in staging is
not available to Twin reasoning until approved. Approval automation without approval
bypass.

This is the Authority Law again — confidence never grants authority — expressed at the
memory layer. It deserves to be a test, not a comment: no promotion path may write
governance_state = 'approved' without an approver identity.

8.2c-ii The same separation governs learned behaviour

Behaviour learns through an evidence pipeline, never by direct mutation of an agent:

observation → candidate → suggested → shadow → approval → active
                                                   ↓
                     remain · return to shadow · suspend · retire

An agent may move a pattern to candidate or suggested. An agent may never promote a rule
to approved_autonomous. Autonomy is granted by policy, never inferred by the agent that
would exercise it — the Authority Law applied where it is most often violated.

Shadow rules evaluate against live opportunities and take no action. Proactive rules may
propose but perform no external write. Autonomous rules execute only a fixed, approved rule
version inside a declared envelope — action types, entity types, rate ceiling, value at risk,
freshness requirement, approval expiry, emergency disable — and drift suspends them without
a code deploy.

Confidence is six things, and one number must never represent all six: pattern confidence ·
prediction confidence · input completeness · data freshness · historical precision · policy
eligibility. Small samples use a named conservative lower bound, not raw accuracy — 3/3 is not
better evidence than 470/500.

Detail: Edge Conditions and Governed Learning
Spec §9–§12.

8.2d The enrichment pipeline

Normalisation makes data canonical. Enrichment makes it retrievable. They are different
passes with different failure modes, and conflating them is why "the search is bad" and "the
data is wrong" get diagnosed as one problem.

Entity created or updated in Neon
        ↓
Extract text from structured fields + linked R2 content
        ↓
Chunk (512 tokens, 50 overlap)
        ↓
Embed into Vectorize
        ↓
Link related entities into the relationship graph
        ↓
Extract key concepts onto the entity
        ↓
Write the embedding reference back onto the entity in Neon

One canonical write triggers the enrichment pass. Vector and structured stores may be used
internally by Context Assembly, but the Twin receives only the resulting AI Operational
Sandbox. The sandbox preserves provenance, freshness, completeness and authority markers;
the model never receives a raw-store authority relationship.

8.2e Cross-source canonical records

Some canonical entities are assembled from several providers at once. An invoice is the
clearest case: billing tool, payment gateway, subscription platform and usage platform each
hold a fragment, and the canonical record carries references to all of them.

Those links are established by the pipeline, never by a user. A human manually asserting
that two provider records are the same object is exactly the identity-resolution decision
that must be deterministic and provenance-bearing — and if it is ambiguous, it blocks rather
than guesses.

8.3 Write authority

Pipeline promotion through Governed Spine Writers
= the sole canonical commit path

The browser, the Twin, connectors, the public MCP, the Normalizer, Triage and the Projection
Engine never write Neon directly. Not "should not" — the credential boundary is meant to
make it impossible. (Today it is not; see §20 S8.)

No dual-write. Ever. Nothing writes synchronously to both the Spine and a projection. The
canonical mutation, its field lineage and a transactional outbox event commit in one
database transaction; every projection is an asynchronous consumer of that event.

┌─ one Spine transaction ─────────────────┐
│  canonical mutation                      │
│  field lineage                           │
│  outbox event                            │
└──────────────┬──────────────────────────┘
               ↓ at-least-once, idempotent consumers
   Brain · search · vector · signals · Workbench · org-memory cache

Delivery is at-least-once with stable event ids, monotonic entity versions, backoff with
jitter, dead-letter queues and reconciliation. The architecture does not claim cross-store
exactly-once delivery — any document that does is wrong.

This is the structural fix for the whole class of defect in §20: a projection that is written
directly becomes a second writer, and a second writer becomes a second source of truth. It
closes S0b and M1 — Neon memory.org_memory is the store, the D1 table is a
projection, and the promotion gate is its only writer.

Detail: Edge Conditions and Governed Learning
Spec §2.

8.3a Uncertainty is a value, not an absence

unknown · unresolved · insufficient_data · conflicted · stale · failed are valid
persisted states. The platform never converts uncertainty into a guessed canonical value.

This applies at three levels, and all three are required:

Level	Carries
Field	normalizationStatus: valid · coerced · invalid · missing · conflicted — with rawValue preserved whenever coercion fails
Identity	resolution_status and canonical_status; an unresolved entity is provisional and not eligible for automation
Response	state (§11.4) and completeness — orthogonal, both required

Two rules that follow and are violated often:

An unknown enumerated value maps to unknown, never to the nearest known value. Nearest-
match is how a system quietly invents facts.

Null, blank and absent are three different things. Collapsing them destroys the difference
between we know it is empty and we never asked.

8.4 The entity contract

Every canonical entity owns seven properties. This is frozen:

Property	Meaning
identity	Canonical reference (id, provider, tenant)
fields	Structured attributes
relationships	Connected entities
timeline	Temporal history
provenance	Source and lineage
permissions	Access governance
capabilities	Available operations

Provenance is not metadata. It is the reason any number on a Workbench can be traced to the
system and field it came from and the time it last changed — which is what makes grounded
reasoning possible and hallucination structurally harder.

8.5 Schemas are entity-based; experience is projection-based

A persisted record represents a business or platform entity, relationship, event, evidence
artifact, policy, capability, execution, versioned definition or runtime record. A table is
never created because a sidebar label exists. There is no canonical home, inbox,
finance-manager or view-n table. Those are projections.

Role, department and industry are projection dimensions, not storage partitions. This is
the single most load-bearing storage decision in the system: it is what preserves
cross-functional work. One account, person, task, document, risk, decision or outcome is
projected into every relevant view without its truth being copied into a departmental
database.

Storage rules:

• Onboarding creates a tenant-specific Spine schema/profile: the activated entity types,
  fields, mappings, vocabulary, relationships, retention and policy configuration for that
  tenant and workspace. This is a governed logical/data contract, not permission to generate
  arbitrary physical tables from UI labels.
• The current physical model uses shared typed tables with mandatory tenant scope. Whether
  stronger physical schema/database isolation is required is an infrastructure decision; it
  must preserve the tenant-specific logical schema and the scope envelope either way.
• Each canonical entity type in its own table, with its own opaque primary key
• tenant_id mandatory on every canonical row, relationship, event, cache entry and evidence link
• Every entity carries a classification address: app_category → business_domain → lifecycle_stage

8.6 The scope envelope

Concern	Field	Meaning
Isolation boundary	tenant_id	The owning tenant. Always required.
Tenant operating account	tenant_account_id	The tenant's root account identifier
Tenant Spine Network	spine_network_id	Groups the entity graph, connector bindings, events and projections
Workspace context	workspace_id	Optional active scope; never replaces tenant_id
Entity identity	<entity>_id, canonical_id	Row identity and merge identity
Connector install binding	connector_binding_id	The user/tenant/provider-workspace installation
Connector connection	spine_connection_id	Lineage of one provider connection
Traceability	trace_id, correlation_id, source_flow	The end-to-end route

spine_network_id and spine_connection_id are not interchangeable. The first is the
tenant's network root, required for cross-connector grouping. The second is the lineage of
one connection inside it. A tenant network has many connections and also holds user-created,
imported and governed entities that belong to no connection.

spine_users are authenticated product users. A business person or contact is a canonical
entity with a person subtype. Conflating them is a recurring bug class.

9. The four flows

Everything entering the system is classified into one of four flows, and only two can create
truth.

Flow	Carries	Canonical boundary
A — Structured operational data	Entities, typed fields, relationships, metrics, events, status, ownership, lifecycle	Deterministic normalisation prepares candidates; governed writers commit
B — Documents and communications	Threads, messages, meetings, calls, documents, attachments, transcripts, evidence	Raw artifacts preserved; extracted meaning retains lineage; promotion uses governed writers
C — AI and cognitive context	Twin/external-AI sessions, model output, plans, proposals, tool calls, candidate memory	Never directly mutates operational truth. Triage proposes promotion
D — Platform binding and control	Identity, tenant, workspace, role, department, permissions, configuration, connections, credential references, capabilities, policies, runtime bindings	Governed platform configuration writers only. Not a business-data partition

Flow C is where every well-meaning shortcut wants to live. "Let the model write it,
we'll review later" is precisely what this partition exists to prevent.

Flow D runs first. It is not a peer of A, B and C — it is their precondition. Nothing can
be classified, scoped or written until identity, tenant, workspace, consent, connection binding
and capability grants have resolved. An observation arriving before Flow D has no tenant, and a
record without a tenant cannot be written; it fails closed.

Flow D is not the execution path. An approved effect follows
Capability → Governance → Hermes → provider → outcome → re-ingestion → reconciliation → promotion. Flow D supplies the authority and binding context that path runs under; it does
not turn external execution into platform-binding data. (This is a recorded post-lock
correction: Architecture Lock v1.0 described Flow D as approved external actions. v1.1
corrected it.)

flowchart TD
  D["D: identity + authn/authz + consent + tenant/workspace/schema binding"] --> Gate{"Tenant activation complete?"}
  Gate -- "no" --> Closed["Fail closed; no ingestion or capability route"]
  Gate -- "yes" --> A["A: structured operational records"]
  Gate -- "yes" --> B["B: messages, email, documents, channels, projects"]
  Gate -- "yes" --> C["C: AI conversations, agent work, continuity candidates"]
  A --> Loader["Loader: capture + source lineage"]
  B --> Loader
  C --> Loader
  Loader --> Normalizer["Normalizer: validate, map, deduplicate, redact"]
  Normalizer --> Evidence["Evidence / R2 / bounded operational staging"]
  Normalizer --> Candidates["Durable typed candidates + provenance"]
  Candidates --> Promotion["Policy + promotion / approval"]
  Promotion --> Fortress["Canonical Spine / Fortress"]
  Fortress --> Search["Links + events + search / embeddings"]
  Search --> Projection["Role/task Workbench + bounded AI context"]

9.0b Activation and phased ingestion

Flow D is a state machine, not a login callback:

initiated → identity_verified → tenant_bound → workspace_created → consent_recorded → tenant_schema_activated → connectors_eligible → ingestion_enabled.

The product may hydrate in phases, but it may not weaken the gates:

Phase	Product value	Intake boundary	Exit evidence
Creamy layer	Fast initial value from high-signal, low-volume objects and recent work	Allowlisted entity types, recent windows, metadata-first document capture	Tenant scope, mappings, provenance, freshness and first role projection verified
Breadth hydration	Historical records, communications and documents fill the connected context	Backfill with rate limits, resumable cursors, deduplication and evidence retention	Coverage and reconciliation metrics meet the tenant activation policy
Full continuity	Incremental sync, AI-host continuity and governed action outcomes remain current	Webhooks/polling, Flow C candidates, execution receipts and re-ingestion	Drift detection, replay, deletion/revocation and steady-state SLOs proven

“Creamy layer” describes rollout order only. It is not a second store, a weaker truth class,
or authority for partial data to masquerade as complete. Every response continues to carry
freshness and completeness.

9.0a Three things arrive from an AI, and they are not the same thing

Conflating them is the most consequential modelling error at the host boundary.

What the AI produced	It is	Destination
Tool result — it invoked an app and got records	Evidence	Flow A or B, via Loader → Normalizer
Model output — reasoning, summary, conclusion	Interpretation	Flow C — candidate only
Requested action — "send this", "update that"	Intent	Not a flow. The governed execution path; its outcome re-enters as A/B

The sharpest case: when a host's model reasons over IntegrateWise data and reaches a
conclusion, that conclusion is Flow C. It does not become organisational truth because a
capable model asserted it, and it does not become truth because its confidence was high. The
reasoning is rented; the truth is owned; the gate between them is ours.

Detailed channel mapping:
Marketplace Channels and Data Flow Spec.

9.1 Normalizer and Triage are separate runtimes

	Normalizer	Triage
Nature	Deterministic	Adaptive
Does	Validate, parse, type, map, deduplicate, resolve identity and relationships, construct provenance, prepare a write candidate	Classify cognitive/unstructured material, bind evidence, estimate materiality and confidence, select a memory or knowledge scope, route for review
Authority	None — prepares candidates	None — cannot self-authorise or auto-promote

Neither commits. Loader Runtime is the sole outer ingress controller; Governed Spine
Writers / Pipeline promotion are the only modules that commit canonical truth.

10. Capability, Governance, Hermes — the execution path

10.0 Capability has three effect classes

One kernel term, three effect classes. Every registered capability declares which it is, and
its governance requirement follows deterministically — it is not a judgement call at
invocation time.

Effect class	Does	External effect	Governance	Examples
read	Retrieves state from a system of record	None	Policy scope only	Fetch an opportunity, list messages
derive	Computes over truth, memory and evidence	None	Policy scope only; output is a candidate, never a fact	Memory view, AI search, context assembly, entity resolution, Twin reasoning
mutate	Changes external or canonical business state	Yes	Proposal → policy → approval token → receipt → reconciliation	Send an email, update a CRM record, create an obligation

This resolves a conflation that ran through the whole prior document set. The Capability
Law reads "Workbench projects tool capabilities" — the word "tool" was already there,
which means the doctrine only ever governed provider operations and left the cognitive half
of the system unnamed. Fourteen of the nineteen public tools are derive or read:
get_context, get_related, get_permitted_memory, get_relevant_knowledge, ask_twin.
Those are the product. They now have a declared class, a governance rule, and a home.

Two consequences worth stating:

A derive capability produces candidates, never facts. Its output enters Flow C. It
reaches canonical truth only through Triage, a promotion record and the applicable approval.
This is the Memory Law expressed as a capability property rather than a convention.

Only mutate requires an approval token. Reads and derivations are bounded by policy
scope, not by approval. Requiring approval for a memory lookup would make the gate
meaningless through overuse.

10.1 The path

Twin or user intent
→ capability resolution          (what operation is this, at what version)
→ immutable execution plan       (parameters fixed; nothing may change after this)
→ Governance policy + evidence   (is this permitted, by whom, with what evidence)
→ explicit human approval        (when required)
→ approval token
→ Hermes                         (the only coordinator of approved execution)
→ provider connector / MCP capability
→ source-system result
→ Pipeline normalisation
→ promoted outcome in Neon
→ projection invalidation

flowchart LR
  Task["User task in Workbench"] --> Context["Assemble task context: canonical IDs + task ID + links + provenance + documents + search"]
  Context --> Twin["Silent Twin: explain, draft or propose"]
  Twin --> Intent["Versioned capability intent"]
  Intent --> Policy["Governance: identity + RBAC + consent + evidence + policy"]
  Policy --> Approval{"Consequential mutation?"}
  Approval -- "no: read/derive" --> Result["Bounded result / candidate"]
  Approval -- "yes" --> Token["Human approval + immutable token"]
  Token --> Hermes["Hermes plan and execution"]
  Hermes --> Source["Source system capability"]
  Source --> Receipt["Receipt + observed outcome"]
  Receipt --> Reingest["Loader → Normalizer → reconcile"]
  Reingest --> Promote["Governed promotion"]
  Promote --> Refresh["Projection invalidation / refresh"]
  Refresh --> Task
  Result --> Task

10.1a Write and approval loop

flowchart TD
  Candidate["User, Twin, agent or connector submits write intent"] --> Resolve["Resolve canonical subject + capability version"]
  Resolve --> Plan["Freeze parameters, evidence, idempotency key and expected version"]
  Plan --> Evaluate["Policy and authority evaluation"]
  Evaluate -- "deny / insufficient context" --> Stop["Reject or return for repair; audit decision"]
  Evaluate -- "approval required" --> Human["Explicit human decision"]
  Human -- "reject / expire" --> Stop
  Human -- "approve" --> Signed["Scoped, expiring approval token bound to plan hash"]
  Evaluate -- "pre-authorised read/derive" --> Execute["Execute allowed route"]
  Signed --> Execute
  Execute --> Observe["Persist receipt; observe provider state"]
  Observe --> Reconcile{"Outcome unambiguous?"}
  Reconcile -- "no" --> Query["Query source; do not retry blindly"]
  Query --> Reconcile
  Reconcile -- "yes" --> Pipeline["Re-ingest + normalize + promote + outbox"]
  Pipeline --> Audit["Audit, provenance and refreshed Workbench projection"]

Governance route and execution route are separate decisions. This is the correction
that makes multi-host deployment possible. Whether an action is permitted, and where it
runs, are answered independently:

• The governance route is invariant. Canonical entity resolution → policy evaluation →
  proposal → approval or confirmation → route resolution → execution → receipt capture →
  reconciliation into Spine. Every material write passes through all of it.
• The execution route is resolved per operation. A write may execute through a
  host-native tool or through the IntegrateWise Capability Fabric. Both produce the same
  canonical receipt structure and both reconcile into the same Spine.

Hermes orchestrates — it plans, sequences, tracks, retries and reconciles, and it
coordinates host-native handoffs as readily as IntegrateWise connectors. It is not the sole
executor. What is invariant is the governance path and the receipt, not the transport.

Three properties make this trustworthy rather than merely orderly:

The plan is immutable. Once prepared, the parameters are fixed. What is approved is
exactly what executes — there is no window between approval and execution in which the
action can change.

A host confirmation is not an IntegrateWise approval. If the host prompts the user and
the user accepts, policy evaluation has still not happened. Both may be required; neither
substitutes for the other.

No material write executes without a receipt and a reconciliation. An execution whose
outcome is unknown enters reconciliation. It is never retried blindly and never assumed
successful.

10.2 Capability Fabric

Capabilities are registered, versioned, discoverable operations. The pattern is
Registry → Resolver → Health → Routing → Versioning.

pool.register(manifest, targetBinding);
pool.resolve({ capability, version });
pool.invoke({ capability, version, args, context });
pool.health();
pool.capabilities();

The Workbench projects capabilities; it does not implement them (Law 6). A capability
catalogue or executor built inside the Workbench is a Law 6 violation regardless of how
convenient it is.

10.3 What "hard gate" means

• No approval token → no external mutation. There is no branch that skips this.
• Fail closed. A missing binding, an expired credential, an ambiguous scope: all fail closed.
  A governance gate that degrades to "proceed" is not a gate.
• Enforcement is server-side at the Gateway. This matters most in a plugin host, where
  the reasoning model belongs to ChatGPT or Claude and cannot be trusted to respect a
  client-side gate. The plugin channel is the case that proves why the rule must hold
  everywhere.
• "Until successful" is policy-bounded retry, never unbounded. Ambiguous remote outcomes are
  queried and reconciled before any mutation is repeated. Exhausted work goes to dead letter
  and governed reprocessing — never blind replay.

10.4 The event envelope and reliability

Every ingress — webhook, polling, streaming, API, MCP, user or agent — normalises to one
tenant-scoped event envelope carrying event type and version, trace, correlation, causation,
idempotency key, subject, source and provenance.

Validate → archive raw evidence → publish immutable event
→ queue / stream → process → resolve capability → govern → Hermes
→ provider outcome → re-ingest → verify → reconcile
→ Pipeline promotion → projection invalidation

That one envelope is what makes the rest of the system uniform: a Slack webhook, a scheduled
Salesforce sync and a Twin-proposed action all become the same shape before anything
downstream sees them. Six guarantees are mandatory rather than best-effort — event
bus/queues, idempotency and deduplication, webhook and polling security, policy-bounded
retry and replay, sync and reconciliation, and end-to-end traceability with structured
logging and SLOs.

Two rules deserve emphasis because they are where distributed systems usually fail quietly:

An ambiguous provider outcome is a question, not a retry. If the system cannot determine
whether a mutation succeeded, it queries and reconciles before repeating. Retrying an
ambiguous write is how one approved action becomes three emails.

Exhausted work goes to dead letter and governed reprocessing. Never blind replay. A
replayed action is a new action and re-enters the governance path.

11. Projection and the Workbench

11.1 The projection contract

The organization has one connected Spine Fabric. Users do not receive separate organizational
databases. They receive projections determined by:

VIEWER
  identity · tenant · role · permissions · department · domain · responsibility

SUBJECT
  entity · work item · lifecycle stage · relationships · evidence

ORGANIZATION
  goals · priorities · standards · business context

SYSTEM
  connector availability · capability availability · freshness · policy

                         ↓
                 Projection Engine
                         ↓
              Role / Domain Projection
                         ↓
                  USER WORKBENCH

This means the same account, customer, project, task, risk or decision can be seen by Sales,
Customer Success, Finance, Engineering or leadership without becoming separate records.

11.2 One organizational truth, many human views

The Workbench is the human operational surface. It projects the relevant slice of Spine Fabric
according to the user's role, domain, responsibility, permissions and current work.

The user should not have to reconstruct organizational context from separate applications. The
projection should bring the relevant business context to the work.

The user-facing centre of gravity remains work:

• What needs my attention?
• What is blocked?
• What is waiting for a decision or approval?
• What changed?
• What should happen next?
• What context explains this work?
• What can my Twin take on?

11.3 User Workbench and Twin Workbench are different surfaces

The two surfaces serve the same user's work but have different purposes.

User Workbench

• role/domain operational view
• work queues and tasks
• business entities and context
• communications and documents
• approvals and decisions
• visual projections and canvases
• human judgment and accountability

Twin Workbench

• agentic working environment for the user's Twin
• AI Operational Sandbox
• plans and decompositions
• agent assignments
• tool/capability execution state
• working memory and evidence
• pipeline/workflow monitoring
• drafts and proposals
• exceptions requiring human intervention

The Twin Workbench may resemble an agentic environment such as an AI runtime console, but it is
not a generic AI playground. It is the execution workspace of the user's bounded Twin, grounded
in the user's role/domain and the organization's Spine Fabric.

11.4 Context Assembly

Context Assembly is the mechanism that turns organizational continuity into task-specific
working context. It combines:

organization context + subject context + work context + role authority + current interaction + freshness + evidence + available capabilities

and produces two different outputs:

SPINE FABRIC
     │
     ├──► HUMAN PROJECTION
     │      → User Workbench
     │
     └──► AI OPERATIONAL SANDBOX
            → Twin Workbench / agents

The two outputs are related but not identical. The human may be allowed to see a canonical field
or sensitive business relationship that the AI sandbox must exclude. The AI may receive derived
working state that is useful for reasoning but is not itself canonical.

11.5 Roles, domains and cross-team work

Role and domain are projection and authority dimensions, not storage partitions.

A user's Twin is scoped to the user's assigned role/domain and the capabilities necessary to
perform that role's work. Domain agents may be narrower still. Cross-team work does not require
cross-team database copies; it requires governed projections of the same Work Graph.

Example:

Customer Renewal
      │
      ├── Customer Success
      │     ├── relationship context
      │     └── renewal strategy
      │
      ├── Finance
      │     ├── billing state
      │     └── commercial constraints
      │
      ├── Product / Engineering
      │     ├── incidents
      │     └── product dependencies
      │
      └── Leadership
            ├── risk
            └── business outcome

             ↑ all connected through Spine Fabric / Work Graph

Each participant sees what their authority permits while the underlying business continuity
remains shared.

11.6 Auto-tuning boundary

Personal and reversible adaptation may improve a user's Workbench or Twin Workbench. It may not
silently change organizational truth, permissions, authority, policy, governance thresholds,
shared schema or organizational memory publication.

11.7 Frontend-to-backend contract

Every Workbench projection follows:

authenticated user → Gateway/TenantGate → projection contract → policy-filtered Spine read model → Workbench

Every AI context request follows:

authenticated user/Twin → Gateway/TenantGate → Context Assembly → AI Sandbox contract → Twin

The browser never queries providers or storage directly. The Twin never queries canonical Spine
directly. Both are clients of governed platform contracts.

12. The Twin

12.1 The Twin is the user's AI work partner

A Twin is assigned to a user instance. It is not "the company's AI" in the abstract. It is a
bounded AI participant operating within the user's role, domain, responsibilities, authority
and active work.

USER
  │
  ├── User Workbench
  │
  └── Twin
        │
        ├── Twin Workbench
        ├── AI Operational Sandbox
        ├── Domain capabilities
        ├── Domain agents
        ├── Workflows
        └── Communication

The Twin is responsible for the user's digital work coordination: gathering context, reasoning,
decomposing work, assigning bounded tasks to agents/workflows, monitoring execution, preparing
communications and bringing exceptions or decisions back to the human.

12.2 Twin operating grammar

The Twin's internal reasoning may use OODA:

OBSERVE → ORIENT → DECIDE → ACT

But OODA is not the product's top-level loop. The Twin's OODA operates inside the SpineWorkspace
Work Operating Loop.

The broader Twin operating grammar is:

UNDERSTAND
   ↓
CONTEXTUALIZE
   ↓
TRIAGE
   ↓
ALLOCATE
   ↓
PLAN / PROPOSE
   ↓
DELEGATE
   ↓
EXECUTE THROUGH GOVERNED CAPABILITIES
   ↓
VERIFY
   ↓
REPORT
   ↓
ADAPT

12.3 Twin and domain agents

The Twin does not need unlimited domain knowledge. The user's Twin coordinates the domain agents,
workflows and capabilities required for that user's role.

User Twin
   │
   ├── Customer Success Agent
   ├── Finance Agent
   ├── Research Agent
   ├── Communication Agent
   ├── Workflow Agent
   └── External / provider agent

These are bounded execution participants. They do not become independent owners of organizational
truth or user authority.

12.4 Work assignment layer

A shared work-assignment layer records:

• work item
• objective
• assignee
• human/AI/system participant
• capability required
• authority envelope
• dependencies
• status
• evidence
• expected outcome
• actual outcome
• escalation condition

The Twin can receive assignments, decompose them, delegate bounded subtasks and report completion.
A human can reclaim or reassign work at any time subject to policy.

12.5 Active context is not activation

Navigating a Workbench surface hydrates context; it does not automatically authorize action or
trigger expensive reasoning. Twin activity is initiated by explicit user intent, a governed
assignment, or a material signal permitted by policy.

12.6 Twin controls

Intent	Twin behaviour
Understand	Explain current work from the AI Sandbox with provenance and uncertainty
Prepare	Draft analysis, communication, plan or decision support
Assign	Accept a bounded work assignment and decompose it
Delegate	Route bounded subtasks to domain agents/workflows
Execute	Request capabilities through Governance and Execution Fabric
Monitor	Track progress, failures, dependencies and freshness
Escalate	Bring consequential decisions, exceptions or missing context to the human
Close	Verify and reconcile outcomes; report completion

The Twin never turns confidence into authority.

13. Continuity, Coworker and the Bridge

13.1 Operational continuity

Continuity preserves the identity, context, state, decisions, assignments, evidence and progress
of work across time, people, systems and AI environments.

The principle is:

Context follows the work, not the application.

13.2 The Coworker

The Coworker is the contextual companion between the human Workbench, the Twin and the
communication/execution substrate.

It gathers context from the user's active interaction and work surface — what the user is
looking at, what work is active, what changed, what communication is relevant, which entities are
in focus and what the current work assignment requires.

It can:

• assemble screen/work context
• surface relevant records and evidence
• maintain communication continuity
• coordinate context between User Workbench and Twin Workbench
• carry relevant pipeline/execution status into the user's working context
• reduce re-briefing and tool switching

It cannot:

• become canonical truth
• grant authority
• bypass the Twin's sandbox boundary
• execute consequential mutations independently

13.3 Human–Twin–Coworker relationship

                    SPINE FABRIC
                         │
          ┌──────────────┴──────────────┐
          │                             │
   HUMAN PROJECTION               AI SANDBOX
          │                             │
          ▼                             ▼
   USER WORKBENCH                 TWIN WORKBENCH
          │                             │
          └──────────────┬──────────────┘
                         │
                     COWORKER
                         │
             Context + Communication
                         │
                         ▼
                 Shared Work Thread

The Coworker makes the user's active work legible to the Twin and makes the Twin's progress
legible to the user. It is a continuity mechanism, not another agent authority.

13.4 Cross-host continuity

AI hosts and external agents participate through the same bounded continuity contract. They do
not exchange credentials or become peer authorities. They receive only the context and
capabilities permitted for the requesting principal and work.

14. Identity, tenancy and isolation

Layer	Contract
Browser identity	Descope is the identity authority
Authority derivation	Gateway validates the session and resolves tenant membership; injects trusted identity headers downstream
Browser claims	Non-authoritative. Tenant, user, role and permission values from the browser are rejected
AI / MCP consumers	Public OAuth-protected MCP boundary
Provider credentials	Tenant-owned, held in the credential wall. Never in a product repository, a projection, or an AI prompt
Tenant scope	Mandatory on every canonical row, relationship, event, cache entry, evidence link and runtime operation

Stale, ambiguous, revoked or expired bindings fail closed and are removed from sync,
projections, Twin context, capabilities and execution.

15. Three axes: Profile × Entry Channel × Surface

Three orthogonal things were previously collapsed into the word "profile," producing a
2×2 that could not represent development and could not represent tool-initiated onboarding.
The resolution is to stop storing the product of the axes and store the axes.

15.1 Profile — which capabilities exist, and who may administer

development · customer_zero · external

This is a property of the runtime a tenant is served by, not of the tenant.

Only five modules vary by profile:

Module	development	customer_zero	external
MCP Pool (admin UI)	full	full	not exposed
Capability Manager	all + experimental	all governed	tenant-permitted subset
Administration	full	full	tenant-scoped
Billing	bypassed	internal accounting	live metering
Deployments	full	full	not exposed

Everything else is identical across all three. Identity, Integration Manager, Connector
Marketplace, Activation Hub, AI Models, Knowledge, Memory & Continuity, Automation,
Pipelines, Governance, Observability, Organizations, Users, Roles, Permissions, Audit, API
Keys and Security vary by tenant scope, which RBAC already handles. Adding profile
branches to them invents variance that does not exist and creates eighteen new drift sites.

This table is resolved server-side at the Gateway and returned in the capability
manifest. The frontend never computes it and never receives definitions for modules the
profile excludes.

On MCP versus MCP Pool. They are two different jobs, not two sizes of one thing.
Verified at HEAD: services/mcp-pool/src contains zero of the 19 semantic tools — it
exposes five lifecycle verbs (register, unregister, capabilities, health, invoke)
over nine platform-management namespaces. A profile running on Pool could not use
IntegrateWise; it could only administer it. The public MCP surface is therefore
byte-identical across all three profiles. MCP Pool is an operator control plane — register, unregister, capabilities,
health, invoke — whose administration UI is exposed only in development and
customer_zero. Pool is never a tool surface and never a per-profile alternative to MCP.
If Customer Zero ran on Pool while external ran on the public surface, Customer Zero would
stop proving the external contract, which is its entire purpose.

15.2 Entry channel — where identity comes from, and where UI renders

Channel	Identity source	UI surface	First connection
connected_tool	OAuth with a provider the user already holds	IntegrateWise browser Workbench	The authenticating provider
mcp_workbench	IW OAuth via MCP registry	IntegrateWise browser Workbench	Chosen in the Workbench
plugin_host	Host installation grant	Embedded surface inside the host	Host-declared, runtime-confirmed capability context

On "inherited." Earlier wording described the plugin's first connection as inherited
from the host's connections. That phrasing is retired: it reads as credential inheritance,
which is precisely what §15.4 forbids. Credentials remain inside their owning trust boundary.
Where the host cannot supply a required capability, the user creates an explicit
IntegrateWise connection. Nothing is inherited — capability is declared and then confirmed.

One onboarding state machine serves all three:

initiated → identity_required → workspace_required → consent_required
         → binding → hydrating → active
                              ↘ degraded | revoked | failed

Only identity_required and workspace_required are channel-dependent. consent_required,
binding, hydrating and active are identical for every channel. This is the
invariant that matters: the Spine write path, hydration, projection composition and
governance do not fork per channel. Fork them and you get three onboarding funnels that
hydrate differently.

Channel and provider are orthogonal. channel is one of the three above; provider is
catalogue data. Adding a new host is a catalogue entry, not a type change.

15.3 Surface — infrastructure isolation only

dev · test · prod. No product semantics. The axes are independent: Customer Zero on
test is a valid and useful combination.

15.4 In a host deployment, the host supplies the agent

IntegrateWise does not ship inference into a host. The host's model reasons. IntegrateWise
supplies the tool surface, the truth, the memory, the governance gate and the embedded UI.

Host capability is never assumed. The IntegrateWise runtime may not enumerate every app
connected to a user's host account, may not access another app's OAuth token, may not invoke
unrelated apps directly, and may not bypass the host's permission, confirmation or workspace
controls. The host orchestrates its own apps.

Host capabilities therefore enter through explicit mechanisms only:

1. Host-declared capability context supplied at app invocation
2. Tool-result handoff — the host invokes its own app and passes the resulting evidence
   to an IntegrateWise tool
3. Workflow orchestration — the host selects both its apps and IntegrateWise tools
4. Explicit IntegrateWise connection where the capability is not available through the host
5. Installation manifest or policy declaration of expected capabilities

Declared is not available. Every one of those must be validated at runtime; expected
availability is never proof of actual runtime access. A capability's availability is
confirmed, declared or unknown, and only confirmed may be routed to.

Two further rules hold:

1. Host-granted access is readable, not writable. Any mutation is a capability execution
   and passes the governance path like any other, whatever route it executes on.
2. Host evidence is still Spine-mediated. A host tool result enters as a
   RawObservation through Loader and the Normalizer Path. The Workbench does not treat a
   provider payload as truth because the host happened to hold a token.

15.5 Create once, deploy anywhere

The governing principle of multi-host deployment:

Host-first access. Spine-complete context. Policy-governed execution. Canonical
reconciliation.

One canonical Workbench and continuity runtime is built once and deployed into many hosts —
a host being any runtime the product renders in: ChatGPT, the IntegrateWise web app, Slack,
Microsoft surfaces, embedded customer applications, desktop shells, customer-hosted
environments, future agent marketplaces.

A host is an integration context, not a rendering container. A deployment must account
for the host's authenticated user, workspace, enabled integrations, granted scopes,
supported operations, confirmation model, surface limitations and runtime availability.
Treating a host as merely a place to draw pixels is the mistake that produces per-host forks.

This resolves what looked like a question about which surface is primary. Neither is.
Domain logic is primary; every host — including the browser — is an adapter.

Layer	Owns	Never
Domain packages	Canonical types, application services, projections, governance rules, capability contracts, core UI	Host specifics
Adapters	Host and infrastructure translation: identity validation, payload translation, schema enforcement, structured results	Domain policy, provider business rules, canonical schema
Apps	Assembly of deployable surfaces	Behaviour not present in domain packages
Deploy	Environment configuration	Anything that changes behaviour

No adapter may redefine canonical entities, governance policy or projection semantics. The
test is falsifiable: the same domain and application-service packages serve the web and the
host deployments, and a deployment can move between infrastructure providers without domain
logic changing.

Repository topology follows from this. The boundary between repositories is drawn by
write authority, not by distribution channel — Platform owns canonical truth and
everything permitted to write it; Product owns operational state, agent working memory and
every channel adapter. Putting two channels in two repositories would make them peers, and
peers drift: the onboarding state machine must be byte-identical across channels, and a git
boundary converts that from a compiler guarantee into a discipline. It would also make every
future host a repository rather than a folder.
Repository Topology and Migration.

15.6 Host-first is a preference, not an entitlement

A host-native route may be selected only when the capability is actually exposed to the
current session, the required scopes are present, policy allows it, the data authority and
freshness are sufficient, and the operation can produce evidence and a receipt where
required. Otherwise the Spine completes the request.

Every request is classified before it is routed. The classification determines whether Spine
enrichment is mandatory:

Scope	Spine enrichment
host-local	Optional — lightweight provenance only
entity · continuity · cross-system · governance · write	Mandatory

A strictly host-local read may stay local only when all of the following hold: the user is
asking only about the active host; no canonical entity or cross-system context is needed; no
material write is involved; policy permits it; provenance is retained; and the result does
not claim to represent complete operational truth.

That last clause is the whole safety property. "Summarise my unread mail" is a legitimate
host-local answer. "What needs my attention?" is not — it claims cross-system completeness
and therefore requires canonical aggregation.

Read precedence: confirmed host-native live capability → permitted Spine-derived operational
context → IntegrateWise-managed live connector → bounded historical/context evidence → request
connection → unavailable. Canonical Spine storage is never a direct AI read route; any Spine-derived
context must pass through Context Assembly and the applicable human or AI projection contract.

This is not a sequential query plan. The resolver combines routes: mail may be host-native
while CRM and chat arrive through the Spine, in one answer, with per-source provenance.

Write precedence: resolve canonical target and policy → create proposal → determine
allowed routes → prefer host-native when confirmed and approved → otherwise Capability
Fabric → capture receipt → normalise and reconcile → rehydrate.

15.7 Connection binding — one route per operation

The same provider must not be called through both the host and IntegrateWise merely because
both are connected. One primary route is selected per operation; a secondary route may be
used for fallback, verification or reconciliation when policy allows.

Principal matching uses canonical identity, never display name. Connection tokens remain
inside their owning trust boundary — no credential is copied between host and IntegrateWise
to unify routing, and IntegrateWise stores no host credential unless the user separately
creates an IntegrateWise connection.

A binding records the provider, the canonical principal, the optional host connection
reference, the optional IntegrateWise integration, the routing preference
(host-first · integratewise-first · policy-decides), whether duplicate calls are
permitted, and the reconciliation mode.

15.8 Agent contracts

Agents are contracts, not transports. An agent definition never owns provider-specific
transport logic, and every agent invocation receives a policy-filtered Active Context
Bundle — never raw provider payloads, unless the task is explicitly ingestion or
normalisation.

Agent	Responsibility
Twin	Reasoning, synthesis, recommendations, proposal drafting
Triage	Intent, urgency, ownership and attention classification
Governance	Policy interpretation, approval requirements, risk classification
Entity Resolver	Canonical entity and identity matching
Evidence	Evidence selection, provenance checks, contradiction detection

The Active Context Bundle is the single input contract: actor and permissions, host and
session, entities, relationships, continuity, commitments, signals, decisions, evidence,
available actions, effective policy, and the completeness level with missing systems named.

Evidence carries authority (system-of-record · canonical · derived · user-supplied) and
freshness (live · recent · stale · historical) separately, because they answer different
questions. Live host evidence is authoritative only for the provider object it
represents; the Spine remains canonical for cross-system identity, relationships,
continuity and reconciled state. Four timestamps are distinguished — observedAt,
receivedAt, normalizedAt, reconciledAt — because collapsing them is how stale data
starts looking fresh.

Derived conclusions are never stored as facts. Conflicting evidence is surfaced, not
silently resolved, and a normalisation conflict quarantines the update while preserving both
records.

16. The public boundary

16.1 Nineteen tools, exactly

The public MCP surface exposes exactly nineteen semantic tools. Not eighteen, not twenty.

Context and continuity: get_my_continuity · get_active_context · get_my_focus ·
get_context · get_changes · get_related · get_history · get_commitments ·
get_decisions · get_permitted_memory · get_relevant_knowledge

Twin: ask_twin · assign_twin · get_prepared_work

Action: get_available_actions · prepare_action · get_action_plan · approve_action

Capture: store_in_spine

The internal MCP Pool, provider operations, raw table access, transport details, context
relay, agent handoff and connector implementation tools are not public. UI resources are
additive — a widget may communicate only through the host's declared bridge and cannot reach
the host DOM, cookies, credentials, Neon, provider credentials or the internal Pool.

Notice the shape of that list: eleven read tools, three Twin tools, four action tools, one
write tool. The single write tool is store_in_spine — a human observation. The four action
tools cannot execute; approve_action requires an approval that a human granted. The public
surface is structurally incapable of autonomous mutation.

16.2 Distribution names

IntegrateWise               = company / firm
SpineWorkspace             = product and user's single connected operational surface
Role workbench              = hostname- and authority-selected projection inside SpineWorkspace
Workspace                   = tenant/user scope inside the product
IW-Spine-Network            = the public distribution identity
IW-Spine-Network Plugin     = plugin-directory package (MCP app UI + skills)
IW-Spine-Network MCP        = MCP-marketplace package and remote server
IW Spine Tools              = the public 19-tool MCP interface
Spine Fabric              = the canonical operating model and truth substrate

SpineWorkspace is built by IntegrateWise and runs on the IW-Spine-Network contract.

Publishing to a channel publishes a channel-specific package bound to the same public
contract — never a different backend. Installing does not clone Customer Zero: activation
resolves an isolated customer tenant and applies the Customer Zero-proven reference
configuration. Customer Zero data, credentials, memory, cache, queues and audit never cross
that boundary.

16.3 Distribution — one product, three entry points

Distribution	Marketplace promise	Primary experience	Package
IW-Spine-Network MCP	Bring continuity and governed action into your AI workspace	Tool-first, conversational invocation	Remote MCP server exposing the 19 semantic tools
IW-Spine-Network Plugin	See and operate your connected workspace inside the AI host	Embedded Workbench, contextual Twin, approval UI	Host app with UI resources and skills, same MCP contract
SpineWorkspace	Operate the complete connected workspace directly	Full browser Workbench	Browser application on the same Gateway

16.3a Marketing-to-product routing

The public marketing surface presents the whole SpineWorkspace product. Role and
function pages explain relevant outcomes; they are not operational workbenches and do not
choose an authenticated projection. From marketing, the user enters or activates the product;
the role workbench then runs on a *.spineworkspace.com hostname selected from authenticated
authority and the allowed hostname map.

flowchart LR
  Marketing["integratewise.ai: full product story, solutions, pricing and activation entry"] --> Auth["OneAuth / Flow D"]
  Auth --> Authority["Tenant + membership + consent + allowed role/workspace"]
  Authority --> Host["role.spineworkspace.com"]
  Host --> Shell["One SpineWorkspace shell"]
  Shell --> Projection["Role/task projection from Spine"]
  Internal["Internal projections: brandstore, book-of-records / orgmemory"] -. "never public marketing solutions" .-> Shell

Surface or mapping	Repository evidence	Classification
Full marketing site at integratewise.ai	apps/marketing/app, sitemap base URL, Vercel topology	VERIFIED in code/config; live routing not re-proved here
Public solutions grouped by function, industry and role	apps/marketing/lib/solution-taxonomy.ts and tests	VERIFIED
Marketing association separated from operational hostname identity	taxonomy types/tests deliberately omit hostname and projection IDs	VERIFIED and correct
Role workbench hosts at *.spineworkspace.com	apps/web/lib/projection-registry/hosts.ts, middleware, Gateway hostname policy and tests	VERIFIED in code; deployed reachability is separate evidence
Authenticated hostname fails closed when unknown or disallowed	Gateway projection tests and middleware 404 rewrite	VERIFIED
Marketing entry deterministically hands off to an allowed role host after Flow D	Pieces exist across marketing, auth/activation and product host maps	INTENDED / partial — one canonical handoff contract and end-to-end test are still required
brandstore and book-of-records operational projections	Workbench/Gateway host registries and policies	VERIFIED internal product projections
brandstore, book-of-records or orgmemory as public marketing solutions	Public taxonomy tests explicitly exclude the first two; orgmemory is absent	Forbidden by doctrine; currently aligned

The public solution catalogue and the operational host registry therefore remain separate
contracts. A solution page may associate with several workbenches; a workbench may be internal
only. No code should derive tenant authority from a marketing URL or expose an internal host
merely because it exists in the operational registry.

One product:      IntegrateWise Workbench on IW-Spine-Network
Distributed via:  MCP Marketplace · Plugin Marketplace · Direct activation

These are acquisition and interaction channels, not products. Each binds to the same
tenant and workspace, the same Spine Fabric, the same Gateway, the same 19-tool semantic
contract, the same governance path and the same Workbench composition model. Marketing them
as distinct products creates the competing-authority problem at the commercial layer that
this document exists to prevent at the architectural one.

The three marketplace surfaces have different commercial jobs:

Marketplace	GTM role	What it installs or activates	Where value appears
Plugin Marketplace	External acquisition and embedded activation	IW-Spine-Network Plugin	Focused UI, skills and approvals inside the AI host
MCP Marketplace	External acquisition and tool-first activation	IW-Spine-Network MCP	Exact 19-tool interface, fallback results, optional widgets and browser Workbench launch
Connector Marketplace	In-product capability activation and expansion	Tenant-scoped provider connection, connector binding, schema mapping and capability grant	Hydrated Spine context and governed provider capabilities inside IntegrateWise

Plugin and MCP marketplaces distribute IntegrateWise. Connector Marketplace does not
install IntegrateWise; it expands what an activated workspace can observe and govern.
Direct Workbench activation remains a non-marketplace entry path. Provider or developer
marketplaces may wrap the Plugin or MCP contract in channel-native installation, OAuth and
webhook semantics, but they do not create another product or authority.

The full GTM motion is:

Category and demand
→ Plugin Marketplace, MCP Marketplace or direct Workbench activation
→ identity, tenant, consent and workspace activation
→ Connector Marketplace connection or eligible connection reuse
→ Spine hydration and role projections
→ first grounded value
→ first approved governed outcome
→ additional connectors, roles and recurring use

The north-star metric is time to first approved governed outcome. Channel metrics support
it: listing view → install → active for Plugin and MCP, and discover → consent → bind or
reuse → healthy → hydrated for Connector Marketplace.

16.4 Acquisition to value

Discover → Install → Resolve identity → Resolve or create workspace
→ Consent → Bind capabilities and connections → Hydrate Spine
→ Compile projections → First value → Daily use
→ Propose governed action → Execute and reconcile → Expand connected systems

Activation must create or resolve, at minimum: Actor · Tenant · TenantAccount · Workspace ·
Membership · Role and permissions · SpineNetwork · MarketplaceInstallation · HostBinding ·
ConnectorBinding · SpineConnection · CredentialReference · CapabilityManifest · PolicySet ·
RoutingPreference · SchemaBindingSet · HydrationJob · ProjectionManifest.

First use must be semantic, not administrative. In the MCP channel the first interaction
should be "What needs my attention?" — and if no workspace exists yet, the activation
detour must preserve the original intent and return to it. An onboarding flow that
discards the question the user actually asked has failed at the Context Law.

16.5 Flow classification at the channel boundary

Payloads are classified individually. A single AI-host interaction spans all four flows,
and labelling the whole exchange "AI data" is the error that lets model output become truth.

#	Event	Flow
1	Plugin installed; identity, tenant, consent, bindings resolved	D
2	User asks "What needs my attention?"	C
3	Host retrieves mail messages	B
4	Host retrieves structured CRM objects	A
5	IntegrateWise supplies canonical continuity	Spine read
6	Model produces analysis and recommendations	C
7	Model proposes an escalation email	C — proposal
8	User approves	Governance
9	Host or IW connector sends it	Governed execution
10	Sent-message artifact	B
11	Delivery and status metadata	A
12	Execution receipt	Audit evidence
13	Reconciliation updates the Spine	Canonical promotion

A tool call is three things, not one:

tool request        → Flow C   (the model's intent)
provider result     → Flow A or B   (what came back)
model interpretation → Flow C   (what the model concluded)

The transport does not determine the flow. The payload's semantic responsibility does. A
Salesforce object that travelled through ChatGPT is Flow A; the sentence ChatGPT wrote about
it is Flow C.

16.6 GTM funnel mapped to runtime state

The commercial funnel and the activation state machine are the same events. Instrument once.

GTM stage	Runtime evidence
Impression	Listing viewed
Install	MarketplaceInstallation created
Activation started	initiated
Identity completed	Canonical actor resolved
Workspace activated	Tenant · workspace · SpineNetwork resolved
First connection	Confirmed host or IntegrateWise binding
Hydration started	Initial sync job created
First value	First canonical — or explicitly disclosed partial — response
Engaged	Repeated continuity and context use
Governed value	First proposal approved
Closed loop	First execution reconciled into the Spine
Expanded	Additional provider connected
Retained	Recurring cross-system use

"Installed" is not an activation metric. The first real milestone is a grounded
continuity answer produced from a resolved workspace, with provenance and disclosed
completeness. The milestone that predicts retention is first governed action executed and
reconciled.

Detail — activation envelope, per-channel journeys, read/write routing precedence, acceptance
criteria: Marketplace Channels and Data Flow
Spec.

16.7 Product and platform ownership

SpineWorkspace owns	IntegrateWise Platform owns
Workbench rendering, canvas composition, interaction state, contextual Twin UI, approval UI, onboarding and administration presentation	Identity resolution, tenant authority, connector catalog and credentials, canonical truth, projections, capability resolution, governance, execution, reconciliation, audit, semantic APIs

No SpineWorkspace deployment becomes a second Fortress, connector runtime, credential store,
canonical database, projection authority or provider-execution path. IntegrateWise owns the
underlying platform substrate; SpineWorkspace consumes it through stable contracts. Product frontends may
run anywhere; they are clients of the matching Gateway. The Platform authority stays
Cloudflare-hosted.

flowchart TD
  Product["PRODUCT owner: Workbench shell, role/task UX, tables, records, documents, messages, canvas, Twin and approval presentation"]
  Gateway["GATEWAY owner: identity assertion, TenantGate, consent/RBAC, semantic API and command boundary"]
  Platform["PLATFORM CONTROL owner: configure, activate, observe, release; never a projection or execution authority"]
  Projection["PROJECTION / CONTINUITY owner: bounded Workbench and agent context"]
  Pipeline["PIPELINE owner: Loader, Normalizer, candidate staging, canonical promotion and outbox"]
  Spine["SPINE owner: canonical entities, operational state, evidence, links, provenance, events and search indexes"]
  Fabric["CAPABILITY FABRIC owner: registry, resolver, health, route and version"]
  Governance["GOVERNANCE owner: policy, decision and approval token"]
  Hermes["HERMES owner: approved orchestration, receipts, retries and reconciliation"]
  Sources["SOURCE SYSTEM owner: external record and observed result"]
  Product --> Gateway
  Platform -. "control / observe" .-> Gateway
  Platform -.-> Pipeline
  Gateway --> Projection
  Projection --> Spine
  Gateway --> Fabric
  Fabric --> Governance
  Governance --> Hermes
  Hermes --> Sources
  Sources --> Pipeline
  Pipeline --> Spine
  Spine --> Projection

The browser calls one typed Gateway client using one variable, NEXT_PUBLIC_IW_API_URL. The
first canonical read after sign-in or workspace switch is GET /api/v1/workspace/discovery,
returning a versioned tenant/RBAC-scoped manifest: identity and scope, projected navigation,
projection IDs and contract versions, connector and sync availability, capability and
approval availability, activation blockers, freshness and remediation.

No browser call reaches Neon, D1, KV, R2, the credential wall, a provider, Hermes or the
internal MCP Pool.

16.8 The unit of operational work

IntegrateWise provides the substrate required to run operational work. The economic model can
therefore be measured around units of operational work, rather than only seats, tokens or
connector count.

A unit of work may be defined by the product according to the actual metering contract, but the
architecture should be capable of attributing cost across:

• context assembly
• AI reasoning
• agent execution
• workflow execution
• connector/API operations
• communications
• governance and approvals
• reconciliation
• infrastructure consumption

The strategic principle is:

IntegrateWise provides the identity, connectivity, AI, execution, communication, governance
and infrastructure substrate required to run work; SpineWorkspace coordinates the work itself.

This does not imply that every internal infrastructure operation is separately billable. It means
the platform is designed to understand the cost and performance of the operational work it enables.

17. Environments and promotion

Environment	Purpose	Isolation
Development	Product engineering, local/preview apps, CI, disposable tests	Synthetic data; development identity, Gateway, Neon, D1/KV/R2/queues and secrets only
Customer Zero	IntegrateWise operating IntegrateWise as its first real customer	Production-grade but isolated tenant, credentials, MCP Pool, queues, evidence, audit and bindings. Never a general test tenant
Customer Production	External customers	Tenant-scoped everything; no access to Development or Customer Zero

Promotion is one-way: Development proof → Customer Zero validation → Customer Production release. Production data, credentials and bindings never flow back.

Test and prod must never share KV namespaces, Queues, D1 databases, R2 buckets, Vectorize
indexes, Durable Objects, secret stores, or service-binding targets. Every feature completes
in three directions: development readiness, platform release readiness, customer activation
readiness.

17.1 Frozen go-live sequence

Go-live promotes the same Product and Platform versions through isolated environments. It
does not copy Customer Zero or create a separate external product.

source commit
→ CI and contract tests
→ Development artifacts
→ Customer Zero private installation
→ Customer Zero evidence
→ version freeze
→ external clean-tenant test
→ Plugin and MCP submission-ready
→ public publication

The release completes five phases in order:

1. Shared contracts: freeze the exact 19 public tools, resources, UI intents, discovery
   envelope, tenant binding contract and versioned activation profiles
2. Customer Zero Plugin: prove the private embedded UI, identity, host composition,
   explicit delegation and the governed proposal-to-reconciliation loop
3. Customer Zero MCP and Workbench: prove OAuth, exactly 19 tools, ordinary-client
   fallback, browser launch, discovery-first composition and role-based access control
   (RBAC) projections
4. Externalization: install the same artifacts into a clean tenant and prove dynamic
   tenant resolution, customer-owned connections and complete Customer Zero isolation
5. Publication: freeze compatible versions, publish the Plugin and MCP, verify a new
   tenant installation and operate governed monitoring, rollback, revocation and deprecation

Only code, manifests, definitions, schemas and versioned activation defaults cross the
promotion boundary. Tenant data, credentials, bindings, queues, caches, evidence, audit
records and runtime state never cross it.

17.2 Mandatory release gates

Customer Production release requires all of the following evidence:

• Customer Zero runs daily work through the Plugin and browser Workbench
• the frozen versions install into an unrelated tenant without code changes
• identity, tenant authority, RBAC and environment isolation pass negative tests
• the public MCP returns exactly 19 tools and supports browser launch and ordinary-client
  fallback
• one real connector passes consent, mapping, hydration, delta sync, health, revoke and
  reconciliation
• every external action follows proposal → approval token → Hermes → provider outcome →
  Spine re-ingestion → projection refresh
• observability, audit, rate limits, rollback, deletion, export, offboarding and revocation
  have live evidence
• the release manifest records compatible Plugin, MCP, frontend, Gateway and Platform
  versions

Any missing gate is a stop-ship condition. Appendix I remains the complete invariant-level
stop-ship list.

Claims about the system use one of three states, and code presence is not live proof:

State	Meaning
Defined	The contract is decided
Implemented	Repository code or migration evidence exists
Live verified	The environment has passed the required runtime and isolation tests

---

Part III — Reality

Reality note: Part I and Part II were re-baselined on 2026-08-24 around the v3.0 human–AI
work-coordination model. Part III below remains a historical repository-grounded snapshot from
2026-08-13 at commit 2187bc91. Where Part III uses older terms such as "Adaptive Spine" or
describes direct AI reads of a Spine projection, those statements are evidence of the prior
implementation state, not permission to override the v3.0 doctrine. New implementation work
must conform to the current Spine Fabric → Human Projection / AI Sandbox boundary.

Parts I and II describe the architecture. This part describes the system as it exists on
2026-08-13, at HEAD 2187bc91. Both are necessary; a document that only described the
intent would be the fourteenth such document.

18.0 Grounded implementation snapshot

This matrix records repository presence, not deployed reachability. “Partial” means the
contract is represented but the closed end-to-end path is not proven from this checkout.

Required product/platform capability	Current repository evidence	Status at 2187bc91
One Workbench with role-aware modules	apps/web, packages/workbench-config (12 role configs), packages/projection-contracts	VERIFIED / partial — contracts and surface exist; legacy surface/taxonomy drift remains in §20
OneAuth, consent, tenant and workspace binding	apps/auth, apps/one-access, apps/activation, services/gateway/src/auth.ts, Gateway activation state machine, services/tenants	VERIFIED / partial — multiple identity surfaces and Clerk/Descope authority remain unresolved
Tenant-specific Spine schema/profile generation	Gateway Spine-schema routes and tenant adaptive-schema resolution in Pipeline Normalizer	VERIFIED / partial — logical hydration exists; complete onboarding-to-schema-to-ingestion gate needs one proof
Flow A/B Loader and Normalizer	services/connector, services/loader, services/pipeline/src/normalizer, provider/connector packages	VERIFIED / partial — duplicate ingress generations and legacy paths remain
Flow C continuity across AI hosts	public continuity facade, services/continuity, Knowledge/memory routes, host-aware contracts	INTENDED / partial — bounded pieces exist; cross-host isolation and promotion need live proof
Canonical and operational Spine boundary	Pipeline canonical writer, D1/KV/R2 bindings, packages/spine-entities, schemas and migrations	DRIFT — Neon/D1/Supabase-era semantics and more than one apparent write path still conflict
Projection, tables/documents/canvas and active context	Gateway projection routes, packages/projection-contracts, context contracts, Workbench modules	VERIFIED / partial — sole-composer and complete live-data claims remain unproven
Silent Twin grounded context	services/twin-orchestrator, services/intelligence, services/context-fetch, packages/context-contracts	DRIFT — substantive code exists, but Twin orchestration is not in the nine-service core release path and context is not uniformly task/ID/evidence bound
ADK orchestration, cache, capability and continuity contracts	packages/adk, services/iw-agent-runtime, model/omni routing packages	VERIFIED / partial — registry/resolver code exists; authoritative runtime ownership and reachability are fragmented
Capability Fabric and MCP Pool	services/mcp-pool, provider/integration/task MCP services, Gateway public Spine tools	DRIFT — several fabric implementations and public/internal boundaries require enforcement, not documentation only
Governance, approval, Hermes, provenance and audit	Gateway governance/HITL modules, governance-engine packages, services/hermes, receipt/provenance types	DRIFT / stop-ship — Hermes routes exist in Gateway but Hermes is outside the core release set; an approval-bypass-shaped Twin coordination branch requires correction
Provider action, sync, re-ingestion and reconciliation	connector/MCP services, connector-sync, Pipeline queues, workflow/HITL	INTENDED / partial — components exist; one real closed action trace remains a release gate
Marketplace/package distribution	public 19-tool contracts, marketplace installation service, plugin/MCP briefs and release packaging scripts	VERIFIED / partial — clean installation and byte-identical multi-channel activation need live evidence
Security, observability and release isolation	TenantGate/Gateway assertions, audit/telemetry services, deployment-policy checks, release validation and packaging scripts	VERIFIED / partial — code presence does not satisfy negative isolation, rollback, revocation and clean-tenant gates

18. What is load-bearing

Stripped of everything unreachable:

Browser (apps/web — Next App Router)
  │
  └─► gateway ─────────── 51-entry ROUTES prefix table
        ├─ INTERNAL_*     auth · projections · billing · tenants · admin · support
        ├─► pipeline      normalise → canonical write        (Spine writer #1)
        ├─► spine         Neon canonical CRUD                (Spine writer #2) ⚠
        ├─► connector     router only ──► loader · store · mcp-connector
        ├─► mcp-connector MCP tools + OAuth authorisation server
        ├─► connector-sync scheduled provider sync
        ├─► knowledge     chunk · embed · search · synthesis · promotion gate
        ├─► intelligence  think · act · govern · agents
        ├─► workflow      (BFF) views · analytics · stream · HITL Durable Object
        ├─► iw-agent-runtime  TWIN_AGENT + TENANT_BRAIN DOs  ⚠ not in CORE_SERVICES
        ├─► mcp-pool      capability routing control plane   ⚠ shared test/prod
        └─► hub-controller-api                               ⚠ AUTH BYPASSED
  continuity              session log; reached via mcp-connector

Nine Workers are in the canonical publication path (scripts/release/deploy-platform.sh):
pipeline → connector → mcp-connector → connector-sync → knowledge → continuity → intelligence → workflow → gateway, Gateway last.

Shared code that genuinely carries weight: @integratewise/types (99 consumers),
connector-contracts (90), lib (23), connectors (18).

Everything else — 11 unbound Workers, ~14 zero-consumer packages, 2 unreachable Capability
Fabric implementations, 2 orphaned application roots, a retired GCP product, 102
_deprecated components, 5 abandoned service folders — is inert mass.

19. Scale

Layer	Count
Source files (.ts/.tsx/.js/.jsx/.mjs, build output excluded)	1,950
apps/	12 top-level folders
services/	31 top-level folders
packages/	50 top-level folders
Markdown under docs/	720 documents
SQL artifacts in the repository	743 files

Verified against HEAD on 2026-08-13: nine CORE_SERVICES in the stated order, 60 Gateway
ROUTES entries, 12 roles in packages/workbench-config, /api/v1/workspace/discovery
present in services/gateway/src/index.ts, spine, hermes, twin-orchestrator and
iw-agent-runtime absent from CORE_SERVICES.

20. Drift register

Every item is a violation of Part I or Part II, ordered by risk removed per unit of effort.
Source: CODEBASE_EXCAVATION.md, 2026-07-30.

Tier 0 — Silent data loss

S0 · The Canonical Spine does not run. Cache writes are reported as canonical
persistence.

Verified at HEAD, 2026-07-31. This is the most severe finding in the register and it is
not a design disagreement — it is a correctness defect that reports success.

The intended canonical writer, services/pipeline/src/canonical/canonical-writer.ts, is
invoked at services/pipeline/src/index.ts:1922 behind a binding guard:

if (env.CANONICAL_SPINE_DB) {
  const canonicalWriter = new CanonicalSpineWriter(env.CANONICAL_SPINE_DB);
  await canonicalWriter.write(rec, { create_relationships: true });
}

Its binding, services/pipeline/wrangler.toml:118–120:

[[d1_databases]]
binding      = "CANONICAL_SPINE_DB"
database_name = "integratewise-canonical-spine"
database_id  = "YOUR_D1_DATABASE_ID_HERE"   # unreplaced scaffold placeholder

The database ID was never replaced. The binding never resolves. The guard is permanently
false, and every canonical write is silently skipped. The surrounding try/catch logs
to console.warn, so even a resolving binding would fail quietly. Three lines later:

// For writes, D1 is authoritative. Return success.
return json({ success: true, written: entities.length, via: "d1-primary" });

Entities written only to the D1 entity cache (integratewise-spine-cache) are reported as
written. A cache write is being returned as canonical persistence.

Four implementations claim Spine authority; the two that matter are not the two anyone
expected:

Implementation	LOC	Store	State
spine/src/entity-store.ts + index.ts	898	D1	LIVE — and correct. This is the Operational Spine: the seven runtime entity types
spine/src/neon-workbench.ts	558	Neon	LIVE — tenant/actor-scoped Workbench projection
spine/src/canonical-store.ts	995	D1	DEAD — no importers. Declares the 16 root concepts and asserts itself the single source of truth. Its types were copy-pasted into pipeline/src/canonical/entity-type-map.ts:16 with the comment "Types duplicated from spine canonical-store to avoid cross-service dependency"
pipeline/src/spine/index.ts	2,773	Supabase	LEGACY — self-labelled "the legacy writer", still in the release path

This inverts §S8. There are not two competing canonical writers to choose between. There
are zero working ones, plus a retired Supabase writer that still runs.

Resolution — this closes D4.

The Canonical Spine is Neon. The Operational Spine is D1. services/spine owns both
boundaries. The Pipeline is the only writer into canonical.

Ordered, because each step removes an ambiguity the next would otherwise encode:

1. Make canonical write failure hard-fail. Replace the console.warn swallow; a failed
   canonical write must not return success: true. This is the highest-value single change
   in the register — it converts silent data loss into a visible error.
2. Route canonical writes through the SPINE binding to Neon; delete CANONICAL_SPINE_DB.
   A second D1 canonical store is not needed and recreates the split it was meant to solve.
3. Move the 16-concept ontology into packages/spine-entities (already consumed by
   services/spine) and delete the copy-paste in entity-type-map.ts. One definition.
4. Retire services/pipeline/src/spine/ once 1–3 land.
5. Stop using the word "Spine" unqualified in new code. It is Canonical or Operational.

Steps 1–3 also unblock the repo split (§15.5): a boundary cannot be drawn while the
canonical store on one side of it is a placeholder.

S0b · org_memory is a documented cache with six writers.
d1_knowledge.sql:12 describes it as "Mirror of memory.org_memory for edge-fast reads."
Six services INSERT/UPDATE it directly — pipeline/src/index.ts,
pipeline/src/memory-promoter.ts, intelligence/src/memory/evolutionary-memory.ts,
intelligence/src/handoff/outcome.ts, intelligence/src/workflows/triage-workflow.ts,
mcp-connector/src/handlers/tools.ts — and 23 files reference it. There is no defined
reconciliation against the Postgres table it claims to mirror. This is S0 repeating one
layer up. It must become either the store or a cache, with one writer. (M1)

S0c · agent_memory exists only inside retired infrastructure. Its sole definition is
services/pipeline/src/spine/index.ts:1360 — inside the Supabase legacy writer scheduled
for deletion. It needs a D1 table alongside personal_memory before step 4 above, or
the capability is lost with the file.

Tier 0b — Publication blockers

Verified 2026-07-31. Each blocks marketplace submission; all but the last are configuration
or copy. Detail: MCP and Plugin Publishing
Spec.

#	Finding	Evidence
F1	Two Workers claim mcp.integratewise.ai — the top-level Worker and env.prod both bind the public custom domain. Last deploy wins; a routine default-env deploy silently repoints the public MCP endpoint. validate-platform-deployment.sh checks existence of mcp-connector-test/-prod, not route uniqueness, so it passes	services/mcp-connector/wrangler.toml:6, 226
F2	The published manifest advertises 23 tools. The tools array holds 19; the description says 23 — the connector count (20 operational + 3 cognitive) written as a tool count. Violates stop-ship invariant #2	marketplace/apps/iw-spine-network.json
F3	The public manifest names mcp-pool as its routing target. Either the public path runs through the internal control plane, or the manifest is wrong and leaks internal topology. Both block	marketplace/apps/iw-spine-network.json → ownership.routing
F4	MCP Pool has no env.test, and env.dev binds integratewise-integration-management-mcp-prod. The development control plane talks to production, on the component with the most privilege	services/mcp-pool/wrangler.toml
F5	iw-continuity-bridge.json — a retired public name (D9) — sits in the publishable directory	marketplace/apps/
F6	Five release flavours against a two-package doctrine, with no stated mapping	releases/

Tier 1 — Correctness and security

S1 · A second, unauthenticated entry point sharing one database across surfaces.
packages/api (hub-controller-api) is bound by the Gateway in dev, test and prod — all
three to the same unsuffixed Worker with one D1 database. The Gateway explicitly skips its
own authentication for every /api/* path that is not /api/v1/*. It carries billing.ts,
auth.ts and capability-routes.ts — money, identity and capability execution. No deploy
script references it, so its deployed code is unversioned relative to the release ledger.
Violates Law 7 (one boundary), §14 (Gateway derives authority), §17 (test/prod isolation).

S2 · Fifteen dangling service bindings. The core nine were renamed from
integratewise-* to bare names; consumers were never updated. These resolve to nothing at
runtime.

S3 · Five test/prod binding leaks in the Gateway. HUB_CONTROLLER and MCP_POOL point
at identical targets in both environments. validate-platform-deployment.sh asserts only
mcp-connector isolation, so none of this is caught by release:check.

Tier 2 — Restore a single truth

S8 · Three deployed Workers assert three different single sources of truth.
services/pipeline claims to be the only holder of Spine write credentials;
services/spine claims to be the platform's single source of truth and holds DATABASE_URL
plus a 995-line canonical store; services/billing asserts Supabase. Additionally
services/pipeline/src/spine/ is a second, self-labelled-legacy Spine implementation
(2,773 LOC, Supabase-backed) that is live in the release path. Violates §8.3 directly.
services/spine is Gateway-bound and named canonical, yet is not in CORE_SERVICES — so
release:deploy --service core never publishes it.

S4 · Four environment vocabularies. Eight services still use retired
staging/production; signals and telemetry have no test surface at all. Both root
wrangler.toml and wrangler.jsonc are invalid and unused. ci-cd.yml is named DISABLED
but still contains seven direct wrangler deploy invocations — a second publication path.

S9 · Seventeen migration roots, 476 files, duplicate sequence numbers. Ordering is
ambiguous in both /migrations (three collisions) and /sql-migrations (nine).

Tier 3 — Inert mass

S5 · Three Capability Fabric implementations, none of them the live one.
packages/core and packages/lib/capability-fabric are near-exact mirrors, ~35 files,
mutually redundant and unreachable. The live path is
services/gateway/src/workbench-capabilities.ts + internal/capability-execution.ts +
services/mcp-pool.

S10 · A complete second, orphaned application root inside apps/web (Vite entry, config
and router, all committed and unreachable), plus 102 tracked _deprecated components.

S11 · Retired GCP/Firebase infrastructure still committed, including
services/mcp-connector/src/lib/firestore.ts inside a core release-path Worker.

S12 · Sixteen packages omit private, which npm treats as publishable — including
packages/connectors (~90 provider integrations) and packages/core (governance engine).

Tier 3b — Contradictory governance, and doctrine enforced by nothing

S5b · Two opposite promotion rules in one service.
knowledge/src/triage-bot.ts:13 — "The Triage Bot NEVER auto-stages. Every
extraction requires customer review."
knowledge/src/synthesis/promotion-gate.ts:8 — "AUTO-APPROVE: High confidence + no
governance flags + trusted domain", with decision: "auto_approved" at lines 124 and 144.

Both are in services/knowledge. The never-auto-stage position is correct per §8.2c-i and
the Authority Law. pipeline/src/memory-promoter.ts (415 LOC, live, queue-driven) already
implements the right shape. synthesis/promotion-gate.ts is orphaned and should be deleted.

S5c · The synthesis pipeline targets a store that no longer exists.
knowledge/src/synthesis/ — triage-bot, promotion-gate, continuity-object-factory,
lineage-tracker, knowledge-model — is a complete, unreferenced pipeline built on
CouchDB, superseded by the D1 memory tables. CouchDB survives in 11 files: three in
synthesis/, three in packages/coda-pack, and five in packages/hermes-spine-memory —
an entire package on retired infrastructure.

Salvage before deleting: lineage-tracker.ts and its UnderstandingObject provenance model
have no equivalent in the live path. memory-promoter.ts writes an audit row but does
not track lineage across promotions. That is a real capability gap, not dead weight.

S5d · The canonical Authority Doctrine is in a package with zero consumers.
packages/contracts/src/authority.ts (228 LOC) declares itself "supersedes all other
architectural rules" and states the Triage Boundary that settles S5b exactly. Verified:
@integratewise/contracts has 0 importers. The doctrine is exported as a template
literal — human-readable, machine-inert. Its neighbours share the fate, including
surfaces/chat.ts ("The Chat surface IS the Triage Hub") and marketplace/installation.ts
(which services/marketplace-installation ignores in favour of its own types).

A rule enforced by nothing is not a rule. Move authority.ts into packages/types (99
consumers) and convert the Triage Boundary into a test.

Tier 4 — Vocabulary and surface discipline

S6 · Retired L-layer vocabulary is the frontend's primary organising principle, and it
leaks to users. components/l1/ is 240 files — the largest component tree in the repo —
plus l2/, l4/, l7/, layers/. A product surface renders the literal string
"12 L1 domain views + 14 L2 cognitive overlay components". The Gateway exposes 19
/api/v1/cognitive/* routes; "cognitive" is not a kernel term. Most seriously,
intelligence/src/agents/specialized/twin-orchestrator.ts embeds "CODA L4 & MCP TOOLS…
Coda documents are connected L4 projection surfaces" inside a live LLM system prompt —
so retired vocabulary is shaping the Twin's reasoning, not merely sitting in comments.
Violates Law 8 and §6.

S7 · The Workbench is not one surface. Four parallel entry namespaces resolve to
Workbench content: /workbench/[department]/work/[module],
/workspace/[department]/work/[module], /domains/[domain]/[view], /app/[...segments].
The first two page files are byte-identical except for one route string. Separately,
components/capability-shell/, inline-executor/ and proactive-capabilities/ place a
capability catalogue and executor inside the Workbench. Violates §11.2 and Law 6.

S13 · Naming collisions. packages/adapters (infrastructure) vs
packages/connectors/src/adapters (providers); two "accelerator" concepts; two Twin
orchestrators (a 3,470-LOC Worker with zero inbound bindings, and a 268-LOC agent); two
contract homes; two marketing implementations, of which the legacy-pages set is the live
one.

S15 · Canonical documentation is itself a sprawl surface. 94 documents in
docs/architecture/, 16 declared canonical, six with "canonical" in the filename. This
document is the remediation.

Schema gaps against the store model

Verified at HEAD on 2026-07-31 against the six-store assignment in §8.2b:

Column	Purpose	State
embedding_id	Vectorize reference on the entity	Present (7 files)
r2_key	R2 reference on attachments	Present, thin (2 files)
memory_scope	user · work · org (§8.2c)	Present, thin (2 files)
conversational_store_id	Raw conversational memory reference on inbox items	Missing
source_records	Cross-source provider fragments on assembled entities (§8.2e)	Missing

Chunking is confirmed at 512 tokens (services/knowledge/src/embeddings.ts:122). Durable
Objects are declared across six services — intelligence, iw-agent-runtime, hermes,
connector-sync, folder-watcher, workflow.

Tier 5 — Orphans requiring a verdict

Several substantial Workers remain outside the nine-service CORE_SERVICES release path,
including agent-registry, hermes, integration-management-mcp,
marketplace-installation, provider-management-mcp, schema-ai, signals, telemetry,
twin-orchestrator and vercel-mcp. Presence outside that list is not proof of
unreachability, but it means the canonical release does not deploy or validate them as one
closed runtime.

hermes is stage 11 of the frozen runtime sequence but is not a core release service.
Gateway declares Hermes routes and test/production service bindings, while the development
binding is commented out. Therefore repository routing is partial, not a verified
end-to-end execution path. This is the most significant gap between Part II and reality:
approval → Hermes → provider → receipt → reconciliation needs a live trace from the same
release manifest.

21. Open decisions

Genuine forks, not deferred work. Each blocks something.

#	Decision	Blocks	Note
D1	Is plugin_host a peer surface or a reduced companion to the browser Workbench?	Plugin channel implementation	Changes what "one Workbench" means. A constrained host panel cannot render six groups and forty items
D2	Does Platform become one gated destination or twenty-two sidebar entries?	Navigation consolidation	§11.2 records the recommendation (one destination); packages/workbench-config currently asserts the opposite
D3	How is the Industry axis derived — tenant Spine schema, or explicit config?	workbench-config shape	12 roles × ~12 departments × N industries cannot be enumerated statically
D4	Which Spine writer survives?	—	RESOLVED 2026-07-31. Neither was writing. Canonical = Neon via the SPINE binding; Operational = D1 in services/spine; Pipeline is the sole canonical writer. See S0
D5	Does development get its own tenant, or is it customer_zero on test?	Profile resolution	§15.3 permits either
D10	Are the Customer Zero Supabase migrations part of the Spine?	Store model, S8	A 2026-07-22 store mapping describes 34 Supabase migrations as "the Postgres partition of the Spine." SOURCE_PACK_RECONCILIATION (07-28) states Supabase is not in the frozen product path, and S8 flags two live Supabase-backed writers. Later date wins; the mapping's storage framing is superseded even where its data-class assignment is sound
D7	Is Co-worker a distinct agent or Twin behaviour?	—	RESOLVED — it was already decided twice. docs/wiki/21-adrs…md:66 records "'Co-worker' as a second runtime → Twin is the contextual AI Co-worker behavior" as a superseded concept, and packages/contracts/src/authority.ts states the boundary: Twin understands context · Co-worker performs bounded prepared work · Human owns authority. Co-worker is a behavioural mode of the Twin — never a type, table, service or route. Good positioning language in user-facing copy; not a second runtime. The Host-Aware Spec §11 listing should be amended
D11	Clerk or Descope as the browser identity authority?	§14, every onboarding path	Live conflict. §14 declares Clerk canonical, following IMPLEMENTATION_CONTRACT_v1.1 §3, which also states "Descope browser-session paths are legacy compatibility only." A more recent Customer Zero decision selects Descope for Magic Link and OTP. Both cannot be authoritative. Resolve before any marketplace listing — identity is the first state in the onboarding machine, and a fork here forks both channels
D12	Does “tenant-specific Spine schema” require physical database/schema isolation, or a tenant-scoped activated logical schema/profile over shared typed tables?	Onboarding, tenancy, migrations and isolation claims	This document requires the tenant-specific logical contract. The current code predominantly uses shared tables plus tenant_id; a stronger physical boundary must be chosen deliberately and proven operationally, not implied by wording.
D13	Which implementations own Twin/ADK orchestration, context assembly and capability resolution in the canonical release?	Silent Twin, agent continuity and runtime closure	twin-orchestrator, iw-agent-runtime, intelligence, context-fetch, packages/adk and multiple capability registries overlap. Choose and wire owners; do not declare all of them canonical simultaneously.
M1	org_memory: store or cache?	—	RESOLVED. Neon memory.org_memory is the store; the D1 table is a projection fed by the transactional outbox; the promotion gate is the only writer. The other five services become read-only consumers
M2	Does a team memory scope exist?	gateway/src/memory-governance.ts	Currently a type with no backing table anywhere. If wanted, it is a new scope decision — not an orphaned type file
M3	May agent memory be cited before triage?	—	RESOLVED. The Twin may cite agent memory within its own scope. It may not let agent memory inform an organisational-level claim until that material has passed triage and promotion
M4	Does Personal Memory ever widen to Org, and by what act?	§8.2c	The hard boundary is currently absolute, and that is defensible
M5	Canonical Spine on Neon only, or Neon plus a D1 read projection?	S0 step 2
M6	Is the Chat surface the Triage Hub, per contracts/src/surfaces/chat.ts?	Sidebar structure, §11.2	Better than a separate Triage nav entry; connects Personal → Brainstorming Sessions to the pipeline
D8	Repository structure	—	RESOLVED 2026-08-02. Consolidated into single monorepo (integratewise-live). Platform kernel lives in packages/ (contracts, connectors, spine-schema, adk, kernel). Product surfaces live in apps/ (web, platform, one-access). Three invokable microfrontends: @integratewise/auth-connectors-mfe, @integratewise/auth-onboarding-mfe, @integratewise/platform-mfe. See MICROFRONTENDS.md
D9	Is IW-Continuity-Bridge a live product name?	—	RESOLVED 2026-08-13. IntegrateWise is the company; SpineWorkspace is the product. “IW Continuity Bridge” is historical. IW-Spine-Network remains a distribution/package contract, not the browser product name.
D6	MCP Pool: one control plane or three per-profile pools?	—	RESOLVED 2026-07-31. One control plane. The public MCP surface is byte-identical across all three profiles; Pool is an operator control plane whose administration UI is exposed only in development and customer_zero. Pool is never a tool surface, never a public route, and never named in a published artifact. MCP_POOL_MULTI_ENVIRONMENT_STRATEGY.md is superseded. See MCP and Plugin Publishing Spec

22. Change discipline

Before adding a concept. Name the responsibility it owns using only the twelve kernel
terms. If you cannot, it is either duplication of an existing primitive or a genuine major
version — and a major version is a founder decision, not a pull request.

Before renaming. Record which of five things is happening: fundamental · evolved ·
renamed · superseded · experimental. Mixing these is how documents start conflicting. Every
rename goes in Appendix J.

Before shipping. Does the surface stay narrow? New platform capability should rarely
produce a new user-facing noun. Broad underneath, narrow at the surface.

When documents disagree. Explain the evolution; never mix eras. Optimise for
architectural fidelity, not document fidelity. Documents are snapshots; the architecture is
the living system.

When this document is wrong. Change it here. Do not write a second document. The reason
this consolidation exists is that the alternative was tried ninety-four times.

23. Implementation handoff — what happens next

Work may start immediately on contract tests, inventory and removal of known bypasses.
Decisions D11–D13 must be confirmed before identity, physical tenancy or Twin/ADK ownership
is frozen. Source material not present in this checkout is handled as a later reconciliation
pass, not a reason to delay this authority lock.

Phase	Depends on	Concrete work	Exit evidence
0. Authority lock	v3.0	Encode company/product naming, work-allocation doctrine, Spine Fabric boundary and public/internal taxonomy	One authority + amendment; terminology and boundary tests pass
1. Identity/tenant/consent	D11 and relevant D12 choice	One Flow D machine across browser/plugin/MCP; tenant/workspace/schema activation; ingestion gate	Negative auth/tenant/RBAC tests and identity-to-ingestion_enabled trace
2. Spine/ingestion	Phase 1	Freeze writer and stores; A/B/C Loader/Normalizer; outbox; phased hydration	No direct Fortress access; provenance-bearing initial/backfill traces
3. Projection mappings	Phases 1–2	Turn §11.7 into checked entity/view/action ownership registry	All 18 projections pass route, entity, field, role, freshness and invalidation tests
4. Workbench	Phase 3	One shell; task views; tables/documents/messages/canvases; active context	Acceptance for allowed role hosts; internal projections hidden from external tenants
5. Governed actions/sync	Phases 2–4	Signed approval, Hermes wiring, receipts, ambiguity handling and re-ingestion	Real provider mutation closes approval → source → reconcile → refresh with audit
6. Twin/Coworker/continuity	Phases 2–5	Select runtime owners; user Twin Workbench; AI Sandbox; work assignment layer; Coworker context/communication; bounded Flow C	No-direct-canonical-access proof, sandbox isolation, assignment/reconciliation proof and cross-host tenant isolation
7. Distribution	Phases 1–6	Browser product, plugin/MCP packages, marketing handoff, connector expansion	Clean install, first grounded value and first governed outcome
8. Operate/release	All	Observability, SLOs, deletion/export/revocation, rollback and isolation	Development → Customer Zero → clean external tenant; every §17.2 gate passes

Can start now: authority/link checks, projection contract generation, approval-bypass and
direct-writer tests, public/internal taxonomy tests, reachability inventory and a real
connector harness. Confirm first: D11, D12, D13, overlapping projection audiences and the
remaining open decisions in §21.

---

Appendices

Appendix A — Kernel terms

See §3. The v3.0 kernel is: ORGANIZATION · GOAL · WORK · WORK GRAPH ·
CONTEXT · MEMORY · SPINE FABRIC · PROJECTION · WORKBENCH · TWIN · COWORKER · AI SANDBOX · WORK
ALLOCATION · CAPABILITY · GOVERNANCE · EXECUTION FABRIC · HERMES · RECONCILIATION · CONTINUITY ·
OUTCOME.

Appendix B — Runtime sequence

Product loop

Organization Goal / Need → Work Graph → Shared Context → Context Assembly
→ Work Allocation → Human + AI Work → Decide → Execute → Verify
→ Reconcile → Continuity / Memory → Next Work

Platform loop

Configuration → Identity / Tenant Binding → Connectivity → Ingestion
→ Normalization → Spine Fabric → Projection / AI Sandbox
→ Capability → Governance → Execution Fabric / Hermes → Provider
→ Outcome → Re-ingestion → Reconciliation → Promotion / Continuity

Twin reasoning loop

Observe → Orient → Decide → Act

OODA is subordinate to the product Work Operating Loop.

Appendix C — Services

Core nine (canonical publication order, Gateway last):

Worker	Responsibility
pipeline	Normalizer + Spine writer. Self-declared sole holder of Spine write credentials
connector	Compatibility router → loader · store · mcp-connector
mcp-connector	MCP tool server + OAuth authorisation server
connector-sync	Schema-driven scheduled and on-demand provider sync
knowledge	Chunking, embedding, search, synthesis, promotion gate, lineage
continuity	Append-only session event log, checkpoints, continuity assembler
intelligence	think + act + govern + agents
workflow	Bound as BFF. Views, analytics, stream gateway, HITL Durable Object
gateway	Single entry point

Bound but outside the release path: spine (SPINE) · iw-agent-runtime
(AGENT_RUNTIME) · webhook-ingress · mcp-pool · admin · billing · tenants ·
folder-watcher · loader · store · task-management

Zero inbound bindings: agent-registry · hermes · integration-management-mcp ·
marketplace-installation · provider-management-mcp · schema-ai · signals ·
telemetry · twin-orchestrator · vercel-mcp

Appendix D — Gateway routes

Route	Target	Purpose
/api/v1/auth	INTERNAL_AUTH	Authentication
/api/v1/projections	INTERNAL_PROJECTIONS	Projection Engine
/api/v1/workspace/discovery	Gateway → Spine	First canonical read
/api/v1/workspace/*	BFF	Workspace operations
/api/v1/billing	INTERNAL_BILLING	Billing
/api/v1/tenants	INTERNAL_TENANTS	Tenant management
/api/v1/support	INTERNAL_SUPPORT	Support
/api/v1/analytics	BFF	Analytics
/api/v1/agents	INTELLIGENCE	Agent management
/api/v1/continuity-bridge	MCP_CONNECTOR	Public 19-tool Spine MCP
/api/v1/connectors	CONNECTOR	Connector management
/api/v1/pipeline	PIPELINE	Data pipeline
/api/v1/intelligence	INTELLIGENCE	Intelligence layer
/api/v1/cognitive/spine	PIPELINE	Spine operations
/api/v1/cognitive/entity360	PIPELINE	Entity 360
/api/v1/cognitive/memories	KNOWLEDGE	Memory operations
/api/v1/cognitive/signals	INTELLIGENCE	Signal processing
/api/v1/cognitive/think	INTELLIGENCE	Think / Twin
/api/v1/cognitive/act	INTELLIGENCE	Act execution
/api/v1/cognitive/govern	INTELLIGENCE	Governance
/api/v1/cognitive/twin	AGENT_RUNTIME	Twin runtime
/api/v1/knowledge	KNOWLEDGE	Knowledge management
/api/v1/marketplace/installations*	MARKETPLACE_INSTALLATION	Onboarding state machine
/api/v1/marketplace/apps	SPINE	Catalogue (Spine data)
/api/v1/l2	L2	Cognitive overlay (retired label — see S6)
/admin	INTERNAL_ADMIN	Admin
/oauth	INTERNAL_AUTH	OAuth flows
/ws, /sse, /stream	BFF	Real-time

Endpoint ownership by intent:

Intent	Family	Owner
Discover product	/api/v1/workspace/discovery	Gateway + Configuration + Activation + Projection
Onboard / configure / activate	/api/v1/workspace/*	Configuration + Activation
Browse / connect / sync / revoke	/api/v1/connectors/*	Integration Manager
Compose Workbench, Inbox, Entity 360, canvas	/api/v1/projections/*	Projection Engine
Read knowledge / evidence	/api/v1/knowledge/*	Knowledge and evidence services
Ask / assign Twin	Semantic Twin routes	Twin runtime — drafts only
Approve / reject / execute	Governance command routes	Governance → Hermes

Appendix E — Gateway bindings

Category	Binding	Type
Database	DB	D1Database (integratewise-spine-cache)
KV	RATE_LIMITS, SESSIONS, CONNECTOR_STATUS, SIGNAL_CACHE, METRICS, OAUTH_STATE_KV	KVNamespace
R2	FILES	R2Bucket
Services	CONNECTOR, CONNECTOR_SYNC, PIPELINE, INTELLIGENCE, KNOWLEDGE, BFF, L2, AGENT_RUNTIME, ADMIN, BILLING, TENANTS, WEBHOOK_INGRESS, HUB_CONTROLLER, SPINE, MCP_POOL, MARKETPLACE_INSTALLATION	Fetcher

Isolation invariant: no env.test target may equal any env.prod target, for any binding
class. validate-platform-deployment.sh currently asserts this only for mcp-connector.

Appendix F — Canonical entities

Entity	Source
Connection	packages/spine-entities/src/connection.ts
Connector	packages/spine-entities/src/connector.ts
SyncJob	packages/spine-entities/src/sync-job.ts
Webhook	packages/spine-entities/src/webhook.ts
Schema	packages/spine-entities/src/schema.ts
Capability	packages/spine-entities/src/capability.ts
TimelineEvent	packages/spine-entities/src/timeline.ts

Tenant lifecycle families: spine_organizations · spine_workspaces · spine_users ·
spine_memberships · spine_roles · spine_permissions · spine_tenant_accounts ·
spine_networks. Generic spine_entities remains the compatibility graph and identity
layer; typed tables are the canonical materialised home for their families.

Entity contract (frozen): identity · fields · relationships · timeline · provenance ·
permissions · capabilities.

Appendix G — Connector lifecycle

Publish connector definition → discover / install → resolve identity and tenant
→ reuse eligible connection or request consent → store opaque credential reference
→ create tenant/workspace connection binding
→ discover provider objects, fields, events, operations
→ approve schema / entity / capability mappings
→ activate initial hydration and delta sync
→ Pipeline promotes entities, relationships, provenance, evidence
→ Projection Engine invalidates and recompiles permitted views
→ monitor, repair, revoke, reconcile

The binding must deterministically resolve:

(user_id, tenant_account_id, tenant_id, spine_network_id, provider_key,
 provider_workspace_id, connector_binding_id, spine_connection_id, schema_binding_set)

Connector installation registers mappings, sources, availability and approved additive
extensions. It does not execute ad-hoc physical DDL.

Appendix H — Public 19 tools

get_my_continuity · get_active_context · get_my_focus · get_context · get_changes ·
get_related · get_history · get_commitments · get_decisions · get_permitted_memory ·
get_relevant_knowledge · ask_twin · assign_twin · get_prepared_work ·
get_available_actions · prepare_action · get_action_plan · approve_action ·
store_in_spine

Appendix I — Stop-ship invariants

A release is not aligned if any of the following is true:

1. The browser selects a legacy identity provider while Clerk is configured
2. The public MCP lists anything other than the exact 19 tools
3. The Plugin claims automatic inheritance of other host-app credentials, or the MCP lane
   omits its standalone browser Workbench / fallback path
4. A UI or Twin route writes Neon directly
5. D1 is described or used as canonical business truth
6. A failed live projection silently becomes demo data
7. A material write executes without a proposal, a policy decision, a receipt and a
   reconciliation — on any route, host-native or IntegrateWise-native
8. A provider connector is copied into a product repository
9. The user must explain context already present in the Spine Network
10. L1/L2/L4/L7 appear as user-facing product navigation
11. A host, MCP client, frontend or agent queries Fortress storage directly
12. An answer claims cross-system completeness without reporting canonical completeness or
    disclosing the systems it could not see
13. Declared host capability is routed to without runtime confirmation
14. The same provider is called through both host and IntegrateWise by default
15. A write path returns success when the canonical write was skipped, failed, or landed
    only in a cache
16. Any automated path can write governance_state = 'approved' without an approver identity
17. A component writes synchronously to both the Spine and a projection
18. An AI classifier establishes source identity or canonical identity on its own
19. An agent promotes a rule into autonomous execution
20. A response conveys uncertainty as a guessed value rather than an explicit state

Additionally, per §17: no test/prod resource sharing of any binding class, and no Worker
publication outside Release Core Workers.

Appendix J — Vocabulary ledger

Retired	Current	Status
Cognitive OS · IntegrateWise OS · AI OS	IntegrateWise Platform	Superseded — category
OS Shell · Views · Topic Boards	Workbench	Renamed — one surface
Atlas Spine	Spine Fabric	Renamed
16 AI Agents (named personas)	Capabilities in the Capability Fabric	Superseded — taxonomy retired
Cognitive Twin · AI assistant · copilot	Twin	Renamed — silent by default
Co-worker (as separate runtime)	Twin	Superseded — one runtime
Normalizer · Hermes (external use)	(internal only)	Never customer-facing
IW Continuity Bridge	IntegrateWise / Continuity Bridge (internal)	Retired public name
TenantClass	Profile	Renamed — it was a runtime property, not a tenant property
L1 / L2 / L4 / L7	Workbench / Twin / Continuity / Governance	Engineering-internal only; never user-facing
/api/v1/cognitive/*	(unresolved)	"Cognitive" is not a kernel term — rename or sanction as an alias
Brain (as a write destination or truth store)	Brain — a reasoning and learning projection used by the Twin	Never a second store. The durable path is Spine → Twin proposal → Governance → Hermes → re-ingestion into Spine

Appendix K — Path to alignment

The ordered sequence that closes the gap between Part II and Part III. Ordering is not
arbitrary: each step removes an ambiguity the next step would otherwise encode.

#	Step	Closes
0	Make canonical write failure hard-fail instead of console.warn + success: true; route canonical writes through SPINE to Neon; delete CANONICAL_SPINE_DB	S0 — silent data loss. Nothing else in this table matters if canonical writes are not landing
1	Close the hub-controller-api bypass — fold into services/ behind Gateway auth with isolated test/prod D1, or delete the catch-all route and the bypass branch	S1
2	Repair the 15 dangling bindings and 5 test/prod leaks; extend validate-platform-deployment.sh to assert, for every binding class, that no env.test target equals any env.prod target and that every service = resolves to a declared name =	S2, S3 — and converts them into a permanently-caught error class
3	Decide the Spine writer (D4); retire the loser; add spine to CORE_SERVICES	S8
4	Wire or formally retire hermes — it is stage 11 of the frozen sequence and currently unreachable	Tier 5
5	Normalise environment vocabulary to dev/test/prod; delete both root wrangler configs and ci-cd.yml	S4
6	Consolidate the migration ledger to one root, one sequence, no duplicate numbers	S9
7	Consolidate frontend calls on NEXT_PUBLIC_IW_API_URL and one typed Gateway client; remove production localhost and direct-service fallbacks	§16.3
8	Complete live deployment plus negative tenant/RBAC and frontend acceptance for /api/v1/workspace/discovery	§16.3
9	Rename the L-layer trees; fix the rendered string in releases-view.tsx; rewrite the L4 passage in the Twin's system prompt; resolve /api/v1/cognitive/*	S6
10	Collapse to one Workbench URL namespace; remove the capability catalogue and executor from the Workbench	S7
11	Delete inert mass — dead Capability Fabrics, orphaned Vite root, _deprecated, retired GCP surfaces, zero-consumer packages	S5, S10, S11
12	Add "private": true to the 16 unmarked packages; make release:packages:check fail on any non-private package other than sdk and spine-schema	S12
13	Complete one connector end to end: consent → strict binding → discovery → schema mapping → hydration → delta sync → revoke → projection invalidation	§16, Appendix G
14	Validate the full four-button governed loop: proposal → approval token → Hermes → provider outcome → re-ingestion → reconciliation → projection refresh	§10
15	Validate Development → Customer Zero → Customer Production promotion with isolated credentials, data, bindings, queues, caches, evidence and audit	§17

Integrated-testing gate. Do not begin the integrated testing event until every item below
has evidence. Any missing item is a blocker, not post-launch cleanup:

environment/DNS/identity/Gateway/Neon/R2/D1/KV/queue/secret health · migration ledger and
schema verification · cross-tenant and cross-environment negative tests · first-read
discovery and every visible sidebar projection contract · one real connector through the full
lifecycle · public MCP OAuth and exact 19-tool listing · no automatic inheritance of unrelated
host-app credentials · no direct frontend database/provider/internal-MCP traffic · explicit
partial and degraded states with no live-to-demo fallback · one complete governed action
trace · bounded retry, ambiguous-outcome protection, dead letter and governed replay ·
observability, audit, rollback and revocation evidence.

Appendix L — Document disposition

docs/architecture/ held 94 entries at consolidation. Their disposition:

Canonical amendment

SPEC_AMENDMENTS_v1.md is the one canonical amendment to this
document. Where it makes an explicit correction, the amendment wins. It is not a subordinate
retained implementation specification.

Retained — still authoritative in their own scope

Detailed specifications this document summarises. Each remains the reference for its
implementation detail and is subordinate to this document.

APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md · CANONICAL_SPINE_SCHEMA_FOUNDATION.md ·
SPINE_ENTITY_TABLE_SCHEMA.md · TENANT_LIFECYCLE_SCHEMA_REGISTER.md ·
TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md · WORKBENCH_ROLE_CAPABILITY_MAP.md ·
IW_SPINE_NETWORK_PLUGIN_AND_MCP_MARKETPLACE_CONTRACT.md ·
FRONTEND_PLATFORM_API_AND_DISCOVERY_SPEC.md · RUNTIME_SUBSTRATE_AND_SURFACE_CONTRACT.md ·
CODEBASE_EXCAVATION.md (the drift baseline; Part III derives from it) ·
HOST_AWARE_CONTINUITY_RUNTIME_SPEC.md (frozen 2026-07-29 — the normative source for
§15.5–15.8: request classification, capability resolution, connection binding, agent
contracts, Loader/Normalizer schemas, failure matrix and acceptance criteria) ·
SPINEWORKSPACE_INFORMATION_ARCHITECTURE.md (host/navigation implementation detail,
subordinate to §11.7 and §16.3a)

Absorbed — content now lives here; archive

ARCHITECTURE_LOCK.md · IMPLEMENTATION_CONTRACT_v1.1.md ·
CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md · PLATFORM_LOCK_v1.0.md ·
FOUR_BUTTONS.md · TWIN_BEHAVIOR.md · WORKBENCH_MATRIX.md · ADAPTIVE_SPINE_MODEL_v1.md ·
CAPABILITY_FABRIC.md · SOURCE_PACK_RECONCILIATION_2026-07-28.md ·
RUNTIME_PROFILE_AND_ENTRY_CHANNEL_CONTRACT.md · CANONICAL_ARCHITECTURE.md ·
MASTER_EXECUTION_PLAN.md · PRODUCT_PLATFORM_BOUNDARY_AND_GO_LIVE_STANDARD.md ·
PLATFORM_PRODUCT_DATA_AND_PROJECTION_REFERENCE.md ·
CUSTOMER_ZERO_TO_EXTERNAL_PRODUCT_AND_MARKETPLACE_SPEC.md ·
CUSTOMER_ZERO_HOSTED_PLUGIN_CODE_BRIEF.md · BROWSER_FRONTEND_AND_MCP_PRODUCT_CODE_BRIEF.md

Constitutions — absorbed into Parts I and II

The nine constitutions each stated the doctrine for one subsystem. Their content is now
distributed across §2–§16.

ADAPTIVE_WORKBENCH_CONSTITUTION.md · CANONICAL_ENTITY_CONSTITUTION.md ·
CAPABILITY_CONSTITUTION.md · CONNECTOR_CONSTITUTION.md · EXECUTION_CONSTITUTION.md ·
GOVERNANCE_CONSTITUTION.md · PROJECTION_CONSTITUTION.md · RUNTIME_CONSTITUTION.md ·
TWIN_CONSTITUTION.md · CUSTOMER_ZERO_CONSTITUTION.md (DRAFT) ·
CUSTOMER_ZERO_DAILY_OPERATING_MANUAL.md (DRAFT)

Superseded — already marked, or superseded by this document

CANONICAL_PLATFORM_ARCHITECTURE.md · CANONICAL_SPINE_CONVERGED.md ·
CANONICAL_ARCHITECTURE_V4.md · PRODUCT_ARCHITECTURE.md · PRODUCT_ARCHITECTURE_V1.md ·
USER_SYSTEM_JOURNEY_BLUEPRINT.md · PLATFORM_ARCHITECTURE.md · END_TO_END_ARCHITECTURE.md ·
SINGLE_END_TO_END_MAP.md · FRONTEND_LAYERED_STACK.md · PLANE_LAYER_CROSS_REFERENCE.md ·
PROJECTION_MODEL.md · PROJECTION_CONTEXT_REFACTOR.md · SPINE_MODEL.md ·
SPINE_DOMAIN.md · ENTITY360_V2_MODEL.md · UNIFIED_GOVERNANCE_SPEC.md ·
WORKBENCH_DOCTRINE.md · MULTI_PROTOCOL_PLATFORM.md · ONBOARDING_FLOW.md ·
CURRENT_CONTEXT_FLOW.md · DETAILED_USER_FLOWS_AND_SYSTEM_PATHS.md ·
AI_CONNECTOR_MCP_FLOW.md · CONNECTOR_RUNTIME_PROOF.md · SPINE_INTELLIGENCE_AGENT.md ·
LONG_TERM_TASK_MANAGEMENT_MCP.md · CODEBASE_ALIGNMENT_SPEC.md ·
ARCHITECTURE_DOCUMENTATION_PLAN.md · DOCUMENTATION_COMPLETION_MANIFEST.md ·
APP_CATEGORY_ENTITY_DOMAIN_MODEL.md (+ .txt duplicate) ·
ONE_AUTH_WORKBENCH_PLATFORM_REFERENCE_ARCHITECTURE.md (source provenance only) ·
TOTAL_END_STATE_CONTRACT.md and its JSON (reference-only enforcement lineage)

Lineage — historical, retain in docs/archive/

The v2 deep-dive family and the locked-v1 lineage. Valuable as evolution record; not
authority.

integratewise-architecture-v2.0.md · v2-ai-capability-fabric.md · v2-capability-layer.md ·
v2-continuity-governance.md · v2-data-model.md · v2-deployment.md · v2-ecosystem.md ·
v2-identity-ingress.md · v2-provider-fabric.md · v2-security.md · locked-v1.md ·
locked-v1.0.1.md · final-e2e-system.md · l1-reality-check.md · reality-audit.md ·
one-full-prompt.md · suite-00-34.md · source/

Unresolved

MCP_POOL_MULTI_ENVIRONMENT_STRATEGY.md — DRAFT, conflicts with §15.1. Blocked on D6.
Do not archive until decided; do not treat as authority meanwhile.

Not architecture

PRODUCT_NARRATIVE.md and STAKEHOLDER_PITCH.md are commercial documents and belong under
docs/commercial/, governed by the Deck Core and
GTM Canon. README.md becomes a pointer to
this document. CANONICAL_SPINE_SCHEMA.sql is an artifact, not a document.

Appendix M — Conflict-resolution ledger

The inventory at 2187bc91 contains 109 top-level Markdown files and 114 top-level
architecture artifacts. Appendix L assigns each architecture family a disposition; only
this document and SPEC_AMENDMENTS_v1.md now declare canonical status.

Action	Source family	Resolution and reason
KEEP	SPEC_AMENDMENTS_v1.md	Explicit implementation corrections remain binding.
KEEP subordinate	Retained specifications in Appendix L	Detailed contracts apply only where compatible; they cannot introduce doctrine or override this file.
ADAPT	OneAuth, host-aware continuity and tenant Spine sources	Kept Flow D precedence, bounded reuse, tenant scope and evidence assembly; removed unrestricted host-trust implications.
ADAPT	SpineWorkspace IA and domain taxonomy	Kept deterministic role hosts and one shell; separated public marketing from operational hostname authority and internal projections.
MERGE	Architecture Lock, contracts, constitutions, Four Buttons and Twin behaviour	Compatible laws, OODA grammar, Silent Twin and governed execution now live in Parts I–II.
MERGE	End-to-end maps and flow documents	A/B/C/D, task/result, approval/write, boundary and ownership views are consolidated here.
SPLIT	“Spine” as one database	Canonical truth, operational state, evidence, retrieval, provenance and event history have explicit owners.
SPLIT	Naming	IntegrateWise = firm; SpineWorkspace = product; Spine = context core; Platform = control substrate; IW-Spine-Network = distribution contract.
MOVE	Public solutions versus host registry	Marketing owns the full story; authenticated *.spineworkspace.com hosts request projections. Neither grants authority.
SUPERSEDE	Old canonical/product/platform/end-state/end-to-end files and nine constitutions	Historical provenance remains; misleading headers now forward here.
REFERENCE ONLY	Excavations, audits and proof reports	Evidence informs Part III but cannot create doctrine; dated claims require revalidation.
DECIDE	D1–D13 and M2/M4–M6	Genuine forks remain explicit rather than being resolved by old prose or convenient code.

Precedence is: README.md → this document → explicit amendments → compatible retained
specification → provenance only. New or attached sources are classified as KEEP | ADAPT | MERGE | SPLIT | MOVE | SUPERSEDE | DECIDE here; they never create a parallel canon.

---

Specification amendments (2026-08-06)

SPEC_AMENDMENTS_v1.md contains 15 required implementation
corrections. These amendments are canonical and supersede conflicting statements in all
prior architecture documents. Key changes:

1. Per-tenant D1 routing uses Workers for Platforms dispatch, not dynamic KV binding
2. Isolation claims corrected to database-resource isolation, not physical boundary
3. D1 fleet capacity policy added (thresholds, overflow strategy)
4. Catalog versioning uses separate identity and release tables
5. Idempotency persistence via processed_commands table in per-tenant D1
6. Transactional outbox pattern for atomic domain-write-plus-event
7. WorkService separated from ExecutionService
8. Capability invocation ownership frozen between CapabilityService and ExecutionService
9. Reconciliation model strengthened (missing transitions, observation history)
10. Complete event envelope (PlatformEvent type) with required tracing fields
11. Consistent tenant_id on every durable D1 record
12. Search service renamed to Tenant-Scoped with per-tenant AI Search instances
13. Cached projection fallback requires explicit freshness indicators
14. Cryptographic approval semantics specified (hash chain, signing, verification)
15. Frontend deployment target frozen (Vercel for product, Workers for platform)

Supporting schemas: TENANT_D1_OPERATIONAL_SCHEMA.sql
and CONTROL_PLANE_SCHEMA_AMENDMENTS.sql.

---

Consolidation record

Before	After
94 documents, 265,000 words	1 document + 10 retained specifications + 1 amendment
16 declared canonical	1 canonical + 1 amendment
6 files with "canonical" in the name	0
Conflicts resolved by precedence chains	Conflicts resolved in place; evolutions recorded
Drift discoverable only by excavation	Drift register, dated, in Part III

Guiding principle. Success is not more code or more documents. It is better thinking,
coherent architecture, less complexity, and a product customers genuinely adopt. If a change
makes this system harder to explain, it is probably the wrong change.

Truth you own. AI you rent. Approval in between.

---

Part IV — Unified Ontology, Workbench IA and Bridge Architecture

24. Unified product ontology

The architecture is organized around Business Context.

INTEGRATEWISE
  integratewise.ai
  Company / Platform Builder
        │
        ▼
SPINEWORKSPACE
  spineworkspace.com
  Customer Product
        │
        ├── Organization
        ├── Business Context
        ├── Connectivity / Ingestion
        ├── Context Ingestion & Synthesis
        ├── Spine Fabric
        ├── Projection
        ├── Work / Work Graph
        ├── User Workbench
        ├── Twin Workbench
        ├── Coworker
        ├── Triage
        ├── Agent Fabric
        ├── Agent Communication
        ├── Capability Fabric
        ├── Governance
        ├── Execution Fabric
        ├── Communications over the Bridge
        ├── Reconciliation
        └── Organizational Memory / Continuity

25. Three canonical system flows

Flow A — Business Context Ingestion & Synthesis

Source Systems
 → Connectivity
 → Loader
 → Raw Evidence
 → Normalizer
 → Schema / Semantic Synthesis
 → Entity Resolution
 → Relationship + Event Linking
 → Business Context
 → Spine Fabric

Flow B — Human–AI Work

Spine Fabric
 → Projection
 → User Workbench
 → User Interaction
 → Coworker
 → Twin
 → Context Assembly
 → AI Operational Sandbox
 → Shared Work
 → Work Allocation
 → Governance
 → Capability
 → Execution

Flow C — Communications, Execution, Reconciliation and Knowledge

Human / Twin / Agent
 → Communications Bridge
 → Governed Context Sharing
 → Capability
 → Governance
 → Execution Fabric
 → Source System
 → Actual State
 → Re-ingestion
 → Reconciliation
 → Updated Business Context
 → Triage / Interpretation
 → Governed Promotion
 → Organizational Memory
 → Spine
 → Next Work

26. Business Context construction

Provider-specific records are never the conceptual center.

Provider Data
 → Structural Normalization
 → Semantic Synthesis
 → Entity Resolution
 → Relationship Linking
 → Event Linking
 → Domain / Account / Work Mapping
 → Linked Business Context

Business Context is the semantic bridge between raw operational data and the human/AI work system.

27. User Workbench IA

The Workbench is a single human operating surface with persistent orientation and adaptive work surfaces.

USER WORKBENCH
├── Orientation
│   ├── Home
│   ├── Today
│   ├── My Work
│   ├── My Queue
│   ├── Tasks
│   └── Recent Work
├── Communication
│   ├── Email
│   ├── Chat
│   ├── Meetings
│   ├── Calls
│   ├── Calendar
│   └── Documents
├── Organizational Memory
│   ├── Decisions
│   ├── Knowledge
│   ├── Documents
│   ├── Policies
│   ├── Processes
│   └── Work History
├── Work
│   ├── Active
│   ├── Waiting
│   ├── Needs Decision
│   ├── Needs Approval
│   ├── Delegated
│   ├── Blocked
│   └── Completed
└── Domain Work Surfaces

The main surface is not a fixed dashboard. It is a projection of Business Context and Work.

28. Twin Workbench IA

TWIN WORKBENCH
├── Current Work
├── Context
├── Plans
├── Decomposition
├── Assignments
├── Agent Work
├── Capability Calls
├── Tool Calls
├── Workflow Runs
├── Communications
├── Evidence
├── Working Memory
├── Proposals
├── Exceptions
└── Results

It runs only over the bounded AI Operational Sandbox.

29. Human Workbench ↔ Twin Workbench

              SHARED WORK
                  │
        ┌─────────┴─────────┐
        │                   │
USER WORKBENCH        TWIN WORKBENCH
Human surface         Agentic surface
        │                   │
        └─────────┬─────────┘
                  │
             Work Graph

The two surfaces are different projections of the same work; they are not separate sources of truth.

30. Communications over the Bridge

The Bridge is the governed communication substrate for work-related communication.

Human / Twin / Agent
        │
        ▼
COMMUNICATION BRIDGE
        │
        ├── Identity / Tenant
        ├── Work ID
        ├── Context Reference
        ├── Purpose
        ├── Policy
        ├── Delivery
        ├── Inbound Event
        ├── Provenance
        └── Audit
        │
        ├── Slack
        ├── Email
        ├── Chat
        ├── Meetings
        └── Agent Communication

The Bridge does not become a fourth memory system. It transports communications/events around Work and preserves their linkage to source, context and authority.

31. ACP vs MCP

MCP
AI ↔ Tool / Resource / Capability

ACP
Agent ↔ Agent / Agent ↔ Twin
through governed Work and Context handoff

ACP is communication, not authority.

The Twin remains the orchestration boundary.

32. Communication continuity

A communication may become:

Communication
 → Evidence
 → Decision
 → Assignment
 → Work Update
 → Outcome
 → Organizational Memory Candidate

Only the governed memory path can make that interpretation Organizational Memory.

33. Source-system return path

All consequential Work ends through:

Capability
 → Governance
 → Execution
 → Source System
 → Receipt
 → Actual State
 → Re-ingestion
 → Reconciliation
 → Spine

This closes the operational continuity loop and prevents false completion.

34. Knowledge evolution

Updated Source State
 → Event
 → Evidence
 → Context
 → Interpretation
 → Triage
 → Candidate
 → Governance
 → Organizational Memory
 → Context
 → Future Work

The system becomes progressively more contextually useful through governed continuity, not unrestricted learning.