IntegrateWise — Canonical Architecture Spec
Version: 1.0 | Date: 2026-08-23 | Status: ACTIVE SOURCE OF TRUTH
Authority: Nirmal (Founder)
The Fundamental Loop
OBSERVE
│
▼
BUSINESS CONTEXT
│
▼
ORIENT
│
▼
SELF-ORGANIZING
WORKSPACE
│
▼
DECIDE
│
▼
TWIN / HUMAN
│
▼
ACT
│
▼
SOURCE SYSTEM EXECUTION
│
▼
RECORD
│
▼
SPINE FABRIC
│
▼
CONTINUITY
│
└──────────────► OBSERVE
1. The Product Boundary
IntegrateWise
IntegrateWise is the company/brand.
Its product proposition is:
Business Context + Business Continuity across an organization's fragmented tool ecosystem.
Spine Workspace
Spine Workspace is the product.
It is:
A self-organizing workspace where people and AI continue and complete work across the organization's authorized business systems without requiring the user to continuously switch tools and reconstruct context.
That means the product is not:
- another CRM
- another project-management system
- another chat application
- another AI agent platform
- another database
- an operating system replacement
It is the working surface and continuity layer across them.
2. The Two Paths
SPINE WORKSPACE
│
┌────────────┴────────────┐
│ │
USER PATH SYSTEM PATH
Experience Execution / Runtime
│ │
▼ ▼
What the user sees How the system operates
and accomplishes to make it possible
User Path asks:
What is the user trying to accomplish?
System Path asks:
What must happen across Spine, tools, intelligence, and execution to accomplish it?
Do not mix these two when defining repositories, features, routes, components, workflows, or services.
3. USER PATH
The User Path is the product experience.
The user should think in terms of business work, not infrastructure.
USER
│
▼
Intent / Business Need
│
▼
Self-Organizing Workbench
│
├── My Work
├── Tasks
├── Inbox
├── Communications
├── Accounts / Records
├── Documents / Knowledge
├── Approvals
├── Activity
├── Canvas
└── Twin
│
▼
Context appears automatically
│
▼
User understands situation
│
▼
User decides / requests / approves
│
▼
Work is performed
│
▼
User sees outcome
The user should not have to reason:
Which database?
Which connector?
Which MCP?
Which agent?
Which workflow?
Which provider?
Which model?
Which queue?
Which worker?
Those belong to the System Path.
4. User Path: Three Experience Layers
A. User Workbench
This is where humans actually work.
It contains:
- personal view
- work view
- organizational context
- tasks
- communications
- records
- documents
- knowledge
- activity
- approvals
- business views
- contextual actions
- Twin interaction
Different users get different views according to their role/work.
B. Twin
Twin is not another destination the user must manage.
The user should effectively have:
one primary AI relationship
That relationship is Twin.
User
│
▼
Twin
│
├── understands user context
├── assembles business context
├── reasons
├── proposes
├── delegates
├── coordinates
└── reports outcome
Twin may use other agents, models, MCP, tools, workflows, capabilities — but those remain implementation/runtime mechanisms.
C. Agentic Workbench
This is the machine-facing operational surface.
It exists for:
- agent runs
- model interactions
- task execution
- delegated work
- tool execution
- agent state
- workflow state
- operational traces
- reasoning context
- execution monitoring
Human Work
↓
User Workbench
AI Work
↓
Agentic Workbench
Twin becomes the bridge between them.
5. SYSTEM PATH
The System Path begins whenever something enters or changes the ecosystem.
IDENTITY
↓
INGESTION
↓
CONTEXT / MEMORY
↓
PROJECTION
↓
INTELLIGENCE
↓
CAPABILITY / EXECUTION
↓
SOURCE SYSTEM
↓
EVENT / RECEIPT
↓
SPINE
6. System Path — Phase 1: Identity
Everything starts with:
User / Agent / Tool
│
▼
One Auth
│
▼
Identity + Tenant + Authority
Identity is not just an authentication feature.
It establishes:
- who
- which tenant
- which role
- which authority
- which capabilities
- which data boundary
- which actions are permitted
This becomes foundational to both paths.
7. System Path — Phase 2: Ingestion
Flow A — Structured Operational Data
Source Tool
↓
Connector / Loader
↓
Normalizer
↓
Context extraction
↓
Spine
Flow B — Unstructured Business Data
Source
↓
Loader
↓
Normalizer / Parser
↓
Semantic/context extraction
↓
Spine
Flow C — AI / Agentic Activity
AI / Agent
↓
Spine interface
↓
Memory/context processing
↓
Spine
Flow D — Identity / Authorization Gate
Flow D is a system prerequisite, not a data type.
AUTHORITY / IDENTITY
│
┌────────────┼────────────┐
▼ ▼ ▼
Flow A Flow B Flow C
Structured Unstructured AI
│ │ │
└────────────┼────────────┘
▼
Loader/Normalizer
│
▼
Spine Fabric
8. Spine Fabric
Spine Fabric is not one database.
It is a collection of storage and memory mechanisms:
SPINE FABRIC
│
┌─────────────────────┼─────────────────────┐
│ │ │
Canonical Truth Operational Memory Artifacts
│ │ │
│ │ ├── documents
│ │ ├── images
│ │ ├── audio
│ │ ├── video
│ │ └── attachments
│ │
├── entities ├── events
├── relationships ├── context
├── transactions ├── embeddings
├── KPIs ├── semantic memory
└── business truth └── active work state
Spine Fabric is the organization's persistent business-context substrate.
It contains the story of what has happened, not merely snapshots of records.
9. Spine Has Two Logical Planes
SPINE FABRIC
│
┌──────────┴──────────┐
│ │
CANONICAL PLANE OPERATIONAL PLANE
│ │
source-of-truth working/contextual
governed truth projections + memory
│ │
protected AI / agents / workspace
│ │
└──────────┬──────────┘
│
governed bridge
Canonical
Protects authoritative truth.
Operational
Makes that truth usable by Workspace, Twin, agents, workflows, context assembly, search, projections, execution.
Do not expose the canonical plane as the user's working interface.
10. Context Assembly
Context assembly is a first-class system operation.
Business Need / User Intent
│
▼
Context Resolver
│
├── User context
├── Work context
├── Organization context
├── Entity context
├── Event history
├── Relevant documents
├── Conversations
├── Related transactions
├── Policies
└── Available capabilities
│
▼
Context Bundle
│
┌────┴─────┐
▼ ▼
Human Twin
View Reasoning
11. What Makes the Workspace "Self-Organizing"
The workspace organizes the relevant work, context, capabilities, and AI assistance around the user's current business need.
Not random UI rearrangement. Targeted assembly.
Example:
Task: Refund requested
Instead of:
Gmail → Salesforce → Zendesk → Stripe → Slack → Notion → Excel → AI
The Workspace assembles:
REFUND REQUEST
├── Customer
├── Account
├── Contract
├── Subscription
├── Previous tickets
├── Relevant emails
├── Slack discussion
├── Payment history
├── Refund policy
├── Previous decisions
├── Current risk
├── Recommended action
├── Supporting evidence
└── Twin
12. Capability Assembly
Each workspace state has two dynamically assembled dimensions:
CONTEXT + CAPABILITY
Example:
Refund Request
Context:
- customer history
- payment history
- support history
- contract
- policy
- previous decisions
Capabilities:
- approve refund
- reject refund
- request review
- reply to customer
- update CRM
- issue refund
- create follow-up task
13. Execution Path
USER
↓
WORKBENCH
↓
ACTION / INTENT
↓
TWIN / GOVERNANCE
↓
CAPABILITY
↓
WORKFLOW / ORCHESTRATION
↓
SOURCE TOOL
↓
RESULT
↓
EVENT / RECEIPT
↓
SPINE
↓
UPDATED CONTEXT
↓
WORKBENCH
The rule:
Read context from Spine; execute against source systems; record the resulting event/receipt back into Spine.
Not: "Everything executes inside Spine."
14. Where Agents Belong
Agents are workers inside the System Path.
TWIN
│
delegates / coordinates
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Agent A Agent B Workflow
│ │ │
└─────────────┼─────────────┘
▼
Capabilities
│
▼
Source Tools
The user does not manage agents. Twin does.
15. MCP's Correct Position
MCP is an interoperability mechanism, not the architecture.
Spine Network / MCP
│
├── expose context
├── expose capabilities
├── expose tools
└── expose continuity
The architectural primitive is:
Spine capability/context network
not:
MCP network
MCP is one transport/interface mechanism.
16. Complete Architecture
INTEGRATEWISE
BUSINESS CONTEXT
+ BUSINESS CONTINUITY
│
▼
┌─────────────────┐
│ SPINE WORKSPACE │
│ PRODUCT │
└────────┬────────┘
│
┌─────────────┴─────────────┐
│ │
USER PATH SYSTEM PATH
│ │
▼ ▼
User Workbench Identity/Auth
│ │
▼ ▼
Business Need Connectivity
│ │
▼ ▼
Contextual Workspace Ingestion
│ A / B / C
▼ │
Twin Interaction ▼
│ Loader/Normalizer
▼ │
Decision / Approval ▼
│ SPINE FABRIC
▼ │
User Action ┌──────┴──────┐
│ │ │
│ Canonical Operational
│ │ │
│ └──────┬──────┘
│ │
│ Context Assembly
│ │
│ Capability Fabric
│ │
│ Twin / Agents
│ │
│ Orchestration
│ │
└──────────────────────► Execution
│
▼
Source Systems
│
▼
Events / Receipts
│
▼
SPINE FABRIC
│
▼
Updated Workspace
17. Repository-Wide Ownership Model
| Area | Owns |
|---|---|
| Spine Workspace | User experience, workbench, projections, work surfaces |
| Spine Fabric | Business context, organizational memory, events, continuity |
| Context Assembly | Deciding what context is relevant |
| Twin | Primary AI representative, reasoning, delegation |
| Capability Fabric | What actions are available and under what authority |
| Integration Manager | Connections/authentication to external systems |
| Loader/Normalizer | Extracting and transforming source data into Spine-compatible representations |
| Workflow/Orchestration | Executing multi-step operations |
| Connectors/MCP | Transport/interface to external systems and AI environments |
| Governance | Policy, approval, authorization, evidence |
| Source Systems | Actual domain execution and authoritative operational state |
| Agentic Workbench | AI operational visibility and execution environment |
18. One Canonical One-Liner
Spine Workspace is the user-facing self-organizing workbench; Spine Fabric is the shared business-context and continuity substrate; Twin is the user's primary digital representative; capabilities and workflows execute authorized work through connected source systems; every resulting event returns to Spine so humans and AI can continue from the same evolving business truth.
This is the repo-wide conceptual spine.