Founder Final Architecture
Definitive architectural lock, plane layer hierarchy, and component ownership.
Canonical product: SpineWorkspace
Platform: IntegrateWise
Core substrate: Spine Fabric
Operating doctrine: Humans govern. AI helps. Spine preserves continuity.
This is the consolidated end state supported by the Founder Canon and the current Spine architecture records. The Founder Canon establishes SpineWorkspace as the product, IntegrateWise as the infrastructure platform, and the shared Business Context Spine as the organizational context over which the Human and AI Workbenches operate.
1. Final Product 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 human and AI continuity.
INTEGRATEWISE
Infrastructure Platform
│
▼
SPINEWORKSPACE
Customer Work Environment
│
┌──────────────┴──────────────┐
│ │
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
└──────────────┬──────────────┘
│
SHARED BUSINESS
CONTEXT
│
▼
SPINE FABRIC
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
ORGANIZATIONAL PERSONAL AI CONTINUITY
MEMORY MEMORY MEMORY
The important distinction is:
- Spine Fabric is not another application.
- Human Workbench is not another truth store.
- AI Workbench is not another business system.
- Twin is not the organizational source of truth.
- MCP is not the Spine.
- Agents are not the Spine.
- Connectors do not define the canonical business model by themselves.
The Spine is the governed contextual substrate from which work is assembled and into which verified organizational state returns.
2. The Complete System Loop
The complete operating model is:
GTM / CUSTOMER
│
▼
CONNECTORS
│
▼
SOURCE SYSTEMS
│
▼
INGESTION
│
▼
NORMALIZATION
│
▼
TRIAGE
│
├──────────────► KNOWN SCHEMA
│
└──────────────► PROMOTION QUEUE
│
▼
HUMAN / GOVERNED REVIEW
│
▼
SCHEMA PROMOTION
│
▼
SPINE FABRIC
│
┌────────────────┼────────────────┐
▼ ▼ ▼
ORGANIZATIONAL ROLE PROJECTION CONTINUITY
CONTEXT
│ │
└────────────────┘
│
▼
HUMAN WORKBENCH
│
▼
CONTEXT ASSEMBLY
│
┌───────┴────────┐
▼ ▼
HUMAN TWIN
│
▼
AI WORKBENCH
│
┌─────┴─────┐
▼ ▼
WORK CAPABILITY
│
┌──────────┼──────────┐
▼ ▼ ▼
MCP REST A2A
│ │ │
└──────────┼──────────┘
▼
GOVERNANCE
│
▼
EXECUTE
│
▼
SOURCE SYSTEMS
│
▼
OUTCOME
│
▼
RE-INGESTION
│
┌──────────┴──────────┐
▼ ▼
VERIFY RECONCILE
│ │
└──────────┬──────────┘
▼
UPDATE SPINE
│
▼
REFRESH PROJECTION
│
▼
NEXT WORK
The architecture records explicitly describe this closed loop from connector ingestion through Spine, projection, Work, capability execution, source-system outcome, re-ingestion, verification and reconciliation.
3. Spine Fabric: What It Actually Contains
The Spine Fabric is the shared organizational context and continuity substrate.
It needs to represent enough of the business that people and AI can perform real work without rebuilding context from individual applications every time.
At the conceptual level:
SPINE FABRIC
│
├── Tenant / Organization
├── People
├── Roles
├── Teams
├── Departments
├── Business Domains
├── Customers / Accounts
├── Contacts
├── Leads / Opportunities
├── Products / Services
├── Projects
├── Contracts
├── Orders
├── Invoices
├── Assets
├── Cases / Tickets
├── Communications
├── Meetings / Calendar Events
├── Documents
├── Knowledge
├── Decisions
├── Tasks
├── Work
├── Goals
├── KPIs
├── Events
├── Activities
├── Relationships
├── Evidence
├── Source References
├── Provenance / Lineage
├── Capabilities
├── Policies
├── Approvals
├── Execution State
└── Continuity State
The exact domain objects are hydrated according to the tenant's connected systems and business needs rather than requiring every organization to instantiate every possible object.
The current tenant-schema material establishes the principle that the tenant Spine contains business entities, object fields, roles and goals, with connectors hydrating the schema and role-based projections determining what users can access.
4. The Missing Logical Layer: Connector → Mapping → Spine
This is the key architectural relationship.
A connector does not simply dump source records into Spine.
The actual path is:
SOURCE OBJECT
│
▼
CONNECTOR RESOURCE
│
▼
UNIVERSAL CONNECTOR OBJECT
│
▼
SOURCE → SPINE MAPPING
│
├── Entity mapping
├── Field mapping
├── Relationship mapping
├── Identity mapping
├── Semantic transformation
├── Type conversion
├── Status/value mapping
└── Provenance mapping
│
▼
CANONICAL SPINE OBJECT
│
▼
SPINE RECORD
Therefore every connector needs a mapping contract.
For example:
Salesforce.Account
│
├── Id → Customer.source_id
├── Name → Customer.name
├── OwnerId → Customer.owner_id
├── Industry → Customer.industry
├── Type → Customer.lifecycle_type
└── ParentId → Customer.parent_customer_id
Another connector may represent the same business concept differently:
HubSpot.Company
│
├── companyId → Customer.source_id
├── name → Customer.name
├── owner → Customer.owner_id
└── lifecycleStage → Customer.lifecycle_type
The Spine therefore has:
One canonical business model, many connector representations.
This is what prevents every new connector from creating another incompatible internal data model.
5. Connector Schema Hydration
Connector ingestion follows a controlled pipeline.
Connector
│
▼
Discover
│
▼
Read resource/object metadata
│
▼
Map to universal connector model
│
▼
Compare against Spine schema
│
├── Known entity
├── Known field
├── Known relationship
├── Known identity
│
└── Unknown / changed
│
▼
TRIAGE
│
┌─────┴─────┐
▼ ▼
Safe Review
mapping required
│ │
│ ▼
│ Promotion Queue
│ │
│ ▼
│ Approval
│ │
└─────┬─────┘
▼
Spine Schema
│
▼
Canonical Data
The existing architecture specifically defines the promotion queue for unknown objects or fields and uses approved promotion to extend the tenant schema while maintaining continuity.
This means schema evolution is itself part of Spine continuity.
6. Source Truth vs Spine Truth
The system must distinguish:
Source systems
They remain authoritative for their own operational transactions.
Examples:
CRM → customer/account transaction state
ERP → financial transaction state
Ticketing → case state
HRIS → employee state
Git → source-code state
Spine
Spine becomes the governed cross-system business context.
It provides:
- canonical representation;
- relationships across systems;
- organizational context;
- evidence;
- lineage;
- history;
- work state;
- continuity;
- projections;
- context for humans and AI.
Therefore:
Spine does not replace every source system. It connects their meaning into a governed business context.
7. Organizational Memory
Organizational Memory is the durable organizational knowledge that has crossed the appropriate governance boundary.
SOURCE DATA
│
▼
INGESTION
│
▼
TRIAGE
│
▼
EVIDENCE
│
▼
CANONICAL SPINE
│
▼
ORGANIZATIONAL MEMORY
It can contain:
- business facts;
- decisions;
- relationships;
- historical state;
- approved knowledge;
- evidence;
- operational patterns;
- completed Work;
- verified outcomes.
The Founder Canon distinguishes Business Context / Organizational Memory from Personal Contextual Memory and AI Continuity Memory.
8. Three Memory Boundaries
The final architecture must preserve these boundaries:
| Memory | Owner | Purpose | Canonical business truth? |
|---|---|---|---|
| Organizational Memory | Tenant / organization | Shared business context and continuity | Yes |
| Personal Contextual Memory | User | Individual working context | No |
| AI Continuity Memory | Twin / AI | AI working continuity | No |
SPINE
│
┌───────────┴───────────┐
│ │
ORGANIZATIONAL PROJECTION
MEMORY │
│
┌──────────┴──────────┐
▼ ▼
HUMAN MEMORY AI CONTINUITY
Personal and AI memory may influence context assembly, but neither silently becomes organizational truth.
9. Role-Based Projection
The Spine is not exposed directly to every user.
Instead:
SPINE
│
▼
AUTHORITY
│
▼
ROLE
│
▼
POLICY
│
▼
PROJECTION REGISTRY
│
▼
ROLE-SPECIFIC PROJECTION
│
▼
USER WORKBENCH
A projection defines:
- permitted entities;
- permitted fields;
- permitted relationships;
- row-level access;
- actions;
- visibility;
- KPI visibility;
- Work visibility;
- evidence visibility;
- sensitive-field masking;
- capability availability.
This is how the same organizational Spine can serve:
CEO
Sales
Finance
Support
HR
Engineering
Operations
Marketing
Admin
AI
without creating separate truth stores.
10. Human Workbench
The Human Workbench is the primary human operating surface.
The user sees the work, not the infrastructure.
The canonical frontend structure established in the project material is:
BUSINESS CONTEXT
│
▼
PROJECTION
│
▼
HUMAN WORKBENCH
│
├── Today
├── Communications
├── Organization Memory
└── Work
├── Domain
├── KPI
├── Entity
├── Work
├── Decisions
└── Operations
11. AI Workbench
The AI Workbench is the operating environment for the user's Twin and AI agents.
TWIN WORKBENCH
│
├── Context
├── Active Work
├── Plan
├── Agents
├── Tools
├── Execution
└── Results
The AI Workbench receives assembled context, rather than unrestricted access to the entire tenant database.
12. Context Assembly
This is the bridge between the two Workbenches.
SPINE
│
┌───────────┼───────────┐
▼ ▼ ▼
ROLE WORK KPI
CONTEXT CONTEXT CONTEXT
│ │ │
└───────────┼───────────┘
▼
CONTEXT ASSEMBLER
│
┌────────────┴────────────┐
▼ ▼
HUMAN WORKBENCH AI WORKBENCH
│ │
▼ ▼
USER TWIN
The result is:
Human and AI work from the same governed business context, but receive different projections appropriate to their role and operating environment.
13. Twin, Coworker and Agents
The architecture should keep these concepts distinct.
Twin
The user's primary AI work partner.
Coworker
The contextual companion that helps assemble active context and communication.
Spine Agents
Specialized agents that perform bounded work through approved capabilities.
TWIN
│
┌────────┼────────┐
▼ ▼ ▼
Context Plan Work
│
▼
SPINE AGENTS
│
▼
CAPABILITY FABRIC
The Twin is not itself another organizational authority.
14. Work Is the Coordination Primitive
The key unit shared by humans and AI is Work.
GOAL
│
▼
WORK
│
├── Human
├── Twin
├── Agent
├── Context
├── Plan
├── Evidence
├── Approval
├── Capability
├── Execution
├── Outcome
└── Continuity
A Work record should therefore carry enough state to answer:
- What business goal does this support?
- Who owns it?
- What entity/domain does it concern?
- What is the current state?
- What context was used?
- What decision was made?
- What AI participated?
- What capabilities were invoked?
- What approvals were required?
- What actually executed?
- What was the source-system result?
- What evidence proves the outcome?
- What remains unresolved?
This makes Work the durable bridge between human activity and AI activity.
15. Goals and KPIs
Goals are not simply dashboard labels.
They are the business objectives against which Work is organized.
BUSINESS GOAL
│
├── Owner
├── Scope
├── Time horizon
├── Status
├── Priority
├── Target
├── Baseline
├── Current value
├── Variance
└── KPIs
│
├── Definition
├── Source
├── Formula
├── Current value
├── Target
├── Trend
└── Evidence
The tenant schema already establishes goals and KPIs as first-class parts of the business context model.
16. Capability Fabric
The Spine determines context and authority.
The Capability Fabric determines what can be done.
SPINE
│
├── Context
├── Policy
├── Work
└── Authority
│
▼
CAPABILITY FABRIC
│
├── MCP
├── REST
├── Connector
├── Workflow
├── Tool
└── Agent capability
The architecture explicitly separates Spine continuity/state from runtime components that consume and mutate that state through governed interfaces.
17. Tool Categories
Capabilities should be represented by what they can accomplish, not merely by vendor names.
CAPABILITY
│
├── Read
│ ├── Search
│ ├── Retrieve
│ ├── Query
│ └── Inspect
│
├── Create
│ ├── Record
│ ├── Document
│ ├── Task
│ └── Work
│
├── Update
│ ├── Record
│ ├── Status
│ └── Relationship
│
├── Communicate
│ ├── Email
│ ├── Message
│ └── Notification
│
├── Coordinate
│ ├── Calendar
│ ├── Assignment
│ └── Handoff
│
├── Execute
│ ├── Workflow
│ ├── Transaction
│ └── Automation
│
└── Analyze
├── KPI
├── Forecast
├── Compare
└── Diagnose
The important abstraction is:
Capability = what the system is allowed and able to do. Execution = how that capability is performed.
18. MCP, REST and A2A
These are communication mechanisms, not competing sources of truth.
| Mechanism | Role |
|---|---|
| MCP | AI ↔ tools/resources |
| REST | System/service ↔ system/service |
| A2A | Agent ↔ agent/Twin contextual handoff |
| Connector | External application ↔ IntegrateWise |
| Spine | Shared governed business context |
The architecture explicitly positions MCP Pool as capability resolution rather than context ownership.
19. Governance
No capability should execute merely because an agent can discover it.
WORK
│
▼
INTENT
│
▼
CAPABILITY RESOLUTION
│
▼
POLICY CHECK
│
▼
RISK / APPROVAL CHECK
│
├── No approval required ───────┐
│ │
└── Approval required │
│ │
▼ │
HUMAN │
APPROVAL │
│ │
└──────────┬───────────┘
▼
EXECUTION
The project material explicitly requires approval metadata, policy enforcement, immutable execution plans after approval and auditability.
20. Execution and Write-Back
The AI does not directly mutate Spine or source systems.
TWIN / AGENT
│
▼
PROPOSE
│
▼
PLAN
│
▼
GOVERN
│
▼
APPROVE
│
▼
CAPABILITY
│
▼
EXECUTE
│
▼
SOURCE SYSTEM
│
▼
OUTCOME
The existing acceptance material explicitly prohibits Twin from directly writing to Spine and requires governed capability execution.
21. Reconciliation
Execution is not completion.
Completion occurs only after the external result is verified.
INTENDED ACTION
│
▼
EXECUTION
│
▼
SOURCE OUTCOME
│
▼
RE-INGEST
│
▼
VERIFY
│
▼
RECONCILE
│
├── Match
│ │
│ ▼
│ COMPLETE
│
└── Mismatch
│
▼
OPEN ISSUE
The source material explicitly requires the external outcome to be verified, re-ingested, reconciled and reflected back into Spine before completion is treated as true.
22. Continuity
Continuity is the mechanism that prevents the organization from repeatedly reconstructing its state.
SOURCE
↓
INGEST
↓
SPINE
↓
PROJECTION
↓
WORK
↓
EXECUTION
↓
OUTCOME
↓
RE-INGEST
↓
VERIFY
↓
RECONCILE
↓
SPINE
↓
NEW PROJECTION
↓
NEXT WORK
That loop is the core reason Spine exists.
23. The Complete Data Model Relationship
The architecture can therefore be reduced to:
TENANT
│
├── PEOPLE
│ └── ROLES
│
├── DOMAINS
│ └── ENTITIES
│ └── OBJECTS
│ └── FIELDS
│
├── GOALS
│ └── KPIs
│
├── WORK
│ ├── Context
│ ├── Decision
│ ├── Evidence
│ ├── Capability
│ ├── Approval
│ ├── Execution
│ └── Outcome
│
├── MEMORY
│ ├── Organizational
│ ├── Personal
│ └── AI Continuity
│
├── CONNECTORS
│ └── MAPPINGS
│
├── CAPABILITIES
│ └── EXECUTORS
│
└── PROJECTIONS
└── ROLE / POLICY / USER
24. The Architectural Boundary
The cleanest formulation is:
Connectors bring external reality into the system. Mapping translates that reality into the canonical Spine model. Triage governs schema evolution. Spine preserves organizational context and continuity. Projection determines what each participant can see. Work coordinates human and AI activity. Capability Fabric determines what can be done. Governance determines whether it may be done. Execution changes external reality. Reconciliation establishes what actually happened.
That is the missing logical chain between connector → schema → Spine → projection → Work → capability → source → Spine.
25. Final SpineWorkspace Contract
ONE WORKSPACE
│
┌──────────────┴──────────────┐
│ │
HUMAN AI
WORKBENCH AI WORKBENCH
│ │
└──────────────┬──────────────┘
│
SHARED WORK
│
▼
ONE SPINE FABRIC
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
ORGANIZATIONAL PROJECTION CONTINUITY
CONTEXT
│
▼
CAPABILITY FABRIC
│
▼
GOVERNANCE
│
▼
EXECUTION
│
▼
SOURCE SYSTEMS
│
▼
OUTCOME
│
▼
RE-INGEST / VERIFY / RECONCILE
│
▼
SPINE
Final system statement
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. IntegrateWise connects the organization's software ecosystem, translates external system data into a canonical business context, governs schema evolution, projects the appropriate context to each participant, enables humans and AI to coordinate through durable Work and approved capabilities, and continuously verifies and reconciles execution back into the Spine.
And the final architectural doctrine remains:
The Workbench is one. The Spine is one. The Projection is many.
Humans govern. AI helps. Spine preserves continuity.
This keeps the product, data model, connector architecture, human/AI interaction model, capability system, governance and continuity loop as one coherent system rather than a collection of separately evolving subsystems. The Founder Canon explicitly frames SpineWorkspace around the shared Business Context Spine, Human Workbench, AI Workbench and distinct continuity scopes.