{"slug":"business/30-adaptive-spine","title":"Adaptive Spine","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/30-adaptive-spine.mdx","bytes":3429,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nThe Adaptive Spine is the canonical operational continuity network of IntegrateWise. It is not a dashboard, not an ESB, and not a simple database table collection.\n\nFor the canonical data model, see `docs/architecture/SPINE_MODEL.md`, `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md`, and `docs/architecture/PROJECTION_MODEL.md`.\n\n## What the Spine is\n\nThe Spine unifies operational objects across connected systems into governed, normalized continuity state. It resolves entities, maintains relationships, tracks meaningful change, and serves read projections to the Workbench and Twin.\n\nThe Spine does not pass transient messages between applications. It is not middleware. It is the persistent, versioned representation of operational reality for a tenant.\n\n## What the Spine is not\n\n- The Spine is not an ESB.\n- The Spine is not an agent runtime.\n- The Spine is not a chat log.\n- The Spine is not a cache-only copy of connected systems.\n- No model owns canonical truth.\n- No agent writes directly to the Spine.\n\n## State substrate\n\nThe Spine is backed by separable substrate layers optimized for access patterns:\n\n- D1 owns structured state and metadata.\n- KV owns hot projections and acceleration state.\n- R2 owns bytes, artifacts, evidence, and raw payloads.\n- Vectorize owns semantic retrieval vectors derived from source truth.\n- Durable Objects own runtime coordination state, not canonical truth.\n\nProduct logic should talk to stable repository contracts. No product plane should depend on provider primitives.\n\n## Entity and relationship model\n\nOperational entities such as accounts, contacts, opportunities, projects, tickets, vendors, and invoices are represented as Spine contexts. Relationships are first-class. Entity resolution, deduplication, and identity normalization are spine responsibilities.\n\nContext360 is a projection over Spine state. Raw provider tables are not surfaced directly to users.\n\n## Context continuity\n\nContinuity is created through three load modes:\n\n- Creamy Load builds initial operational foundation from connected systems.\n- Delta Load absorbs recurring changes.\n- Streaming Load ingests real-time events.\n\nNot every event becomes canonical truth. The platform filters, normalizes, synthesizes, governs, and promotes approved operational state into the Spine.\n\n## Read path\n\nThe Workbench reads projections assembled from Spine state. Progressive loading is used to preserve responsiveness:\n\n- identity and header first\n- key operational state next\n- current work and primary relationships\n- recent timeline\n- knowledge and files\n- AI-generated interpretation asynchronously\n\nAI enrichment never blocks core operational content.\n\n## Write and promotion path\n\nChanges may originate from providers, users, Twin proposals, or execution outcomes. None become canonical automatically.\n\nPromotion depends on:\n\n- provider confirmation when applicable\n- policy alignment\n- data integrity validation\n- approval lineage when the change originated from a governed proposal\n\nOnly promotion creates canonical Spine truth.\n\n## Partner assumptions\n\nPartners should assume:\n\n- connected-system state is a source, not canonical truth.\n- cached projections may lag behind canonical state and will show freshness metadata.\n- direct writes to Spine storage are prohibited outside governed pathways.\n- entity identifiers and relationships may change through promotion and reconciliation.\n"}