Founder Architecture Flow
Complete visual and operational flow from external SaaS ingestion to Workbench UI and AI Twin.
From: https://chatgpt.com/g/g-p-69ff5004949881918e9c45b51e437475/c/6a99d5c4-36ec-83ee-887d-6ba8dce195a6
you asked
message time: 2026-09-04 01:47:06
INITIAL SPINE SCHEMA FOR TENANT ORG TOOLS TO SPINE INGESTION INITIAL ROLE-BASED PROJECTION VIEWS FOR ROLES AND ACCESS ORGANIZATIONAL MEMORY - SPINE FABRIC HOW THE SPINE SCHEMA IS HYDRATED BASED ON THE CONNECTOR - TRIAGE INVOLVES - PROMOTION QUEUE AND CONTINUITY PROJECTIONS ON USER WORKBENCH - SPINEWORKBENCH - TWIN + COWORKER (CONTEXT ASSEMBLY) + A2A, MCP AND REST COMMS PERSONAL MEMORY - USER PROJECTIONS ON AI WORKBENCH - TWIN WORKBENCH AGENTIC MEMORY - AI HUMAN + AI INTERACTION ON TASK AND WORKS - TOOL CAPABILITIES AND INTERACTIONS WORKFLOWS AND SYNC BACK TO SOURCE '
chatgpt response
Your sequence is the right way to assemble the architecture. I would make it the canonical tenant-to-work loop, with one important distinction: Spine schema, projection, memory, AI Workbench, and execution are different layers of the same system—not separate products or truth stores.
The current founder canon already freezes the relevant boundaries: Business Context Spine / Organizational Memory, Personal Contextual Memory, AI Continuity Memory, Work, Projection Engine, Twin/AI Workbench, Capability Fabric, Governance, Hermes, and re-ingestion/reconciliation.
Canonical SpineWorkspace operating flow
TENANT ORGANIZATION
│
▼
1. INITIAL SPINE SCHEMA
│
Tenant Business Context Model
│
┌─────────────┴─────────────┐
│ │
Core entities Relationships
Work Authority
People Evidence
Communications Events
Knowledge Capabilities
│
▼
2. CONNECTED TOOLS
CRM · ERP · Email · Docs
Chat · Calendar · GitHub
SaaS · APIs · MCP · etc.
│
▼
3. TOOLS → SPINE INGESTION
│
Flow A / B / C / D
│
▼
Loader / Normalizer
│
▼
TRIAGE
│
┌─────────────┼─────────────┐
│ │ │
classify link/dedupe prioritize
│ │ │
└─────────────┼─────────────┘
▼
SPINE HYDRATION
│
operational business context/state
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Evidence Knowledge Memory Intake
4. Initial role-based projection
Once the Spine has sufficient context:
BUSINESS CONTEXT SPINE
│
▼
PROJECTION ENGINE
│
┌────────────────┼────────────────┐
│ │ │
Role Department Industry
│ │ │
└────────────────┼────────────────┘
│
Permission / RBAC
│
▼
AUTHORIZED PROJECTION
│
▼
HUMAN WORKBENCH
This means the tenant does not receive a Sales schema, Engineering schema, Finance schema, etc.
There is one organizational Spine.
The Projection Engine produces the appropriate view of that Spine for:
Role × Department × Industry × Authority × Context
That is consistent with the canonical rule that context assembly belongs to the Projection Engine/authorized context contracts rather than being independently reconstructed by UI or agents.
5. SpineWorkbench
The Human Workbench is the first operational projection of the hydrated Spine.
SPINEWORKSPACE
│
▼
HUMAN WORKBENCH
│
┌─────────────────┼─────────────────┐
│ │ │
Work Records Knowledge
Tasks Tables Documents
Views Pages Evidence
Canvas Entities Context
│ │ │
└─────────────────┼─────────────────┘
│
▼
ACTIVE CONTEXT
│
▼
TWIN / COWORKER
The important point is that the Twin does not independently discover the organization's context.
The Workbench interaction establishes the context.
6. Twin + Coworker = contextual AI work layer
The Twin is the human-facing AI coworker inside the AI Workbench model defined by the founder canon.
Its context is assembled from:
Business Context Spine
+
Current Work
+
Selected entity
+
User authority
+
Relevant organizational memory
+
Personal contextual memory
+
AI continuity memory
+
Evidence
+
Available capabilities
+
Current conversation/session
Conceptually:
Human
│
│ selects / asks / assigns
▼
Human Workbench
│
▼
Context Assembly
│
├── Business Context
├── Work
├── Evidence
├── Personal Memory
├── AI Continuity
└── Authority
│
▼
Twin / AI Workbench
7. Communication fabric
The Twin and agents should then communicate through the governed communication/capability fabric:
TWIN
│
┌──────────┼──────────┐
│ │ │
A2A MCP REST
│ │ │
▼ ▼ ▼
Agents Tools APIs
│ │ │
└──────────┼──────────┘
▼
CAPABILITY FABRIC
These are communication/execution mechanisms, not competing sources of organizational truth.
The founder canon explicitly freezes:
- Agent runtime → ADK + governed agent contracts
- Capability selection → Capability Discovery + Capability Fabric
- MCP outward → IW Spine Network MCP
- MCP inward → MCP Pool
- Authority → Governance
- Execution coordination → Hermes.
8. Personal Memory, Organizational Memory, AI Memory
This is where your sequence needs three explicit branches.
Organizational memory
Triage
↓
Memory Evolution
↓
Promotion Queue
↓
Human approval
↓
Organizational Memory
↓
Knowledge / retrieval / future context
The documented eight-layer memory pipeline places the Promotion Queue and human approval between AI-derived observations and durable organizational memory.
Personal contextual memory
User
↓
personal observations / preferences / context
↓
Personal Contextual Memory
Private by default.
AI continuity memory
Twin / Agent
↓
reasoning/session/continuity state
↓
AI Continuity Memory
This is not organizational truth.
The founder canon explicitly separates Personal Contextual Memory and AI Continuity Memory from the shared Business Context Spine.
So the model becomes:
┌──────────────────────────┐
│ BUSINESS CONTEXT SPINE │
│ Organizational Truth │
└────────────┬─────────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Personal AI Continuity Knowledge
Memory Memory
USER AI
9. Human + AI work
Now everything converges around Work.
WORK
│
┌────────────┼────────────┐
│ │ │
Human Twin Agent
│ │ │
└────────────┼────────────┘
│
Shared context
+ authority
+ evidence
+ lineage
│
▼
Work execution
The founder canon makes Work the shared coordination object between humans and AI, backed by context, authority, evidence and lineage.
This is the missing conceptual center if we only describe the system as “Spine → Twin → tools.”
10. Capability interaction
When the Twin needs to do something:
Twin
↓
Understand Work
↓
Determine required capability
↓
Capability Discovery
↓
Capability Fabric
↓
Resolve implementation
↓
Governance
↓
Approval if required
↓
Hermes
↓
MCP / REST / Agent / Workflow / Provider
↓
External action
The Twin therefore proposes and coordinates.
It does not become an uncontrolled writer.
11. Sync back to source
This is essential to close the loop.
External Action
│
▼
Provider Result
│
▼
Re-ingestion
│
▼
Normalization
│
▼
Verification
│
▼
Reconciliation
│
▼
Spine Updated
│
▼
Projection Refresh
│
▼
Human Workbench
│
▼
Twin receives new context
The platform's documented rule is that outbound execution does not itself become truth; the result returns through the controlled data path and the Spine is refreshed.
12. The complete architecture in one diagram
This is the version I would now use as the canonical conceptual diagram:
SPINEWORKSPACE
│
▼
┌──────────────────┐
│ TENANT / ORG │
└────────┬─────────┘
│
▼
INITIAL SPINE SCHEMA
│
▼
CONNECTED BUSINESS TOOLS
│
┌────────┼────────┐
│ │ │
Data Docs/Comms AI
│ │ │
└────────┼────────┘
▼
INGESTION / LOADER
│
▼
NORMALIZATION
│
▼
TRIAGE
│
┌───────────────┼───────────────┐
│ │ │
classify link/dedupe prioritize
│ │ │
└───────────────┼───────────────┘
▼
BUSINESS CONTEXT
SPINE FABRIC
│
┌───────────────┼────────────────┐
│ │ │
Organizational Evidence Knowledge
Memory
│
├───────────────┐
│ │
Promotion Queue Continuity
│ │
Human approval context transfer
│ │
└───────┬───────┘
▼
PROJECTION ENGINE
│
Role × Dept × Industry
× Permission × Context
│
▼
HUMAN WORKBENCH
│
active work/context
│
▼
TWIN / AI WORKBENCH
│
┌──────────┼──────────┐
│ │ │
Personal AI Business
Memory Continuity Context
│ Memory │
└──────────┼───────────┘
│
▼
WORK
│
Human ⇄ Twin ⇄ Agents
│
▼
CAPABILITY FABRIC
│
┌──────────┼───────────┐
│ │ │
MCP REST A2A
│ │ │
└──────────┼───────────┘
▼
GOVERNANCE
│
▼
HERMES
│
▼
SOURCE SYSTEMS
│
▼
OUTCOME / EVENT
│
▼
RE-INGEST / VERIFY / RECONCILE
│
▼
BUSINESS CONTEXT
│
▼
NEW PROJECTION
│
▼
NEXT WORK
│
└───────────────► LOOP
The three memory boundaries are therefore explicit
SPINE
= what the organization knows / what is operationally true
PERSONAL MEMORY
= what the individual carries across work
AI CONTINUITY MEMORY
= what the Twin/AI carries across reasoning and sessions
And the complete product loop is:
Tools → Ingestion → Triage → Spine Fabric → Role/Authority Projection → Human Workbench → Context Assembly → Twin/AI Workbench → Work → Capability Fabric → Governance → Hermes → Source Systems → Re-ingestion → Verification → Reconciliation → Spine → new projections → next work.
That is the architecture I would use as the top-level SpineWorkspace operating model. It incorporates the current founder freeze without introducing another product layer, another truth store, or another independent flow.
you asked
message time: 2026-09-04 01:48:54
FINAL GOAL ALIGNMENT INCLUDING UI AND MARKETING WITH ALL SHELLS AND WORKSPACE FOR HUMAN AND AI SHARING WAT EVER MENTIONED ABOVE
chatgpt response
FINAL GOAL ALIGNMENT — INTEGRATEWISE + SPINEWORKSPACE
This is the consolidated goal I would now treat as the founder-level product, UI, architecture, and marketing alignment.
The latest Founder Canon explicitly establishes SpineWorkspace as the product, IntegrateWise as the infrastructure/platform, with a Human Workbench and AI Workbench operating over the same Business Context Spine, while personal and AI continuity remain separately scoped.
1. The simplest definition
SpineWorkspace is a shared workspace where humans and AI work together over the same governed business context and Work, while respecting their different boundaries, responsibilities and continuity.
And:
IntegrateWise is the infrastructure platform that makes SpineWorkspace possible.
The core idea is therefore:
SPINEWORKSPACE
The place where work happens
│
▼
SHARED WORKBENCH
│
┌──────────┴──────────┐
│ │
HUMAN AI
WORKBENCH WORKBENCH
│ │
└──────────┬──────────┘
│
SHARED BUSINESS
CONTEXT
│
▼
SPINE FABRIC
The user does not buy the Spine, MCP, Hermes, loaders, agents or databases.
The user gets a workspace where the right work, context, information and capabilities are already assembled.
2. The product hierarchy
This hierarchy should remain fixed.
INTEGRATEWISE
Infrastructure Platform
│
▼
SPINEWORKSPACE
Product / Workspace
│
├──────────────────────┐
│ │
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
└──────────┬───────────┘
▼
SHARED WORK
│
▼
BUSINESS CONTEXT SPINE
│
┌──────────┼──────────┐
▼ ▼ ▼
Organizational Personal AI
Memory Memory Continuity
This is the constitutional product rule:
SpineWorkspace = Human Workbench + AI Workbench + Shared Business Context + Separate Human and AI Continuity + Governed Work and Execution.
3. What the customer sees
The customer sees Workspace, not platform machinery.
Common SpineWorkspace shell
Every user gets a stable, learnable shell.
SPINEWORKSPACE
│
├── Home
│
├── My Work
│ ├── Inbox
│ ├── Tasks
│ ├── My Queue
│ ├── Approvals
│ ├── Notifications
│ ├── Recent Work
│ └── Favorites
│
├── Communications
│ ├── Activity Feed
│ ├── Email
│ ├── Calendar
│ ├── Meetings
│ ├── Chat
│ ├── Calls
│ └── Shared Documents
│
├── Personal
│ ├── Notes
│ ├── Knowledge Base
│ ├── Brainstorming Sessions
│ └── Activity
│
├── Work
│ └── Adaptive Workbench
│
├── Platform
│ └── Authorized operators only
│
└── Administration
└── Authorized administrators only
This stable shell is explicitly part of the current architecture: navigation stays stable; Work adapts.
4. Work is where the workspace becomes adaptive
The shell is common.
Work is not.
The Work area is projected from:
Role
× Department
× Industry
× Responsibility
× Permissions
× Business Context
× Connected Systems
× Active Lifecycle
× Current Work
× Available Capabilities
× Knowledge
× Evidence
× User Preferences
× Freshness / Readiness
Therefore:
Founder
↓
Executive Work
Sales
↓
Sales Work
Customer Success
↓
Customer Success Work
Engineering
↓
Engineering Work
Finance
↓
Finance Work
But these are projections over one Business Context, not independent applications or databases.
The same Base Spine remains underneath them.
5. The Human Workbench
The Human Workbench is the primary daily product experience.
It is not:
- a dashboard;
- a CRM;
- a database UI;
- a document editor;
- a chatbot;
- a department-specific SaaS application.
It is the operational surface through which a person understands and moves work.
It can render:
Tables
Views
Pages
Documents
Boards
Queues
Calendar
Timeline
Canvas
Entity views
Knowledge
Evidence
Approvals
Work
Twin
All of these are projections.
The UI does not own the underlying truth.
6. The AI Workbench
The AI Workbench is the corresponding machine-side operating environment.
It is first-class architecturally even when much of it is invisible to the human user.
AI WORKBENCH
│
├── Objective
├── Work
├── Current Context
├── Business Context
├── AI Continuity
├── Evidence
├── Plan
├── Subtasks
├── Agents
├── Capabilities
├── Authority
├── Approvals
├── Execution
├── Results
├── Verification
└── Handoff
This is not merely:
ChatGPT
+
tools
It is a persistent working environment for AI.
The current canon explicitly distinguishes AI Workbench from Twin: Twin is the contextual co-worker closest to the human, while the AI Workbench can coordinate broader agentic work.
7. Human and AI share the Workbench, but not everything
This is one of the most important final distinctions.
They share:
Business Context
Work
Organizational Memory
Evidence
Relationships
Goals
Operational state
Authorized capabilities
Governed context
They do not automatically share:
Human private memory
AI private continuity
Unauthorized information
Unapproved authority
Private reasoning
Unpromoted observations
Therefore:
SHARED
BUSINESS CONTEXT
│
┌──────┴──────┐
│ │
HUMAN AI
│ │
Personal Memory AI Continuity
The constitutional memory rule remains:
User thought
≠
AI inference
≠
Organizational truth
Personal Contextual Memory and AI Continuity Memory do not silently become organizational memory.
8. Twin
The Twin is the human's contextual AI co-worker.
The human does not have to reconstruct the business context manually.
The interaction becomes:
User opens Work
↓
User selects something
↓
Workspace knows the context
↓
Twin receives authorized context
↓
Twin understands the Work
↓
Twin researches / analyzes / prepares
↓
Twin proposes next action
↓
Human decides / approves when required
↓
Capability executes
↓
Result returns
↓
Workspace updates
The user experience therefore becomes task-centric rather than AI-centric.
OODA remains an internal operating grammar rather than something the user must consciously operate as four buttons.
9. Spine Agents
Twin does not have to do everything itself.
It can coordinate specialized Spine Agents.
TWIN
│
┌─────────┼─────────┐
│ │ │
Research Analysis Execution
Agent Agent Agent
│ │ │
└─────────┼─────────┘
│
WORK
│
EVIDENCE
│
HANDOFF
The important part is that agents do not communicate merely through ephemeral chat.
They coordinate through:
Work
Context
Evidence
Authority
Handoff
Continuity
That is why Work is the durable unit of human-AI coordination and handoff.
10. Spine Fabric
The Spine Fabric is the common organizational substrate.
It receives information from the connected business environment:
CRM
ERP
Email
Calendar
Chat
Documents
Support
Projects
GitHub
Billing
HR
Product
Industry systems
APIs
MCP
Then:
Tools
↓
Ingestion
↓
Loader
↓
Normalization
↓
Triage
↓
Spine
↓
Projection
Triage is important because ingestion is not automatically organizational memory.
The system distinguishes:
raw information
→ normalized information
→ contextualized information
→ candidate memory
→ governed promotion
→ organizational memory
11. The Base Spine is always there
Every tenant begins with the mandatory Base Spine.
BASE SPINE
│
├── Business entities
├── Relationships
├── Work
├── People
├── Evidence
├── Provenance
├── Authority
├── Lifecycle
├── Governance
└── Continuity
Then:
Base Spine
+
Industry
+
Department
+
Role
+
Connector
+
Tenant
+
Context
=
Effective Spine
Everything is additive.
No role or connector creates its own reduced organizational universe.
12. Projection Engine
The Projection Engine is the boundary between the underlying system and the experience.
SPINE
│
▼
PROJECTION ENGINE
│
┌─────────┴─────────┐
▼ ▼
HUMAN PROJECTION AI CONTEXT
│ │
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
This is deliberately dual-sided.
It composes:
- what the human is authorized to see and work with;
- what the Twin/Agent is authorized to reason over.
The UI and AI runtime should not independently reconstruct organizational truth.
13. Capabilities
The Twin does not directly "know how to use every application."
It asks the Capability Fabric what can be done.
Twin
↓
Required capability
↓
Capability Discovery
↓
Capability Fabric
↓
Approved implementation
↓
Governance
↓
Execution
Possible execution mechanisms include:
MCP
REST
API
Tool-to-tool
Agent-to-agent
Workflow
Local execution
Provider adapter
MCP is therefore one mechanism inside the capability architecture, not the product's central identity.
The canonical vocabulary defines Capability Fabric as the provider-neutral resolver for how authorized intent can be performed.
14. Governance
Governance sits between intent and consequential action.
Human / Twin / Agent
│
▼
CAPABILITY
│
▼
GOVERNANCE
│
┌────┼────┐
▼ ▼ ▼
Allow Deny Approval
│
▼
Hermes
This preserves the human authority boundary:
Human
= judgment + accountability + consequential approval
AI
= reasoning + preparation + coordination + permitted execution
The product is therefore not promising unrestricted autonomous AI.
15. Hermes and execution
Once an action is authorized:
Governance
↓
Hermes
↓
Capability implementation
↓
MCP / REST / Agent / Workflow / Provider
↓
External system
But execution is not the end.
16. The closed continuity loop
The complete system must close the loop:
SOURCE SYSTEMS
│
▼
INGESTION
│
▼
NORMALIZATION
│
▼
TRIAGE
│
▼
SPINE
│
▼
PROJECTION
│
▼
WORKBENCH
│
▼
TWIN / AI WORKBENCH
│
▼
WORK
│
▼
CAPABILITY
│
▼
GOVERNANCE
│
▼
HERMES
│
▼
EXECUTION
│
▼
SOURCE SYSTEM
│
▼
RE-INGESTION
│
▼
VERIFY
│
▼
RECONCILE
│
▼
GOVERNED SPINE UPDATE
│
▼
RE-PROJECTION
│
▼
WORKBENCH
│
▼
NEXT WORK
This is continuity.
A provider saying "success" is not automatically organizational truth. The result must return through the verification/reconciliation path.
17. The full UI model
From the user's perspective:
SPINEWORKSPACE
│
┌─────────────┴─────────────┐
│ │
COMMON SHELL WORKSPACE
│ │
┌────────┼────────┐ ┌───────┴───────┐
│ │ │ │ │
Home My Work Personal HUMAN AI
│ │ │ WORKBENCH WORKBENCH
│ │ │ │ │
│ │ │ └───────┬───────┘
│ │ │ │
└────────┴────────┴──────────────────┤
▼
SHARED WORK
│
BUSINESS CONTEXT
│
TWIN
│
CAPABILITIES
│
GOVERNANCE
│
EXECUTE
The common shell is stable.
The Work surface is adaptive.
The AI side is first-class.
The underlying platform remains mostly invisible.
18. Platform shell
There is also an operator/admin side.
PLATFORM
│
├── Integration Manager
├── Connector Marketplace
├── Activation Hub
├── Capability Manager
├── MCP Pool
├── AI Models
├── Knowledge
├── Memory & Continuity
├── Automation
├── Pipelines
├── Governance
└── Observability
And:
ADMINISTRATION
│
├── Organizations
├── Users
├── Roles
├── Permissions
├── Audit
├── Billing
├── Deployments
├── API Keys
└── Security
These are platform/operator shells, not what every normal user experiences.
19. Marketing architecture
The marketing story should start with the workspace, not the infrastructure.
Hero
One Workspace. Shared Work. Human + AI.
SpineWorkspace brings your business work into one place, where people and AI work together over the same governed business context.
Then:
Stop switching between applications to find information, reconstruct context and move work forward.
SpineWorkspace connects the software your business already uses and brings the relevant context, work, knowledge, evidence and capabilities into one adaptive workbench.
Your Twin works alongside you—assembling context, communicating across systems and agents, preparing work and handling permitted execution—while organizational boundaries and human authority remain intact.
This is consistent with the current founder canon's experience-first direction and the older "one workspace / connected workbench" value proposition, while avoiding the outdated framing of the product itself as merely an AI workspace.
20. The marketing message hierarchy
Problem
Work is fragmented because business context is fragmented.
CRM
+ Email
+ Calendar
+ Chat
+ Documents
+ Support
+ Finance
+ Projects
+ Other SaaS
The employee becomes the integration layer.
Product
SpineWorkspace is the place where the work comes together.
Experience
One Workbench.
AI
Your Twin works with you over that same business context.
Infrastructure
IntegrateWise connects, normalizes, preserves, projects, governs and executes underneath.
Outcome
Less application switching
Less context reconstruction
Less repetitive coordination
Less duplicated work
More continuity
More visibility
More leverage
21. The customer should experience this
Instead of:
"Which app contains this?"
the user experiences:
"This is already here."
Instead of:
"Let me gather all the information before asking AI."
the user experiences:
"My Twin already understands the Work."
Instead of:
"I need to update five systems."
the user experiences:
"Prepare this for me."
Instead of:
"Did the AI actually finish it?"
the user experiences:
"The result is verified and the Workbench is updated."
That is the product.
22. What IntegrateWise is doing underneath
The infrastructure story can then be shown after the product story:
SPINEWORKSPACE
│
Experience Layer
│
Human + AI Workbench
│
Shared Work
│
Business Context
│
SPINE FABRIC
│
┌──────────────┼──────────────┐
│ │ │
Integration Intelligence Continuity
│ │ │
Ingestion Twin/Agents Memory
Discovery Capability Evidence
Activation Governance Reconciliation
│ │ │
└──────────────┼──────────────┘
│
Execution
│
Connected Applications
The infrastructure enables the experience; it does not become the experience.
23. Final terminology map
| Concept | Final meaning |
|---|---|
| IntegrateWise | Infrastructure platform/company |
| SpineWorkspace | Product/shared workspace |
| Workspace | Environment where business work happens |
| Shell | Stable navigation and product structure |
| Human Workbench | Primary human operating surface |
| AI Workbench | AI-side operating environment |
| Shared Workbench | The common work/context relationship between human and AI |
| Work | Durable human-AI coordination unit |
| Twin | Human-facing contextual AI co-worker |
| Spine Agent | Governed specialized AI worker |
| Business Context Spine | Shared organizational context/truth substrate |
| Organizational Memory | Governed durable organizational knowledge |
| Personal Contextual Memory | User-specific continuity |
| AI Continuity Memory | AI-specific working continuity |
| Projection Engine | Composes authorized human/AI context |
| Capability Fabric | Resolves how authorized work can be performed |
| MCP | One tool/resource communication mechanism |
| A2A | Agent-to-agent communication/handoff |
| REST | API communication mechanism |
| Governance | Authority boundary |
| Hermes | Approved execution coordination |
| Continuity | Intent → work → execution → verification → reconciliation → rehydration |
These definitions are directly aligned with the latest canonical vocabulary.
24. Final founder-level architecture
INTEGRATEWISE
Platform / Infrastructure
│
▼
SPINEWORKSPACE
Shared Business Workspace
│
┌────────────────┴────────────────┐
│ │
HUMAN WORKBENCH AI WORKBENCH
│ │
│ TWIN
│ │
└────────────────┬────────────────┘
│
SHARED WORK
│
BUSINESS CONTEXT SPINE
│
┌───────────────┼────────────────┐
│ │ │
Organizational Evidence Continuity
Memory
│
┌───────┴────────┐
│ │
Personal AI Continuity
Memory Memory
│ │
└───────┬────────┘
│
PROJECTION ENGINE
│
Context + Authority
│
CAPABILITY FABRIC
│
MCP / A2A / REST
│
GOVERNANCE
│
HERMES
│
EXECUTION
│
CONNECTED SYSTEMS
│
RE-INGESTION
│
VERIFY / RECONCILE
│
BACK TO THE SPINE
│
REPROJECT
│
NEXT WORK
The final message
SpineWorkspace is the shared workspace for human and AI work. It brings business context, work, knowledge, evidence and capabilities together in one adaptive workbench, while humans and AI operate within their own responsibilities, memory boundaries and authority.
The human works through the Human Workbench. The Twin and Spine Agents work through the AI Workbench. Both operate over the same governed Business Context and Work.
IntegrateWise is the infrastructure underneath—connecting systems, ingesting and normalizing information, preserving organizational continuity, projecting context, providing capabilities, enforcing governance, executing authorized work, and reconciling outcomes back into the Spine.
And the shortest expression of the entire vision:
One Workspace. Shared Work. Human + AI.
Humans govern. AI helps. Spine preserves continuity.
you asked
message time: 2026-09-04 01:50:26
EVERY PROJECTION CORRESPONDS TO TABLE TO FRONTEND AND BACKEND MAPPING AND HOW THE DIFFERENT MEMORY AND DB AND AI STORAGE AND MEDIA IS USED AND RETRIVED AND ALL
chatgpt response
Canonical Projection → Table → Frontend → Backend → Storage → Memory → Retrieval Model
This is the missing layer that connects the Spine schema to the actual SpineWorkspace UI.
The key rule from the canonical material is:
The frontend never reads a database or provider directly. Every surface is a projection delivered through the Projection Platform API. A projection can combine multiple canonical tables and storage layers; a sidebar label is never itself a database table.
So the correct relationship is:
USER
│
▼
SPINEWORKSPACE SHELL
│
▼
PROJECTION
│
├── View definition
├── Entity/table bindings
├── Fields
├── KPI definitions
├── Filters
├── Layout
├── Permissions
├── Capabilities
├── Memory scope
└── Twin context
│
▼
PROJECTION PLATFORM API
│
├── Identity
├── Tenant
├── Role
├── Department
├── Industry
├── Permissions
├── Connector availability
├── Cache
└── Data retrieval
│
▼
SPINE FABRIC
│
├── Structured truth
├── Operational state
├── Files/media
├── Conversations
├── Search/embeddings
├── Memory
└── Evidence
│
▼
FRONTEND PROJECTION
1. First: there is NOT one physical table per frontend projection
This distinction is important.
For example:
Finance
is a projection.
It may read:
accounts
invoices
payments
budgets
expenses
approvals
contracts
signals
work
documents
It does not mean:
finance_table
The canonical schema explicitly states that role, department and industry are projection dimensions, not storage partitions, and that views are filters/layouts/column configurations over the same Spine entities.
Therefore the actual contract is:
Projection
↓
Projection Binding
↓
Canonical Entity / Table Family
↓
Fields
↓
Storage layers
↓
API response
↓
Frontend component
2. The Projection Binding Registry
This should be the master object connecting everything.
ProjectionBinding
│
├── projection_id
├── view_id
├── route
├── role
├── department
├── industry
│
├── entity_types[]
├── canonical_table_families[]
├── fields[]
├── kpis[]
│
├── read_endpoint
├── write_capability
├── governance_policy
│
├── memory_scope
├── knowledge_sources
├── media_sources
├── search_collections
│
├── twin_context_definition
├── freshness_policy
├── cache_policy
│
├── connector_dependencies
├── source_systems
│
├── reconciliation_rule
└── projection_version
The repository material specifically calls for this type of registry so that the chain is traceable:
canonical entity/table family
→ operational read model
→ projection contract
→ Gateway route/service
→ policy/field visibility
→ frontend view
→ capability/action
→ invalidation/reconciliation
3. The six storage layers
The Spine is not one database.
The current canonical storage model is:
| Layer | Storage | What belongs there | Used for |
|---|---|---|---|
| 1 | Postgres / Neon or tenant operational DB according to the active Book-of-Record boundary | Structured entities, relationships, KPIs, work, governance, provenance | Canonical structured reads/writes |
| 2 | Redis / KV | Hot state, session state, invalidation, connector state | Fast projection reads |
| 3 | R2 | Files, PDFs, images, audio, video, exports, raw payloads | Media/document retrieval |
| 4 | Conversational Store | Email, chat, transcripts, conversations, long-form interaction records | Conversation retrieval and extraction |
| 5 | Vectorize / pgvector / AI Search | Embeddings and retrieval indexes | Semantic search |
| 6 | Agent Memory / Durable Objects + cognitive storage | User, Work and AI continuity state | Twin/AI continuity |
The source material explicitly describes these as separate layers and says the five additional layers beyond structured storage cannot be represented as ordinary Coda/database tables.
4. How one record exists across the layers
Consider:
Customer renewal risk
It can exist as:
Postgres
│
└── account
└── renewal_risk_level = high
Conversational Store
│
└── customer email / meeting transcript
R2
│
└── contract.pdf / QBR.pdf / recording.mp3
Vectorize
│
└── embedded chunks from those sources
source_links
│
└── links account_signal → source document/chunk
intelligence_evidence
│
└── which retrieved chunks supported the AI output
Agent Memory
│
└── Twin's active continuity around this account
These are not six copies of the same truth.
They are different representations serving different retrieval jobs.
5. Structured Spine → frontend
For structured data:
Postgres
↓
Projection Platform
↓
policy filtering
↓
field selection
↓
KPI calculation
↓
projection JSON
↓
frontend table/card/canvas
Example:
account_tasks
may provide:
Task
Owner
Status
Due date
Priority
Entity
Playbook
Approval
The frontend receives only the fields defined by that projection.
It does not receive the raw table.
6. Redis / KV → frontend
Redis/KV is not business truth.
It is used for:
hot projections
session state
connector health
invalidation
feature flags
frequently accessed counts
The canonical projection flow is:
Frontend request
↓
Projection Platform
↓
Redis/KV
│
├── HIT → return hot projection
│
└── MISS
↓
Spine read
↓
shape projection
↓
cache result
↓
frontend
This is why the frontend can feel immediate without turning the cache into the source of truth.
The documented resolution chain explicitly checks the hot session state before falling back to Spine reads.
7. R2 → media and documents
R2 is where the actual bytes live.
Examples:
PDF
DOCX
PPTX
PNG
JPG
SVG
MP3
MP4
CSV
exports
recordings
attachments
But:
Frontend
✕
R2 direct
Instead:
Frontend
↓
Projection API
↓
source_links
↓
authorized media reference
↓
signed/controlled retrieval
↓
R2
The source-link layer is important because the Workbench should show:
display label
thumbnail
preview
source type
source page
timestamp
deep link
rather than exposing raw storage keys.
8. Conversational Store → conversation retrieval
This handles information such as:
Email
Chat
Meeting transcript
Call transcript
Customer conversation
Portal submission
AI conversation
Flow:
Source
↓
Conversational Store
↓
chunk / parse
↓
entity extraction
↓
action extraction
↓
signal detection
↓
Spine promotion
Example:
Customer says in meeting:
"We are evaluating another platform."
↓
meeting transcript
↓
chunk
↓
signal
↓
account risk
↓
source_links
↓
Postgres structured signal
The original conversation remains retrievable.
9. Vectorize / AI Search → semantic retrieval
Vector storage does not replace the source document.
It answers:
"Which pieces of information are semantically relevant to this question?"
Example:
User clicks Account
↓
Twin asks:
"What changed recently?"
↓
semantic query
↓
Vector Search
↓
top K chunks
↓
source_links
↓
original document
The evidence chain records:
chunk_id
similarity_score
BM25 score
RRF score
source_link_id
so the AI result can be traced back to the actual source.
10. Agent / AI Memory
AI memory is different again.
The source material identifies:
User Memory
Work Memory
Org Memory
and separately describes agent/Twin continuity.
The critical rule is:
AI memory
≠
organizational truth
AI can remember:
User preference
Current working context
Previous Twin interaction
Active account
Current work
Reasoning continuity
Learned pattern
But an AI observation that should become organizational knowledge goes through:
AI observation
↓
Triage
↓
proposal
↓
governance / HITL
↓
promotion
↓
organizational memory
The source material explicitly requires HITL for AI-originated writes and preservation of provenance such as origin, confidence and approval.
11. Personal Memory
Personal memory is strictly scoped.
USER
│
└── Personal Memory
├── preferences
├── private notes
├── personal context
├── personal filters
└── private continuity
It can be used when assembling that user's context.
It does not automatically become:
Team memory
Organization memory
Another user's context
The canonical memory boundary explicitly says personal memory can only be cited by the user who owns it.
12. Organizational Memory
Organizational memory is the opposite:
TENANT
│
▼
ORGANIZATIONAL MEMORY
│
├── accepted facts
├── decisions
├── policies
├── learnings
├── patterns
├── commitments
└── institutional knowledge
It is created through governed promotion.
Raw information
↓
Interpretation
↓
Triage
↓
Candidate memory
↓
Approval where required
↓
Organizational memory
This prevents:
"The AI said it"
from becoming:
"The company knows it."
13. Evidence is another cross-cutting layer
Every meaningful AI-derived result needs to answer:
Where did this come from?
That is the purpose of:
source_links
and:
intelligence_evidence
The chain becomes:
SOURCE
│
├── email
├── meeting
├── PDF
├── image
├── recording
├── chat
└── document
│
▼
SOURCE_LINK
│
▼
EMBEDDED CHUNK
│
▼
RETRIEVAL
│
▼
INTELLIGENCE_EVIDENCE
│
▼
AI OUTPUT
│
▼
WORKBENCH
That means the Twin can say:
This risk was detected because:
• customer email
• QBR document
• support conversation
rather than producing an unsupported statement.
14. Now map this to the frontend
Common shell
These are not domain-specific projections.
Home
Frontend
↓
home projection
↓
events
+ work
+ approvals
+ notifications
+ calendar
+ recent activity
+ personal context
My Work
Frontend
↓
work projection
↓
work_items
+ assignments
+ approvals
+ deadlines
+ commitments
+ calendar
Inbox
Frontend
↓
inbox projection
↓
email
+ chat
+ notifications
+ mentions
+ CRM activity
+ tickets
+ approvals
+ workflow events
The Inbox therefore isn't an email table.
It is a cross-source operational projection.
Tasks
Frontend
↓
task projection
↓
work_items
+ tasks
+ dependencies
+ assignments
+ SLA
My Queue
Frontend
↓
queue projection
↓
work
+ approvals
+ handoffs
+ automation steps
+ priority policy
Approvals
Frontend
↓
approval projection
↓
approvals
+ memory proposals
+ governance
+ evidence
Notifications
Frontend
↓
notification projection
↓
notifications
+ connector events
+ workflow events
+ security events
+ Twin events
The complete common shell is server-composed and filtered by identity, permissions, entitlement and freshness.
15. Communications mapping
Activity Feed
spine_events
+ timeline
+ connector events
+ work events
+ execution events
+ human activity
+ AI activity
email_threads
+ messages
+ linked entities
+ extracted actions
+ source_links
+ Twin context
Calendar
calendar_events
+ participants
+ linked entities
+ work
+ meetings
Meetings
meeting records
+ transcripts
+ decisions
+ tasks
+ commitments
+ source_links
+ memory candidates
Chat
chat_threads
+ messages
+ entities
+ actions
+ context
Calls
call_records
+ transcript
+ recording
+ entities
+ actions
+ sentiment
Documents Shared
document metadata
+ R2 object
+ source_links
+ embeddings
+ extracted entities
+ knowledge
The canonical shell specifically defines Communications as the place where information enters, leaves and becomes operational evidence.
16. Personal mapping
Notes
Personal projection
↓
user-scoped notes
↓
structured note metadata
+
R2 if attachment
+
Vector search if indexed
Knowledge Base
Knowledge projection
↓
knowledge entities
+
documents
+
embeddings
+
source links
Brainstorming Sessions
conversation/session
↓
brainstorm record
↓
entities
decisions
learnings
commitments
↓
candidate memory
↓
triage
↓
promotion
The source material explicitly describes brainstorming as capable of becoming user, organizational or agent memory depending on governed classification/promotion.
Activity
spine_events
WHERE actor_id = current_user
This is user-scoped memory/activity, not a new operational truth table.
17. Work projections
This is where the domain-specific projections enter.
The currently registered projection family contains:
founder
sales
cs
marketing
finance
operations
product
engineering
account-success
technical-account-success
business-intelligence
campaigns
knowledge-management
revops
support
brandstore
book-of-records
ops
The repository has enriched these projection manifests with real donor view inventories rather than treating each domain as an independent application.
Each one is:
same Spine
+
different entity emphasis
+
different fields
+
different KPIs
+
different views
+
different capabilities
+
different permissions
+
different Twin context
18. Example: Sales projection
SALES WORKBENCH
│
▼
Projection: sales
│
├── Accounts
├── Contacts
├── Leads
├── Opportunities
├── Discovery
├── Proposals
├── Forecast
└── Handoffs
Backend:
sales projection
↓
accounts
contacts
leads
opportunities
activities
work_items
signals
communications
knowledge
Frontend:
Dashboard
Pipeline
Accounts
Leads
Opportunities
Forecast
Activities
Handoffs
Twin context when clicking an opportunity:
opportunity
+
account
+
contact
+
recent communications
+
open work
+
signals
+
relevant documents
+
semantic retrieval
+
authorized memory
Not:
generic AI chat
19. Example: Finance projection
FINANCE
│
├── Invoices
├── Payments
├── Expenses
├── Budgets
├── Cash
├── Forecast
├── Vendors
└── Approvals
Possible underlying structured sources:
billing records
invoice entities
payment entities
expense entities
budget entities
approval records
work items
contracts
Additional storage:
R2
→ invoice PDFs
→ contracts
→ financial reports
Conversational Store
→ finance emails
→ approval conversations
Vector Search
→ contracts
→ policies
→ financial documents
Memory
→ approved financial operating knowledge
Frontend:
Invoice Queue
Payment Calendar
Budget vs Actual
Vendor Contracts
Approval Queue
These are views over the same underlying data, not five databases. The Finance Manager example in the schema documentation illustrates exactly this pattern.
20. Example: Customer Success
CUSTOMER SUCCESS
│
├── Accounts
├── Health
├── Success Plans
├── Adoption
├── Cases
├── Renewals
├── QBRs
└── Commitments
Structured:
accounts
account_contacts
account_health_logs
account_success_plans
account_tasks
account_signals
account_initiatives
Documents:
QBR deck
contract
customer report
meeting recording
Conversation:
emails
meetings
calls
support conversations
Search:
account-related embeddings
knowledge
similar cases
customer history
Twin:
click account
↓
assemble account context
↓
retrieve evidence
↓
show health explanation
↓
show relevant work
↓
propose next action
The Account Intelligence schema explicitly maps these layers and links health signals and Twin reasoning back to evidence.
21. Canvas is also a projection
This is important for the Coda/Notion/UI Bakery style you described.
A canvas does not create a new database.
CANVAS
│
├── Section A → entity fields
├── Section B → related entities
├── Section C → table
├── Section D → knowledge
├── Section E → documents
├── Section F → signals
├── Section G → work
└── Section H → Twin context
So:
Canvas
↓
Projection API
↓
multiple Spine entities/tables
↓
multiple storage layers
↓
assembled page
This is why a record can contain:
structured fields
+
related table
+
document
+
image
+
timeline
+
knowledge
+
signal
+
Twin
without duplicating the underlying data.
22. The Twin retrieval sequence
When a user clicks an object:
USER CLICKS ENTITY
↓
IDENTIFY
entity_id
tenant_id
user_id
projection
↓
AUTHORIZE
↓
LOAD STRUCTURED ENTITY
↓
LOAD RELATED ENTITIES
↓
LOAD ACTIVE WORK
↓
LOAD RELEVANT MEMORY
↓
LOAD KNOWLEDGE
↓
SEMANTIC SEARCH
↓
LOAD SOURCE LINKS
↓
LOAD EVIDENCE
↓
ASSEMBLE ACTIVE CONTEXT
↓
TWIN
The result is:
ActiveContextBundle
containing the authorized information needed for that particular piece of Work.
23. Twin context is therefore assembled, not stored as one giant blob
TWIN CONTEXT
│
┌─────────────────┼─────────────────┐
│ │ │
Structured Documents Memory
│ │ │
Postgres R2 User/AI/Org
│ │ │
├──────────┐ │ ┌──────────┤
│ │ │ │ │
Work/Entity Signals Search Evidence Conversation
│ │ │ │ │
└──────────┴──────┴──────┴──────────┘
│
▼
ACTIVE CONTEXT
│
▼
TWIN
This is the correct implementation of the idea:
Twin is not another database. Twin is cognition operating over assembled, governed context.
24. Write path
The reverse path is equally important.
Human edit
Frontend
↓
Projection API
↓
Governance / authorization
↓
governed writer
↓
structured Spine
↓
outbox/event
↓
cache invalidation
↓
source write-back if required
↓
reconciliation
↓
projection refresh
Twin proposal
Twin
↓
proposal
↓
Governance
↓
approval if required
↓
governed writer
↓
Spine
↓
source_links / evidence
↓
outbox
↓
source system
↓
receipt
↓
re-ingestion
↓
reconciliation
↓
updated projection
The canonical material explicitly says the browser, Twin, connectors, public MCP, normalizer, Triage and Projection Engine do not directly write canonical storage; canonical promotion is through governed writers.
25. Connector hydration
A connector doesn't simply create a separate mini-application.
It changes what the Spine can represent.
CONNECTOR INSTALLED
↓
Connector category
↓
Schema Module
↓
Field/entity capability
↓
Ingestion mapping
↓
Spine hydration
↓
Search/index updates
↓
Projection recalculation
↓
New columns / records / signals
↓
Twin context expands
The connector schema material explicitly says connector installation can affect all six Spine layers and that views, signal categories, health calculations and Twin context adapt accordingly.
26. The complete frontend/backend/storage contract
This is the final mapping I would put into the architecture document:
┌──────────────────────────────────────────────────────────────┐
│ FRONTEND │
│ │
│ Shell → Surface → View → Table/Card/Canvas/Twin │
└───────────────────────────┬──────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ PROJECTION PLATFORM API │
│ │
│ Identity → Tenant → Role → Department → Industry │
│ Permissions → Connector availability → Projection manifest │
│ Cache → Query → Shape → Capability → Response │
└───────────────────────────┬──────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ SPINE FABRIC │
│ │
│ Structured │ Operational │ Knowledge │ Memory │ Evidence │
└───────┬────────┬─────────┬──────────┬─────────┬─────────────┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
SQL DB KV/D1 R2 Conversation Vector
Store Search
│ │ │ │ │
└────────┴─────────┴──────────┴─────────┘
│
▼
CONTEXT ASSEMBLY
│
┌───────────┴───────────┐
│ │
HUMAN WORKBENCH AI WORKBENCH
│ │
└───────────┬───────────┘
│
TWIN
│
CAPABILITY FABRIC
│
GOVERNANCE
│
HERMES
│
SOURCE SYSTEMS
│
RE-INGEST / VERIFY
│
RECONCILIATION
│
SPINE
27. The most important final rule
Every visible thing in SpineWorkspace should be traceable.
Frontend
↓
Projection
↓
View
↓
Entity
↓
Field
↓
Canonical table
↓
Storage layer
↓
Source
And for AI:
Frontend
↓
Twin
↓
Context
↓
Memory / Search / Evidence
↓
Source
And for execution:
Frontend / Twin
↓
Intent
↓
Capability
↓
Governance
↓
Execution
↓
Source system
↓
Receipt
↓
Re-ingestion
↓
Reconciliation
↓
Spine
↓
Projection refresh
That gives you the complete spine-to-UI contract:
The table is not the projection. The projection defines how canonical entities and their supporting storage layers become a frontend experience. The backend assembles and authorizes it. Structured storage holds structured truth; R2 holds media; the conversational store holds long-form interaction data; vector search retrieves meaning; memory preserves scoped continuity; evidence connects intelligence back to sources; and the frontend receives only the resulting authorized projection.
This is the level of mapping needed so that every Workbench table, page, dashboard, board, calendar, canvas, communication surface and Twin interaction can be traced all the way down to the underlying Spine and all the way back to the original source.
you asked
message time: 2026-09-04 01:51:45
NOW ADD CONNECTOR FLOW AND INGESTION AND THE PIPELINE AND GTM FLOW, OR GO LIVE FLOW
chatgpt response
Final Integrated Flow: Connector → Ingestion → Spine → Projection → Workbench → AI → GTM → Go-Live
The connector flow should now be added before the projection/storage flow, because connectors are what progressively turn a blank tenant into a useful, continuously operating SpineWorkspace.
The complete model is:
MARKET / GTM
↓
ENTRY / ACTIVATION
↓
IDENTITY + TENANT + WORKSPACE
↓
CONNECTOR DISCOVERY
↓
CONSENT + CONNECTION
↓
CONNECTOR DISCOVERY
↓
CATEGORY + MAPPING + CAPABILITY ACTIVATION
↓
INGESTION PIPELINE
↓
SPINE HYDRATION
↓
MEMORY / KNOWLEDGE / EVIDENCE
↓
PROJECTION ENGINE
↓
HUMAN WORKBENCH
↕
AI WORKBENCH / TWIN
↓
WORK
↓
CAPABILITY
↓
GOVERNANCE
↓
EXECUTION
↓
SOURCE SYSTEM
↓
SYNC / RE-INGESTION
↓
RECONCILIATION
↓
SPINE
↓
WORKBENCH REHYDRATION
↓
CONTINUOUS VALUE
↓
EXPANSION / RETENTION
The architecture documents distinguish Flow D as the prerequisite activation/control path and Flows A, B and C as the actual data/cognitive paths.
1. GTM → Customer Entry
There are three marketplace/distribution surfaces, but they have different jobs.
| Entry | Purpose | What happens |
|---|---|---|
| Plugin Marketplace | External acquisition + embedded activation | User installs the IntegrateWise Spine Network Plugin |
| MCP Marketplace | External acquisition + tool-first activation | MCP client connects to IntegrateWise |
| Connector Marketplace | In-product activation + expansion | Existing workspace connects another business system |
| Direct Workbench | Direct acquisition | User starts IntegrateWise directly |
The important distinction is:
Plugin and MCP Marketplace bring the customer into IntegrateWise. Connector Marketplace expands the customer's connected operating environment.
2. GTM → Workspace Activation
The customer journey becomes:
CATEGORY / DEMAND
↓
Plugin / MCP / Direct Workbench
↓
IDENTITY
↓
ORGANIZATION
↓
TENANT
↓
WORKSPACE
↓
GOALS + ROLE + RESPONSIBILITY
↓
CONNECT REALITY
↓
DISCOVER
↓
CONFIGURE
↓
ACTIVATE
The founder canon explicitly defines onboarding as:
Identity
→ Organization / Role / Responsibility
→ Goals and Operating Context
→ Connect Reality
→ Discovery
→ Configuration
→ Activation
→ Initial Hydration
→ Business Context Spine
→ Personal Contextual Memory Initialization
→ AI Continuity / Twin Activation
→ Capability Activation
→ Projection
→ SpineWorkspace
So onboarding is not account creation.
It is:
Blank tenant → connected operational environment → useful workspace.
3. Connector Marketplace
Once the workspace exists:
CONNECTOR MARKETPLACE
↓
Select Salesforce / Slack / Gmail / GitHub / Zendesk / etc.
↓
CONNECT
↓
OAuth / API / MCP / approved transport
↓
CONSENT
↓
SCOPES
↓
TENANT BINDING
↓
CONNECTION READY
The connector does not immediately dump provider data into the Spine.
It first establishes the connector contract.
4. Connector Discovery
The connector then discovers:
Provider
│
├── Objects
├── Fields
├── Types
├── Constraints
├── Events
├── Webhooks
├── Read operations
├── Write operations
├── MCP tools
├── MCP resources
├── Pagination
├── Cursors
├── Rate limits
├── Account scope
└── Region / environment
Discovery produces provider metadata.
It does not yet change canonical business truth.
5. Connector Category Resolution
The provider is then classified.
Salesforce
HubSpot
Dynamics
↓
CRM
Zendesk
Freshdesk
↓
Support
Gmail
Slack
↓
Communication
Stripe
NetSuite
↓
Finance / Billing
GitHub
Linear
↓
Project / Engineering
The crucial rule:
Provider name identifies the source. Category determines the canonical contract.
So Salesforce and HubSpot can populate the same canonical CRM structures.
6. Connector → Capability Activation
The category then activates the relevant platform behavior.
CATEGORY
↓
SEMANTIC / DOMAIN EXTENSION BUNDLE
↓
CANONICAL ENTITIES
↓
FIELDS
↓
RELATIONSHIPS
↓
DOCUMENT TYPES
↓
SIGNAL TYPES
↓
HEALTH METRICS
↓
CAPABILITIES
↓
PROJECTION HINTS
The current architecture replaces the older physical "Module Activator" concept with Semantic and Domain Extension Bundles.
Activation is idempotent and versioned.
7. Connector → Mapping
Now provider fields are mapped into the canonical model.
Provider object
↓
Canonical entity
↓
Canonical field
↓
Transformation
↓
Type conversion
↓
Unit / enum conversion
↓
Source binding
↓
Source priority
↓
Read / write direction
↓
Conflict policy
For example:
Salesforce Account
↓
Canonical Account
HubSpot Company
↓
Canonical Account
Zendesk Ticket
↓
Canonical Work / Support Ticket
Slack Message
↓
Conversation / Communication
Google Calendar Event
↓
Meeting / Event
Unmapped provider fields are routed for mapping review rather than silently becoming arbitrary Spine schema.
8. Connector → Flow Activation
Now the connector determines which ingestion routes are armed.
CONNECTOR
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
FLOW A FLOW B FLOW C
Structured Documents AI /
Operations Comms Cognitive
│ │ │
└────────────┼────────────┘
│
▼
FLOW D
Platform / activation
Flow A
Structured operational data.
CRM
ERP
Billing
Support
HR
Project
Telemetry
Flow B
Unstructured operational information.
Email
Chat
Documents
Attachments
Calls
Meeting transcripts
Flow C
AI/cognitive information.
Twin observations
Agent work
Interpretations
Signals
Proposals
Continuity candidates
Flow D
Connector/control state.
Identity
Consent
Connection
Mapping
Sync
Health
Capability
Policy
Flow D binds the connector to the tenant; it does not itself absorb business records.
9. The Ingestion Pipeline
This is the central data movement system.
Structured
PROVIDER
↓
TENANT GATE
↓
LOADER
↓
FLOW ROUTER
↓
NORMALIZER
↓
VALIDATOR
↓
DEDUP / RELATIONSHIP RESOLUTION
↓
GOVERNED SPINE WRITER
↓
SPINE
The current Loader Runtime performs bootstrap and continuous hydration through this boundary.
10. Document / Communication Pipeline
For Flow B:
SOURCE
↓
INGEST
↓
PARSE
↓
CLASSIFY
↓
EXTRACT
↓
ENRICH
↓
ROUTE
↓
GOVERN
↓
PROMOTE
The documented 8-stage pipeline is:
Ingest → Parse → Classify → Extract → Enrich → Route → Govern → Promote.
This means an email, PDF, meeting transcript or attachment does not simply become a Postgres record.
11. Media / Document Storage During Ingestion
The media path is:
Document / Attachment / Recording
↓
R2
│
├── original artifact
├── metadata
└── retrieval reference
↓
Parsing
↓
Chunks
↓
Embeddings
↓
Vector Search
↓
Source Links
So:
R2
= artifact bytes
Conversational Store
= long-form communications
Vector
= semantic retrieval representation
Spine
= governed canonical representation / relationships
source_links
= relationship between the representation and source
This preserves the distinction between source material and derived representations.
12. Creamy Initial Hydration
The first sync is deliberately different from ongoing synchronization.
CONNECTION READY
↓
CREAMY LOAD
↓
INITIAL ENTITY / DOCUMENT INGESTION
↓
CANONICALIZATION
↓
RELATIONSHIP BUILDING
↓
INITIAL INDEXING
↓
INITIAL PROJECTIONS
↓
WORKSPACE READY
The documented onboarding implementation invokes the real loader for Creamy hydration, rather than fabricating a job or simply seeding frontend data.
The goal is:
The first time the user opens the workspace, it already contains useful business context.
13. Then Breadth Hydration
Creamy does not mean "everything."
The next stage expands coverage.
CREAMY
↓
Core useful entities
↓
BREADTH
↓
More entities / documents / relationships
↓
FULL CONTINUOUS SYNC
This avoids delaying first value while still allowing the Spine to become comprehensive over time.
The architecture describes this as:
creamy-layer initial hydration → breadth hydration → full ongoing continuity.
14. Continuous Sync
After initial hydration:
WEBHOOK
│
POLL
│
SCHEDULE
│
DELTA
│
BATCH
│
STREAM
│
▼
INGESTION
↓
NORMALIZATION
↓
SPINE UPDATE
Then:
Redis invalidation
↓
Vector re-embedding
↓
Projection refresh
↓
Twin context refresh
The older detailed connector algorithm explicitly describes Redis invalidation, vector re-embedding and view rebuilding as downstream effects of connector activation.
15. Connector Activation Changes the Entire Workspace
This is the important Capability Fabric behavior.
Adding:
Zendesk
does not merely add:
Zendesk connector
It can cause:
Support fields
+
Support signals
+
Support score
+
Document types
+
Pipeline rules
+
Vector collections
+
Twin context
+
Workbench columns
+
Capabilities
to become available.
The connector therefore expands the operating model, not merely the integration list.
The documented Fabric model describes this as classification → schema/domain activation → signal propagation → intelligence recalibration → governance.
16. Spine Hydration
The end result is:
CONNECTED ECOSYSTEM
│
┌─────────────┼─────────────┐
│ │ │
Structured Documents Cognitive
│ │ │
▼ ▼ ▼
Flow A Flow B Flow C
│ │ │
└─────────────┼─────────────┘
▼
GOVERNED
SPINE STATE
The Spine now contains the organization's connected operational context.
17. Projection Generation
Then:
SPINE
↓
PROJECTION ENGINE
↓
Role
× Department
× Industry
× Permissions
× Connected capabilities
× Current Work
↓
WORKBENCH COMPOSITION
So a connector changes what can be projected.
Example:
No Support connector
↓
No support-specific operational projection
Zendesk connected
↓
Support context becomes available
Zendesk + CRM
↓
Customer + Support relationship
Zendesk + CRM + Product telemetry
↓
Customer + Support + Usage context
18. Human Workbench
The user sees:
HOME
MY WORK
INBOX
TASKS
QUEUE
APPROVALS
COMMUNICATIONS
WORK
PERSONAL
and inside Work:
TABLE
DETAIL
BOARD
DASHBOARD
CANVAS
TIMELINE
FEED
CALENDAR
These are projections, not independent databases.
19. AI Workbench
At the same time:
ACTIVE WORK
↓
CONTEXT ASSEMBLY
↓
┌──────────┼──────────┐
│ │ │
Business Memory Evidence
Context /Search
│ │ │
└──────────┼──────────┘
↓
TWIN
The Twin receives the context relevant to the current Work.
20. Memory Activation
Connector data can feed multiple memory/retrieval paths.
SPINE
│
┌──────────────┼──────────────┐
│ │ │
Organizational Personal AI
Memory Memory Continuity
│ │ │
│ │ │
└──────────────┼──────────────┘
│
Context Assembly
│
▼
TWIN
But the boundaries remain strict:
Personal Memory
→ user scope
AI Continuity
→ AI scope
Organizational Memory
→ governed organizational scope
AI-generated information does not automatically become organizational truth.
21. Work → Twin → Capability
Now the customer actually uses the system.
USER
↓
WORK
↓
TWIN
↓
UNDERSTAND
↓
PROPOSE
↓
CAPABILITY DISCOVERY
↓
CAPABILITY RESOLUTION
↓
GOVERNANCE
Possible capability paths:
MCP
REST
API
Tool → Tool
Agent → Agent
Workflow
Local execution
AI execution
The capability fabric determines how the approved work can be performed.
22. Governance → Execution
TWIN PROPOSAL
↓
GOVERNANCE
↓
┌─────┼────────┐
│ │ │
ALLOW DENY APPROVAL
│
▼
HUMAN APPROVES
│
▼
HERMES
│
▼
PROVIDER ACTION
The system must never treat:
AI said it succeeded
as:
business truth
23. Source-System Writeback
After execution:
Hermes
↓
Provider
↓
External system
↓
Provider outcome
↓
Receipt
Then the system re-enters the ingestion path.
PROVIDER OUTCOME
↓
RE-INGEST
↓
VERIFY
↓
RECONCILE
↓
CANONICAL SPINE UPDATE
The current architecture explicitly defines the end-to-end loop as external event → normalization → Spine → projection → Twin → human decision → capability execution → provider acceptance → reconciliation → verified Spine update.
24. Projection Rehydration
Only after reconciliation:
VERIFIED SPINE STATE
↓
CACHE INVALIDATION
↓
VECTOR / SEARCH UPDATE
↓
PROJECTION REBUILD
↓
WORKBENCH REFRESH
↓
TWIN CONTEXT REFRESH
The user therefore sees the actual reconciled state.
Not:
"Saved"
while the provider is still pending.
The documented stop-ship rule is to show Pending Sync until reconciliation confirms the result.
25. Now the Complete Customer Lifecycle
This is the final combined flow:
MARKET
│
┌──────────────┼──────────────┐
│ │ │
Plugin MCP Direct
Marketplace Marketplace Workbench
│ │ │
└──────────────┼──────────────┘
▼
IDENTITY / TENANT
│
▼
WORKSPACE
│
▼
GOALS / ROLE
│
▼
CONNECTOR MARKETPLACE
│
▼
CONNECT SYSTEM
│
▼
CONSENT
│
▼
DISCOVERY
│
▼
CATEGORY RESOLUTION
│
▼
MAPPING / CAPABILITIES
│
▼
FLOW ACTIVATION
│
┌─────────────┼─────────────┐
│ │ │
FLOW A FLOW B FLOW C
Structured Documents AI/Cognitive
│ │ │
└─────────────┼─────────────┘
▼
LOADER / PIPELINE
│
▼
CREAMY HYDRATION
│
▼
BREADTH HYDRATION
│
▼
BUSINESS CONTEXT SPINE
│
┌─────────────┼─────────────┐
│ │ │
Evidence Memory Search
│ │ │
└─────────────┼─────────────┘
▼
PROJECTION ENGINE
│
┌────────────┴────────────┐
│ │
HUMAN WORKBENCH AI WORKBENCH
│ │
└────────────┬────────────┘
▼
WORK
│
HUMAN ↔ TWIN
│
▼
CAPABILITY FABRIC
│
▼
GOVERNANCE
│
▼
HERMES
│
▼
SOURCE SYSTEM
│
▼
RE-INGESTION
│
▼
VERIFY
│
▼
RECONCILIATION
│
▼
VERIFIED SPINE
│
▼
PROJECTION REFRESH
│
▼
HUMAN + AI REHYDRATE
│
▼
NEXT WORK
│
└──────────────►
CONTINUITY
26. GTM and Product Become One Flywheel
The GTM loop then becomes:
DISCOVER
↓
ACTIVATE
↓
CONNECT
↓
HYDRATE
↓
SEE VALUE
↓
WORK
↓
APPROVE
↓
OUTCOME
↓
RECONCILE
↓
MORE CONTEXT
↓
MORE CAPABILITIES
↓
MORE CONNECTORS
↓
MORE WORK
↓
RECURRING VALUE
The canonical GTM metric is therefore:
Time to first approved governed outcome
rather than:
number of connectors installed.
The GTM evidence model explicitly progresses from listing/install/activation to first grounded value, first approved proposal, first reconciled execution, and then expansion.
27. Go-Live is a separate promotion flow
GTM activation should not be confused with production release.
The product/customer flow is:
Customer
→ Connect
→ Hydrate
→ Work
→ Outcome
The engineering release flow is:
DEVELOPMENT
↓
CI / CONTRACT TESTS
↓
DEVELOPMENT ARTIFACTS
↓
CUSTOMER ZERO
↓
CUSTOMER ZERO EVIDENCE
↓
VERSION FREEZE
↓
CLEAN EXTERNAL TENANT
↓
PLUGIN / MCP SUBMISSION READY
↓
PUBLIC PUBLICATION
That is the frozen go-live sequence.
28. Five Go-Live Phases
Phase 1 — Shared Contracts
Freeze:
Public tools
Resources
UI intents
Discovery envelope
Tenant binding
Activation profiles
Phase 2 — Customer Zero Plugin
Prove:
Identity
Embedded UI
Host composition
Delegation
Proposal
Approval
Execution
Reconciliation
Phase 3 — Customer Zero MCP + Workbench
Prove:
OAuth
19 tools
Browser launch
Ordinary-client fallback
Discovery
RBAC projections
Phase 4 — Externalization
Install the same artifacts into a clean tenant.
Prove:
Dynamic tenant resolution
Customer-owned connections
Isolation
Hydration
Workbench
Phase 5 — Publication
Then:
Version freeze
Plugin publication
MCP publication
New-tenant installation
Monitoring
Rollback
Revocation
Deprecation
These five phases are explicitly defined in the current go-live doctrine.
29. The final distinction: three flows
You now have three different flows that should appear together in the final architecture.
A. Customer Activation Flow
Market
→ Identity
→ Workspace
→ Connector
→ Consent
→ Discovery
→ Hydration
→ Spine
→ Projection
→ Workbench
B. Continuity / Work Flow
Source
→ Spine
→ Projection
→ Human
→ Twin
→ Work
→ Capability
→ Governance
→ Hermes
→ Source
→ Reconciliation
→ Spine
→ Workbench
C. GTM / Go-Live Flow
Development
→ Customer Zero
→ Evidence
→ Version Freeze
→ Clean Tenant
→ Plugin/MCP Ready
→ Publication
→ New Customer
→ Activation
→ First Governed Outcome
→ Expansion
30. One unified final picture
┌───────────────────────────┐
│ GO-TO-MARKET │
│ Plugin · MCP · Direct │
└─────────────┬─────────────┘
│
▼
┌─────────────────────┐
│ CUSTOMER ACTIVATION │
│ Identity · Tenant │
│ Workspace · Goals │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ CONNECTOR MARKETPLACE│
└──────────┬──────────┘
│
▼
┌─────────────────────────────┐
│ CONNECTION + DISCOVERY │
│ Consent · Schema · Events │
│ Capabilities · Mapping │
└──────────────┬──────────────┘
│
▼
┌─────────────────────┐
│ INGESTION PIPELINE │
│ A · B · C · D │
└──────────┬──────────┘
│
┌──────────┴──────────┐
▼ ▼
CREAMY LOAD CONTINUOUS SYNC
│ │
└──────────┬──────────┘
▼
┌──────────────────┐
│ SPINE FABRIC │
│ Truth · Evidence │
│ Memory · Search │
└────────┬─────────┘
│
┌──────┴──────┐
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
└──────┬──────┘
▼
WORK
│
HUMAN ↔ TWIN
│
▼
CAPABILITY FABRIC
│
▼
GOVERNANCE
│
▼
HERMES
│
▼
SOURCE SYSTEMS
│
▼
RE-INGEST / VERIFY
│
▼
RECONCILIATION
│
▼
VERIFIED SPINE
│
▼
RE-PROJECTION
│
▼
HUMAN + AI CONTINUITY
│
▼
NEXT WORK
│
└──────────────►
│
MORE VALUE
│
MORE USAGE
│
MORE CONNECTORS
│
└──────► GTM EXPANSION
Final product/GTM sentence
IntegrateWise brings a customer's existing systems into one connected operational environment, turns that environment into a living Business Context Spine, projects the right work into each person's Workbench, gives the Twin and AI the same governed working context, enables approved capabilities to act across connected systems, and continuously reconciles the results back into the Spine—so every new connection and every completed piece of Work makes the workspace more useful.
That is the complete Connector → Ingestion → Pipeline → Spine → Projection → Human/AI Workbench → Execution → Reconciliation → GTM/Expansion → Go-Live story, with the marketplace and release paths kept distinct.
you asked
message time: 2026-09-04 01:53:59
END TO END WRITEUP
chatgpt response
SpineWorkspace — End-to-End Product, Platform, Connector, Ingestion, Memory, AI, Work, GTM and Go-Live Writeup
Canonical product: SpineWorkspace
Infrastructure platform: IntegrateWise
Operating doctrine: Humans govern. AI helps. Spine preserves continuity.
The 31 August Founder Canon defines SpineWorkspace as the product and daily working environment, while IntegrateWise is the infrastructure underneath it. The product has a primary Human Workbench, a first-class AI Workbench, shared Business Context, separate human and AI continuity, durable Work, governed capabilities, and a closed execution/reconciliation loop.
1. What SpineWorkspace Is
SpineWorkspace is a self-organizing shared workspace where humans and AI work from the same governed business context.
It brings together:
- the organization's connected systems;
- structured business data;
- communications;
- documents and media;
- knowledge;
- evidence;
- organizational memory;
- personal contextual memory;
- AI continuity;
- Work;
- capabilities;
- approvals;
- Twin interactions;
- Spine Agents;
- execution;
- verification;
- reconciliation.
The user does not move between applications to reconstruct the business context.
Instead:
SPINEWORKSPACE
│
┌───────────┴───────────┐
│ │
HUMAN WORKBENCH AI WORKBENCH
│ │
│ │
└───────────┬───────────┘
│
SHARED BUSINESS
CONTEXT SPINE
│
┌─────────────┼─────────────┐
│ │ │
Connected Memory Evidence
Systems Knowledge & Search
│ │ │
└─────────────┼─────────────┘
│
WORK
│
HUMAN ↔ TWIN
│
CAPABILITY FABRIC
│
GOVERNANCE
│
HERMES
│
SOURCE SYSTEM
│
VERIFY / RECONCILE
│
▼
SPINE REHYDRATES
The result is not another dashboard or another AI chatbot.
It is the operating environment for human and AI work.
2. The Three-Level Product Architecture
The system has three distinct levels.
| Level | Meaning |
|---|---|
| SpineWorkspace | Product and daily working experience |
| Spine Context & Continuity System | Shared Business Context Spine + Personal Contextual Memory + AI Continuity Memory |
| IntegrateWise Platform | Connectivity, ingestion, intelligence, projection, capability, governance, execution and continuity infrastructure |
The Founder Canon explicitly establishes this separation.
So:
SPINEWORKSPACE
↓
the customer experience
SPINE CONTEXT & CONTINUITY
↓
the shared context and continuity substrate
INTEGRATEWISE
↓
the infrastructure that makes it work
3. The Customer Starts With a Blank Organization
A new customer does not manually build a database.
The lifecycle begins with:
Identity
↓
Organization
↓
Role / Responsibility
↓
Goals / Operating Context
↓
Connect Reality
↓
Discovery
↓
Configuration
↓
Activation
↓
Initial Hydration
↓
Business Context Spine
↓
Personal Contextual Memory
↓
AI Continuity
↓
Capability Activation
↓
Projection
↓
SpineWorkspace
The onboarding doctrine specifically defines this transition from blank state to useful work. The first useful workspace should already contain real context from connected systems, relevant Work, readiness information and a functioning Twin rather than an empty shell.
4. GTM: How the Customer Enters
GTM begins outside the workspace.
There are multiple distribution surfaces, but they have different roles.
External acquisition
Plugin Marketplace
Brings IntegrateWise into a compatible host through the IW-Spine-Network Plugin.
MCP Marketplace
Makes the IW-Spine-Network MCP available to MCP clients.
Direct Workbench
Customer enters directly through the SpineWorkspace experience.
Internal expansion
Connector Marketplace
This exists inside the product.
It expands the customer's connected ecosystem after the workspace exists.
Therefore:
Plugin Marketplace ──┐
MCP Marketplace ─────┼──► CUSTOMER ENTRY
Direct Workbench ────┘
│
▼
SPINEWORKSPACE
│
▼
CONNECTOR MARKETPLACE
│
▼
MORE BUSINESS CONTEXT
The locked GTM model distinguishes external distribution from in-product connector activation.
5. GTM Wedge → General Platform
The product itself is horizontal.
A GTM wedge can target a specific function without turning the architecture into a function-specific application.
For example:
PRODUCT
SpineWorkspace
↓
GTM WEDGE
Customer Success
↓
BUYER
Head / VP Customer Success
↓
FIRST USE
Account Success Workbench
↓
EXPANSION
Sales
Marketing
Finance
Operations
Engineering
Support
Founder
The important architectural rule is:
Role specificity is runtime composition, not marketplace packaging.
The same SpineWorkspace can compose different work environments based on role, responsibility, department, industry, connected systems and active Work.
6. One Connection Opens the Door
The customer connects a system.
For example:
Salesforce
The system does not merely create a Salesforce page.
It establishes a tenant-scoped connection into the IntegrateWise operating environment.
CONNECTOR
↓
Consent
↓
Identity / Tenant Binding
↓
Discovery
↓
Schema / Capability Resolution
↓
Mapping
↓
Activation
↓
Ingestion
↓
Spine
The connector becomes a doorway into the broader continuity system.
7. Connector Lifecycle
The complete connector lifecycle is:
Discover
↓
Select
↓
Connect
↓
Authenticate
↓
Consent
↓
Bind to Tenant / Workspace
↓
Discover Provider Schema
↓
Classify Domain
↓
Resolve Canonical Model
↓
Map Fields
↓
Activate Capabilities
↓
Activate Ingestion
↓
Initial Hydration
↓
Health Check
↓
Continuous Sync
The Integration Manager owns connection lifecycle, OAuth, mappings, webhooks, discovery and sync policy. The Activation Manager manages tenant activation, while the Activation Bridge compiles the effective runtime configuration from identity, context, connections, policy and capabilities.
8. Discovery Is Not Ingestion
The connector first discovers what exists.
Provider
↓
Objects
Fields
Types
Relationships
Events
Webhooks
Operations
Tools
Resources
Capabilities
Limits
↓
Discovery Result
Discovery answers:
What does this connected system provide?
Ingestion answers:
What business information should enter the Spine, and how should it become canonical context?
This separation prevents provider-specific structures from becoming the product's underlying model.
9. Provider → Canonical Spine Mapping
The system is provider-neutral.
For example:
Salesforce Account
↓
Canonical Account
HubSpot Company
↓
Canonical Account
Similarly:
Zendesk Ticket
↓
Support Work / Ticket
Google Calendar Event
↓
Meeting / Event
Slack Message
↓
Communication
GitHub Issue
↓
Work / Engineering Context
The provider is the source.
The Spine is the normalized organizational representation.
This is the Normalize Once. Render Anywhere. principle.
10. Connector Activation Changes Context
Connecting a provider can activate more than data.
It can activate:
- canonical entities;
- fields;
- relationships;
- document types;
- signal types;
- health calculations;
- capabilities;
- projection fields;
- Twin context;
- search/indexing;
- workflows;
- operational views.
Therefore:
CONNECTOR
↓
DOMAIN EXTENSION
↓
CANONICAL MODEL
↓
CAPABILITIES
↓
SIGNALS
↓
CONTEXT
↓
PROJECTIONS
The connector becomes part of the organization's operating context.
11. The Four Platform Flows
The architecture uses four major flows.
Flow A — Structured operational data
Provider
↓
Connector Runtime
↓
Loader
↓
Normalizer
↓
Validation
↓
Canonical Spine Writer
↓
Business Context Spine
Used for:
- CRM;
- ERP;
- billing;
- support;
- project systems;
- operational records;
- structured provider objects.
Flow B — Documents and communications
Source
↓
Ingest
↓
Parse
↓
Classify
↓
Extract
↓
Enrich
↓
Route
↓
Govern
↓
Promote
The canonical document pipeline is explicitly Ingest → Parse → Classify → Extract → Enrich → Route → Govern → Promote.
Flow C — AI / cognitive continuity
Human / Twin / Agent
↓
Observation
↓
Interpretation
↓
Evidence
↓
Proposal / Work
↓
Triage / Governance
↓
Memory or governed write
Flow D — platform activation/control
Identity
Consent
Tenant
Configuration
Connector
Discovery
Mapping
Capabilities
Health
Sync
Policy
Flow D establishes and controls the runtime; it does not replace the business-data flows.
12. Initial Hydration
The first connection must produce useful context.
CONNECTION READY
↓
CREAMY INITIAL HYDRATION
↓
CORE ENTITIES
↓
RELATIONSHIPS
↓
DOCUMENTS / COMMUNICATIONS
↓
INDEXING
↓
PROJECTIONS
↓
WORKSPACE READY
The purpose of the initial "creamy" layer is to make the workspace useful quickly rather than waiting for the entire provider ecosystem to be synchronized.
Then:
Creamy
↓
Breadth
↓
Full Continuous Hydration
The canonical onboarding model explicitly calls for initial hydration followed by broader continuity.
13. Continuous Ingestion
After the initial load, the Spine becomes continuously hydrated.
Webhook
Poll
Delta
Cursor
Scheduled Sync
Batch
Stream
↓
Connector Runtime
↓
Loader
↓
Normalizer
↓
Canonical Writer
↓
Spine
The Spine therefore does not become stale simply because the customer originally connected a provider.
14. The Spine Is the Shared Business Context
The Business Context Spine contains the organization's operational continuity.
It can include:
- mission;
- objectives;
- goals;
- KPIs;
- teams;
- people;
- roles;
- customers;
- accounts;
- vendors;
- products;
- projects;
- assets;
- Work;
- tasks;
- commitments;
- lifecycle states;
- dependencies;
- events;
- signals;
- communications;
- documents;
- decisions;
- approvals;
- policies;
- capabilities;
- execution state;
- evidence;
- provenance;
- organizational memory.
The canonical definition is:
Business Context Memory belongs to the organization.
It is the shared, governed continuity substrate available to authorized humans, Twin and agents.
15. Storage Is Layered
The logical Spine should not be confused with one physical database.
The system separates:
STRUCTURED TRUTH
↓
Structured storage
HOT / OPERATIONAL STATE
↓
Cache / state
DOCUMENTS / MEDIA
↓
Object storage
CONVERSATIONS
↓
Conversation storage
SEMANTIC RETRIEVAL
↓
Vector / search storage
CONTINUITY
↓
Personal / AI / organizational memory systems
The Founder Canon deliberately treats physical storage as an implementation detail beneath the logical Spine contract.
16. Media and Documents
A document can have multiple representations.
For example:
customer-qbr.pdf
may exist as:
Original artifact
↓
Object storage
Metadata
↓
Structured Spine record
Parsed text
↓
Document chunks
Embeddings
↓
Vector search
Source relationship
↓
Evidence / source link
Extracted information
↓
Canonical entities / Work / signals
These are not independent copies of business truth.
They serve different purposes.
17. Conversation Storage
A meeting or email thread may contain information that has not yet become structured organizational truth.
For example:
Meeting transcript
↓
Conversation storage
↓
Parsing
↓
Entity extraction
↓
Commitment extraction
↓
Signal
↓
Evidence
↓
Possible Work
↓
Possible memory promotion
The original conversation remains available as evidence.
18. Semantic Retrieval
Semantic search is not the source of truth.
It is a retrieval mechanism.
User / Twin Question
↓
Semantic Query
↓
Vector / Search Index
↓
Relevant Chunks
↓
Source Links
↓
Original Documents / Conversations
↓
Evidence
↓
Context
This lets the Twin answer:
"Why is this account considered at risk?"
using retrieved evidence rather than an unsupported model inference.
19. Evidence and Provenance
The system maintains the relationship:
SOURCE
↓
SOURCE LINK
↓
CHUNK / RECORD
↓
RETRIEVAL
↓
EVIDENCE
↓
AI OUTPUT
↓
WORK / PROPOSAL
This is critical for enterprise trust.
The user should be able to move from an AI conclusion back toward the underlying evidence.
20. Three Memory Domains
The system has three different continuity scopes.
Organizational Memory
Organization
↓
Business Context Spine
↓
Organizational Memory
Shared, governed and available to authorized participants.
Personal Contextual Memory
Human
↓
Personal Contextual Memory
Contains:
- personal notes;
- reminders;
- priorities;
- drafts;
- bookmarks;
- private working knowledge;
- unfinished thoughts;
- personal preferences;
- personal work continuity.
It is private by default.
AI Continuity Memory
Twin / Spine Agent
↓
AI Continuity Memory
Contains things such as:
- prior assignment state;
- working summaries;
- unresolved questions;
- current plans;
- active hypotheses;
- handoff context;
- prior observations;
- pending verification;
- model-independent continuity.
It is not organizational truth.
21. Memory Promotion
The critical boundary is:
AI Observation
↓
Triage
↓
Governance
↓
Governed Writer
↓
Organizational Memory
Therefore:
AI thought
≠
company fact
and:
Personal note
≠
organizational memory
until the appropriate governed transition occurs.
The Founder Canon explicitly requires that private personal memory and AI continuity do not silently become organizational truth.
22. Projection Is the Bridge to the UI
The frontend does not independently construct business truth.
Instead:
SPINE
↓
PROJECTION ENGINE
↓
AUTHORIZED PROJECTION
↓
WORKBENCH CONTRACT
↓
UI
The Projection Engine is the sole composer of authorized, versioned Workbench/context contracts.
23. Every Projection Maps Back to Data
A projection can contain many underlying sources.
For example:
CUSTOMER SUCCESS ACCOUNT VIEW
may combine:
Account
Contacts
Health
Open Work
Renewal
Meetings
Emails
Support
Usage
Documents
Signals
Commitments
Knowledge
Evidence
It is therefore incorrect to think:
Account View = account_table
The correct model is:
Account View
↓
Projection
↓
multiple canonical entities
↓
multiple storage/retrieval layers
↓
one authorized UI contract
24. Human Workbench
The Human Workbench is the primary daily product surface.
It can contain:
Home
My Work
Inbox
Tasks
Queue
Approvals
Notifications
Communications
Email
Calendar
Meetings
Chat
Calls
Shared Documents
Personal
Notes
Knowledge
Brainstorming
Work
Domain-specific projections
The exact content adapts according to:
Role
+
Responsibility
+
Department
+
Industry
+
Goals
+
Connected Systems
+
Current Work
+
Permissions
+
Capabilities
+
Personal Context
The architecture explicitly defines this as a self-organizing Workbench, not a manually constructed collection of applications.
25. AI Workbench
The AI Workbench is the AI-side operating environment.
It assembles:
Authorized Business Context
+
AI Continuity Memory
+
Current Objective
+
Current Work
+
Evidence
+
Authority
+
Capabilities
+
Agent Runtime State
Then:
AI Workbench
↓
Twin / Spine Agent
The Twin is therefore inside the AI Workbench.
The Twin is not the whole AI Workbench.
26. Human + AI Work on the Same Work
The fundamental coordination unit is Work.
Human
↓
Work
↓
Twin
↓
Spine Agent
↓
Capability
↓
Execution
Every participant uses the same Work identity and authorized context.
The operating invariant is:
No participating worker begins meaningful work without a Spine-derived authorized context and Work identity.
This is what prevents human-to-AI handoff from becoming:
"Here is the whole story again..."
27. Twin Interaction
The user can ask:
What needs my attention?
Prepare me for my next meeting.
What changed?
What commitments are still open?
What am I missing?
Prepare the next step.
Show me work ready for review.
What needs my approval?
The Twin resolves context from:
Business Context
+
Personal Context
+
Work
+
Evidence
+
AI Continuity
+
Capabilities
+
Authority
Then it can:
Observe
↓
Orient
↓
Prepare
↓
Propose
↓
Request Approval
OODA remains an internal operating grammar rather than requiring the user interface to expose four literal controls everywhere.
28. Spine Agents
A Spine Agent is a governed AI worker.
It operates with:
Identity
+
Work
+
Context
+
Authority
+
Capabilities
+
Evidence
+
Continuity
It can take a bounded subtask from the human/Twin.
Human
↓
Work
↓
Twin
↓
Spine Agent
↓
Subtask
↓
Result
↓
Work updated
The handoff remains durable.
29. Capability Fabric
The Workbench/Twin determines:
What needs to happen?
The Capability Fabric determines:
How can it happen?
The capability may resolve to:
REST
MCP
API
Tool
Agent → Agent
Workflow
Local execution
AI execution
The provider is therefore replaceable.
The durable product contract is the capability, not the provider-specific implementation.
30. Governance
Before consequential execution:
Intent
↓
Capability
↓
Authority Check
↓
Governance
Governance can:
ALLOW
DENY
REQUIRE APPROVAL
BOUND DELEGATION
The AI does not own authority.
The human/policy boundary does.
This is part of the Founder Canon's explicit authority model.
31. Hermes
Once an action is authorized:
Approved Plan
↓
Hermes
↓
Execution Route
↓
Provider
Hermes coordinates the approved execution lifecycle.
The system therefore separates:
Cognition
↓
Capability
↓
Authority
↓
Execution
rather than creating one monolithic "AI orchestrator."
32. Execution Does Not Immediately Become Truth
Suppose the Twin updates a CRM opportunity.
The flow is:
Twin
↓
Proposal
↓
Human Approval
↓
Governance
↓
Hermes
↓
CRM
↓
Provider Outcome
At this point:
Provider said "success"
does not yet mean:
Business truth changed
The system must verify.
33. Re-ingestion and Reconciliation
The provider result comes back through the system:
Provider Outcome
↓
Re-ingestion
↓
Normalization
↓
Verification
↓
Expected vs Actual
↓
Reconciliation
↓
Governed Spine Update
↓
Projection Refresh
The canonical completion condition is therefore:
Outcome → Re-ingestion → Verification → Reconciliation → Spine update → Rehydration.
The Founder Canon explicitly defines completion this way.
34. The Workspace Then Rehydrates
Once the Spine is updated:
Verified Spine
↓
Projection Engine
↓
Human Workbench
+
AI Workbench
↓
Updated Work
↓
Next action
So the loop is:
WORK
↓
AI / HUMAN
↓
ACTION
↓
SOURCE SYSTEM
↓
OUTCOME
↓
RECONCILIATION
↓
SPINE
↓
MEMORY / EVIDENCE
↓
PROJECTION
↓
WORKBENCH
↓
NEXT WORK
That is the actual continuity loop.
35. Full Customer Operating Loop
The complete product lifecycle is:
CUSTOMER
│
▼
IDENTITY
│
▼
TENANT / WORKSPACE
│
▼
GOALS / RESPONSIBILITY
│
▼
CONNECTORS
│
▼
DISCOVERY
│
▼
MAPPING / ACTIVATION
│
▼
INGESTION
│
▼
HYDRATION
│
▼
BUSINESS CONTEXT SPINE
│
├───────────────┐
│ │
▼ ▼
MEMORY EVIDENCE
│ │
└───────┬───────┘
▼
PROJECTION ENGINE
│
┌────┴────┐
▼ ▼
HUMAN WB AI WB
│ │
└────┬────┘
▼
WORK
│
HUMAN ↔ TWIN
│
▼
CAPABILITY
│
▼
GOVERNANCE
│
▼
HERMES
│
▼
SOURCE SYSTEM
│
▼
OUTCOME
│
▼
RE-INGESTION
│
▼
VERIFICATION
│
▼
RECONCILIATION
│
▼
SPINE
│
▼
REHYDRATE
│
▼
NEXT WORK
│
└──────────► CONTINUITY
36. GTM Becomes a Product Flywheel
The customer acquisition funnel connects directly to the operational loop:
MARKET DEMAND
↓
PLUGIN / MCP / DIRECT ENTRY
↓
IDENTITY
↓
WORKSPACE
↓
CONNECTOR
↓
HYDRATION
↓
FIRST GROUNDED VALUE
↓
FIRST APPROVED GOVERNED OUTCOME
↓
RECONCILED EXECUTION
↓
RECURRING WORK
↓
MORE CONNECTORS
↓
MORE CONTEXT
↓
MORE CAPABILITIES
↓
MORE VALUE
↓
EXPANSION
The canonical GTM metric is therefore:
Time to first approved governed outcome
rather than simply:
installations.
The locked GTM model explicitly treats install as a diagnostic and grounded value, approval and reconciliation as the meaningful product progression.
37. Connector Expansion Is the Expansion Engine
After the customer experiences value:
One connector
↓
More connectors
↓
More context
↓
More cross-system relationships
↓
Better projections
↓
Better Twin context
↓
More capabilities
↓
More Work
For example:
CRM
+
Support
+
Calendar
+
Communication
+
Billing
+
Product Usage
creates a much richer customer operating context than any one provider could supply.
The product becomes more useful as the organization's connected context becomes richer.
38. The Same System Serves Every Role
The underlying Spine remains shared.
Only the projection changes.
BUSINESS CONTEXT SPINE
│
┌───────────────────┼───────────────────┐
│ │ │
SALES CS FINANCE
│ │ │
Sales View CS View Finance View
│ │ │
└───────────────────┼───────────────────┘
│
SAME SPINE
Similarly:
Founder
Sales
Customer Success
Support
Marketing
Finance
Operations
Engineering
Product
do not require separate products or separate canonical databases.
The projection adapts to the worker.
39. Customer Zero
Customer Zero is not a demo environment.
IntegrateWise itself becomes the first real operating tenant.
The Customer Zero workspace should exercise:
- product work;
- architecture;
- code;
- decisions;
- tasks;
- GTM;
- documents;
- connectors;
- incidents;
- releases;
- AI work;
- approvals;
- outcomes;
- reconciliation;
- organizational continuity.
The purpose is to prove that the same system intended for customers can operate the company itself.
40. Go-Live Is a Separate Promotion Train
GTM gets the customer into the product.
Go-live determines whether the product itself is ready for external production.
The canonical sequence is:
SOURCE COMMIT
↓
CI / CONTRACT TESTS
↓
DEVELOPMENT ARTIFACTS
↓
CUSTOMER ZERO PRIVATE INSTALLATION
↓
CUSTOMER ZERO EVIDENCE
↓
VERSION FREEZE
↓
EXTERNAL CLEAN-TENANT TEST
↓
PLUGIN / MCP SUBMISSION-READY
↓
PUBLIC PUBLICATION
This is a one-way promotion process.
41. Go-Live Phase 1 — Shared Contracts
Freeze:
Public tools
Resources
UI intents
Discovery envelope
Tenant binding
Activation profiles
The external surface must have a known, stable contract.
42. Go-Live Phase 2 — Customer Zero Plugin
Prove:
Identity
+
Embedded UI
+
Host composition
+
Delegation
+
Proposal
+
Approval
+
Execution
+
Reconciliation
The important test is not whether the plugin installs.
It is whether the full continuity loop works.
43. Go-Live Phase 3 — Customer Zero MCP + Workbench
Prove:
OAuth
+
19 public tools
+
Browser launch
+
Ordinary-client fallback
+
Discovery-first composition
+
RBAC projections
The MCP surface remains an access/distribution boundary into IntegrateWise rather than becoming the core business-data plane.
44. Go-Live Phase 4 — Externalization
Install the same artifacts into a clean tenant.
Prove:
Dynamic tenant resolution
+
Customer-owned connections
+
Isolation
+
Hydration
+
Projection
+
Continuity
No customer should require a special architecture.
45. Go-Live Phase 5 — Publication
Then:
Version Freeze
↓
Plugin Publication
↓
MCP Publication
↓
New Tenant Installation
↓
Monitoring
↓
Rollback / Revocation / Deprecation
Production is not considered complete merely because the public listing exists.
The release gates require real connector hydration, projection, governed execution, reconciliation, audit, isolation, rollback and operational evidence.
46. The Complete Architecture in One View
MARKET
│
┌───────────────┼────────────────┐
│ │ │
PLUGIN MCP DIRECT
MARKETPLACE MARKETPLACE WORKBENCH
│ │ │
└───────────────┼────────────────┘
▼
SPINEWORKSPACE
│
IDENTITY / TENANT / ROLE
│
▼
WORKSPACE READY
│
▼
CONNECTOR MARKETPLACE
│
▼
CONNECT / CONSENT
│
▼
DISCOVERY
│
▼
CONFIGURATION / MAPPING
│
▼
ACTIVATION
│
┌─────────────┼─────────────┐
│ │ │
FLOW A FLOW B FLOW C
STRUCTURED DOCUMENTS AI /
OPERATIONS COMMUNICATIONS COGNITIVE
│ │ │
└─────────────┼─────────────┘
│
FLOW D
CONTROL PLANE
│
▼
INGESTION PIPELINE
│
┌─────────────┴─────────────┐
▼ ▼
INITIAL LOAD CONTINUOUS SYNC
│ │
└─────────────┬─────────────┘
▼
BUSINESS CONTEXT SPINE
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
ORGANIZATIONAL PERSONAL AI
MEMORY CONTEXTUAL CONTINUITY
MEMORY
│ │ │
└──────────────────┼──────────────────┘
│
KNOWLEDGE / EVIDENCE
│
SEARCH / RETRIEVAL
│
▼
PROJECTION ENGINE
│
┌──────────────┴──────────────┐
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
│ TWIN
│ SPINE AGENTS
└──────────────┬──────────────┘
▼
WORK
│
CAPABILITY FABRIC
│
GOVERNANCE
│
HERMES
│
┌─────────────┼─────────────┐
▼ ▼ ▼
API MCP AGENT
│ │ │
└─────────────┼─────────────┘
▼
SOURCE SYSTEMS
│
OUTCOME
│
RE-INGESTION
│
VERIFY
│
RECONCILIATION
│
▼
VERIFIED BUSINESS CONTEXT
│
MEMORY / EVIDENCE
│
NEW PROJECTIONS
│
┌──────────────┴──────────────┐
▼ ▼
HUMAN REHYDRATES AI REHYDRATES
│ │
└──────────────┬──────────────┘
▼
NEXT WORK
│
▼
CONTINUITY
│
▼
EXPANSION
│
▼
MORE CONNECTORS
47. What the Frontend Actually Is
The frontend is not:
React
↓
Database
It is:
User
↓
SpineWorkspace
↓
Projection Contract
↓
Projection API
↓
Authorized Spine Context
↓
UI Composition
The frontend therefore renders:
- tables;
- views;
- pages;
- boards;
- queues;
- timelines;
- calendars;
- canvases;
- entity views;
- communication surfaces;
- approvals;
- Twin interactions.
But all are manifestations of the same underlying context.
48. What the Backend Actually Is
The backend is not one monolithic AI server.
It is a set of platform authorities:
One Auth
Configuration
Integration Manager
Discovery
Activation Bridge
Gateway
Loader
Flow A/B/C/D
Normalizer
Triage
Governed Writers
Spine
Knowledge
Memory
Evidence
Search
Projection
Intelligence
Model Routing
ADK
Agent Runtime
Capability Fabric
Governance
Hermes
Sync
Verification
Reconciliation
Audit
Observability
The Founder Canon retains these platform capabilities while changing their relationship to the product: they are underneath SpineWorkspace, rather than competing with the primary user experience.
49. The Architectural Ownership Rule
The entire system can be reduced to:
PRODUCT
SpineWorkspace
│
▼
EXPERIENCE
Human Workbench + AI Workbench
│
▼
CONTEXT
Business Context Spine
│
├── Organizational Memory
├── Personal Contextual Memory
└── AI Continuity Memory
│
▼
PROJECTION
Projection Engine
│
▼
WORK
Human ↔ Twin ↔ Spine Agents
│
▼
CAPABILITY
Capability Fabric
│
▼
AUTHORITY
Governance
│
▼
EXECUTION
Hermes
│
▼
REALITY
Connected Source Systems
│
▼
CLOSURE
Re-ingestion → Verification → Reconciliation
│
▼
CONTINUITY
Spine → Memory → Projection → Next Work
50. Final Product Doctrine
For the customer
One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.
For the architecture
Shared business reality; separate participant continuity; governed promotion between scopes.
For the execution model
Intent → Capability → Governance → Hermes → Provider → Outcome → Re-ingestion → Verification → Reconciliation.
For the product experience
The human works in SpineWorkspace; the Twin works with the human; both operate from the same governed business context.
For GTM
Market → Entry → Workspace → Connect → Hydrate → First grounded value → First approved governed outcome → Recurring use → Expansion.
For go-live
Development → Customer Zero → Evidence → Version Freeze → Clean Tenant → Submission → Publication.
Final definition
SpineWorkspace is the shared operating environment where humans and AI work toward the same business goals through different workbenches, using the same governed Business Context Spine while maintaining separate personal and AI continuity. IntegrateWise is the infrastructure platform underneath that connects the organization's systems, hydrates and preserves its business context, assembles authorized projections and AI context, coordinates capabilities and governed execution, and closes every action through verification, reconciliation and continuous rehydration.
The complete doctrine remains:
Humans govern. AI helps. Spine preserves continuity.
you asked
message time: 2026-09-04 01:56:11
START WITH MAREKTING,
SPINE WORKSPACE - COMPONENTS IN PLATFORM, WORKSPACE - HOW IT COMMUNICATES
DOMAIN WORKBENCHES
AI WORKBENCH
SIDE BAR STRUCTURE
FRONTEND AND BACKEND TABLES AND VIEWS
PROJECTION REGISTRY
WIRING
GO LIVE
chatgpt response
SpineWorkspace — End-to-End Canonical Product Writeup
1. Marketing — The Product Starts Here
SpineWorkspace
One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.
Businesses do not work in one application.
Customer information lives in CRM.
Work lives in project systems.
Communication lives in email and chat.
Documents live in drives.
Finance lives elsewhere.
Operational knowledge lives in people's heads.
And increasingly, AI and agents operate across all of it.
SpineWorkspace brings that distributed business reality into one self-organizing workspace.
It connects the organization's systems, builds a governed Business Context Spine, and projects the right context into the right workbench for each person and for AI.
Humans and AI therefore work on the same business Work, from different operating environments, with shared organizational context but separate continuity.
Humans govern. AI helps. Spine preserves continuity.
The core promise is not "another dashboard."
It is:
Stop reconstructing your business every time you need to work.
The workspace already knows the relevant context, history, relationships, evidence, Work and available capabilities.
2. What the Customer Buys
The customer sees SpineWorkspace.
Underneath it is the IntegrateWise platform.
CUSTOMER
│
▼
SPINEWORKSPACE
│
├── Human Workbench
├── AI Workbench
├── Domain Workbenches
├── Communications
├── Work
└── Shared Business Context
│
▼
INTEGRATEWISE PLATFORM
│
├── Identity
├── Configuration
├── Connectors
├── Ingestion
├── Spine Fabric
├── Memory
├── Knowledge
├── Projection
├── AI / Twin
├── Capabilities
├── Governance
├── Execution
├── Verification
└── Reconciliation
IntegrateWise is therefore the infrastructure platform underneath SpineWorkspace, not the primary daily destination for ordinary users.
3. SpineWorkspace Components
The product has two first-class operating sides.
Human side
Human Workbench
│
├── Home
├── My Work
├── Communications
├── Personal
└── Domain Workbenches
AI side
AI Workbench
│
├── Context
├── Active Work
├── Plans
├── Twin
├── Agents
├── Capabilities
├── Execution
└── Results
Both operate over:
BUSINESS CONTEXT SPINE
│
┌──────────────┼──────────────┐
│ │ │
Organizational Evidence Knowledge
Memory
│ │ │
└──────────────┼──────────────┘
│
WORK
│
Human ↔ AI ↔ Agents
The Human Workbench and AI Workbench are therefore different working environments over the same organizational business reality.
4. The Spine Fabric
The Spine Fabric is the center of the system.
It is not simply a database.
It is the governed representation of the organization's operational context.
CONNECTED SYSTEMS
│
▼
INGESTION
│
▼
NORMALIZATION
│
▼
SPINE FABRIC
│
├── Entities
├── Relationships
├── Work
├── Events
├── Signals
├── Decisions
├── Commitments
├── Evidence
├── Knowledge
├── History
└── Organizational Memory
The logical Spine may use multiple physical stores underneath it. Physical storage is an implementation detail; the logical Business Context Spine is the durable product contract.
5. How SpineWorkspace Communicates
There are two directions.
Human → AI
Human
↓
Work
↓
Twin
↓
AI Workbench
↓
Context Assembly
↓
AI / Agent
The human does not need to manually copy the relevant CRM records, emails, documents and previous decisions into a prompt.
The Work already carries its context.
AI → Human
AI / Twin
↓
Observation
↓
Analysis
↓
Proposal
↓
Work
↓
Human
↓
Approve / Reject / Modify
The AI does not independently become the authority.
AI → System
AI
↓
Capability
↓
Governance
↓
Execution
↓
Provider
↓
Outcome
System → AI / Human
Provider
↓
Re-ingestion
↓
Verification
↓
Reconciliation
↓
Spine
↓
Projection
↓
Human + AI
That creates the closed continuity loop.
6. Work Is the Coordination Object
Chat is not the durable handoff mechanism.
Work is.
A Work item carries:
Work
├── Objective
├── Context
├── Participants
├── Human responsibility
├── AI responsibility
├── Agent state
├── Evidence
├── Decisions
├── Commitments
├── Capabilities
├── Approvals
├── Execution state
├── Provider state
└── Continuity history
The governing rule is:
No participating worker begins meaningful work without a Spine-derived authorized context and Work identity.
That applies to humans, Twin, Spine Agents, workflows and execution providers.
7. Domain Workbenches
The Human Workbench is the common shell.
Domain Workbenches are projections of the same Spine into a particular business operating context.
Examples:
Sales
Customer Success
Technical Account Success
Marketing
Campaigns
Finance
RevOps
Operations
Product
Engineering
Support
Knowledge Management
Founder
The architecture's existing donor map includes these domain surfaces and their source applications.
The important distinction is:
DOMAIN WORKBENCH
↓
PROJECTION
↓
COMMON SPINE
not:
DOMAIN WORKBENCH
↓
separate database
8. Example: Sales Workbench
A Sales Workbench can project:
Pipeline
Accounts
Contacts
Opportunities
Activities
Forecast
Deal Risk
Tasks
Meetings
Communications
Documents
Signals
The same account may simultaneously appear in:
Sales
Customer Success
Finance
Support
Founder
because these are different projections of the same underlying business context.
9. Example: Customer Success Workbench
Accounts
Health
Renewals
Usage
Stakeholders
QBRs
Open Work
Support
Billing
Commitments
Risk
Expansion
The Twin can assemble the account context without requiring the CSM to manually search multiple systems.
The Projection Registry associates entities, widgets, capabilities and connectors with the projection.
10. Example: Finance Workbench
Revenue
Invoices
Payments
Subscriptions
Burn
Expenditure
Approvals
Reconciliation
Forecast
Again:
Finance Projection
↓
same Business Context Spine
not another Finance database.
11. AI Workbench
The AI Workbench is the machine-side equivalent of the Human Workbench.
It provides AI with:
Authorized Business Context
+
Current Work
+
AI Continuity Memory
+
Evidence
+
Authority
+
Capabilities
+
Execution State
The AI Workbench is therefore not simply:
ChatGPT + tools
It is:
AI OPERATING ENVIRONMENT
│
├── Context
├── Work
├── Memory
├── Evidence
├── Twin
├── Agents
├── Capabilities
├── Governance
└── Execution
The Founder Canon explicitly establishes the AI Workbench as a first-class operating environment rather than merely a chat session.
12. Twin
The Twin is the AI worker closest to the human.
USER
↕
TWIN
↓
AI WORKBENCH
↓
SPINE / MEMORY / EVIDENCE
↓
SPINE AGENTS
The Twin can:
- understand current Work;
- assemble context;
- research;
- analyze;
- prepare;
- recommend;
- coordinate;
- draft;
- request approval;
- delegate;
- monitor;
- execute authorized work.
The Twin does not own organizational truth.
13. Spine Agents
Specialized AI workers operate underneath the Twin.
Twin
│
├── Research Agent
├── Analysis Agent
├── Revenue Agent
├── Compliance Agent
├── Planning Agent
└── Other governed Spine Agents
They coordinate through:
Work
+
Context
+
Evidence
+
Authority
+
Handoff State
rather than independent conversations.
14. Sidebar Structure
The sidebar should expose where the user works, not every backend service.
Universal shell
SPINEWORKSPACE
│
├── Home
│
├── My Work
│ ├── Inbox
│ ├── Tasks
│ ├── Queue
│ ├── Approvals
│ └── Recent
│
├── Communications
│ ├── Activity
│ ├── Email
│ ├── Calendar
│ ├── Meetings
│ ├── Chat
│ └── Calls
│
├── Personal
│ ├── Notes
│ ├── Personal Knowledge
│ └── Brainstorming
│
├── Work
│ ├── Domain
│ ├── KPI
│ ├── Entity
│ ├── Work
│ ├── Decisions
│ └── Operations
│
└── Platform
└── Authorized administrative surfaces
The existing architecture identifies the stable shell around Home, My Work, Communications, Personal and adaptive Work.
Global utilities
These should remain accessible everywhere rather than becoming ordinary sidebar destinations:
Global Search
Twin
Notifications
Profile
Command / Quick Actions
Domain navigation
The Work section changes according to:
Role
+
Department
+
Industry
+
Responsibility
+
Goals
+
Connected Systems
+
Current Work
+
Permissions
15. Frontend → Projection → Backend
The frontend must not independently reconstruct the business.
The canonical path is:
FRONTEND
↓
WORKBENCH ROUTE
↓
PROJECTION REQUEST
↓
PROJECTION ENGINE
↓
AUTHORIZED PROJECTION
↓
BACKEND DATA / CONTEXT
↓
WORKBENCH RESPONSE
↓
UI
The Projection Engine is the authoritative composer of authorized, versioned Workbench/context contracts.
16. Frontend Surface Model
A frontend surface can be represented as:
Surface
├── Route
├── Workbench
├── Projection
├── Entity types
├── Views
├── Widgets
├── Capabilities
├── Twin modules
├── Signals
├── Connectors
└── Permissions
For example:
Customer Success
│
▼
csm.accounts
│
├── Account
├── Renewal
├── Task
│
├── Account Grid
├── Renewal Summary
└── Risk Summary
│
├── account.update
└── meeting.schedule
That pattern is explicitly described in the Projection Registry working specification.
17. Backend Data Model
The backend should separate logical domains.
TENANT
├── organization
├── users
├── memberships
├── roles
└── permissions
CONNECTION
├── connectors
├── connections
├── credentials / secret references
├── mappings
├── sync state
└── discovery
SPINE
├── canonical entities
├── relationships
├── events
├── signals
├── work
├── decisions
├── commitments
└── provenance
MEMORY
├── organizational memory
├── personal contextual memory
└── AI continuity memory
KNOWLEDGE
├── documents
├── chunks
├── embeddings
├── source links
└── evidence
PROJECTION
├── projection definitions
├── projection versions
├── projection bindings
├── view definitions
└── widget composition
CAPABILITY
├── capability definitions
├── providers
├── routes
├── permissions
└── execution plans
EXECUTION
├── approvals
├── execution runs
├── outcomes
├── verification
├── reconciliation
└── audit
The physical schema can be implemented across the appropriate stores; the important boundary is the logical ownership of each data type.
18. Storage and Retrieval
The complete retrieval model is:
REQUEST
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Structured Search Memory
Spine /Vector Stores
│ │ │
└─────────────┼─────────────┘
▼
CONTEXT ASSEMBLY
│
▼
WORK / UI
│
▼
HUMAN / AI
Documents and media follow:
Original Artifact
↓
Object Storage
↓
Metadata
↓
Parsing
↓
Chunks
↓
Embeddings
↓
Semantic Retrieval
↓
Evidence
The original artifact remains the source representation; vectors and derived records are retrieval/interpretation mechanisms.
19. Projection Registry
The Projection Registry becomes the contract between:
Business Context
↓
Domain
↓
Frontend
↓
AI Context
A projection definition should be able to describe:
Projection
├── ID
├── Version
├── Domain
├── Audience
├── Entities
├── Views
├── Widgets
├── Connectors
├── Signals
├── Capabilities
├── Twin Modules
├── Policies
├── Permissions
└── Data dependencies
Example:
projection: csm.accounts
entities:
account
renewal
task
views:
account_grid
account_detail
renewal_view
risk_view
widgets:
renewal_summary
risk_summary
health_card
capabilities:
account.update
meeting.schedule
connectors:
salesforce
slack
twin_modules:
renewal_intelligence
account_health
This is what allows the UI to become registry-driven rather than hardcoded.
20. The Supporting Registries
The Projection Registry should not exist alone.
The architecture naturally converges toward:
Entity Registry
Capability Registry
Projection Registry
Widget Registry
Twin Registry
Signal Registry
Connector Registry
Department Registry
Runtime Registry
Entity Registry
Defines:
Fields
Relationships
Timeline
Signals
KPIs
Capabilities
Twin Modules
Governance
Projection Types
Widgets
Capability Registry
Defines:
Inputs
Permissions
Governance
Execution Steps
Providers
Retry
Rollback
Evidence
Timeline Events
Twin Registry
Defines reusable intelligence modules.
Signal Registry
Normalizes provider events into business meaning.
Salesforce
↓
Opportunity Closed
↓
Canonical Signal
↓
Revenue Increased
The Twin understands the signal, not the provider.
Widget Registry
Reusable UI components.
Health Card
Risk Card
Timeline
Decision Queue
Evidence Viewer
Relationship Graph
Activity Feed
Meeting Timeline
Twin Recommendation
KPI Card
Connector Registry
Defines:
Entities
Capabilities
Signals
Timeline Events
KPIs
Relationships
Authentication
Sync Policy
These registry concepts are explicitly proposed in the project architecture material.
21. Wiring
The actual system wiring is:
CONNECTOR
↓
DISCOVERY
↓
MAPPING
↓
INGESTION
↓
NORMALIZATION
↓
TRIAGE
↓
GOVERNED WRITE
↓
SPINE
↓
PROJECTION ENGINE
↓
WORKBENCH
For AI:
WORK
↓
PROJECTION
↓
CONTEXT ASSEMBLY
↓
AI WORKBENCH
↓
TWIN
↓
SPINE AGENT
↓
CAPABILITY DISCOVERY
↓
CAPABILITY RESOLUTION
↓
GOVERNANCE
↓
HERMES
↓
PROVIDER
Then closure:
PROVIDER
↓
OUTCOME
↓
RE-INGESTION
↓
VERIFICATION
↓
RECONCILIATION
↓
SPINE
↓
PROJECTION INVALIDATION
↓
PROJECTION REBUILD
↓
WORKBENCH REFRESH
↓
TWIN REFRESH
The implementation readiness material identifies this exact missing/proof-critical chain: Gateway → Capability Runtime → Governance → Hermes → Connector Runtime, followed by projection refresh and end-to-end validation.
22. Connector → Ingestion → Spine
The customer experience hides the machinery:
User:
"Connect Salesforce."
The platform performs:
Salesforce
↓
OAuth / Consent
↓
Tenant Binding
↓
Discovery
↓
Object / Field Mapping
↓
Connector Classification
↓
Ingestion
↓
Normalization
↓
Canonical Spine
↓
Projection
Initial hydration creates the first useful operating context.
Then:
Initial Hydration
↓
Breadth Hydration
↓
Continuous Sync
The customer should experience:
Connect → Assemble → Work
rather than:
Configure a database → build dashboards → manually import data → configure AI.
23. Triage and Memory Promotion
Not everything entering the system becomes organizational memory.
The boundary is:
SOURCE
↓
INGEST
↓
INTERPRET
↓
TRIAGE
↓
GOVERNANCE
↓
PROMOTE
For example:
Meeting transcript
↓
Extracted commitment
↓
Candidate organizational fact
↓
Triage
↓
Governance
↓
Business Context Spine
Likewise:
AI inference
≠
organizational truth
and:
Personal note
≠
organizational truth
The three memory domains remain separate unless an explicit governed transition occurs.
24. OODA Is Internal
The system still operates using:
Observe
↓
Orient
↓
Decide
↓
Act
But users should experience natural work interactions rather than four artificial AI buttons.
For example:
"Prepare my renewal review."
"Show me what changed."
"Draft the customer response."
"Handle the approved follow-up."
"Why is this account at risk?"
OODA is the internal operating grammar.
The product experience remains Work-centric.
25. Governance and Execution
Every consequential action follows:
Intent
↓
Capability
↓
Authority
↓
Governance
↓
Approval if required
↓
Execution Plan
↓
Hermes
↓
Provider
Possible governance results:
ALLOW
DENY
REQUIRE APPROVAL
BOUNDED DELEGATION
The AI can recommend.
The system can prepare.
The human or policy controls authority.
26. Verification and Reconciliation
This is what makes the architecture operational rather than merely conversational.
AI says:
"Opportunity updated."
is not enough.
The system must establish:
Requested State
↓
Provider Action
↓
Provider Outcome
↓
Re-ingestion
↓
Actual State
↓
Compare
↓
Reconcile
↓
Verified Spine State
Only then does the Workbench update.
The canonical completion condition requires outcome re-ingestion, verification and reconciliation before the new state becomes verified business context.
27. Go-Live
Go-live is the final product validation and publication path.
SOURCE COMMIT
↓
CI / CONTRACT TESTS
↓
DEVELOPMENT ARTIFACTS
↓
CUSTOMER ZERO
↓
CUSTOMER ZERO EVIDENCE
↓
VERSION FREEZE
↓
CLEAN EXTERNAL TENANT
↓
PLUGIN / MCP SUBMISSION
↓
PUBLICATION
The frozen go-live doctrine explicitly requires this one-way promotion sequence.
28. Customer Zero
Customer Zero is the first real SpineWorkspace tenant.
It should operate the actual company using the same system:
Product
Code
Architecture
Decisions
Tasks
Documentation
Connectors
AI Work
GTM
Operations
Releases
Continuity
This makes Customer Zero an operating reference implementation rather than a synthetic demo.
29. Go-Live Release Gates
Before external production:
Identity
Authentication
Tenant binding
RBAC
Isolation
Connectivity
Real connector
Consent
Mapping
Hydration
Delta sync
Health
Revoke
Workspace
Human Workbench
Domain projections
AI Workbench
Twin
AI
Context assembly
Memory retrieval
Evidence
Proposal
Agent handoff
Execution
Capability
Governance
Approval
Hermes
Provider
Continuity
Outcome
Re-ingestion
Verification
Reconciliation
Projection refresh
Operations
Audit
Observability
Rate limits
Rollback
Deletion
Export
Offboarding
Revocation
The release gates explicitly treat missing evidence as stop-ship.
30. The Complete End-to-End Architecture
MARKET
│
▼
SPINEWORKSPACE.COM
│
┌──────────┼──────────┐
▼ ▼ ▼
Plugin MCP Direct
Marketplace Marketplace Entry
│ │ │
└──────────┼──────────┘
▼
IDENTITY / TENANT
│
▼
WORKSPACE
│
ROLE / GOALS / CONTEXT
│
▼
CONNECTOR MARKETPLACE
│
▼
CONNECT / CONSENT
│
▼
DISCOVERY
│
▼
MAPPING / ACTIVATION
│
▼
INGESTION PIPELINE
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
STRUCTURED DOCUMENTS AI /
FLOW A FLOW B COGNITIVE
│ │ │
└─────────────────┼─────────────────┘
▼
TRIAGE
│
▼
GOVERNED SPINE WRITE
│
▼
BUSINESS CONTEXT SPINE
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
Organizational Personal AI
Memory Contextual Continuity
Memory Memory
│ │ │
└─────────────────────┼─────────────────────┘
│
KNOWLEDGE / EVIDENCE
│
SEARCH / RETRIEVAL
│
▼
PROJECTION REGISTRY
│
▼
PROJECTION ENGINE
│
┌──────────────┴──────────────┐
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
┌────────┼────────┐ │
▼ ▼ ▼ ▼
Sales CS Finance Twin
Marketing Support RevOps │
Product etc. ▼
Spine Agents
│ │
└──────────────┬──────────────┘
▼
WORK
│
HUMAN ↔ AI ↔ AGENTS
│
▼
CAPABILITY FABRIC
│
GOVERNANCE
│
APPROVAL
│
HERMES
│
PROVIDER / API / MCP
│
▼
SOURCE SYSTEM
│
OUTCOME
│
RE-INGESTION
│
VERIFICATION
│
RECONCILIATION
│
▼
VERIFIED SPINE
│
┌────────────┴────────────┐
▼ ▼
PROJECTION REFRESH AI CONTEXT REFRESH
│ │
└────────────┬────────────┘
▼
NEXT WORK
│
▼
CONTINUITY
│
▼
MORE CONTEXT
│
▼
MORE CONNECTORS
│
▼
EXPANSION
31. Final Product Architecture Formula
SPINEWORKSPACE
=
HUMAN WORKBENCH
+
AI WORKBENCH
+
DOMAIN WORKBENCHES
+
SHARED BUSINESS CONTEXT
+
PERSONAL CONTEXTUAL MEMORY
+
AI CONTINUITY MEMORY
+
WORK
+
TWIN
+
SPINE AGENTS
+
PROJECTION ENGINE
+
CAPABILITY FABRIC
+
GOVERNANCE
+
HERMES
+
VERIFICATION
+
RECONCILIATION
And underneath:
INTEGRATEWISE
=
IDENTITY
+
CONFIGURATION
+
INTEGRATION
+
DISCOVERY
+
ACTIVATION
+
INGESTION
+
SPINE FABRIC
+
KNOWLEDGE
+
MEMORY
+
EVIDENCE
+
PROJECTION
+
AI RUNTIME
+
CAPABILITIES
+
GOVERNANCE
+
EXECUTION
+
SYNC
+
VERIFICATION
+
RECONCILIATION
+
AUDIT
+
OBSERVABILITY
+
DISTRIBUTION
32. Final GTM → Product → Platform → Go-Live Story
GTM
│
├── Discover
├── Install / Enter
└── Activate
│
▼
SPINEWORKSPACE
│
├── Identity
├── Workspace
├── Connectors
└── First Context
│
▼
SPINE FABRIC
│
├── Ingest
├── Normalize
├── Govern
├── Remember
└── Retrieve
│
▼
WORKBENCH
│
├── Human
├── Domain
└── AI
│
▼
WORK
│
├── Human
├── Twin
└── Agents
│
▼
CAPABILITY
│
├── Resolve
├── Govern
└── Execute
│
▼
REAL WORLD
│
├── Provider
├── Outcome
└── External State
│
▼
CONTINUITY
│
├── Re-ingest
├── Verify
├── Reconcile
├── Update Spine
└── Refresh Workbench
│
▼
VALUE
│
├── More context
├── More connected systems
├── More capabilities
└── More Work
│
▼
EXPANSION
│
▼
GO-LIVE / SCALE
Final positioning
SpineWorkspace is the shared operating environment where humans and AI work toward the same business goals through different workbenches, using the same governed Business Context Spine while maintaining separate human and AI continuity. IntegrateWise is the infrastructure platform underneath it, connecting the organization's software ecosystem, ingesting and governing business context, composing the right projections and AI context, enabling governed capabilities, executing approved work, and continuously reconciling reality back into the Spine.
The architectural doctrine remains:
Humans govern. AI helps. Spine preserves continuity.
chatgpt response
What would you like me to produce from the uploaded material?
I can continue the SpineWorkspace canonical writeup from the previous structure, with the next section focused on the exact frontend/backend table mapping, Projection Registry, wiring, connector ingestion pipeline, and go-live flow, or produce a consolidated final document.
you asked
message time: 2026-09-04 01:59:13
END TO END TECH SPEC AND DATA FLOW SPEC IN ALIGNED WITH GTM
chatgpt response
SpineWorkspace — End-to-End Technical Specification & Data Flow Specification
Alignment: SpineWorkspace product + IntegrateWise platform + GTM + connector ingestion + projection + Human Workbench + AI Workbench + governed execution + go-live.
Canonical principle:
One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.
Humans govern. AI helps. Spine preserves continuity.
The 31 August Founder Canon is the primary product authority. The earlier platform contracts remain the implementation baseline where they are not superseded.
1. GTM → PRODUCT ENTRY
SpineWorkspace has three marketplace surfaces, but they have different jobs.
| Surface | GTM role | Result |
|---|---|---|
| Plugin Marketplace | External acquisition + embedded activation | IW-Spine-Network Plugin |
| MCP Marketplace | External acquisition + tool-first activation | IW-Spine-Network MCP |
| Connector Marketplace | In-product activation + expansion | Customer's connected systems |
| Direct Workbench | Direct acquisition | SpineWorkspace tenant |
Plugin and MCP marketplaces bring the customer into IntegrateWise.
The Connector Marketplace expands the customer's existing workspace.
The locked GTM sequence is:
MARKET
↓
Plugin / MCP / Direct Entry
↓
Identity
↓
Tenant
↓
Workspace
↓
Connector
↓
Hydration
↓
First Grounded Value
↓
First Approved Governed Outcome
↓
Recurring Work
↓
More Connectors
↓
More Context
↓
Expansion
This distinction is explicitly established in the GTM architecture: Plugin and MCP are acquisition channels; Connector Marketplace is the post-entry activation/expansion mechanism.
2. TENANT CREATION
A new customer begins with an isolated tenant.
Identity
↓
Organization
↓
Tenant
↓
Users
↓
Roles
↓
Permissions
↓
Goals / Operating Context
↓
Workspace
Core tenant data
tenant
organization
users
memberships
roles
permissions
tenant_config
tenant_spine_config
The tenant boundary is foundational: every subsequent connection, ingestion event, memory object, Work item, projection and execution belongs to a tenant-scoped context.
3. SPINEWORKSPACE SHELL
The user enters:
SPINEWORKSPACE
The stable shell contains:
Home
My Work
├── Inbox
├── Tasks
├── Queue
├── Approvals
├── Recent
└── Favorites
Communications
├── Activity
├── Email
├── Calendar
├── Meetings
├── Chat
├── Calls
└── Shared Documents
Personal
├── Notes
├── Personal Knowledge
└── Brainstorming
Work
└── Adaptive Domain Workbenches
Administration
└── Authorized operator surfaces
The shell is stable; the Work section is adaptive.
The Human Workbench is the primary daily product surface.
4. WORKBENCH COMPOSITION
The Workbench is not a database page.
It is a projection.
Role
+
Department
+
Industry
+
Goals
+
Responsibility
+
Connected Systems
+
Permissions
+
Current Work
+
Business Context
+
Memory
+
Capabilities
↓
PROJECTION
↓
WORKBENCH
Therefore:
Sales user
↓
Sales projection
CS user
↓
Customer Success projection
Finance user
↓
Finance projection
while all remain connected to the same Business Context Spine.
The existing routing model explicitly defines role-driven columns, department-driven joins, industry-specific fields and connector-dependent field availability.
5. DOMAIN WORKBENCHES
Domain Workbenches are projections, not separate products.
Possible domains include:
Sales
Customer Success
Marketing
Finance
Operations
Engineering
Support
Product
RevOps
Founder / Executive
For example:
CUSTOMER SUCCESS
↓
Account
Health
Renewal
Stakeholders
Meetings
Support
Usage
Commitments
Tasks
Risk
The same Account can simultaneously appear in:
Sales
Customer Success
Finance
Support
Executive
because those are different views over the same canonical context.
6. AI WORKBENCH
AI has a separate first-class operating environment.
AI WORKBENCH
│
├── Authorized Context
├── Current Work
├── AI Continuity
├── Evidence
├── Twin
├── Spine Agents
├── Capabilities
├── Governance
└── Execution
The AI Workbench does not replace the Human Workbench.
It is the operating environment for:
Twin
+
Spine Agents
Both operate against the same organizational Business Context Spine while retaining separate continuity memory.
7. THE THREE MEMORY DOMAINS
7.1 Organizational Memory
Business Context Spine
↓
Organizational Memory
Shared, governed business context.
7.2 Personal Contextual Memory
User
↓
Personal Contextual Memory
Private user continuity.
7.3 AI Continuity Memory
Twin / Agent
↓
AI Continuity Memory
AI working continuity across turns, model changes and agent handoffs.
The constitutional boundary is:
User thought
≠
AI inference
≠
Organizational truth
Neither personal nor AI memory silently becomes organizational truth.
8. CONNECTOR MARKETPLACE
Once the workspace exists:
Connector Marketplace
↓
Select Provider
↓
Connect
↓
OAuth / Consent
↓
Tenant Binding
↓
Discovery
↓
Mapping
↓
Activation
Examples:
Salesforce
Slack
Google Workspace
Support systems
Finance systems
Engineering systems
The connector is not itself the product's business model.
It extends the Business Context available to the workspace.
9. CONNECTOR RUNTIME
The connector architecture contains a compatibility layer that routes connector operations toward loader, MCP and storage services.
The existing implementation defines:
Connector
├── /api/v1/connector/*
├── /api/v1/loader/*
├── /nango/webhook
├── /tools
├── /invoke
├── /v1/mcp/*
├── /files/*
└── /upload/*
The Loader handles schema-driven onboarding/background sync, while Connector Sync handles scheduled and on-demand synchronization.
10. CONNECTOR DISCOVERY
Discovery establishes:
Provider
↓
Objects
↓
Fields
↓
Relationships
↓
Events
↓
Capabilities
↓
Available operations
The output becomes configuration rather than immediately becoming organizational truth.
DISCOVERY
↓
TENANT CONFIGURATION
↓
INGESTION RULES
↓
ACTIVATION
11. SOURCE → CANONICAL SPINE
The source system has provider-specific semantics.
The Spine uses canonical semantics.
Salesforce Account
↓
Canonical Account
HubSpot Company
↓
Canonical Account
Likewise:
Provider Ticket
↓
Canonical Support Work
Provider Meeting
↓
Canonical Meeting
Provider Opportunity
↓
Canonical Deal / Pipeline Context
This is the point of normalization.
The Spine should not become a collection of provider-specific tables.
12. INGESTION PIPELINE
The ingestion path is:
SOURCE
↓
CONNECTOR
↓
LOADER
↓
PARSE
↓
CLASSIFY
↓
EXTRACT
↓
ENRICH
↓
ROUTE
↓
GOVERN
↓
PROMOTE
↓
SPINE
The canonical document/data pipeline is explicitly defined as an eight-stage process:
Ingest
→ Parse
→ Classify
→ Extract
→ Enrich
→ Route
→ Govern
→ Promote
13. INITIAL HYDRATION
The first synchronization is different from ongoing synchronization.
CONNECTOR ACTIVATED
↓
INITIAL / CREAMY SYNC
↓
CORE ENTITIES
↓
CORE RELATIONSHIPS
↓
RELEVANT DOCUMENTS
↓
KNOWLEDGE INDEX
↓
BUSINESS CONTEXT
↓
PROJECTIONS
↓
WORKSPACE READY
The Loader is specifically responsible for creamy onboarding sync, background sync and scheduled polling.
The goal is:
Connect → Assemble → Work
rather than:
Connect → configure everything manually → wait → build workspace.
14. CONTINUOUS SYNC
After initial hydration:
Webhook
Poll
Delta
Cursor
Scheduled Sync
Manual Sync
↓
Connector Sync
↓
Loader
↓
Normalizer
↓
Canonical Writer
↓
Spine
The Connector Sync service provides scheduled and on-demand synchronization, using tenant configuration to determine what is synchronized.
15. NORMALIZATION
Normalization converts source data into canonical business context.
SOURCE OBJECT
↓
IDENTIFY
↓
MAP
↓
NORMALIZE
↓
RESOLVE ENTITY
↓
ATTACH PROVENANCE
↓
CLASSIFY
↓
CANONICAL OBJECT
The canonical object should retain source lineage.
Conceptually:
Canonical Account
├── source: Salesforce
├── source_record_id
├── observed_at
├── confidence
└── source fields
This allows the Spine to preserve business meaning without losing where information came from.
16. TRIAGE
Not every incoming observation becomes durable organizational memory.
Incoming Data
↓
Interpretation
↓
Triage
↓
Promotion Queue
↓
Governance
↓
Canonical Write
Triage decides what needs:
Accept
Reject
Review
Promote
This is particularly important for:
- inferred facts;
- extracted commitments;
- AI-generated observations;
- conflicting source values;
- entity merges;
- organizational memory candidates.
17. PROMOTION QUEUE
The Promotion Queue is the boundary between:
OBSERVED / DERIVED
and:
ACCEPTED ORGANIZATIONAL CONTEXT
Example:
Meeting transcript
↓
"Customer intends to renew."
↓
Candidate commitment
↓
Triage
↓
Human / policy validation
↓
Promote
↓
Spine
The promotion boundary protects organizational truth.
18. SPINE FABRIC
After governed promotion:
SPINE
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Entities Work Signals
│ │ │
▼ ▼ ▼
Relationships Decisions Events
│ │ │
└──────────────┼──────────────┘
▼
Business Context
│
▼
Organizational Memory
This is the shared business substrate.
19. KNOWLEDGE + MEDIA STORAGE
Documents/media are not treated like ordinary relational rows.
SOURCE FILE
↓
OBJECT STORAGE
↓
METADATA
↓
PARSER
↓
TEXT / STRUCTURE
↓
CHUNKS
↓
EMBEDDINGS
↓
VECTOR / HYBRID INDEX
The Knowledge service handles:
- chunking;
- embeddings;
- vector search;
- hybrid search;
- session search.
The implementation notes D1/database bindings alongside Vectorize/search and AI services.
20. RETRIEVAL
A user or Twin does not query every storage layer independently.
Instead:
QUESTION / WORK
↓
CONTEXT ASSEMBLY
↓
Structured Spine
+
Knowledge Search
+
Evidence
+
Memory
+
Work State
↓
AUTHORIZED CONTEXT
The retrieval result should preserve references back to the source.
AI statement
↓
Evidence
↓
Source record/document
This creates an evidence chain rather than unsupported generation.
21. PROJECTION REGISTRY
The Projection Registry defines how canonical context becomes a product view.
A projection definition contains concepts such as:
projection_id
version
domain
audience
entities
fields
views
widgets
signals
connectors
capabilities
permissions
policies
Twin modules
Example:
projection:
csm.accounts
entities:
account
renewal
task
views:
account_grid
account_detail
renewal_view
risk_view
widgets:
health_card
renewal_summary
risk_summary
capabilities:
account.update
meeting.schedule
The existing Projection Registry specification uses this model and establishes projection IDs, versions, domains, entities, views, widgets, capabilities and connectors.
22. PROJECTION ENGINE
The request path is:
USER
↓
WORKBENCH
↓
Projection ID
↓
Projection Engine
↓
Tenant
↓
Role
↓
Permissions
↓
Available Connectors
↓
Available Data
↓
Projection
↓
UI
The important invariant is:
No Workbench component reads directly from a database.
The Projection Platform owns:
- query;
- permission checking;
- cache strategy;
- fallback;
- projection composition.
This is explicitly established in the platform specification.
23. FRONTEND ↔ BACKEND DATA CONTRACT
The frontend should therefore map:
ROUTE
↓
PROJECTION
↓
VIEW
↓
ENTITY
↓
FIELDS
↓
CAPABILITIES
Example:
/frontend/csm/accounts
↓
projection: csm.accounts
↓
view: account_grid
↓
entity: account
↓
fields:
name
health_score
renewal_date
engagement
risk
↓
capabilities:
account.update
meeting.schedule
The UI does not know which provider supplied the fields.
24. TABLES AND VIEWS
The logical model should distinguish:
Canonical tables/entities
Account
Contact
Opportunity
Deal
Task
Work
Meeting
Signal
Decision
Commitment
Document
Evidence
Projection views
account_grid
account_detail
renewal_view
risk_view
pipeline_view
task_queue
approval_queue
meeting_view
UI widgets
Health Card
Risk Card
Timeline
KPI Card
Evidence Viewer
Relationship Graph
Twin Recommendation
Approval Card
A table/view/widget is therefore a projection artifact, not an independent source of truth.
25. CONNECTOR-DEPENDENT PROJECTIONS
Connector availability affects projection composition.
For example:
Salesforce connected
↓
crm_stage available
No Salesforce:
crm_stage
↓
hidden / unavailable
Similarly:
Telemetry connector
↓
adoption_tier
feature_adoption_score
The Projection Platform determines what can actually be populated for that tenant. The documented routing model explicitly states that connector installation determines whether corresponding columns become available.
26. HUMAN CONTEXT ASSEMBLY
A Human Workbench request becomes:
User
↓
Role
↓
Projection
↓
Authorized Spine Context
↓
Personal Contextual Memory
↓
Current Work
↓
Relevant Knowledge
↓
Evidence
↓
UI
The human therefore sees the relevant business context without manually stitching it together.
27. AI CONTEXT ASSEMBLY
AI receives a related but distinct context:
Work
↓
Authorized Business Context
↓
Relevant Evidence
↓
AI Continuity Memory
↓
Current Objective
↓
Capabilities
↓
Authority
↓
AI Workbench
↓
Twin / Agent
Personal memory is only included when authorized.
AI continuity is not silently converted into organizational memory.
28. HUMAN ↔ TWIN
The coordination flow is:
HUMAN
↓
WORK
↓
TWIN
↓
CONTEXT ASSEMBLY
↓
REASON / PREPARE
↓
PROPOSAL
↓
HUMAN REVIEW
Examples:
"Prepare my renewal review."
"What changed with this customer?"
"Draft the follow-up."
"What commitments are still open?"
"Prepare the next action."
The user interacts naturally; OODA remains the internal operating grammar rather than a mandatory four-button UI.
29. TWIN → SPINE AGENT
The Twin can delegate specialized work.
Twin
↓
Work
↓
Subtask
↓
Spine Agent
↓
Context
↓
Capability
↓
Result
↓
Work
The handoff contains:
Identity
Work ID
Context
Objective
Authority
Evidence
Expected output
Continuity state
The agent therefore does not start from an empty conversation.
30. CAPABILITY FABRIC
The AI determines:
What needs to happen?
The Capability Fabric determines:
Which approved capability can perform it?
Intent
↓
Capability Registry
↓
Available Provider
↓
Route
Possible transports include:
REST
MCP
A2A
API
Workflow
Agent
The architecture retains capability-driven routing rather than making the model/provider the business abstraction.
31. GOVERNANCE
Before consequential action:
Intent
↓
Capability
↓
Authority
↓
Policy
↓
Risk
↓
Decision
Possible results:
ALLOW
DENY
REQUIRE APPROVAL
BOUNDED DELEGATION
The implementation's Governance service handles policy, canExecute, proposal approval/rejection, audit and HITL queues.
32. APPROVAL
For a consequential action:
Twin / Agent
↓
Proposal
↓
HITL Queue
↓
Human
↓
Approve / Reject
↓
Approval Token
The human remains accountable for the decision.
The system does not treat model output as authority.
33. EXECUTION
Once approved:
Approved Work
↓
Capability
↓
Execution Plan
↓
Hermes / Runtime
↓
Provider
For example:
"Update Salesforce opportunity."
↓
account.update / opportunity.update
↓
Governance
↓
Execution
↓
Salesforce
34. SOURCE SYSTEM OUTCOME
The source system becomes the external operational reality.
EXECUTION
↓
SALESFORCE
↓
Provider outcome
But the system still does not immediately assume that its intended state equals actual state.
35. RE-INGESTION
The outcome comes back through the normal data path.
Provider
↓
Webhook / Poll / Delta
↓
Loader
↓
Normalizer
↓
Spine Pipeline
The system now has:
Requested State
+
Actual Provider State
36. VERIFICATION
Requested
vs
Actual
↓
Verification
Examples:
Expected opportunity stage = Closed Won
Actual opportunity stage = Closed Won
↓
Verified
or:
Expected = Closed Won
Actual = Proposal
↓
Mismatch
↓
Reconciliation / Exception
37. RECONCILIATION
Only after verification/reconciliation does the system update durable context.
Provider Outcome
↓
Verification
↓
Reconciliation
↓
Governed Spine Update
↓
Projection Refresh
↓
AI Context Refresh
This is the continuity contract.
The Founder Canon requires the full outcome → re-ingestion → verification → reconciliation → Spine update → rehydration chain.
38. CONTINUITY LOOP
The complete operational loop is:
┌───────────────┐
│ CONNECTED │
│ SYSTEMS │
└───────┬───────┘
↓
INGESTION
↓
NORMALIZE
↓
TRIAGE
↓
PROMOTE
↓
SPINE
↓
PROJECTION
↓
┌──────────┴──────────┐
↓ ↓
HUMAN WB AI WB
↓ ↓
HUMAN TWIN
└──────────┬──────────┘
↓
WORK
↓
CAPABILITY
↓
GOVERNANCE
↓
APPROVAL
↓
EXECUTION
↓
SOURCE SYSTEM
↓
OUTCOME
↓
RE-INGEST
↓
VERIFY
↓
RECONCILIATION
↓
SPINE
↓
REHYDRATE
↓
NEXT WORK
This is the technical expression of:
Loop = execution becomes knowledge.
39. FRONTEND/BACKEND/SOURCE MAPPING
The complete relationship is:
| Product layer | Technical responsibility |
|---|---|
| Sidebar | Navigation / route |
| Domain Workbench | Projection |
| Table | Structured projection view |
| Widget | Projection/UI component |
| Work | Durable coordination state |
| Twin | AI contextual worker |
| AI Workbench | AI operating environment |
| Projection Registry | UI/context contract |
| Projection Engine | Authorized composition |
| Spine | Canonical business context |
| Memory | Continuity by scope |
| Knowledge | Document/semantic retrieval |
| Capability Registry | What can be executed |
| Governance | Whether execution is allowed |
| Hermes/runtime | How approved execution occurs |
| Connector | Provider access |
| Loader | Provider ingestion |
| Normalizer | Canonicalization |
| Triage | Promotion boundary |
| Reconciliation | Actual-vs-expected closure |
40. END-TO-END GTM + TECHNICAL FLOW
MARKET
│
├── Plugin Marketplace
├── MCP Marketplace
└── Direct Workbench
│
▼
IDENTITY
│
▼
TENANT
│
▼
SPINEWORKSPACE
│
├── Human Workbench
└── AI Workbench
│
▼
CONNECTOR MARKETPLACE
│
▼
CONNECT / CONSENT
│
▼
DISCOVERY
│
▼
MAPPING / ACTIVATION
│
▼
INGESTION
│
▼
NORMALIZE / TRIAGE
│
▼
BUSINESS CONTEXT SPINE
│
┌────────┼────────┐
▼ ▼ ▼
ORG MEM PERSONAL AI CONTINUITY
│ │ │
└────────┼────────┘
▼
KNOWLEDGE / EVIDENCE
│
▼
PROJECTION REGISTRY
│
▼
PROJECTION ENGINE
│
┌───────┴────────┐
▼ ▼
HUMAN WB AI WB
│ │
│ TWIN
│ │
└───────┬────────┘
▼
WORK
│
▼
SPINE AGENTS
│
▼
CAPABILITY FABRIC
│
▼
GOVERNANCE
│
┌─────┴─────┐
▼ ▼
ALLOW APPROVAL
│ │
└─────┬─────┘
▼
HERMES
│
▼
SOURCE SYSTEMS
│
▼
OUTCOME
│
▼
RE-INGESTION
│
▼
VERIFICATION
│
▼
RECONCILIATION
│
▼
VERIFIED SPINE
│
┌───────┴────────┐
▼ ▼
HUMAN REHYDRATION AI REHYDRATION
│ │
└───────┬────────┘
▼
NEXT WORK
│
▼
RECURRING VALUE
│
▼
MORE CONNECTORS
│
▼
EXPANSION
41. GO-LIVE ARCHITECTURE
GTM and production release are related but distinct.
GTM
Market
↓
Entry
↓
Activation
↓
Customer Value
↓
Expansion
Product Go-Live
Development
↓
Customer Zero
↓
Evidence
↓
Version Freeze
↓
Clean Tenant
↓
Submission
↓
Publication
The frozen architecture defines go-live as a one-way promotion of the same verified artifacts from Development → Customer Zero → Customer Production.
42. CUSTOMER ZERO
Customer Zero proves the complete system with real operational usage.
It must exercise:
Identity
Tenant
Connector
Hydration
Spine
Projection
Human Workbench
AI Workbench
Twin
Spine Agents
Capabilities
Governance
Approval
Execution
Re-ingestion
Verification
Reconciliation
Audit
Continuity
The acceptance contract requires proving the complete loop rather than merely proving that individual services respond.
43. EXTERNAL TENANT VALIDATION
After Customer Zero:
CUSTOMER ZERO
↓
Evidence
↓
Version Freeze
↓
CLEAN TENANT
↓
Fresh Identity
↓
Fresh Connections
↓
Fresh Hydration
↓
Fresh Projections
↓
Fresh AI Context
This proves that the product is genuinely tenant-aware rather than accidentally dependent on Customer Zero state.
44. MARKETPLACE PUBLICATION
After the clean-tenant gates:
IW-SPINE-NETWORK PLUGIN
↓
Plugin Marketplace
and:
IW-SPINE-NETWORK MCP
↓
MCP Marketplace
These are distribution artifacts.
They expose the same underlying platform contracts rather than separate business-data systems.
The documented model distinguishes the Plugin and MCP artifacts and their marketplace roles.
45. GO-LIVE STOP-SHIP CONDITIONS
Production should not proceed if any critical chain is unproven:
No tenant isolation
→ STOP
No real connector hydration
→ STOP
No valid projection
→ STOP
AI has no authorized context
→ STOP
AI can execute without governance
→ STOP
Execution cannot be verified
→ STOP
Outcome cannot reconcile
→ STOP
Audit/evidence chain incomplete
→ STOP
Customer Zero only works with special state
→ STOP
Clean tenant fails
→ STOP
The canonical acceptance tests specifically require authentication, hydration, projections, memory boundaries, AI context, evidence, agent handoff, capability resolution, governance, execution, reconciliation, rehydration and traceability.
46. THE FINAL TECHNICAL CONTRACT
The entire SpineWorkspace system can be reduced to these layers:
L0 — MARKET / DISTRIBUTION
Plugin
MCP
Direct
L1 — WORKSPACE
Identity
Tenant
Human Workbench
AI Workbench
Domain Workbenches
L2 — CONTEXT
Business Context Spine
Organizational Memory
Personal Contextual Memory
AI Continuity Memory
Knowledge
Evidence
L3 — PROJECTION
Entity Registry
Projection Registry
Projection Engine
Views
Widgets
Context Assembly
L4 — WORK
Human
Twin
Spine Agents
Work
Handoffs
Continuity
L5 — CAPABILITY / CONTROL
Capability Registry
Routing
Governance
Approval
L6 — EXECUTION
Hermes / Runtime
MCP
A2A
REST
Provider
L7 — REALITY
Connected Source Systems
Provider Outcome
L8 — CLOSURE
Re-ingestion
Verification
Reconciliation
Spine Update
Projection Refresh
AI Refresh
L9 — GO-TO-MARKET LOOP
Grounded Value
Approved Outcome
Recurring Work
Connector Expansion
Customer Expansion
47. THE SINGLE SYSTEM VIEW
GTM
│
Plugin / MCP / Direct Entry
│
▼
SPINEWORKSPACE
│
┌──────────────┴──────────────┐
│ │
HUMAN WORKBENCH AI WORKBENCH
│ │
Domain Workbenches Twin
│ Spine Agents
└──────────────┬──────────────┘
│
WORK
│
┌─────────┴─────────┐
│ │
BUSINESS CONTINUITY
CONTEXT MEMORY
│ │
└─────────┬─────────┘
│
PROJECTION
│
CAPABILITY
│
GOVERNANCE
│
EXECUTION
│
CONNECTORS
│
SOURCE SYSTEMS
│
OUTCOME
│
RE-INGESTION
│
VERIFY
│
RECONCILE
│
SPINE
│
REHYDRATION
│
WORK
│
VALUE
│
EXPANSION
Final technical definition
SpineWorkspace is the product surface. The Human Workbench and AI Workbench are its two first-class operating environments. Domain Workbenches are projections of the same Business Context Spine. The Projection Registry defines those projections and the Projection Engine composes them from authorized tenant context, role, permissions, connector availability, memory, evidence and Work. Connectors discover and ingest external systems through the governed ingestion pipeline, normalize provider data into canonical Spine context, and continuously rehydrate that context. Humans, Twin and Spine Agents work through durable Work identities. Capabilities resolve provider-neutral intent into governed execution through MCP, A2A, REST or other approved transports. Execution outcomes return through re-ingestion, verification and reconciliation before becoming verified Spine state, which then refreshes both human and AI work environments. GTM brings the customer into the workspace through Plugin, MCP or direct entry; Connector Marketplace expands the connected context; Customer Zero proves the full loop; and the same verified artifacts are promoted through clean-tenant validation into production.
This preserves the central architectural boundary:
Shared organizational context. Separate human and AI continuity. Governed promotion. Durable Work. Verified execution. Continuous rehydration.