Canonical End-to-End Specification
The complete single-continuous-system architecture of IntegrateWise: Discover → Hydrate → Normalize → Classify → Relate → Project → Work → Execute → Reconcile → Grow.
The architecture is expressed as one continuous system rather than as separate features.
The governing idea is:
Humans and AI work toward the same business objective, from their own workbenches, using the same governed business context.
The mechanism is:
Discover → Hydrate → Normalize → Classify → Relate → Project → Work → Execute → Reconcile → Grow.
This aligns with the current canonical architecture: the Spine is the protected organizational-context core, the Workbench is a projection of that Spine, the Projection Engine composes authorized context contracts, and the Continuity Bridge/MCP boundary exposes the system to external AI/application surfaces.
1. What IntegrateWise Actually Is
IntegrateWise is not another CRM, another ETL platform, another AI chatbot, or another collection of connectors.
The existing systems remain the systems where operational work happens.
IntegrateWise provides the layer that makes those systems contextually continuous.
EXISTING ECOSYSTEM
Salesforce HubSpot Zendesk Jira Slack Gmail Notion
│ │ │ │ │ │ │
└───────────┴────────┴───────┴───────┴───────┴───────┘
│
▼
IW SPINE NETWORK
│
▼
SPINE
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Context Memory Relationships
│ │ │
└─────────────┼─────────────┘
▼
PROJECTION ENGINE
│
▼
WORKBENCH
│
┌─────────┴─────────┐
▼ ▼
HUMAN TWIN
│ │
└─────────┬─────────┘
▼
DECISION / WORK
│
▼
GOVERNED EXECUTION
│
▼
SOURCE SYSTEMS
│
▼
RECONCILIATION
│
▼
SPINE
The canonical operating loop is explicitly:
Tools → Spine → Workbench → Human/AI → Tools → Reconciliation → Spine.
2. The First Principle: Know the User
When a user installs or authorizes IW Spine Network MCP through an AI host such as ChatGPT, the first objective is not to start copying data.
The first objective is:
Understand the user and discover the ecosystem in which that user already works.
So the first event is:
USER
│
▼
AUTHORIZE IW SPINE NETWORK
│
▼
DISCOVERY
│
├── User
├── Tenant
├── Workspace
├── Role
├── Department
├── Connected tools
├── MCPs
├── Plugins
├── Skills
├── Knowledge sources
├── Files
└── Existing work/context
This is the missing bridge between an AI host and a business-context system.
The architecture defines host-environment discovery, connector/capability discovery, first-use hydration and initial Twin context as part of onboarding.
3. Important Boundary: Discovery Does Not Mean Credential Theft
If ChatGPT has 50 tools, IntegrateWise does not receive ChatGPT's private OAuth credentials.
Likewise, if Claude has 50 connected applications, IntegrateWise does not silently acquire Claude's credentials.
The architecture must distinguish:
DISCOVERY
≠
CREDENTIAL REUSE
The Spine Network discovers what the host exposes and what is authorized to be discovered.
The actual live capability can subsequently be reached through:
- The current host, if that host exposes it;
- An IntegrateWise-authorized connection;
- Another explicitly authorized capability route.
Host authorization does not automatically transfer OAuth authority between hosts.
Therefore the promise is:
Continuity without unnecessary re-authentication—not unauthorized credential sharing.
4. Discovery: The User's Existing AI Ecosystem Becomes Visible to Spine
Suppose:
Claude
├── Salesforce
├── HubSpot
├── Slack
├── Gmail
├── Notion
├── Jira
├── GitHub
├── Linear
├── Zendesk
└── 40 other tools
The user should not have to manually register those 50 systems one by one.
The host discovery process identifies the capabilities available to the user.
Claude
│
▼
IW Spine Network
│
▼
Discovery
│
├── Tool 1
├── Tool 2
├── Tool 3
├── ...
└── Tool 50
│
▼
Capability / Connection Registry
This does not mean all 50 tools become data warehouses inside Spine.
It means Spine understands:
These capabilities exist, they are associated with this user's ecosystem, and here is how authorized work can reach them.
5. Then Spine Hydrates
Once discovery establishes the ecosystem, the system starts building the user's business context.
There are three primary data flows, with Flow D providing the prerequisite authority and activation layer.
Flow D — Identity and Authority
Identity
Authentication
Authorization
Consent
Tenant
Workspace
Role
Permissions
Connector eligibility
Ingestion activation
Flow D must exist before A/B/C ingestion.
6. Flow A — Structural Business Data
The first data layer is structured operational information.
For ten connectors:
Connector 1 → SSOT
Connector 2 → SSOT
Connector 3 → SSOT
...
Connector 10 → SSOT
Examples:
Account
Contact
Opportunity
Ticket
Subscription
Invoice
Usage
Project
Task
Status
Owner
KPI
But:
IntegrateWise does not copy the entire connector.
It extracts the canonical entities and relationships required for business continuity.
The bulk operational data remains in the originating systems.
So:
SOURCE SYSTEM
│
├──────────────► Operational detail stays here
│
└──────────────► Relevant SSOT
│
▼
SPINE
7. Flow B — Business Context
Flow B captures what happens around the structured records.
For example:
Emails
Slack
Documents
Tickets
Comments
Meeting notes
Meeting transcripts
Tasks
Projects
Commitments
Decisions
This is what explains the structured state.
For example:
CRM:
Renewal = delayed
does not tell you why.
Flow B may contain:
Customer email:
"We cannot proceed until the issue is fixed."
Support:
Ticket unresolved.
Product:
Feature request still pending.
Slack:
CSM escalating the issue.
Together:
STRUCTURED STATE
+
BUSINESS CONTEXT
=
BUSINESS STORY
8. Flow C — Conversational / AI Continuity
Flow C captures the continuity created by AI interaction.
ChatGPT conversations
Claude conversations
AI sessions
Twin interactions
Agent work
Plans
Proposals
Tool execution context
Generated artifacts
Candidate memories
This matters because the AI itself becomes part of the user's working history.
For example:
User:
"Investigate why ACME renewal is slipping."
AI:
"Potential causes are support backlog and declining adoption."
User:
"Check product usage."
AI:
"Usage dropped 23%."
User:
"Prepare a customer recovery plan."
That sequence itself becomes useful context.
It should not disappear when the chat session ends.
9. Processing Before It Becomes Spine Context
A/B/C data is processed through the normalization and knowledge pipeline:
Source
│
▼
Ingestion
│
▼
Normalization
│
├── Entity extraction
├── Relationship mapping
├── Metadata
├── Provenance
├── RAG indexing
└── Embeddings
│
▼
Canonical Spine
The Spine is more than a SQL database: it includes operational truth/state, evidence, search, embeddings, relationships, provenance, event history and bounded context projections.
10. What Actually Lives in the Spine
The resulting Spine contains the continuity representation of the business.
Conceptually:
SPINE
│
├── Entities
├── Relationships
├── Business state
├── KPIs
├── Signals
├── Communications/context
├── Knowledge
├── Memory
├── Evidence
├── Provenance
├── Events
├── Work
├── Connections
├── Capabilities
├── Continuity
└── Projection state
The important distinction is:
Spine stores what the organization needs to remember and understand—not a blind copy of every source system.
11. Three Memory Classifications
Once the information enters the continuity layer, it must be classified.
SPINE
│
┌────────────┼────────────┐
▼ ▼ ▼
ORGANIZATIONAL USER AGENTIC
MEMORY MEMORY MEMORY
Organizational
Shared tenant-level truth.
Accounts
Contracts
Policies
Formal decisions
Company KPIs
Organizational context
User
The individual user's working context.
Personal preferences
Private working context
Tasks
Personal focus
Drafts
User-specific views
Agentic
AI operational continuity.
Plans
Agent work
Proposals
Execution history
Working state
Candidate memories
The distinction is critical because AI-generated information cannot automatically become organizational truth without explicit human governance.
12. The Universal Anchor: Account
For B2B, the primary cross-system anchor is:
Account.
Example:
ACME
│
├── CRM
├── Support
├── Billing
├── Product Usage
├── Email
├── Slack
├── Meetings
├── Documents
├── Projects
└── AI conversations
The account becomes the gravitational center through which the different systems can be related.
13. Why Account Changes Everything
Consider:
Support ticket unresolved
↓
Feature request unresolved
↓
Product usage declines
↓
Customer health declines
↓
Renewal becomes risky
↓
Payment is delayed
The information is distributed across different systems.
The CSM may only see:
Usage ↓
The salesperson may only see:
Payment delayed
Support sees:
Ticket open
Product sees:
Feature request
The Spine connects these signals through the account.
14. Spine Does Not Need to Know Everything
Suppose Spine knows:
ACME
HubSpot Account ID = 123
Zendesk Account ID = 456
Stripe Customer ID = 789
And:
Renewal = at risk
Usage = declining
Support issue = unresolved
But the user asks:
"What exactly happened in the last three support interactions?"
Spine doesn't need to contain every Zendesk conversation.
Instead:
Co-worker
│
▼
Spine
│
▼
ACME
│
▼
Zendesk connection/capability
│
▼
Account ID 456
│
▼
Retrieve required detail
│
▼
Context assembly
That is the SSOT + deep-source retrieval model.
15. MCP's Actual Role
This makes the role of MCP much clearer.
MCP is not the Spine.
MCP is not the business context.
MCP is not the source of truth.
MCP is a communication/capability protocol.
SPINE
│
▼
CO-WORKER
│
▼
CAPABILITY FABRIC
│
▼
MCP / API / AGENT
│
▼
SOURCE PLATFORM
The architecture defines MCP as the outward protocol boundary and MCP Pool as the inward registry of approved MCP servers/tools.
16. The Co-worker's Job
The Co-worker does not blindly query ten systems.
It first asks:
What do I already know?
Then:
What is missing?
Then:
Where can I obtain that missing information?
So:
USER QUESTION
│
▼
CO-WORKER
│
▼
READ SPINE
│
▼
UNDERSTAND ACCOUNT
│
▼
CONTEXT COMPLETE?
/ \
YES NO
│ │
│ ▼
│ CAPABILITY FABRIC
│ │
│ MCP / API / AGENT
│ │
│ SOURCE SYSTEM
│ │
│ REQUIRED DETAIL
│ │
└───────┬─────┘
▼
CONTEXT ASSEMBLY
│
▼
USER
This is where the system becomes materially different from a normal RAG application.
17. Projection
The Spine contains organizational context.
The user should not receive all of it.
The Projection Engine composes the authorized view.
The canonical model defines the Projection Engine as the sole composer of authorized, versioned Workbench/context contracts.
The projection is determined by:
Role
×
Department
×
Industry
×
Permissions
×
Connectors
×
Current Context
×
Account
18. Same Account, Different Projection
Sales
ACME
├── Opportunity
├── Pipeline
├── Stage
├── Contacts
├── Competitors
├── Pricing
└── Close date
CSM
ACME
├── Health
├── Usage
├── Support
├── SLA
├── Commitments
├── Renewal
└── Risk
Marketing
ACME
├── Engagement
├── Campaigns
├── Content
├── Account activity
└── Attribution
The account is the same.
The context is the same underlying organizational reality.
The projection is different.
19. Connectors Automatically Enrich the Projection
Suppose the tenant has:
CRM
Support
Billing
Product Analytics
Conversation Intelligence
The projection can expose:
CRM → pipeline
Support → tickets
Billing → renewal/payment
Product → usage
Conversation Intelligence → call signals
If Gong is added:
NEW CONNECTOR
↓
CATEGORY
↓
DOMAIN EXTENSION
↓
NEW FIELDS / KPIs
↓
SPINE SCHEMA VERSION
↓
PROJECTION UPDATE
This is schema growth rather than schema freeze: a new connector activates a semantic/domain extension, registers fields/KPIs, adjusts the versioned Spine schema and enriches the user projection.
20. The Workbench
The Workbench is not another database.
It is a projection of the Spine.
SPINE
│
▼
PROJECTION ENGINE
│
▼
AUTHORIZED CONTEXT CONTRACT
│
▼
WORKBENCH
The Workbench can show:
- Accounts
- Tasks
- Signals
- KPIs
- Communications
- Documents
- Timeline
- Work
- Approvals
- Relevant connector capabilities
- Twin interactions
These are projections, not independent truth stores.
21. Then the Human + AI Loop Starts
Now the system has context.
The user doesn't need to rebuild it.
The OODA loop becomes:
OBSERVE
Spine shows what is happening.
↓
ORIENT
Co-worker assembles cross-system context.
↓
DECIDE
Human determines what matters.
↓
ACT
AI prepares/executes the authorized work.
↓
RECONCILE
System verifies what actually happened.
↓
REMEMBER
Spine is updated.
↓
GROW
Next cycle starts with more context.
22. Human Authority Remains Central
AI can:
Search
Correlate
Analyze
Summarize
Prepare
Recommend
Draft
Coordinate
Execute authorized actions
The human decides:
Is this the right solution?
Does this actually solve the problem?
Is this appropriate for this customer?
Should we proceed?
What matters?
Therefore:
AI gathers, connects and proposes. Human judges, decides and authorizes.
The Spine remembers both sides of the interaction.
23. Execution
Once the user approves:
USER DECISION
│
▼
PROPOSAL
│
▼
GOVERNANCE
│
▼
APPROVAL TOKEN
│
▼
HERMES
│
▼
CAPABILITY FABRIC
│
▼
MCP / API / AGENT
│
▼
SOURCE SYSTEM
The crucial rule is:
Provider acceptance is not final truth.
Outcome capture must be followed by verification/reconciliation before the Spine is treated as updated truth.
24. Reconciliation
Suppose the Co-worker creates a Salesforce opportunity update.
Salesforce says:
SUCCESS
That is only an Outcome Event.
The system then verifies:
Expected state
vs
Actual state
Then:
EXPECTED
↓
EXECUTED
↓
PROVIDER OUTCOME
↓
RE-INGEST
↓
VERIFY
↓
RECONCILE
↓
CANONICAL SPINE UPDATE
Only then does the projection refresh.
25. The Spine Therefore Gets Better Over Time
Every completed cycle produces additional continuity.
DAY 1
Discovery
↓
Initial Spine
DAY 2
New work
↓
More context
DAY 3
New execution
↓
New outcome
DAY 30
Accumulated business history
DAY 300
Deep organizational + user + AI continuity
The next interaction starts from:
KNOWN CONTEXT + NEW DELTA
That is the core value.
26. The Complete Architecture
AI HOST
ChatGPT / Claude / etc.
│
▼
IW SPINE NETWORK MCP
│
AUTHORIZATION
│
▼
DISCOVERY
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
USER ECOSYSTEM WORK
Identity/Role MCPs/Tools/Plugins Conversations
Tenant/Workspace Skills/Connections Files/Activity
│ │ │
└─────────────────────┼─────────────────────┘
▼
FLOW D
Identity / Authority / Activation
│
┌────────────────┼────────────────┐
▼ ▼ ▼
FLOW A FLOW B FLOW C
Structured Business AI /
SSOT Context Conversations
│ │ │
└────────────────┼────────────────┘
▼
NORMALIZATION / RAG /
EMBEDDINGS / PROVENANCE
│
▼
CANONICAL SPINE
│
┌────────────────┼────────────────┐
▼ ▼ ▼
ORGANIZATIONAL USER AGENTIC
MEMORY MEMORY MEMORY
│ │ │
└────────────────┼────────────────┘
▼
ACCOUNT MODEL
│
▼
RELATIONSHIP GRAPH
│
▼
PROJECTION ENGINE
│
ROLE × DEPT × INDUSTRY
× CONNECTORS × CONTEXT
│
▼
WORKBENCH
│
USER / TWIN
│
▼
USER INTENT
│
▼
CONTEXT ASSEMBLY
│
┌─────────┴─────────┐
▼ ▼
SPINE CONTEXT MISSING DATA
│ │
│ CAPABILITY FABRIC
│ │
│ MCP / API / AGENT
│ │
│ SOURCE SYSTEM
│ │
└─────────┬─────────┘
▼
HUMAN DECISION
│
▼
GOVERNANCE
│
▼
HERMES
│
▼
EXECUTION
│
▼
PROVIDER OUTCOME
│
▼
RE-INGESTION
│
▼
RECONCILIATION
│
▼
VERIFIED SPINE UPDATE
│
▼
EVIDENCE + AUDIT
│
▼
MEMORY PROMOTION
│
▼
LIVE WORKBENCH REFRESH
│
▼
NEXT WORK CYCLE
│
▼
GROWTH
27. The Most Important Conceptual Separation
| Layer | Primary responsibility |
|---|---|
| Host | Where the user/AI is operating |
| IW Spine Network | External access/distribution boundary into IntegrateWise |
| Discovery | Understand user ecosystem and available capabilities |
| Connectors | Reach source systems |
| Flow A | Structured SSOT |
| Flow B | Business context |
| Flow C | AI/conversational continuity |
| Flow D | Identity, authority and activation |
| Spine | Canonical business continuity/context |
| Account | Cross-system business anchor |
| Projection Engine | Decide what context the user is authorized to see |
| Workbench | Human operating surface |
| Twin / Co-worker | Contextual intelligence |
| Capability Fabric | Resolve how an authorized capability can be performed |
| MCP | Communication/protocol boundary |
| Governance | Authority and approval boundary |
| Hermes | Approved execution lifecycle |
| Reconciliation | Determine whether the intended change actually occurred |
28. The Actual Product Flywheel
Everything ultimately reduces to this:
KNOW
│
▼
DISCOVER
│
▼
HYDRATE
│
▼
REMEMBER
│
▼
LEARN
│
▼
PROJECT
│
▼
WORK
│
▼
DECIDE
│
▼
EXECUTE
│
▼
RECONCILE
│
▼
GROW
│
└──────────────► KNOW
Or, in the shortest possible form:
Know the user. Learn the user. Grow with the user.
And the technical interpretation is:
Discover the user's ecosystem, preserve the business context that matters, project the right context to the right human or AI worker, execute through governed capabilities, reconcile the outcome, and continuously add the resulting knowledge back into the Spine.