{"slug":"business/SPINE","title":"SPINE","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/SPINE.mdx","bytes":5520,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Tier C — Historical.** This document is a point-in-time snapshot preserved for reference. For current architecture, see [CANONICAL_PLATFORM_ARCHITECTURE.md](../architecture/CANONICAL_PLATFORM_ARCHITECTURE.md).\n\nStatus: CURRENT\nScope: Spine truth concept, canonical authority model, current write-reality classification\nCanonical Owner: Platform / SPINE\nLast Verified: 2026-07-11\nEvidence Basis: docs/CANON.md, docs/architecture/SPINE_DOMAIN.md, docs/architecture/SPINE_MODEL.md, docs/architecture/SPINE_INTELLIGENCE_AGENT.md, docs/platform-specs/02-operational-spine-canonical-highest-priority.md, docs/FINAL_E2E_SYSTEM.md, wrangler manifests, Option B divergence audit, AGENTS.md\nSupersedes: none\nSuperseded By: none\n\n---\n\n## 1. WHAT SPINE IS\n\n```text\nSPINE\n=\nCANONICAL OPERATIONAL TRUTH\n+\nNORMALIZED ENTITY STATE\n+\nOPERATIONAL CONTINUITY FOUNDATION\n```\n\nSpine is the system of record for operational entities, context, decisions, signals, proposals, approvals, execution outcomes, and continuity markers.\n\nSpine exists as an architectural concept with an operational realization. Platform documentation must always separate these two.\n\n---\n\n## 2. STORAGE REALISM\n\nStorage implementations may participate in Spine. They are not individually the Spine architecture.\n\nCurrent repo recognizes cloudy storage boundaries:\n\n- D1 as operational edge surface\n- KV, R2, Vectorize, Durable Objects as supporting substrates\n- Postgres/Supabase references in historical docs as retired product evidence until migration is complete\n\nSpine storage classification must follow:\n\n- is this substrate operational\n- is it canonical\n- is it temporary edge cache\n- is it retired product evidence\n\n---\n\n## 3. CANONICAL WRITE LAW\n\n```text\nGOVERNED RESULT\n      ↓\nSPINE WRITER\n      ↓\nCANONICAL STATE\n```\n\n```text\nNo agent writes to Spine directly.\n```\n\nTarget doctrine is governed sole-writer path to canonical state. This is a target architecture, not an assumed operational condition.\n\nDocumentation of write authority must be classified as:\n\n- VERIFIED_SPINE_WRITER\n- HISTORICAL_PIPELINE\n- DIRECT_DATABASE_PATHS\n- MULTIPLE_WRITE_PATHS\n- UNKNOWN\n\n---\n\n## 4. TARGET RUNTIME IDENTITIES\n\nTarget topology includes runtime identity responsibilities:\n\n- spine-writer\n- schema-synthesis\n- continuity\n- governance\n\nCurrent repository evidence reportedly shows:\n\n- services/pipeline exists\n- services/spine-writer does not exist as a service identity yet\n- schema-synthesis may not be deployed as a partitioned service\n\nThese are UNKNOWN states until verified by repo evidence and runtime review.\n\nDo not classify target identities as CURRENT without evidence.\n\n---\n\n## 5. CANONICAL TRUTH LAW\n\nNo model, agent, Twin, human, frontend, or external integration owns canonical truth.\n\nAgents may infer.\nAgents may propose.\nAgents may coordinate.\nReported results must be governed before canonical write.\n\nTwin reasoning must not bypass governed result path.\nAdmin panels must not bypass governed result path.\nHuman users may govern, not unilaterally redefine canonical state.\n\n---\n\n## 6. SPINE DOCUMENTATION BAN\n\nNever document Spine as equivalent to:\n\n- Supabase product database\n- Postgres\n- CouchDB\n- Redis\n- KV\n- R2\n- a route named /spine/\\*\n- a client named spineClient\n- a Next.js API route\n\nThese may participate in or reach toward Spine. They are not Spine.\n\n---\n\n## 7. SPINE INQUIRY REQUIREMENTS\n\nBefore classifying any path as Spine-backed:\n\n- identify the calling flow\n- trace to downstream implementation\n- confirm governed writer step\n- confirm route authority and storage target\n- confirm tenant isolation at write boundaries\n\nIf tracing requires additional evidence than currently documented, classify that path as UNKNOWN until verified.\n\n---\n\n## 8. D1 / SUPABASE / HISTORICAL CLAIMS\n\nDocumentation historically mixes:\n\n- D1 Spine tables\n- Supabase Fortress doctrine\n- Postgres SSOT prose\n\nCurrent canon states Cloudflare-only product plane with D1/KV/R2/Vectorize/AI Search/DO as primary platform storage. Supabase reference evidence in retained docs must be classified HISTORICAL unless a runtime migration artifact shows seamless replacement.\n\n---\n\n## 9. EXAMPLES OF ACCURATE SPINE DOCUMENTATION\n\nINSTEAD OF\nSpine queries are wired.\n\nWRITE\nThe Customer Zero frontend calls Next.js routes under /api/spine/\\*. The downstream canonical authority must be verified before classifying the flow as Spine-backed.\n\nINSTEAD OF\nPipeline owns canonical state.\n\nWRITE\nservices/pipeline is present in current repository. Historically described as an active Spine writer. Current sole-writer target expects spine-writer runtime identity. Authority must be traced before classifying pipeline as canonical writer.\n\n---\n\n## 10. CURRENT READY STATE\n\n- Verified authoritative writer identity: UNKNOWN until write-authority trace is closed\n- Historical likely contributor identity: pipeline if runtime still performs governed normalize/publish lifecycle\n- Known opposing/retired evidence: Supabase canonical references in historical docs\n- Next required evidence: repo tracing of write paths, env-secret usage in wrangler manifests, gateway->spine-writer or legacy actor bindings, tested end-to-end readback\n\n---\n\n## 11. DOCUMENTS THAT PRECEDE THIS\n\n- docs/architecture/SPINE_MODEL.md\n- docs/architecture/SPINE_DOMAIN.md\n- docs/architecture/SPINE_INTELLIGENCE_AGENT.md\n- docs/platform-specs/02-operational-spine-canonical-highest-priority.md\n\nWhen conflict arises between this document and those documents, this document is canonical.\n"}