SpineWorkspace — Full Canonical Ontology & End-to-End Work Model

Status: CANONICAL TARGET
Company: IntegrateWise (integratewise.ai)
Product: SpineWorkspace (spineworkspace.com)
Foundation: Business Context Spine (THE semantic foundation)
Primary concern: Business Context
Primary coordination unit: Work
Primary human–AI relationship: User ↔ Twin

0. The ontology in one sentence

SpineWorkspace is a human–AI work coordination environment centered on Business Context, with the Business Context Spine providing THE organization’s memory, the User Workbench providing the human operating surface, the AI Workbench providing the machine-side operating surface, and the IntegrateWise platform providing governed connectivity, communication, capability and execution.

The Tier-0 Principle

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 Spine gives work its business context.

1. Root hierarchy

INTEGRATEWISE
Company / Platform Builder
integratewise.ai
│
└── SPINEWORKSPACE
    Customer Product
    spineworkspace.com
    │
    ├── ORGANIZATION
    ├── BUSINESS CONTEXT
    ├── HOST AWARENESS
    ├── DISCOVERY / MARKETPLACES
    ├── CONNECTIVITY / INGESTION
    ├── CONTEXT INGESTION & SYNTHESIS
    ├── BUSINESS CONTEXT SPINE
    ├── PROJECTION
    ├── WORK
    ├── HUMAN WORKBENCH
    ├── AI WORKBENCH
    ├── TRIAGE
    ├── AGENT FABRIC
    ├── AGENT COMMUNICATION
    ├── CAPABILITY FABRIC
    ├── GOVERNANCE
    ├── EXECUTION FABRIC
    ├── COMMUNICATIONS OVER THE BRIDGE
    ├── RECONCILIATION
    ├── MEMORY / KNOWLEDGE
    └── CONTINUITY

2. Dual-domain rule

The term dual domain means the two primary product/company domains:

integratewise.ai
    ↓
IntegrateWise — company / platform

spineworkspace.com
    ↓
SpineWorkspace — product / customer work environment

Business domains such as Sales, Finance and Account Success are inside SpineWorkspace. They are not the second half of the dual-domain model.

3. Business Context is the center

Business Context is:

The relevant representation of organizational reality required to understand, decide, coordinate, execute and continue business work.

It contains or links:

Business Context
├── Organization
├── Goals
├── Objectives
├── People
├── Teams
├── Roles
├── Responsibilities
├── Domains
├── Business Entities
├── Relationships
├── Events
├── Current State
├── Historical State
├── Decisions
├── Communications
├── Evidence
├── Policies
├── Commitments
├── Dependencies
├── Risks
├── Work
└── Outcomes

Business Context Spine exists to make this context continuous across the organization’s existing systems.

4. Three canonical flows

Flow 1 — Business Context Ingestion & Synthesis

SOURCE SYSTEMS / TOOLS / AGENTS
        ↓
CONNECTIVITY
        ↓
LOADER
        ↓
RAW EVIDENCE
        ↓
NORMALIZER
        ↓
SCHEMA / SEMANTIC SYNTHESIS
        ↓
ENTITY RESOLUTION
        ↓
RELATIONSHIP / EVENT LINKING
        ↓
DOMAIN / ACCOUNT / WORK LINKING
        ↓
BUSINESS CONTEXT
        ↓
BUSINESS CONTEXT SPINE

The result is connected Business Context, not a collection of copied provider records.

Flow 2 — Human–AI Work

BUSINESS CONTEXT SPINE
        ↓
PROJECTION
        ↓
HUMAN WORKBENCH
        ↓
USER INTERACTION
        ↓
BUSINESS CONTEXT ASSEMBLY
        ↓
TWIN OBSERVE / ORIENT
        ↓
CONTEXT ASSEMBLY
        ↓
AI WORKBENCH
        ↓
TWIN
        ↓
USER + TWIN + SHARED WORK
        ↓
WORK ALLOCATION
        ↓
HUMAN / TWIN / AGENT / SYSTEM / HUMAN+AI
        ↓
DECIDE
        ↓
GOVERNANCE
        ↓
EXECUTION

Flow 3 — Communication, Execution, Reconciliation & Knowledge Continuity

HUMAN / TWIN / AGENT
        ↓
COMMUNICATIONS OVER THE BRIDGE
        ↓
GOVERNED CONTEXT SHARING
        ↓
CAPABILITY
        ↓
GOVERNANCE
        ↓
EXECUTION FABRIC
        ↓
SOURCE SYSTEM
        ↓
ACTUAL STATE
        ↓
RE-INGESTION
        ↓
NORMALIZATION
        ↓
RECONCILIATION
        ↓
UPDATED BUSINESS CONTEXT
        ↓
TRIAGE / INTERPRETATION
        ↓
CANDIDATE
        ↓
GOVERNANCE
        ↓
ORGANIZATIONAL MEMORY
        ↓
UPDATED SPINE CONTEXT
        ↓
NEXT WORK

5. Source-to-Spine ontology

Loader

The Loader preserves:

source identity
tenant identity
provenance
evidence
ingestion metadata
replay information

It does not decide canonical meaning.

Normalizer

The Normalizer makes source structures structurally comparable:

fields
types
timestamps
identifiers
enums
events
source mappings

Schema Synthesis

Schema Synthesis turns provider structures into canonical organizational semantics.

provider schema
    ↓
normalized schema
    ↓
semantic synthesis
    ↓
canonical entity / relationship / event

Entity Resolution

Entity Resolution answers:

Are two provider records the same business entity?

Salesforce Account
Stripe Customer
HubSpot Company
        ↓
    canonical Account

Relationship Linking

Relationships connect otherwise isolated records into Business Context.

Event Linking

Events become temporally connected to:

entities
work
decisions
communications
outcomes

Domain Mapping

One business event may appear in multiple domain projections without creating multiple truths.

6. Business Context Spine

BUSINESS CONTEXT SPINE
├── Business Context (THE semantic foundation)
├── Canonical Spine
├── Operational Spine / Runtime State
├── Linked Business Context
├── Work
├── Entity State
├── Event History
├── Organizational Memory
├── Provenance
├── Lineage
├── Projections
├── Reconciliation
└── Continuity

Canonical Spine

Governed organizational truth.

Operational Sandbox

Bounded working context derived from Business Context Spine for a user, role, task and interaction. AI works in the sandbox. AI does not directly own or mutate canonical Business Context Spine.

7. Organization ontology

Organization
├── Identity
├── Structure
│   ├── Business Units
│   ├── Departments
│   ├── Teams
│   └── Functions
├── People
├── Roles
├── Responsibilities
├── Authority
├── Business Domains
├── Goals
├── Objectives
├── Standards
├── Policies
├── Processes
├── Capabilities
└── Outcomes

Organizational lifecycle:

NEED
 ↓
GOAL
 ↓
OBJECTIVE
 ↓
PLAN
 ↓
WORK
 ↓
ASSIGN
 ↓
EXECUTE
 ↓
MONITOR
 ↓
DECIDE
 ↓
VERIFY
 ↓
RECONCILE
 ↓
OUTCOME
 ↓
LEARN
 ↓
NEXT WORK

8. Business domain taxonomy

Executive / Corporate
Sales
Marketing
Account Success
Technical Account Success
Support / Service
Finance
Revenue Operations
Business Operations
Product
Engineering
Human Resources
Legal
IT
Security / Risk
Procurement
Administration

Subdomains remain organization-configurable.

9. Entity ontology

Organization
Person
Team
Role
Customer
Account
Contact
Product
Contract
Opportunity
Deal
Invoice
Payment
Ticket
Case
Project
Document
Meeting
Decision
Policy
Work
Task
Workflow
Agent
Capability
System
Outcome

10. Work Graph ontology

The Work Graph connects:

Goal
Objective
Work
 ├── Task
 ├── Assignment
 ├── Entity
 ├── Dependency
 ├── Decision
 ├── Approval
 ├── Communication
 ├── Evidence
 ├── Capability
 ├── Agent
 ├── Execution
 └── Outcome

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

11. Projection ontology

Projection is a governed view over the same organizational reality.

Viewer
├── Identity
├── Tenant
├── Role
├── Permissions
├── Department
├── Domain
└── Responsibility

Subject
├── Entity
├── Work
├── Lifecycle
├── Relationships
└── Evidence

Organization
├── Goals
├── Priorities
├── Standards
└── Business Context

System
├── Connector Availability
├── Capability Availability
├── Freshness
└── Policy
        ↓
Projection Engine
        ↓
Role / Domain / Responsibility Projection

There are no departmental copies of canonical truth.

12. User Workbench

The User Workbench is the human operational surface.

User Workbench
├── Personal
│   ├── Home
│   ├── Today
│   ├── My Work
│   ├── My Queue
│   ├── Tasks
│   └── Calendar
├── Communications
│   ├── Email
│   ├── Chat
│   ├── Meetings
│   ├── Calls
│   └── Documents
├── Organizational Memory
│   ├── Decisions
│   ├── Knowledge
│   ├── Documents
│   ├── Policies
│   ├── Processes
│   └── Work History
├── Work
│   ├── Active
│   ├── Waiting
│   ├── Needs Decision
│   ├── Needs Approval
│   ├── Delegated
│   ├── Blocked
│   └── Completed
└── Business Domain Work Surfaces

The Workbench is adaptive, but only personal/reversible presentation changes may occur automatically. Shared truth, permissions, authority, policy and organizational-memory publication remain governed.

13. Twin ontology

Every user has one bounded Twin.

USER
├── User Workbench
└── Twin
    ├── Twin Workbench
    ├── AI Operational Sandbox
    ├── Domain Capabilities
    ├── Domain Agents
    ├── Workflows
    ├── Communications
    └── Work Assignment

Twin responsibility:

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

OODA is the internal reasoning loop:

OBSERVE → ORIENT → DECIDE → ACT

14. Coworker ontology

Coworker is the contextual companion between active Workbench use and the Twin.

User
 ↓
Workbench
 ↓
Coworker
 ├── observes active work
 ├── gathers context
 ├── retrieves relevant information
 ├── supports communication
 └── keeps active human/Twin context aligned
 ↓
Twin

Coworker is not a second authority.

15. Triage ontology

Triage:

classifies
links
detects duplicates
detects conflicts
detects ambiguity
evaluates materiality
evaluates sensitivity
evaluates freshness
evaluates completeness
proposes memory scope
stages candidates
routes review

Canonical doctrine:

Triage classifies. Governance decides. The Pipeline promotes. Spine owns organizational memory. Twin consumes the governed result.

16. Agent Fabric

Agent Fabric
├── Twin
├── Coworker
├── Triage
├── Domain Agents
├── Specialist Agents
├── Research Agents
├── Workflow Agents
└── External Agents

The Twin remains the orchestration boundary.

17. Agent Communication

ACP

ACP is the Agent Communication Protocol.

MCP = AI ↔ Tool / Resource
ACP = Agent ↔ Agent / Agent ↔ Twin through governed work/context handoff

ACP carries:

Work ID
Task ID
Sender
Recipient
Capability
Context Reference
Authority Scope
Constraints
Expected Output
Evidence Requirements
Status
Result
Attribution
Correlation ID
Causation ID

ACP is a communication mechanism, not an authority grant. Agents receive a bounded Context Package:

Tenant
Work
Purpose
Relevant Entities
Relevant State
Constraints
Authority
Allowed Capabilities
Evidence
Freshness
Sensitivity
Expiry
Provenance

They do not receive unrestricted organizational memory.

19. Capability Fabric

Capability answers:

What can be done?

A capability declares:

Identity
Description
Inputs
Outputs
Required Context
Required Authority
Risk
Evidence Requirements
Policy
Execution Bindings

Capability is independent from implementation.

20. Execution Fabric

API
MCP
Spine Tools
ADK
Workflow
Pipeline
Agent Runtime
Orchestrator / Hermes
Provider Tools
Workers
Durable Execution

All consequential external effects traverse governed Execution Fabric.

21. Governance

Identity
Tenant
Role
Permission
Responsibility
Authority
Policy
Risk
Approval
Evidence
Audit
Accountability

Confidence never grants authority.

22. Communications Over the Bridge

The Bridge is the communication substrate connecting human, Twin, agents and source systems around the same Work.

Human
 │
 ├── Workbench Chat
 ├── Slack
 ├── Email
 ├── Teams
 ├── Meeting
 └── Call
 │
 ▼
COMMUNICATION BRIDGE
 │
 ├── Identity / Tenant
 ├── Work Context
 ├── Context Reference
 ├── Policy
 ├── Delivery
 ├── Inbound Event
 └── Audit
 │
 ▼
Twin / Coworker / Agent / Workflow
 │
 ▼
Spine Work / Context

The Bridge does not become a new memory store. It transports communication and work context while preserving source provenance.

23. Source-system execution and return path

Intent
 ↓
Capability
 ↓
Governance
 ↓
Execution Plan
 ↓
Execution Fabric
 ↓
Source System
 ↓
Receipt
 ↓
Actual State
 ↓
Re-ingestion
 ↓
Reconciliation
 ↓
Spine

Provider success is not business completion.

24. Knowledge evolution

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

Knowledge therefore emerges from processed outcomes, not from raw data or raw model output.

25. Canonical laws

IntegrateWise is the company; SpineWorkspace is the product.
Business Context is THE semantic foundation. Without it, nothing works.
The Spine gives work its business context.
One canonical organizational reality; many governed projections.
AI never directly reads or writes canonical Business Context Spine.
AI operates in a bounded AI Workbench.
Work is the primary coordination unit.
Work Allocation determines who/what performs each part of Work.
Every user has one bounded Twin.
Triage never becomes a canonical writer.
Capability defines what; Execution Fabric defines how.
Governance controls consequential mutation.
ACP communicates work/context; it does not grant authority.
MCP is a tool/resource/capability interoperability mechanism.
Source execution must return through re-ingestion and reconciliation.
Business Context informs organizational truth; it does not silently become organizational truth.
Business Context is published only through governed promotion.
Personal/reversible adaptation may auto-tune; shared/consequential change requires governance.
IntegrateWise Platform remains substrate, not a second Workbench.
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.

26. Canonical system loop

ORGANIZATIONAL NEED
 ↓
GOAL / OBJECTIVE
 ↓
WORK GRAPH
 ↓
BUSINESS CONTEXT
 ↓
BUSINESS CONTEXT SPINE
 ↓
PROJECTION / CONTEXT ASSEMBLY
 ↓
HUMAN WORKBENCH + AI WORKBENCH
 ↓
SHARED WORK
 ↓
WORK ALLOCATION
 ↓
HUMAN / AI / HUMAN+AI
 ↓
COMMUNICATION / CONTEXT SHARING
 ↓
GOVERNANCE
 ↓
CAPABILITY
 ↓
EXECUTION
 ↓
SOURCE SYSTEM
 ↓
RE-INGESTION
 ↓
RECONCILIATION
 ↓
UPDATED CONTEXT
 ↓
TRIAGE / INTERPRETATION
 ↓
GOVERNED KNOWLEDGE PROMOTION
 ↓
ORGANIZATIONAL MEMORY
 ↓
CONTINUITY
 ↓
NEXT WORK

27. Host-aware and marketplace ontology

Host and marketplace capabilities sit above Connectivity and Capability discovery:

HOST
 ↓
DISCOVERY
 ↓
INTEGRATION MARKETPLACE
PLUGIN MARKETPLACE
MCP MARKETPLACE
 ↓
COMPATIBILITY / TRUST
 ↓
INSTALL / CONNECT / AUTHORIZE
 ↓
CAPABILITY REGISTRY
 ↓
GOVERNANCE
 ↓
EXECUTION

Host awareness changes the contextual surface available to the user/Twin. It never creates authority and never changes canonical Business Context. The marketplace is not a new source of Business Context. It discovers and distributes capabilities that may participate in Work.

​SpineWorkspace — Full Canonical Ontology & End-to-End Work Model

​0. The ontology in one sentence

​The Tier-0 Principle

​1. Root hierarchy

​2. Dual-domain rule

​3. Business Context is the center

​4. Three canonical flows

​Flow 1 — Business Context Ingestion & Synthesis

​Flow 2 — Human–AI Work

​Flow 3 — Communication, Execution, Reconciliation & Knowledge Continuity

​5. Source-to-Spine ontology

​Loader

​Normalizer

​Schema Synthesis

​Entity Resolution

​Relationship Linking

​Event Linking

​Domain Mapping

​6. Business Context Spine

​Canonical Spine

​Operational Sandbox

​7. Organization ontology

​8. Business domain taxonomy

​9. Entity ontology

​10. Work Graph ontology

​11. Projection ontology

​12. User Workbench

​13. Twin ontology

​14. Coworker ontology

​15. Triage ontology

​16. Agent Fabric

​17. Agent Communication

​ACP

​18. Context sharing

​19. Capability Fabric

​20. Execution Fabric

​21. Governance

​22. Communications Over the Bridge

​23. Source-system execution and return path

​24. Knowledge evolution

​25. Canonical laws

​26. Canonical system loop

​27. Host-aware and marketplace ontology