SpineWorkspace / IntegrateWise — Canon
Class: CANON — this is the only document permitted to redefine architecture.
Status: CURRENT
Effective: 2026-08-31
Source of authority: the SpineWorkspace Founder Canon, v6.0.0, 31 August 2026 — committed
verbatim at FOUNDER-CANON-2026-08-31.md. Load-bearing sections:
§0A Founder Decision Register, §4A Dual-Workbench Context Model, §19 Governance outcomes, §31A
Supersession Map, §32 Canonical Vocabulary, Appendix C Founder Freeze Decisions. This file is the
repository's in-tree statement of that canon; where the two differ, the Founder Canon governs and
this file is corrected.
Supersedes: PRODUCT_FRAMING_LOCK.md (2026-08-25), SPINEWORKSPACE_CANONICAL_PRODUCT_MANUAL.md, and the Aug 1 canonical freeze in the areas named in §7.
Changing this document requires an ADR under adr/.
The constitutional product rule:
SPINEWORKSPACE
= Human Workbench
+ AI Workbench
+ Shared Business Context
+ Separate Human and AI Continuity
+ Governed Work and Execution
1. Positioning
SpineWorkspace
The workspace where humans and AI work on the same business context, with separate continuity,
governed execution, and one continuous work loop.
IntegrateWise
The infrastructure platform that provides the identity, connectivity, discovery, activation,
Spine, capabilities, governance, execution and continuity required to make SpineWorkspace
possible.
SpineWorkspace is the product. IntegrateWise is the infrastructure underneath. Never use
IntegrateWise as the product name; never use SpineWorkspace as the company name.
Core principle
Humans govern. AI helps. Spine preserves continuity.
1A. Business Context is the semantic foundation — TIER-0
Tier-0 principle. This sits before the product architecture, not inside it. Everything below it
in this document is mechanism, and everything else in the canonical set derives from it.
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; it becomes another collection of tools and interfaces.
The product-level expression, and one of the central anchors of the entire IntegrateWise
architecture:
The Spine gives work its business context.
The correction this makes
SpineWorkspace is not a workspace with a Spine. It is a workspace constituted by the Business
Context Spine.
That distinction is the whole framing. A workspace with a Spine treats business context as a
feature it offers — something retrievable, attachable, optional. A workspace constituted by the
Spine has no coherent existence without it. Everything else derives from that.
A view without business context is a table. An action without it is an untyped write. A Twin
without it is a chatbot. An agent without it is a script. The Spine exists so that none of those is
what the user gets.
The Spine is therefore not primarily an integration layer or a data store. It is the semantic
operating substrate through which organizational business becomes contextual, actionable and
continuous.
The canonical hierarchy
ORGANIZATIONAL BUSINESS
│
▼
BUSINESS CONTEXT SPINE
───────────────────────────
The semantic substrate
│
┌───────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
HUMAN AI ORGANIZATION
│ │ │
▼ ▼ ▼
Human Workbench AI Workbench Shared Work
│ │ │
▼ ▼ ▼
Personal Contextual AI Continuity Organizational
Memory Memory Memory
│ │ │
└───────────────────────┼───────────────────────┘
│
▼
Contextualized Capabilities
Agents · Knowledge · Tools
Communication · Decisions
│
▼
GOVERNED EXECUTION
│
▼
OUTCOME / EVIDENCE / STATE
│
▼
RECONCILIATION → SPINE
The three branches are the three participants — Human, AI, Organization — and they line up
exactly with the three continuity domains beneath them. Capabilities, agents, knowledge, tools,
communication and decisions sit below all three, because they are contextualized by business
context rather than being organizing principles of their own.
The critical loop
Business → Context → Work → Action → Outcome → Context
Not:
Workspace → tools → AI → memory
The second ordering is the fragmentation SpineWorkspace exists to end. It puts the container first
and the meaning last.
Business Context is the connective tissue
Every major capability is contextualized against the business, and answers a business question:
| Capability | The business question it must answer |
|---|---|
| Work | What business objective or responsibility does this work serve? |
| People | Who is responsible, involved, accountable or affected? |
| AI | Why is AI involved, and what business context does it operate on? |
| Agents | What organizational role and business responsibility does this agent serve? |
| Memory | What continuity matters to the organization, person or AI? |
| Knowledge | What does the organization know about its business? |
| Capabilities | What can be done in service of the business? |
| Tools / ecosystems | Where does the underlying business data or action live? |
| Communication | What business context does this message, update or decision belong to? |
| Decisions | What business decision was made, by whom, with what authority? |
| Governance | What is permitted in this business context? |
| Execution | What business action is being performed? |
| Evidence | What proves what actually happened? |
| Projection | What portion of the business reality should this participant see? |
| Continuity | What needs to persist so work can continue intelligently? |
A capability that cannot answer its question is not yet part of the product.
The Spine is the business contextual memory
The product is not "memory" as a feature, and IntegrateWise does not offer agentic memory or
personal memory as things in themselves.
The Spine is the business contextual memory. That is the product.
Personal Contextual Memory and AI Continuity Memory remain first-class separations, and the
three-scope invariant in §3 holds unchanged. But their purpose is protective, not promotional: they
exist so that a user's private thinking and an AI's working inference cannot silently become
organizational truth. They are walls around business context, not parallel products beside it.
The three domains read cleanly once business context is the foundation:
| Domain | What it holds |
|---|---|
| Business / Organizational Memory | What the organization knows, and what has become part of organizational reality. |
| Personal Contextual Memory | What matters to the individual human while they operate on the business. |
| AI Continuity Memory | What the AI needs to maintain continuity while helping with business work. |
Both personal and AI memory operate on Business Context. They do not replace it.
Memory is subordinate to business context, and Organizational Memory is the output of the loop
rather than a sibling of the other two:
BUSINESS CONTEXT
│
┌───────────┴───────────┐
▼ ▼
PERSONAL CONTEXT AI CONTINUITY
MEMORY MEMORY
│ │
└───────────┬───────────┘
│
GOVERNED WORK
│
▼
BUSINESS OUTCOME
│
▼
ORGANIZATIONAL MEMORY
Personal and AI continuity feed governed work; the business outcome of that work is what becomes
organizational memory. Neither participant's continuity becomes organizational truth by being
written down — only by producing a governed outcome.
This reframes the open substrate question. It is not "where do we store AI memory?" — it is:
How does AI Continuity maintain its own continuity while remaining continuously grounded in the
authoritative Business Context Spine?
Grounding is the requirement; storage is an implementation of it. See G-10.
Read the constitutional memory rule in that light:
User thought ≠ AI inference ≠ Organizational truth
The rule protects the middle thing the company actually sells.
What this obliges
- Business context leads everywhere. It is the primary dimension of every surface, every
action, and every ranking — not an attribute retrieved after the fact. - Priority is business priority. Where work or actions compete for attention, objectives, goals
and KPIs decide the order — never recency or screen position. - Business context is carried, not re-derived. Any surface or action that cannot state the
business context it operates on is not ready to act.
The test for any future feature
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.
A feature that fails this test is a tool sitting next to the product, which is the fragmentation
SpineWorkspace exists to end. The test applies to new work before it is built, not as a review
afterwards.
2. The Founder Canon — product model
The Human Workbench and the AI Workbench are not two independent applications. They are two
projections over the same business reality.
BUSINESS CONTEXT SPINE
│
┌───────────┴───────────┐
│ │
HUMAN PROJECTION AI PROJECTION
│ │
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
Personal Memory AI Continuity
│ │
└───────────┬───────────┘
│
SHARED WORK
│
▼
BUSINESS OUTCOMES
The Spine is at the top because it is the foundation, not a service the Workbenches call. Each side
receives a projection of the same organizational reality and augments it with its own continuity —
never with its own truth.
The projection changes. The business reality does not.
That is one of the strongest architectural principles in the whole concept. The Workbenches are
different participant experiences over the same underlying business reality — not two
applications independently connected to the platform, and not silos.
This is why the product cannot be described as two apps sharing a database:
- A user does not come to SpineWorkspace to access applications. They come because their work
has meaning within a business context. - The AI does not operate because an LLM is available. It operates because there is business
context, business work, business authority and a business outcome to support.
The invariant
Shared business reality; separate participant continuity; governed promotion between scopes.
2A. The five views are distinct
Tier-0 says business context is the foundation of everything. That must not be read as "one
projection for everything." The opposite follows: because there is one business reality, the views
over it can and must be specialised.
User view, Platform view, Package view, Pipeline executions and Agentic executions are separate
views. They are not one and the same.
| View | Audience | Answers |
|---|---|---|
| User view | The person doing business work | What is my work, what does it mean, what should I do next? |
| Platform view | Authorized platform operators | Is the substrate healthy, configured, connected and governed? |
| Package view | Whoever installs, publishes or governs distributable units | What is available, installed, versioned and permitted in this tenant? |
| Pipeline executions | Operators, and audit | Did information enter, normalize and promote correctly? |
| Agentic executions | Operators, governance, and the responsible human | What did Twin or an agent actually do, under what authority, with what evidence? |
Why they must stay separate
Each has a different audience, a different question and a different failure mode. Collapsing them
breaks all five:
- Pipeline or agentic execution detail in the user view leaks infrastructure into daily work.
Canon §10 and Appendix C item 22 are explicit — infrastructure complexity stays hidden unless the
viewer is an authorized platform operator. A user should never need to read a reconciliation ID
to finish their work. - User framing in the platform view hides operational reality from the operator, who needs the
substrate, not a curated experience of it. - Pipeline and agentic executions merged into one run log loses the distinction that matters
most: whether information arrived correctly versus whether an actor acted correctly under
authority. These have different owners, different remedies and different accountability. - Package view folded into the platform view conflates what is installed and permitted with
what is currently running.
The Platform Console is an operator surface, not a competing daily work destination (canon
§25).
What keeps them coherent
The same principle that governs the two Workbenches governs all five:
The projection changes. The business reality does not.
Every one of these views is a projection over the same Business Context Spine. That is what makes
them different views of one system rather than five disconnected tools — and it is why each still
owes an answer to the Tier-0 test in §1A.
Open — needs founder confirmation. Package view is recorded here as the distributable-unit
surface — connectors, MCP servers, plugins, marketplace packages: what is available, installed,
versioned and permitted in a tenant. If it instead means the monorepo/developer package surface,
or something else, this row needs correcting rather than reinterpreting.
Humans and AI operate over the same Business Context Spine. They receive different
projections of it. They retain separate continuity. Nothing crosses between continuity scopes
except by governed promotion.
3. Canonical vocabulary
One meaning per term. Where the codebase currently uses a term differently, that is a gap
recorded in 17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md — not a second definition.
| Term | Definition |
|---|---|
| SpineWorkspace | The product. The workspace where humans and AI work on shared business context. |
| IntegrateWise | The company, and the infrastructure platform beneath SpineWorkspace. |
| Human Workbench | The primary human operating experience. |
| AI Workbench | The AI operating environment over the same Business Context Spine. |
| Twin | The human-facing contextual AI coworker, operating inside the AI Workbench. Twin is not the AI Workbench. |
| Spine Agents | Governed digital employees operating within the business context, carrying identity, authority, memory namespace and capabilities. |
| Business Context / Organizational Memory | The shared organizational reality and durable knowledge. |
| Personal Contextual Memory | The human's private continuity. |
| AI Continuity Memory | AI's own continuing working memory. |
| Business Context Spine | The shared contextual substrate holding truth, work, events, relationships, decisions, evidence and organizational memory. |
| Shared Work State | The medium through which Twin, Spine Agents and humans coordinate — not agent-to-agent re-explanation. |
| Capability Fabric | How an intent could be performed. |
| Governance | Whether it may be performed, and by whose authority. |
| Hermes | Reliable coordination of approved execution. |
| Projection Engine | The context → workspace compiler. |
| Continuity Pipeline | Outcome back to verified organizational state. |
Drift watch — terms that keep reappearing from source material
Define-IntegrateWise-Spine.md and material derived from it is supporting evidence (precedence
level 4), not canon. It carries three variants that must not be absorbed:
| Appears as | Canonical form | Why |
|---|---|---|
| "Spine Workspace" (two words) | SpineWorkspace | Founder Canon Appendix C item 1 fixes the product brand. Two-word form appears zero times in the Founder Canon. |
| "Twin AI Memory" | AI Continuity Memory | Founder Canon §32. §31A explicitly supersedes the older broad "Twin Memory" description by splitting Personal Contextual Memory and AI Continuity Memory. |
Human Workbench ↔ Twin ↔ Specialist agents | Twin and Spine Agents operate inside the AI Workbench | Omitting the AI Workbench reinstates Twin-as-environment, superseded by ADR-2026-08-31-01. |
Terms deliberately not carried forward
| Retired term | Disposition |
|---|---|
| Twin Workbench | Superseded by AI Workbench. Twin is an actor within it, not the environment itself. See ADR-2026-08-31-01. |
| Coworker | Retired, absorbed into Twin. It appeared as a numbered architectural layer in the superseded Product Manual (layer 9) and as a defined term in the Framing Lock (§9). The Founder Canon uses "coworker" only as a common noun describing Twin — "Twin is the human-facing contextual AI coworker operating within the AI Workbench" — and Appendix C item 5 names the human-AI interface as Twin, with no Coworker beside it. Not a separate concept and not a second orchestration authority. |
| AI Orchestrator (as a monolith) | Retired. Responsibilities stay separated across Twin, model routing, ADK, agents, Capability Fabric, Governance and Hermes. |
| "Spine database" as the product definition | Retired. The Spine is a continuity substrate, not a database product. |
| Provider success as final truth | Retired. Execution closes only after verification and reconciliation. |
| MCP as the core data plane | Retired. MCP is one capability transport; the Projection API is the Workbench data plane. |
| Continuity Bridge as the full product | Retired. It is the distribution/access boundary for external AI surfaces. |
| A blank, manually-built workspace as onboarding | Retired. Onboarding goes from blank state to useful work. |
The dual-workbench context model
Both Workbenches read the same Business Context and receive different projections plus different
continuity augmentation. This is the mechanism behind the invariant.
Human Active Context AI Active Context
= =
Business Context Projection Business Context Projection
+ Personal Contextual Memory + AI Continuity Memory
+ Current Work + Current Objective
+ Current Interaction Context + Current Work State
+ Authorized Knowledge/ + Evidence
Evidence + Authority Envelope
+ Policy + Available Capabilities
+ Capabilities + Agent Runtime State
This is why the two sides can collaborate without collapsing privacy, inference and organizational
truth into one memory store.
The constitutional memory rule
User thought ≠ AI inference ≠ Cache content ≠ Organizational truth
Personal thought is not organizational truth. AI inference is not organizational truth. Cache
content is not organizational truth — until a governed process promotes and records it with
provenance. Spine Cache accelerates access to Spine truth and can be discarded and rebuilt; it is
never canonical.
A Personal Contextual Memory item stays personal unless deliberately shared or promoted. An AI
Continuity Memory item stays AI working continuity unless promoted through the Triage / Governance
/ write path. Organizational Memory is durable business memory only after the organization accepts
it into the governed Business Context Spine.
3A. The four context actions
The OODA grammar made operable:
OBSERVE → Store in Spine → organizational truth
ORIENT → Ask your Twin → understanding
DECIDE → Assign your Twin → proposal / prepared work
ACT → Approve → governed execution
These are not top buttons. They are inbuilt in every action.
They are ambient affordances, not a toolbar: they appear against a specific owner — a record,
section, selection, signal or canvas object — and only where they legitimately apply. Availability
is a governed, per-context decision (available / hidden / disabled / already canonical)
carrying a readable reason, never a global on/off.
This is why OODA stays internal. The user performs natural work actions; the interface never
exposes four literal global controls.
Twin does not own ACT. The human owns consequential authority. Twin can prepare the action, the
capability layer can execute it, and Governance decides whether approval is required — but
accountability stays legible.
Every one of the four routes through the governed path:
Intent → Twin Proposal → Capability Resolution → Policy Check
→ Approval (if required) → Execution → Provider Acceptance
→ Reconciliation → Spine Update
See ADR-2026-09-01-01.
4. Human–AI work loop
Organization Intent → Goals / KPIs → Business Context → Work → Human + AI
→ Decision / Proposal → Governed Action → Outcome → Verification
→ Reconciliation → Memory / Continuity → Next Work
Humans remain responsible for consequential business decisions. AI reduces context assembly,
repetitive work and context switching — operating as a capable digital teammate, never an
independent authority.
Execution is not complete because a provider returned success. It closes only after
re-ingestion → verification → reconciliation → governed Spine update → rehydration.
4A. Actors and authority
Every actor has a bounded responsibility. The constitutional split:
Humans own why, priorities, judgment, authority and accountability. Agents own context
assembly, preparation, bounded execution, monitoring and continuity.
Humans are not reduced to approval buttons. They remain the accountable organizational actors.
| Humans own | Meaning |
|---|---|
| Intent | Goals, desired outcomes, priorities, what matters now. |
| Judgment | Ambiguity, trade-offs, relationships, ethics, business meaning. |
| Authority | Approve, deny, delegate or escalate consequential actions. |
| Accountability | Responsibility for customer, financial, legal, people, strategic and operational decisions. |
| Exceptions | Situations where policy, data, automation or prior assumptions do not fit reality. |
| Truth correction | Challenge inaccurate context, validate material facts, promote information into organizational truth through governed process. |
| Leadership | Direction for human-agent teams, and deciding what should not be automated. |
| Agents own | Meaning |
|---|---|
| Context assembly | Collect and organize relevant records, history, relationships, evidence, current work. |
| Research and synthesis | Find, compare, summarize, surface risks and opportunities. |
| Preparation | Draft messages, plans, updates, briefs, tasks, decision material. |
| Monitoring | Watch for changes, deadlines, health signals, exceptions, missing information. |
| Task decomposition | Break an objective into bounded steps, dependencies, handoffs, required evidence. |
| Routine execution | Permitted low-risk work through approved capabilities. |
| Verification support | Gather evidence, compare expected vs observed, detect discrepancies, prepare reconciliation. |
| Continuity | Preserve AI-side working memory so tasks continue across sessions, models and handoffs. |
What agents must never do
An agent cannot grant itself access, decide its own authority, convert assumptions into official
truth, or bypass required human approval. Every agent acts with an identity, tenant scope, assigned
purpose, defined capabilities, policy boundary, delegated authority and audit trail.
The runtime authority model
Responsibility is deliberately split, so that no single component owns context, memory,
permissions, tools, decision-making, execution and truth at once:
| Question | Responsible actor |
|---|---|
| What is the business reality? | Business Contextual Spine |
| What does this mean, and what should we do? | Human with Twin |
| How can the task be performed? | Capability Fabric |
| May it be performed, and under whose authority? | Governance, and a human approver when required |
| How is approved work coordinated reliably? | Hermes |
| Did the real world actually change? | Sync, verification, reconciliation |
| What should the organization retain? | Governed Spine writeback |
This separation is what prevents an "AI orchestrator" from becoming an uncontrolled god-service —
the pattern canon §3 retires by name.
5. Platform stack
What IntegrateWise provides beneath the product:
IW One Auth
↓
Ecosystem Connectivity
↓
Discovery
↓
Activation
↓
Ingestion / Normalization
↓
Business Context Spine
↓
Projection / Context Assembly
↓
Human Workbench + AI Workbench
↓
Capability Fabric
↓
Governance
↓
Hermes / Execution
↓
Source Systems
↓
Re-ingestion
↓
Verification
↓
Reconciliation
↓
Spine / Continuity / Next Work
Standing separations
These are load-bearing and must not be collapsed:
- Capability Fabric → Governance → Hermes. Capability states what could be done and holds
no authority. Governance decides. Hermes coordinates approved execution and reads its authority
from Governance, never from itself. This separation is already substantially correct in the
codebase and should not be redesigned. - Governance outcomes are exactly four (canon §19):
ALLOW,DENY,REQUIRE APPROVAL,
DELEGATE / ALLOW WITH BOUNDED AUTHORITY.ALLOWis an explicit bounded policy decision, not a
bypass; consequential external mutations default toREQUIRE APPROVAL. The runtime proposal/
ledger contract carries the three-wayGovernanceDecisionOutcomevocabulary
(allowed | approval_required | blocked); bounded delegation resolves at the Governance boundary
into one of the three per invocation. - Hermes never performs an arbitrary canonical Spine write. It produces execution results,
evidence and outcome events. Sync, verification, reconciliation and the governed writer commit
canonical truth. - No central orchestrator. Responsibilities stay separated across Twin, model routing, ADK,
agents, Capability Fabric, Governance and Hermes. A single central brain is invalid. - MCP is one capability transport, not the data plane. The Adaptive Spine is truth; the
Projection API is the Workbench data plane.
6. Experience first
The user experiences relevant work, assembled context, evidence, recommendations, collaboration,
decisions, approvals and verified outcomes.
The platform internally handles projection, UI composition, AI context assembly, OODA, model
routing, ADK, agent runtime, MCP, Capability Fabric, Governance, Hermes, execution, sync,
verification and reconciliation.
The architecture is complex so the experience does not have to be. OODA, the UI composition
pipeline and the AI context composition pipeline are internal mechanisms — real, first-class, and
invisible to the user.
"One channel" means one coordination fabric across many surfaces — not one chat interface.
7. Supersession map
What this document changes relative to earlier repository artifacts:
| Area | Earlier position | Canon position |
|---|---|---|
| AI operating environment | "Twin Workbench" — per-user, Twin-owned | AI Workbench — hosts Twin and Spine Agents |
| Continuity scopes | Two: personal, org | Three: Business/Organizational, Personal Contextual, AI Continuity |
| Personal context | Not a plane; a memory namespace | Personal Contextual Spine — a first-class plane |
| Spine Agents | Named; effectively domain agents | First-class governed actors with identity, authority, memory namespace, capabilities, shared Work state |
| Agent cooperation | Unspecified | Through shared Work / context / evidence state |
| Primary product identity | IntegrateWise Workbench | SpineWorkspace |
| Coworker | Numbered architectural layer | Retired — absent from the v6.0.0 Canonical Vocabulary (§32); the governed-co-worker role belongs to Twin and Spine Agents over shared Work. Repository: CoworkerAgent renamed CollaborationLogAgent (log/evidence role, not an authority) |
Everything in the Aug 1 freeze not listed above is retained as the implementation baseline.
8. Related documents
README.md— the CANON / ALIGNMENT doctrine and source precedence17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md— nine planes mapped to real code17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md— where the repository does not yet match this documentadr/— the decisions that produced this document