{"slug":"canonical/01-PRODUCT-AND-EXPERIENCE","title":"01 — Product, Experience and Human-AI Operating Model","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/01-PRODUCT-AND-EXPERIENCE.md","bytes":13389,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Canonical reference:** `00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md` §1, §7, §8, §10, §11  \n**Status:** Canonical\n\n---\n\n## 1. SpineWorkspace\n\nSpineWorkspace 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.\n\n**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.\n\n## 2. IntegrateWise\n\nIntegrateWise 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.\n\nIntegrateWise is not the daily destination for most users. It is the infrastructure substrate that makes the SpineWorkspace experience possible.\n\n## 3. The Core Thesis\n\n> **Neither humans nor AI should have to reconstruct the organization every time they need to work.**\n\n> **Tools are replaceable. Models are replaceable. Agents are replaceable. Organizational continuity is not.**\n\n## 3A. Business Context is the product\n\nBusiness 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.\n\n**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.\n\nIt 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.\n\nEvery action in the system is grounded in Business Context:\n\n| What happens | Business Context driving it |\n|---|---|\n| User opens the product | Sees what matters now **because Business Context determines priority** |\n| Workbench composes a view | Projection is shaped by **role, department, KPIs, lifecycle state and active objectives** |\n| Twin reasons about a task | Starts from **the business objective, current state, commitments and evidence** — not a blank prompt |\n| Agent takes a subtask | Receives **the business goal, authority envelope, KPI impact and constraints** — not just a task description |\n| Governance evaluates an action | Weighs **business risk, KPI impact, policy, authority and expected outcome** |\n| Execution occurs | Is grounded in **the business capability being performed, not just the API call** |\n| Reconciliation closes the loop | Compares **expected business outcome against observed reality** — not just HTTP status codes |\n| Memory is promoted | Becomes durable **because it changed what the organization knows about its business** |\n\nThe user should never have to \"feed context to the system.\" The system already knows the business. The user works; context is already there.\n\n## 4. Product hierarchy\n\n| Level | Canonical meaning |\n|---|---|\n| **SpineWorkspace** | The product and daily working experience. Exists to make Business Context actionable for humans and AI together. |\n| **Business Context Spine** | THE semantic foundation. THE organization's memory. Without it, nothing works. |\n| **Human Workbench** | Primary user-facing surface. A projection of Business Context for the human. |\n| **AI Workbench** | AI-side operating environment. A projection of Business Context for AI. |\n| **Spine Context & Continuity System** | Business Context Spine plus working continuities (Personal Contextual Memory, AI Continuity Memory). |\n| **IntegrateWise Platform** | The infrastructure that makes Business Context connect, persist, project, execute and reconcile. |\n\nInside SpineWorkspace are two first-class operating environments:\n\n| Human Workbench | AI Workbench |\n|---|---|\n| Primary user-facing product surface | AI-side operating environment |\n| Human-readable and attention-oriented | Agent-readable and context-oriented |\n| Understand, prioritize, decide, collaborate, approve | Understand, research, analyze, plan, prepare, coordinate, monitor |\n| Uses Personal Contextual Memory | Uses AI Continuity Memory |\n| Receives role/responsibility projections | Receives task/agent/authority projections |\n| Human owns accountability | AI owns execution state, not business accountability |\n\n## 4A. Five separate views — not one monolithic thing\n\nSpineWorkspace 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.\n\n```text\n                    BUSINESS CONTEXT SPINE\n                            │\n        ┌───────────────────┼───────────────────┐\n        │                   │                   │\n        ▼                   ▼                   ▼\n   USER VIEW         PLATFORM VIEW        PACKAGE VIEW\n   (Human Workbench)  (IntegrateWise       (Product offering\n    What the user      Platform Console)    and packaging)\n    sees and does      What the operator\n                       manages\n        │                   │                   │\n        └───────────────────┼───────────────────┘\n                            │\n                ┌───────────┴───────────┐\n                │                       │\n                ▼                       ▼\n         PIPELINE VIEW            AGENTIC VIEW\n         (Data flow:              (AI/agent work:\n          ingestion →              Twin → Spine Agents →\n          normalization →          Capability Fabric →\n          four flows →             Governance → Hermes →\n          governed writes)         Execution → Reconciliation)\n```\n\n### View 1: User View (Human Workbench)\n\nWhat 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.\n\n### View 2: Platform View (IntegrateWise Platform Console)\n\nWhat 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.\n\n### View 3: Package View (Product Offering)\n\nHow 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.\n\n### View 4: Pipeline View (Data Flow)\n\nHow 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.\n\n### View 5: Agentic View (AI/Agent Execution)\n\nHow 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.\n\n### The rule\n\nThese 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.\n\n## 5. Experience Contract\n\n### Human-visible experience\n\n```text\nOpen SpineWorkspace\n→ see what matters now\n→ enter current work\n→ find the relevant business history and evidence already assembled\n→ ask or assign Twin when useful\n→ review prepared work / recommendation / proposal\n→ decide or approve when authority is required\n→ continue working\n→ see the verified result return to the same context\n```\n\nThe user should **not** be forced to understand MCP Pool, ADK, Flow C, model routing, queue semantics, reconciliation identifiers, Spine Cache or the execution topology.\n\n### AI-visible experience\n\n```text\nI have an identity\n→ I know my objective\n→ I have the authorized business context\n→ I have my AI continuity memory\n→ I know the current Work state\n→ I know the evidence\n→ I know my authority\n→ I know which capabilities are available\n→ I can hand work to another authorized agent without losing continuity\n→ I can return evidence and resume later\n```\n\n### Internal experience machinery (product internals, not user concepts)\n\n```text\nProjection Engine · Workbench Contract · UI Composition\nAI Context Builder · Model Resolver · ADK / Agent Runtime\nCapability Discovery · Capability Fabric · Governance · Hermes\nEvents / Queues · Sync · Verification · Reconciliation · OODA state transitions\n```\n\n## 6. Twin and Spine Agents\n\n### Twin's role\n\nTwin is the contextual human-facing cognitive participant. It can:\n\n- assemble authorized context;\n- retrieve Business Memory, Personal Context where authorized, AI Continuity Memory, history and evidence;\n- explain current state and changes;\n- identify risks, gaps and commitments;\n- prepare drafts, plans, reports, mutations and capability inputs;\n- propose actions and request approval;\n- monitor authorized execution outcomes.\n\nTwin cannot directly own organizational truth, self-approve consequential actions, bypass Governance, become the storage layer, or claim success before verification and reconciliation.\n\n### Spine Agents\n\nA 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.\n\nSpine Agents cooperate by reading and updating shared Work state and returning evidence, not by relying only on free-form agent-to-agent conversation.\n\n```text\nAgent A\n→ performs sub-work\n→ writes evidence / updates Work state\n→ handoff recorded\n→ Agent B reads same authorized Work context\n→ continues\n```\n\n### Agent Development Kit (ADK)\n\nADK 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.\n\n## 7. OODA — Internal Interaction Grammar\n\nOODA 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.\n\n### How OODA lives inside the product\n\n| What the user naturally does | OODA happening underneath |\n|---|---|\n| 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.\" |\n| 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. |\n| 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. |\n| 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. |\n\n### The continuous loop\n\n```text\nObserve → Orient → Decide → Act → Outcome → Re-ingest → Verify → Reconcile → Observe again\n```\n\n### The constitutional rule\n\n> **Twin does not own the consequential \"Act\" authority.** Policy may permit low-risk automation, but consequential authority is always explicit in Governance.\n\nThe 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.\n"}