Founder Final Goal
The ultimate product and business destination for IntegrateWise and SpineWorkspace.
1. Final goal
SpineWorkspace is the shared business workspace where humans and AI work toward the same business goals using the same governed organizational context, while each retains its own continuity, permissions, responsibilities and working environment.
The foundational product relationship is:
INTEGRATEWISE
Infrastructure / Platform
│
▼
SPINEWORKSPACE
Shared Business Workspace
│
├───────────────────────┐
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
│ TWIN / AGENTS
│ │
└───────────┬───────────┘
▼
SHARED WORK
│
▼
BUSINESS CONTEXT SPINE
│
┌────────────┼────────────┐
▼ ▼ ▼
ORGANIZATIONAL PERSONAL AI CONTINUITY
MEMORY MEMORY MEMORY
The Founder Canon establishes the governing principle:
Humans govern. AI helps. Spine preserves continuity.
The architectural rule is:
The Workbench is one. The Spine is one. The Projection is many.
The core Spine remains stable; projections vary according to role, industry, department, connector availability, active context and policy.
2. What the Spine actually is
The Spine Fabric is the tenant-scoped organizational context and continuity substrate.
It is not:
- the CRM
- the ERP
- the AI model
- MCP
- an agent runtime
- a UI
- a connector
- a second source system
It is the governed representation of the organization's operational context, with provenance, relationships, work state, evidence, continuity and capabilities.
For Customer Zero, the Spine can represent:
Organization
├── People
├── Teams
├── Roles
├── Customers / Accounts
├── Contacts
├── Products
├── Projects
├── Initiatives
├── Deals
├── Contracts
├── Orders
├── Tickets
├── Incidents
├── Tasks
├── Work
├── Goals
├── KPIs / Metrics
├── Risks
├── Signals
├── Decisions
├── Approvals
├── Policies
├── Communications
├── Documents
├── Knowledge
├── Evidence
├── Events
├── Activities
├── Connectors
├── Capabilities
├── Agents / Twins
├── Conversations
├── Handoffs
├── Continuity checkpoints
└── Execution / reconciliation state
This is consistent with the existing tenant model, which defines Organization, User/Actor, DigitalTwin, Goal, WorkItem, Task, Decision/Approval, Proposal/Plan, Evidence, KPI/Metric, Policy/Rule, Capability/Tool and AuditLog as major shared-context objects.
3. The critical logical layer: connector → mapping → Spine
This is the part that must not remain implicit.
A connector does not simply dump provider records into Spine.
The actual flow is:
CONNECTED SYSTEM
│
▼
CONNECTOR
│
├── Authentication
├── Schema discovery
├── Capability discovery
├── Source object discovery
└── Source events / records
│
▼
INGESTION
│
▼
CANONICAL MAPPER
│
├── Source object → Spine entity
├── Source field → Spine field
├── Source ID → canonical reference
├── Relationships → Spine relationships
└── Transformations
│
▼
VALIDATION / TRIAGE
│
├── Valid known mapping
├── Duplicate / conflict
├── Unknown field
├── Unknown object
├── Unknown relationship
└── Candidate schema extension
│
▼
PROMOTION QUEUE
│
├── Auto-promotable
└── Human review
│
▼
GOVERNED SPINE WRITE
│
▼
SPINE FABRIC
│
├── Canonical state
├── Source provenance
├── Evidence
├── Events
└── Continuity
│
▼
PROJECTION ENGINE
│
▼
USER / TWIN / AGENT CONTEXT
The existing architecture explicitly separates canonical mapping, validation, the Spine Write Bus and Projection Engine. Connectors and Twin do not directly mutate canonical storage.
4. Connector schema hydration
The Spine is adaptive, but not uncontrolled.
When a connector is installed:
Connector
↓
Category
↓
Schema Module
↓
Source entities / fields
↓
Canonical mappings
↓
Validation
↓
Promotion if necessary
↓
Spine schema hydration
↓
Projection availability
For example:
Salesforce Account
│
├── Name
├── Industry
├── Owner
├── ARR
└── Renewal Date
│
▼
Canonical Account
│
├── account.name
├── account.industry
├── account.owner
├── account.arr
└── account.renewal_date
Likewise:
HubSpot Company ────────┐
Dynamics Account ───────┼──► Canonical Account
Salesforce Account ─────┘
The universal schema already defines source-to-Spine mapping fields such as destination_field, transformation rules, required status, AI suggestion state, confidence and approval.
5. Four primary ingestion flows
The canonical material distinguishes four flows rather than treating all connector data identically.
Flow A — Structured business data
CRM
ERP
Finance
ITSM
HR
Project systems
Billing
Marketing
Analytics
Produces:
Entities + typed tuples
Examples:
Account
Deal
Ticket
Employee
Invoice
Project
Task
and:
ARR
health_score
renewal_date
priority
status
amount
owner
Flow A is strongly typed at the schema level.
Flow B — Unstructured context
Email
Slack
Meetings
Call transcripts
Documents
PDFs
PPTX
Notes
Attachments
Messages
Contracts
Support conversations
Produces:
Chunks
Embeddings
Evidence
Source links
Conversational context
This feeds organizational retrieval and context assembly rather than becoming indiscriminately flattened into structured business tables.
Flow C — AI continuity
AI-generated:
Observations
Proposals
Plans
Reasoning outputs
Handover context
Session conclusions
remain within AI continuity until they qualify for organizational promotion.
Flow D — Authentication / authority
Identity and authorization establish:
Who
↓
Which tenant
↓
Which workspace
↓
Which role
↓
Which permissions
↓
Which capabilities
↓
Which data
↓
Which actions
This prevents context from being separated from authority.
6. Triage and promotion
The key principle is:
Not everything ingested becomes organizational truth.
Incoming information is classified:
RAW
↓
PARSED
↓
NORMALIZED
↓
TRIAGED
↓
CANDIDATE
↓
REVIEW
├── REJECTED
└── APPROVED
↓
PROMOTED
↓
CANONICAL
The promotion queue contains fields including:
queue_id
memory_item_id
memory_scope
memory_type
subject_refs
canonical_domain
canonical_entity_type
proposed_by
proposed_at
confidence
origin
promotion_status
reviewed_by
reviewed_at
rejection_reason
committed_at
canonical_record_id
canonical_version
This provides the bridge between information that exists and information the organization has decided to preserve as shared continuity.
7. The Spine data model
The Spine should therefore be understood as several related domains.
Identity and organization
tenants
organizations
users
teams
roles
permissions
workspaces
memberships
Business context
accounts
contacts
customers
products
services
contracts
deals
orders
projects
initiatives
Work
goals
work_items
tasks
steps
dependencies
assignments
handoffs
work_status
work_history
Intelligence
signals
risks
insights
recommendations
proposals
plans
decisions
Metrics
kpis
metric_definitions
metric_values
targets
thresholds
sla_definitions
measurements
Knowledge and evidence
documents
knowledge_items
chunks
source_links
evidence
citations
policies
runbooks
Communication
messages
conversations
meetings
activities
communications
attachments
Integration
connectors
connections
source_objects
source_records
field_mappings
webhooks
sync_jobs
sync_state
The connector itself remains responsible for connectivity; the Spine owns the normalized organizational representation.
The universal connector model already includes tenant, provider, authentication type, category, status, version, manifest, MCP status and MCP endpoint metadata.
8. Provenance is part of the Spine
Every meaningful canonical value must be traceable.
Conceptually:
Spine Field
│
├── source_connector
├── source_system
├── source_object
├── source_record
├── source_field
├── source_timestamp
├── ingested_at
├── mapping_version
├── evidence_ref
└── confidence / classification
This gives the Twin and human user an answer to:
Where did this come from?
The retrieval contract similarly requires record reference, source reference, locator, score components, classification, freshness, permission decision and index version.
9. Role-based projection
The Spine does not become a different database for each role.
Instead:
ONE SPINE
+
ROLE
+
DEPARTMENT
+
INDUSTRY
+
CONNECTORS
+
ACTIVE CONTEXT
+
POLICY
↓
PROJECTION
The Projection Engine produces:
Navigation
Views
Fields
KPIs
Tables
Boards
Timelines
Forms
Actions
Evidence
Twin context
This is the core reason the same underlying Account can appear differently for:
Account Executive
Sales Manager
CRO
or:
CSM
CS Manager
VP Customer Success
The role determines the job; the department determines the domain; permissions determine authority; the projection determines what is surfaced.
10. Initial role/access projection
The access chain is:
USER
↓
MEMBERSHIP
↓
ROLE
↓
PERMISSION SET
↓
RESOURCE
↓
ACTION
↓
SCOPE
Permission actions include:
read
write
execute
approve
with scopes such as:
tenant
workspace
own
The role model includes department, permissions, capability grants and projection manifest.
Therefore:
Role ≠ UI
Role → Projection policy
11. Organizational memory
Spine Fabric = organizational memory, but organizational memory has structure.
It contains:
Operational truth
What is true now?
Historical continuity
What happened?
Organizational knowledge
What do we know?
Decisions
What did we decide?
Why?
Evidence
What supports it?
Intent
What are we trying to accomplish?
Work state
What is currently being done?
This is why the Spine is more than a normalized connector database.
12. Three memory boundaries
The architecture must keep three memories separate.
| Memory | Owner | Purpose |
|---|---|---|
| Organizational Memory | Tenant / Spine | Shared business truth and durable organizational continuity |
| Personal Memory | User | User-specific preferences, context and personal continuity |
| AI Continuity Memory | Twin / AI | Task/session-specific AI continuity |
The project material explicitly defines these three scopes.
The important rule is:
Personal ≠ Organizational
AI continuity ≠ Organizational truth
AI observations can become organizational knowledge only through the governed promotion path.
13. SpineWorkspace Human Workbench
The Human Workbench is the primary product surface.
It should answer:
What matters?
What is my goal?
What needs attention?
What work is mine?
What changed?
What decision is needed?
What can I do next?
What is my Twin preparing?
The user should not need to understand:
MCP
R2
Vectorize
loader
normalizer
schema mapper
Hermes
agent runtime
model routing
unless their role explicitly requires those capabilities.
14. AI Workbench / Twin
The AI Workbench is the environment where the Twin operates over the same business context.
The Twin does not receive arbitrary connector payloads.
It receives an Active Context Bundle assembled from authorized Spine state, memory, evidence and current work.
User / Work
↓
Active Context
↓
Projection
↓
Context Assembly
↓
Twin
The Twin then reasons about:
Goal
Work
Context
History
Signals
Evidence
Policies
Available capabilities
The Twin is therefore:
Cognition over governed, assembled context.
It is not another database.
15. Human + Twin interaction
The fundamental unit is Work, not chat.
BUSINESS GOAL
↓
WORK
↓
HUMAN + TWIN
↓
CONTEXT
↓
PROPOSAL / PLAN
↓
HUMAN DECISION
↓
EXECUTION
↓
OUTCOME
The Twin may:
- observe
- summarize
- prepare
- recommend
- draft
- analyze
- plan
- identify risks
- assemble context
- request approval
- hand work to another agent
The human remains the authority boundary for governed consequences.
16. Capability Fabric
A capability is not simply a tool name.
It describes what can be accomplished and under what constraints.
Examples:
read_customer
update_customer
create_task
send_email
schedule_meeting
query_database
run_test
create_pull_request
deploy_application
rollback_deployment
update_ticket
create_invoice
Capabilities have:
category
operation
input schema
output schema
required permissions
risk level
approval requirement
tenant availability
connector dependency
execution mechanism
The capability can then be implemented through:
MCP
REST
A2A
workflow
connector API
local filesystem
browser
Git
database
So:
Capability = what may be done.
MCP/REST/A2A = how communication reaches it.
17. Tool categories
The Spine should understand tool capabilities by category rather than hard-code individual vendors.
Business systems
CRM
ERP
Finance
Billing
HR
Support
ITSM
Marketing
Analytics
Productivity
Email
Calendar
Documents
Chat
Meetings
Knowledge
Engineering
Git
Code
CI/CD
Cloud
Infrastructure
Databases
Monitoring
Interaction
Browser
REST
MCP
A2A
Webhook
Local/runtime
Filesystem
Terminal
Shell
Development environment
The provider can change without changing the business capability contract.
18. Communication architecture
SPINEWORKSPACE
│
Context / Work
│
┌────────────┼────────────┐
│ │ │
MCP REST A2A
│ │ │
Tool/resource Service/API Agent
│ │ │
└────────────┼────────────┘
▼
Capability Fabric
│
▼
Governance
│
▼
Hermes
│
▼
Connector / Runtime
│
▼
Source System
MCP is therefore one communication mechanism inside the capability/runtime architecture, not the Spine itself. The architecture documents explicitly establish this distinction.
19. Workflow and writeback
The reverse path is as important as ingestion.
Human
Human action
↓
Projection API
↓
Authorization
↓
Governed Writer
↓
Spine
↓
Event
↓
Source write
↓
Receipt
↓
Re-ingestion
↓
Reconciliation
↓
Projection refresh
Twin
Twin
↓
Proposal
↓
Governance
↓
Approval
↓
Execution Plan
↓
Hermes
↓
Capability
↓
Source System
↓
Outcome
↓
Verification
↓
Reconciliation
↓
Spine
↓
New Context
The canonical architecture specifies this write path and prohibits browser, Twin, connector and projection components from bypassing governed writes.
20. Continuity
Continuity is the complete closed loop:
INTENT
↓
GOAL
↓
WORK
↓
CONTEXT
↓
ACTION
↓
OUTCOME
↓
EVIDENCE
↓
VERIFICATION
↓
RECONCILIATION
↓
SPINE UPDATE
↓
NEW PROJECTION
↓
NEXT WORK
This is what makes Spine different from a static data warehouse.
The system remembers not merely:
"Account X has ARR = $2M"
but also:
why it matters
what changed
who owns it
what was attempted
what was decided
what evidence exists
what remains unresolved
what should happen next
21. KPI model
KPIs belong to the business goal and work context, not merely to dashboards.
A KPI should support fields such as:
kpi_id
tenant_id
goal_id
work_item_id
name
description
metric_type
formula
unit
currency
aggregation
source_entities
source_fields
current_value
baseline_value
target_value
minimum_value
maximum_value
threshold
direction
status
variance
variance_pct
trend
period
period_start
period_end
forecast_value
confidence
owner_id
department
role_visibility
sla
freshness
last_calculated_at
source_ref
evidence_ref
version
Then:
GOAL
↓
KPI
↓
CURRENT STATE
↓
TARGET
↓
VARIANCE
↓
SIGNALS
↓
WORK
↓
ACTION
This makes KPIs operational rather than decorative.
22. Business-goal interaction
A goal should carry enough structure for both human and AI work:
goal_id
tenant_id
name
description
objective
owner
department
priority
status
start_date
target_date
success_definition
kpi_ids
related_work_ids
related_entities
risks
dependencies
constraints
required_capabilities
required_approvals
active_context
evidence
created_by
updated_by
version
Then the Twin can reason:
What is preventing this goal from being achieved?
rather than merely:
What information is in the CRM?
23. Work as the human-AI coordination object
The durable coordination object is:
Work
A Work record should connect:
Goal
↓
Work Item
↓
Tasks
↓
People
↓
Twin / Agents
↓
Context
↓
Capabilities
↓
Decisions
↓
Approvals
↓
Evidence
↓
Outcomes
This allows:
Human starts work
↓
Twin prepares
↓
Human reviews
↓
Twin executes permitted portions
↓
Human approves consequence
↓
System writes back
↓
Outcome reconciles
↓
Work closes
↓
Continuity preserved
24. Final enterprise Spine architecture
TENANT
│
┌──────────────┴──────────────┐
│ │
IDENTITY CONFIGURATION
│ │
Users / Roles / Policy Industry / Connectors
│ │
└──────────────┬──────────────┘
▼
CONNECTOR FABRIC
│
┌───────────┼───────────┐
▼ ▼ ▼
Discovery Ingestion Capabilities
│ │ │
└───────────┼───────────┘
▼
NORMALIZATION / TRIAGE
│
┌──────────┴──────────┐
│ │
Known mapping New / uncertain
│ │
│ PROMOTION QUEUE
│ │
│ REVIEW / APPROVE
│ │
└──────────┬──────────┘
▼
GOVERNED SPINE WRITE
│
▼
┌──────────────┐
│ SPINE FABRIC │
└──────────────┘
│
┌────────────────────────┼─────────────────────────┐
▼ ▼ ▼
BUSINESS CONTEXT ORGANIZATIONAL CONTINUITY
STRUCTURE MEMORY STATE
│ │ │
└────────────────────────┼─────────────────────────┘
▼
PROJECTION ENGINE
│
┌────────────────┴────────────────┐
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
Role projection Twin / Agents
│ │
└────────────────┬────────────────┘
▼
WORK
│
CONTEXT ASSEMBLY
│
CAPABILITY FABRIC
│
GOVERNANCE
│
HERMES
│
MCP / REST / A2A
│
SOURCE SYSTEMS
│
OUTCOME / VERIFICATION
│
RE-INGEST / RECONCILE
│
▼
SPINE UPDATE
│
▼
NEW PROJECTION
│
▼
NEXT WORK
25. What is actually shared between Human and AI
They share:
Business goals
Work
Authorized business context
Relevant entities
KPIs
Signals
Evidence
Decisions
Policies
Approved outcomes
Organizational continuity
They do not automatically share:
Personal memory
Private user context
AI ephemeral reasoning
Unauthorized data
Unapproved actions
Raw connector credentials
That distinction is fundamental.
26. Final system contract
The complete SpineWorkspace contract is therefore:
Connect the organization's software. Discover its schemas and capabilities. Map source data into a governed tenant Spine. Hydrate the Spine as new domains and connectors become available. Preserve provenance, evidence and organizational continuity. Compose role- and context-specific projections from that Spine. Give humans and their Twins the same authorized business context for the same work. Let the Twin prepare, reason and propose. Let capabilities perform governed actions through MCP, REST, A2A and other runtime mechanisms. Write approved outcomes back to source systems. Re-ingest, verify and reconcile the result. Preserve the resulting state as organizational continuity and project the next work.
That is the end-to-end Spine Fabric for an enterprise organization.
And the product-level abstraction remains deliberately simple:
One Workspace. All Connected Software. Business Context. Shared Work. Human + AI Working Together.
The platform underneath can be extremely sophisticated; the user's experience should remain centered on goals, context, work, decisions and outcomes.