01 — Product, Experience and Human-AI Operating Model
Canonical reference: 00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md §1, §7, §8, §10, §11
Status: Canonical
1. SpineWorkspace
SpineWorkspace is one product with two first-class operating sides: the Human Workbench for people and the AI Workbench for Twin and Spine Agents. They are two projections over the same organizational Business Context Spine. Each carries its own continuity memory, and neither side owns organizational truth by itself.
Business Context is the semantic foundation. The user should experience a narrow, direct product even though the platform underneath is broad: the relevant information is already assembled; the current work already has history and evidence; the Twin can prepare difficult or repetitive work; approvals appear when authority requires them; and verified outcomes return to the same work surface. None of this works without Business Context.
2. IntegrateWise
IntegrateWise is the infrastructure platform that connects the organization's software ecosystem, preserves governed business context and continuity, composes SpineWorkspace for humans and AI, and coordinates authorized work across APIs, MCP, agents, workflows, models, local runtimes and human routes.
IntegrateWise is not the daily destination for most users. It is the infrastructure substrate that makes the SpineWorkspace experience possible.
3. The Core Thesis
Neither humans nor AI should have to reconstruct the organization every time they need to work.
Tools are replaceable. Models are replaceable. Agents are replaceable. Organizational continuity is not.
3A. Business Context is the product
Business Context is not a database, not a search index, not a record selector. It is the complete operating reality of the organization — objectives, KPIs, goals, initiatives, lifecycle state, relationships, decisions, evidence, commitments, policies, and outcomes.
Without Business Context, there is no SpineWorkspace. Business Context is the thread that connects every feature, every surface, every action in the product. It is the reason the product exists and the thing that gives every other capability meaning.
It connects the Human Workbench to the AI Workbench. It connects Twin to Spine Agents. It connects Governance to Execution. It connects what the user sees to what AI reasons about. It connects what was decided to what happens next. It connects intent to outcome. It connects the organization to its work.
Every action in the system is grounded in Business Context:
| What happens | Business Context driving it |
|---|---|
| User opens the product | Sees what matters now because Business Context determines priority |
| Workbench composes a view | Projection is shaped by role, department, KPIs, lifecycle state and active objectives |
| Twin reasons about a task | Starts from the business objective, current state, commitments and evidence — not a blank prompt |
| Agent takes a subtask | Receives the business goal, authority envelope, KPI impact and constraints — not just a task description |
| Governance evaluates an action | Weighs business risk, KPI impact, policy, authority and expected outcome |
| Execution occurs | Is grounded in the business capability being performed, not just the API call |
| Reconciliation closes the loop | Compares expected business outcome against observed reality — not just HTTP status codes |
| Memory is promoted | Becomes durable because it changed what the organization knows about its business |
The user should never have to "feed context to the system." The system already knows the business. The user works; context is already there.
4. Product hierarchy
| Level | Canonical meaning |
|---|---|
| SpineWorkspace | The product and daily working experience. Exists to make Business Context actionable for humans and AI together. |
| Business Context Spine | THE semantic foundation. THE organization's memory. Without it, nothing works. |
| Human Workbench | Primary user-facing surface. A projection of Business Context for the human. |
| AI Workbench | AI-side operating environment. A projection of Business Context for AI. |
| Spine Context & Continuity System | Business Context Spine plus working continuities (Personal Contextual Memory, AI Continuity Memory). |
| IntegrateWise Platform | The infrastructure that makes Business Context connect, persist, project, execute and reconcile. |
Inside SpineWorkspace are two first-class operating environments:
| Human Workbench | AI Workbench |
|---|---|
| Primary user-facing product surface | AI-side operating environment |
| Human-readable and attention-oriented | Agent-readable and context-oriented |
| Understand, prioritize, decide, collaborate, approve | Understand, research, analyze, plan, prepare, coordinate, monitor |
| Uses Personal Contextual Memory | Uses AI Continuity Memory |
| Receives role/responsibility projections | Receives task/agent/authority projections |
| Human owns accountability | AI owns execution state, not business accountability |
4A. Five separate views — not one monolithic thing
SpineWorkspace is one system, but it is experienced through five separate views. These views are not the same thing. They should not be conflated, documented as one, or confused with each other.
BUSINESS CONTEXT SPINE
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
USER VIEW PLATFORM VIEW PACKAGE VIEW
(Human Workbench) (IntegrateWise (Product offering
What the user Platform Console) and packaging)
sees and does What the operator
manages
│ │ │
└───────────────────┼───────────────────┘
│
┌───────────┴───────────┐
│ │
▼ ▼
PIPELINE VIEW AGENTIC VIEW
(Data flow: (AI/agent work:
ingestion → Twin → Spine Agents →
normalization → Capability Fabric →
four flows → Governance → Hermes →
governed writes) Execution → Reconciliation)
View 1: User View (Human Workbench)
What the human sees and does. The primary daily product surface. Role-specific projections of Business Context. Understand, prioritize, decide, collaborate, approve. This is the product the user interacts with.
View 2: Platform View (IntegrateWise Platform Console)
What the platform operator/admin manages. Integration Manager, Activation Manager, Capability Manager, MCP Pool, AI Models, Governance Policy, Agent Registry, Observability, Security, Tenancy, Billing. This is the infrastructure control surface — not the daily work product.
View 3: Package View (Product Offering)
How SpineWorkspace is packaged and offered. What comes with which tier. What features are enabled. What connectors are available. What capabilities are included. This is the commercial product boundary.
View 4: Pipeline View (Data Flow)
How data flows through the system. Gateway → Loader Runtime → Four Flows (A-B-C-D) → Normalizer → Triage → Governed Spine Writers → Business Context Spine. This is the ingestion and data processing pipeline — the machinery that feeds the Spine.
View 5: Agentic View (AI/Agent Execution)
How AI and agents work. Twin → Context Assembly → Work Allocation → Capability Discovery → Capability Fabric → Governance → Hermes → Execution → Outcome → Re-ingestion → Verification → Reconciliation → Spine Update. This is the AI operating loop — separate from the data pipeline, separate from the user experience.
The rule
These five views share the same Business Context Spine. They do not share the same interface, the same concerns, or the same documentation. Each view should be documented, understood and developed independently while remaining grounded in the same Business Context.
5. Experience Contract
Human-visible experience
Open SpineWorkspace
→ see what matters now
→ enter current work
→ find the relevant business history and evidence already assembled
→ ask or assign Twin when useful
→ review prepared work / recommendation / proposal
→ decide or approve when authority is required
→ continue working
→ see the verified result return to the same context
The user should not be forced to understand MCP Pool, ADK, Flow C, model routing, queue semantics, reconciliation identifiers, Spine Cache or the execution topology.
AI-visible experience
I have an identity
→ I know my objective
→ I have the authorized business context
→ I have my AI continuity memory
→ I know the current Work state
→ I know the evidence
→ I know my authority
→ I know which capabilities are available
→ I can hand work to another authorized agent without losing continuity
→ I can return evidence and resume later
Internal experience machinery (product internals, not user concepts)
Projection Engine · Workbench Contract · UI Composition
AI Context Builder · Model Resolver · ADK / Agent Runtime
Capability Discovery · Capability Fabric · Governance · Hermes
Events / Queues · Sync · Verification · Reconciliation · OODA state transitions
6. Twin and Spine Agents
Twin's role
Twin is the contextual human-facing cognitive participant. It can:
- assemble authorized context;
- retrieve Business Memory, Personal Context where authorized, AI Continuity Memory, history and evidence;
- explain current state and changes;
- identify risks, gaps and commitments;
- prepare drafts, plans, reports, mutations and capability inputs;
- propose actions and request approval;
- monitor authorized execution outcomes.
Twin cannot directly own organizational truth, self-approve consequential actions, bypass Governance, become the storage layer, or claim success before verification and reconciliation.
Spine Agents
A Spine Agent is an AI worker operating inside the organization's governed Work and context model. Every agent receives identity, tenant, purpose, owner, delegated authority, scopes, capability access, memory namespace, runtime/model profile, risk policy and audit identity.
Spine Agents cooperate by reading and updating shared Work state and returning evidence, not by relying only on free-form agent-to-agent conversation.
Agent A
→ performs sub-work
→ writes evidence / updates Work state
→ handoff recorded
→ Agent B reads same authorized Work context
→ continues
Agent Development Kit (ADK)
ADK is the developer/runtime abstraction for registering and invoking agents through governed platform contracts. It should describe skills, schemas, runtime requirements, tool bindings and execution interfaces, while authority remains with One Auth/Governance and canonical truth remains with governed Spine writers.
7. OODA — Internal Interaction Grammar
OODA is the internal operating grammar that governs how every interaction works. It is not a literal four-button interface. These four actions are embedded into every natural interaction — the user never sees them as explicit controls.
How OODA lives inside the product
| What the user naturally does | OODA happening underneath |
|---|---|
| Opens a customer, project, task or document | Observe — the system captures context, links evidence, updates the running continuity record. The user does not click "Store in Spine." |
| Reads current state, sees what changed, asks a question | Orient — Twin retrieves and explains active context. The user does not click "Ask Your Twin." The Twin is already present where context is needed. |
| Delegates work, asks Twin to prepare a draft, or routes a task | Decide — the system assigns the objective through governed Work state. The user does not click "Assign Your Twin." The handoff is a natural work action. |
| Reviews a proposal and confirms, or a policy allows low-risk automation | Act — governance records human authority for consequential execution. The user does not click "Approve." Approval appears when authority requires it; it is not a default step. |
The continuous loop
Observe → Orient → Decide → Act → Outcome → Re-ingest → Verify → Reconcile → Observe again
The constitutional rule
Twin does not own the consequential "Act" authority. Policy may permit low-risk automation, but consequential authority is always explicit in Governance.
The product succeeds when users experience natural work actions that already carry context — they should never need to understand that OODA is the grammar making that possible.