Unclassified

IntegrateWise — Architecture Lock v1.1

Status: SUPERSEDED — absorbed into INTEGRATEWISE_ARCHITECTURE.md v2.1. Implementation details amended by
IMPLEMENTATION_CONTRACT_v1.1.md; runtime
terminology clarified by
CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md
Original freeze: July 17, 2026
v1.1 clarification: July 28, 2026
Source: Code excavation of integratewise-live codebase

I. PLATFORM CANON

The 12 Kernel Terms

Term	Definition	Owner
WORK	A human or machine is moving an objective through state	Spine
CONTEXT	The minimum relevant connected state required to understand current work	Continuity
SPINE	The canonical connected model of operational work state	Spine
CONTINUITY	The preservation and bounded transfer of relevant context across time, systems, humans, and agents	Bridge
WORKBENCH	The role-specific projection of work and context presented to a human	Product
TWIN	The non-authoritative cognitive participant that consumes grounded context	Intelligence
CAPABILITY	A registered operation that may read, derive, or change work state	MCP Pool
GOVERNANCE	The authority that determines whether a capability or proposed consequence is permitted	Governance
HERMES	The execution coordinator for authorized capability invocations	Execution
SYNC	The reconciliation of resulting state across connected systems	Sync
BRIDGE	The governed exchange boundary through which an authorized consumer receives or contributes bounded continuity	Bridge
OUTCOME	The observed result of work or execution that may become new canonical state	Spine

The OODA Grammar

OODA	Action	Meaning
Observe	Store in Spine	Capture truth
Orient	Ask Your Twin	Understand the work
Decide	Assign Your Twin	Delegate intent
Act	Approve Twin's Action	Authorize execution

The Frozen Laws

Twin Law: Twin is a capability of the Workbench, not a panel.
Context Law: The human never explains already-known work context to AI.
Memory Law: Spine owns truth. Memory informs truth. Memory is not truth.
Authority Law: Confidence increases trust. Confidence never grants authority.
Silence Law: Twin prefers silence over low-value commentary.
Capability Law: Workbench projects tool capabilities, doesn't duplicate tools.
Bridge Law: One platform. One boundary. Different projections.
Product–Platform Law: Broad underneath. Narrow at the surface.

The Runtime Sequence (Frozen)

Configuration
    ↓
Integration
    ↓
Pipeline
    ↓
Adaptive Spine
    ↓
Workbench Composition
    ↓
Continuity Bridge
    ↓
User Workbench
    ↓
Twin
    ↓
Capability
    ↓
Governance
    ↓
Hermes
    ↓
Sync
    ↓
Promotion

The Go-Live Sequence (Frozen)

Go-live promotes the same verified Product and Platform versions through three
isolated environments:

Development proof
→ Customer Zero validation
→ Customer Production release

The mandatory promotion sequence is:

source commit
→ CI and contract tests
→ Development artifacts
→ Customer Zero private installation
→ Customer Zero evidence
→ version freeze
→ external clean-tenant test
→ Plugin and MCP submission-ready
→ public publication

Phase	Required result
Shared contracts	Freeze the exact 19 public tools, resource schemas, UI intents, discovery envelope, tenant binding contract and versioned activation profiles.
Customer Zero Plugin	Privately install the focused embedded UI and prove identity, host composition, explicit delegation, approval, Hermes execution and outcome reconciliation.
Customer Zero MCP and Workbench	Deploy the OAuth-protected remote MCP, verify exactly 19 tools, prove ordinary-client fallback, launch the browser Workbench and verify discovery-first RBAC projections.
Externalization	Install the same artifacts into a clean external tenant and prove dynamic tenant resolution, customer-owned connectors and complete Customer Zero isolation.
Publication	Freeze compatible versions, submit the Plugin, publish the MCP, verify a new-tenant installation and operate governed monitoring, rollback, revocation and deprecation.

Go-Live Laws

Same-Artifact Law: Customer Zero and external customers use the same build with server-selected profiles. Do not create Product forks.
One-Way Promotion Law: Promote only code, manifests, definitions, schemas and versioned activation defaults. Never promote tenant data, credentials, connector bindings, queues, caches, evidence, audit records or runtime state.
Customer Zero Proof Law: Customer Zero must run daily work through both the Plugin and browser Workbench before external publication.
Clean-Tenant Law: The frozen Customer Zero-verified versions must install into an unrelated tenant without code changes or Customer Zero-only dependencies.
Governed Execution Law: Every external action requires a scoped human approval token, Hermes execution, audit evidence and outcome reconciliation into the Spine.
Compatibility Law: The release manifest records compatible Plugin, MCP, frontend, Gateway and Platform versions and the last compatible rollback set.

Stop-Ship Gate

Do not begin external testing or publication if environment isolation, tenant
authority, the exact 19-tool contract, clean installation, connector lifecycle,
projection/RBAC enforcement, governed execution, reconciliation, observability,
revocation or rollback lacks live evidence. The detailed evidence gates are
defined in
CUSTOMER_ZERO_TO_EXTERNAL_PRODUCT_AND_MARKETPLACE_SPEC.md
and
CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md.

The GTM Marketplace Model (Frozen)

Go-to-market (GTM) is the complete path from discovery to retained governed
value. A marketplace listing is one acquisition mechanism within that path.

IntegrateWise has three marketplace surfaces with different jobs:

Marketplace	GTM role	Published or activated item	Primary experience
Plugin Marketplace	External acquisition and embedded activation	IW-Spine-Network Plugin	A focused MCP-backed UI, skills and approvals inside an AI host. The host controls conversation and model orchestration.
MCP Marketplace	External acquisition and tool-first activation	IW-Spine-Network MCP	The exact 19 public tools, meaningful text/JSON fallback, optional widgets and launch into the full browser Workbench.
Connector Marketplace	In-product capability activation and expansion	A tenant-scoped provider `Connection`, connector binding, schema mapping and capability grant	Users connect, reuse, monitor, revoke and replace operational systems inside IntegrateWise. It does not install IntegrateWise itself.

Plugin and MCP marketplaces distribute IntegrateWise. Connector Marketplace
expands what an activated IntegrateWise workspace can observe and govern. They
converge on the same tenant, Workspace, Adaptive Spine, Gateway, public tool
semantics and governed execution path.

Category and demand
→ Plugin Marketplace, MCP Marketplace or direct Workbench activation
→ identity, tenant, consent and workspace activation
→ Connector Marketplace connection or eligible connection reuse
→ Spine hydration and role projections
→ first grounded value
→ first approved governed outcome
→ additional connectors, roles and recurring use

The shared north-star metric is time to first approved governed outcome.
Channel metrics diagnose that path:

Plugin and MCP marketplaces: listing view → install → active
Connector Marketplace: discover → consent → bind or reuse → healthy → hydrated
Product: first grounded response → first approval → reconciled outcome → recurring use

Provider or developer marketplaces may require a channel-native package, OAuth
lifecycle or webhook contract. That package is a distribution adapter over the
same Product and Platform contracts, not a fourth product or a new source of
truth.

II. PLATFORM ARCHITECTURE

The Four Planes

┌─────────────────────────────────────────────┐
│  EXPERIENCE PLANE                           │
│  User Workbench · Twin · Admin · Mobile     │
│  AI Chat · Model Selector · Agent Canvas    │
├─────────────────────────────────────────────┤
│  INTELLIGENCE PLANE                         │
│  Hermes · Knowledge · Memory · Signals      │
│  Model Gateway · Omni Router                │
├─────────────────────────────────────────────┤
│  EXECUTION PLANE                            │
│  Gateway · MCP Pool · Provider MCP          │
│  Integration MCP · Task MCP                 │
├─────────────────────────────────────────────┤
│  FOUNDATION PLANE                           │
│  Adaptive Spine · Identity · Security       │
│  Storage · Timeline · Provenance            │
└─────────────────────────────────────────────┘

The Gateway (Entry Point)

Service: services/gateway/ (46 files)
Domain: gateway.dev.integratewise.ai
Canonical truth: Neon Postgres
Bounded edge state: D1 integratewise-spine-cache

Env Bindings (Frozen)

Category	Binding	Type
Database	DB	D1Database
KV	RATE_LIMITS	KVNamespace
KV	SESSIONS	KVNamespace
KV	CONNECTOR_STATUS	KVNamespace
KV	SIGNAL_CACHE	KVNamespace
KV	METRICS	KVNamespace
KV	OAUTH_STATE_KV	KVNamespace
R2	FILES	R2Bucket
Services	CONNECTOR	Fetcher
Services	CONNECTOR_SYNC	Fetcher
Services	PIPELINE	Fetcher
Services	INTELLIGENCE	Fetcher
Services	KNOWLEDGE	Fetcher
Services	BFF	Fetcher
Services	L2	Fetcher
Services	AGENT_RUNTIME	Fetcher
Services	ADMIN	Fetcher
Services	BILLING	Fetcher
Services	TENANTS	Fetcher
Services	WEBHOOK_INGRESS	Fetcher
Services	HUB_CONTROLLER	Fetcher

Gateway Route Table (Frozen)

Route	Target	Purpose
`/api/v1/auth`	INTERNAL_AUTH	Authentication
`/api/v1/projections`	INTERNAL_PROJECTIONS	Projection Engine
`/api/v1/billing`	INTERNAL_BILLING	Billing
`/api/v1/tenants`	INTERNAL_TENANTS	Tenant management
`/api/v1/support`	INTERNAL_SUPPORT	Support
`/api/v1/analytics`	BFF	Analytics
`/api/v1/agents`	INTELLIGENCE	Agent management
`/api/v1/continuity-bridge`	MCP_CONNECTOR	Public 19-tool Spine MCP
`/api/v1/connectors`	CONNECTOR	Connector management
`/api/v1/pipeline`	PIPELINE	Data pipeline
`/api/v1/intelligence`	INTELLIGENCE	Intelligence layer
`/api/v1/cognitive/spine`	PIPELINE	Spine operations
`/api/v1/cognitive/entity360`	PIPELINE	Entity 360
`/api/v1/cognitive/memories`	KNOWLEDGE	Memory operations
`/api/v1/cognitive/signals`	INTELLIGENCE	Signal processing
`/api/v1/cognitive/think`	INTELLIGENCE	Think/Twin
`/api/v1/cognitive/act`	INTELLIGENCE	Act execution
`/api/v1/cognitive/govern`	INTELLIGENCE	Governance
`/api/v1/cognitive/twin`	AGENT_RUNTIME	Twin runtime
`/api/v1/knowledge`	KNOWLEDGE	Knowledge management
`/api/v1/workspace`	BFF	Workspace operations
`/api/v1/l2`	L2	L2 cognitive overlay
`/admin`	INTERNAL_ADMIN	Admin operations
`/oauth`	INTERNAL_AUTH	OAuth flows
`/ws`, `/sse`, `/stream`	BFF	Real-time connections

Model Gateway Routes (Added)

Route	Target	Purpose
`/api/v1/models`	MODEL_GATEWAY	Model registry & selection
`/api/v1/models/providers`	MODEL_GATEWAY	Provider management
`/v1/chat/completions`	MODEL_GATEWAY	OpenAI-compatible chat
`/v1/completions`	MODEL_GATEWAY	OpenAI-compatible completions
`/v1/embeddings`	MODEL_GATEWAY	Embeddings
`/v1/images/generations`	MODEL_GATEWAY	Image generation
`/v1/audio/transcriptions`	MODEL_GATEWAY	Audio transcription
`/v1/audio/translations`	MODEL_GATEWAY	Audio translation

Omni Router Routes (Added)

Route	Target	Purpose
`/api/v1/omni/tools`	OMNI_ROUTER	Tool registry & discovery
`/api/v1/omni/execute`	OMNI_ROUTER	Tool execution
`/api/v1/omni/connectors`	OMNI_ROUTER	Connector management
`/api/v1/omni/stats`	OMNI_ROUTER	Execution statistics

III. CAPABILITY FABRIC

MCP Pool

Service: services/mcp-pool/ (14 files)
Capabilities: 55 registered
Pattern: Registry → Resolver → Health → Routing → Versioning

Registered MCPs

MCP	Capabilities	Status
Provider Management	15 (`provider.`, `apps.`, `connections.`, `oauth.`)	✅ Built
Integration Management	28 (`connectors.`, `sync.`, `webhooks.`, `schemas.`)	✅ Built
Task Management	12 (`tasks.*`)	✅ Built

Capability API

pool.register(manifest, targetBinding);
pool.resolve({ capability, version });
pool.invoke({ capability, version, args, context });
pool.health();
pool.capabilities();

Provider Management MCP

Service: services/provider-management-mcp/ (15 files)
Capabilities: 15

Domain	Capabilities
`provider.*`	list, health
`apps.*`	list, get, create
`connections.*`	list, get, connect, delete, status, invoke, health
`oauth.*`	start, callback, status

Integration Management MCP

Service: services/integration-management-mcp/ (10 files)
Capabilities: 28

Domain	Capabilities
`connectors.*`	install, configure, enable, disable, remove, get, list, providers, stats
`sync.*`	start, complete, cancel, retry, list, latest, stats
`webhooks.*`	register, pause, resume, remove, list, findByEvent, stats
`schemas.*`	register, normalize, list, latest, entityTypes, diff

Task Management MCP

Service: services/task-management/ (11 files)
Capabilities: 12

Domain	Capabilities
`tasks.*`	create, get, list, update, delete, pause, resume, runNow, history, getDue, markCompleted, markFailed

Model Gateway (Added)

Service: packages/model-gateway/ (NEW)
Routes: /api/v1/models, /v1/chat/completions, /v1/embeddings, /v1/images/generations, /v1/audio/transcriptions
Providers: llama.cpp, Hugging Face, OpenAI, OpenAI-compatible

Capability	Endpoint	Description
Model Registry	`GET /api/v1/models`	List all registered models
Provider Management	`GET /api/v1/models/providers`	List all registered providers
Chat Completions	`POST /v1/chat/completions`	OpenAI-compatible chat
Completions	`POST /v1/completions`	OpenAI-compatible completions
Embeddings	`POST /v1/embeddings`	Text embeddings
Image Generation	`POST /v1/images/generations`	Image generation (DALL-E compatible)
Audio Transcription	`POST /v1/audio/transcriptions`	Speech to text (Whisper compatible)
Audio Translation	`POST /v1/audio/translations`	Translation (Whisper compatible)

Omni Router (Added)

Service: packages/omni-router/ (NEW)
Routes: /api/v1/omni/tools, /api/v1/omni/execute, /api/v1/omni/connectors, /api/v1/omni/stats
Providers: Salesforce, GitHub, Slack, MCP servers (via connector executors)

Capability	Endpoint	Description
Tool Registry	`GET /api/v1/omni/tools`	List all available tools
Tool Execution	`POST /api/v1/omni/execute`	Execute any tool via provider-agnostic router
Connector Management	`GET/POST /api/v1/omni/connectors`	Register/manage connectors
Execution Statistics	`GET /api/v1/omni/stats`	Execution metrics & tracing

IV. ADAPTIVE SPINE

Canonical Entities

Entity	Source	Status
Connection	`packages/spine-entities/src/connection.ts`	✅ Built
Connector	`packages/spine-entities/src/connector.ts`	✅ Built
SyncJob	`packages/spine-entities/src/sync-job.ts`	✅ Built
Webhook	`packages/spine-entities/src/webhook.ts`	✅ Built
Schema	`packages/spine-entities/src/schema.ts`	✅ Built
Capability	`packages/spine-entities/src/capability.ts`	✅ Built
TimelineEvent	`packages/spine-entities/src/timeline.ts`	✅ Built

Entity Contract (Frozen)

Every entity owns:

Property	Meaning
identity	Canonical entity reference (id, provider, tenant)
fields	Structured attributes
relationships	Connected entities
timeline	Temporal history (TimelineEvent)
provenance	Source and lineage
permissions	Access governance
capabilities	Available operations

Spine Service

Service: services/spine/ (scaffolded)
Store: EntityStore<T> — generic CRUD with in-memory Map
Routes: REST API for all 7 entity types

Route	Method	Entity
`/api/v1/connections`	GET/POST	Connection
`/api/v1/connectors`	GET/POST	Connector
`/api/v1/sync-jobs`	GET/POST	SyncJob
`/api/v1/webhooks`	GET/POST	Webhook
`/api/v1/schemas`	GET/POST	Schema
`/api/v1/capabilities`	GET/POST	Capability
`/api/v1/timeline`	GET/POST	TimelineEvent
`/api/v1/stats`	GET	Entity counts

V. PRODUCT SURFACES

The Workbench

The User Workbench is the role-specific projection of work and context presented to a human.

The Workbench is one surface. No L1/L2/L4/L7 layers in the UI.

Sidebar = Capability Navigation

┌────────────────────────────────────────────────────────────┐
│ Header                                                     │
├──────────────┬─────────────────────────────────────────────┤
│ Left Sidebar │                                             │
│              │          Active Workspace                   │
│              │                                             │
│ ── Operational ──                                          │
│ Home         │                                             │
│ Accounts     │                                             │
│ Contacts     │                                             │
│ Meetings     │                                             │
│ Tasks        │                                             │
│ Calendar     │                                             │
│ Docs         │                                             │
│ Knowledge    │                                             │
│ Analytics    │                                             │
│              │                                             │
│ ── Platform ──                                             │
│ Continuity   │                                             │
│ Governance   │                                             │
│ Integrations │  (Integration Manager)                     │
│ Configuration│  (Configuration Manager)                    │
│ Activation   │  (Activation Hub)                           │
│ Network Graphs│ (Spine relationship graph)                │
│ Settings     │                                             │
│              │                                             │
│ Twin: NOT a sidebar item. It surfaces contextually,      │
│       invoked by "Ask your Twin" / "Assign your Twin".    │
│              │                                             │
└──────────────┴─────────────────────────────────────────────┘

Platform section = the platform control surfaces. Each is a real module
wired to the platform, not an architectural layer and not the Twin.

Integrations → Integration Manager (connectors, sync, webhooks, schemas)

Configuration → Configuration Manager (tenant schema, depth matrix, policies)

Activation → Activation Hub (onboarding completion, intelligence activation)

Network Graphs → Spine entity relationship graph

Governance → Approvals, audit, policy gates

Continuity → Memory, context

Twin is silent by default. It is NOT a permanent sidebar destination, panel, or layer.
It observes the pipeline continuously and surfaces only when there is material value
or when the user explicitly engages via the Four Buttons.

The User Never Sees Layers

❌ Never in UI	✅ Always in UI
"Open L2"	"Open Twin"
"Switch to L4"	"Open Continuity"
"Go to L7"	"Open Governance"
"Layer 1 Workbench"	"Open Home"

Internal Architecture (invisible to user)

Workbench (UI)
    ↓
Continuity (L4 — memory, context)
Governance (L7 — approvals, policies)
Twin (L2 — cognitive overlay)
Spine (SSOT)
Gateway (routing)
MCP (capabilities)

External Architecture (what user sees)

Workbench

Role Projection (sidebar per role)

Customer Success:

── Operational ──
Home, Accounts, Contacts, Meetings, Tasks, Calendar, Risks, Renewals, Analytics
── Platform ──
Continuity, Governance, Integrations, Configuration, Activation, Network Graphs, Settings
(Twin is silent — surfaces contextually, not a nav item)

Technology:

── Operational ──
Home, Repositories, Services, Deployments, Incidents, Knowledge, Analytics
── Platform ──
Continuity, Governance, Integrations, Configuration, Activation, Network Graphs, Settings
(Twin is silent — surfaces contextually, not a nav item)

Founder:

── Operational ──
All operational modules (union of all roles)
── Platform ──
Continuity, Governance, Integrations, Configuration, Activation, Network Graphs, Settings
(Twin is silent — surfaces contextually, not a nav item)

Documentation Convention

Context	Reference
Product docs	Workbench, Operational Modules, Platform Capabilities, Twin, Adaptive Spine
Engineering docs	L1 (Workbench), L2 (Cognitive), L4 (Memory), L7 (Governance)
User-facing	Never mention L1–L7

Domain Structure (from IW-CUS-ZERO)

type DomainId =
  | "integratewise-apac" // Founder / Customer Zero
  | "personal" // Personal workspace
  | "account-success" // Customer Success
  | "revops" // Revenue Operations
  | "salesops"; // Sales Operations

Domain Views (Account Success example — 17 views)

domains/account-success/views/
├── account-master-view.tsx
├── api-portfolio-view.tsx
├── business-context-view.tsx
├── capabilities-view.tsx
├── company-growth-view.tsx
├── engagement-log-view.tsx
├── initiatives-view.tsx
├── insights-view.tsx
├── people-team-view.tsx
├── platform-health-view.tsx
├── product-client-view.tsx
├── risk-register-view.tsx
├── stakeholder-outcomes-view.tsx
├── strategic-objectives-view.tsx
├── success-plans-view.tsx
├── task-manager-view.tsx
└── value-streams-view.tsx

Workbench Components

Component	File	Size	Purpose
Workspace Shell	`workspace-shell.tsx`	11KB	Top-level layout, context switching
L1 Module Content	`l1-module-content.tsx`	57KB	Domain-specific module rendering
Onboarding Flow	`onboarding/onboarding-flow.tsx`	26KB	Initial setup and activation
Intelligence Overlay	`intelligence-overlay.tsx`	—	L2 cognitive overlay
Command Palette	`command-palette.tsx`	—	Quick actions
Twin UI	`twin-ui/twin-shell.tsx`	—	Twin interface
Governance Workbench	`governance/governance-workbench.tsx`	21KB	L7 governance/approval
Continuity Shell	`continuity/continuity-shell.tsx`	—	L4 memory hub
Integrations Hub	`integrations-hub.tsx`	—	Connector management

Context Types (CTXEnum)

Context	Role
`CTX_CS`	Customer Success
`CTX_SALES`	Sales
`CTX_SUPPORT`	Support
`CTX_PM`	Project Management
`CTX_MARKETING`	Marketing
`CTX_BIZOPS`	Business Operations
`CTX_TECH`	Technology
`CTX_HR`	Human Resources
`CTX_FINANCE`	Finance
`CTX_LEGAL`	Legal

L1 Module Types

type L1Module =
  | "Home"
  | "Projects"
  | "Accounts"
  | "Contacts"
  | "Meetings"
  | "Docs"
  | "Tasks"
  | "Calendar"
  | "Notes"
  | "Knowledge Space"
  | "Team"
  | "Pipeline"
  | "Risks"
  | "Expansion"
  | "Analytics"
  | "Integrations"
  | "Ingress"
  | "Schema Registry"
  | "Governance"
  | "Continuity"
  | "Operations"
  | "Admin"
  | "AI Chat"
  | "Settings"
  | "Subscriptions"
  | "Profile";

L2 Component Types

type L2Component =
  | "SpineUI"
  | "ContextUI"
  | "KnowledgeUI"
  | "Evidence Drawer"
  | "Signals"
  | "Think"
  | "Act"
  | "HITL"
  | "Govern"
  | "Adjust";

Spine Integration

The Workbench reads from Spine via:

useSpine() — Spine client hook
useDomainTable(domain, table) — Domain-specific data
useSpineProjection(context) — Context projection
useSpineReadiness() — Spine readiness status

Backend Connection

api-client.ts — Direct fetch to /api/*
workspace-api.ts — Workspace-specific API calls
Gateway integration via VITE_API_BASE_URL

VI. DATA FLOW (Canonical)

Source Documents

docs/architecture/source/integratewise-data-flow.md — Canonical data flow KT
docs/architecture/source/code-map-appendix.md — Code implementation map
docs/architecture/source/product-service-offers.md — Productized service offers
docs/architecture/source/app-landing-page.md — App landing page content

The Canonical Runtime Chain

Landing → Auth → L0 Onboarding → L1 Workspace → L2 Cognitive → L3 Backend

The Canonical System Loop

LOAD → NORMALIZE → STORE → THINK → REVIEW & APPROVE → ACT → REPEAT

The Four Flows

Flow	Purpose	Canonical write boundary
Flow A	Structured operational entities, relationships, metrics, events and lifecycle state	Deterministic normalization prepares candidates; governed writers/Pipeline promotion commit.
Flow B	Documents, communications, attachments, transcripts and unstructured evidence	Raw artifacts and extracted context retain provenance; promoted canonical records use governed writers.
Flow C	AI sessions, model output, proposals, tool calls and candidate memory/knowledge/decisions	Never writes operational truth directly; Triage proposes promotion.
Flow D	Identity, tenant, workspace, role, configuration, connection, credential-reference, capability, policy and runtime binding context	Governed Platform configuration writers only; Flow D is not a business-data partition.

v1.1 correction: approved external execution is not Flow D. It is the
downstream governed path:

Twin or user intent
→ Capability Fabric
→ Governance
→ Hermes
→ execution provider
→ provider outcome
→ re-ingestion
→ verification and reconciliation
→ Pipeline promotion

Flow D supplies the authority and binding context used by that path.

Deterministic Normalization Functions

The current implementation may express these as eight stages. The functions and
their deterministic boundary are normative; an internal stage count is not a
separate product concept.

1. Raw Event Ingestion
2. Canonical Field Mapping
3. Schema Normalization
4. Entity Resolution
5. Deduplication
6. Relationship Linking
7. Depth Matrix Evaluation
8. Spine Write

Core Principles

The Spine is the single source of truth — all durable business value must be created through a Spine-based flow
No data may bypass the governed write path — every canonical mutation passes through tenant, schema, provenance, idempotency and authority enforcement
Flow C never writes directly to the Spine — knowledge and decision context only become truth through approved actions
The workspace is not a truth layer — L1 is dynamically generated from Spine data, not a separate SSOT
No action executes without approval — Think → Govern → HITL → Act / Adjust
Normalizer and Triage are separate — Normalizer is deterministic; Triage is adaptive and cannot confer authority
A click is context, not authority — clicks may refresh Active Context and passive observation, but visible Twin reasoning remains governed by the Silence Law

Desktop

App: apps/desktop/ (Electron + electron-vite)
Framework: Electron wrapper
Routes: 0 (wraps web app)
Backend: Indirect (through web app)

Mobile

App: apps/mobile/ (Expo 52 + React Native 0.76)
Framework: expo-router
Routes: 4 tab routes (Dashboard, Signals, Playbook, Settings)
Backend: Direct fetch to /api/v1/*
Status: Scaffolded, no build output

Local Monitor

App: apps/local-monitor/ (Node.js daemon)
Framework: Chokidar file watcher
Purpose: Bridges local filesystem changes into pipeline
Backend: POST to /webhooks/folder-monitor

VI. DATA SUBSTRATE

Neon Postgres (Canonical)

Neon owns canonical operational entities, relationships, lineage, governed
artifacts, and promoted outcomes. Pipeline promotion is its sole writer.

D1 (Bounded Operational State)

Database	Binding	Purpose
`integratewise-spine-cache`	DB (gateway)	Active context, idempotency, projections, runtime indexes

KV (Hot Cache)

Namespace	Binding	Purpose
Rate Limits	RATE_LIMITS	API rate limiting
Sessions	SESSIONS	User sessions
Connector Status	CONNECTOR_STATUS	Connector install/runtime status
Signal Cache	SIGNAL_CACHE	Signal event cache
Metrics	METRICS	Application metrics
OAuth State	OAUTH_STATE_KV	OAuth flow state

R2 (Blobs)

Bucket	Binding	Purpose
Files	FILES	Files, attachments, evidence, raw payloads

VII. IDENTITY

Authentication Stack

Layer	Provider	Status
Primary	Clerk	✅ Canonical
JWT	Clerk session validation + tenant membership	✅ Canonical
OAuth	Google, GitHub, Slack, Salesforce, HubSpot	✅ Active
MCP Auth	Cloudflare Access	✅ Active
Webhook Auth	HMAC signature verification	✅ Active

VIII. FOUR CONNECTION PATHS

Path	Purpose	Contract
MCP	Connects tools and resource protocols	Tool protocol
AI Connector	Connects intelligence providers and AI runtimes	Intelligence provider contract
API Connector	Connects operational systems	Provider integration contract
API Wrapper	Converts existing callable operations into governed capabilities	Capability abstraction contract

IX. VERSIONING

Platform Version Rules

Change	Version
New kernel concept	Major (2.0)
New runtime step	Major (2.0)
New doctrine	Minor (1.1)
New capability type	Minor (1.1)
Implementation improvement	Patch (1.0.1)
New projection	Patch (1.0.1)
New role composition	Patch (1.0.1)

Current Status

Platform Lock: DECLARED
Version: 1.0
Status: FROZEN

X. TAGLINE

Truth you own. AI you rent. Approval in between.