{"slug":"architecture/ARCHITECTURE","title":"ARCHITECTURE","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/ARCHITECTURE.mdx","bytes":4522,"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: System composition and architectural laws\nCanonical Owner: Platform\nLast Verified: 2026-07-11\nEvidence Basis: docs/CANON.md, docs/FINAL_E2E_SYSTEM.md, docs/platform-specs/\\_MASTER_INDEX.md, docs/platform-specs/\\_doctrine-and-sales-narrative.md, Option B branch evidence, wrangler manifests\nSupersedes: none\nSuperseded By: none\n\n---\n\n## 1. SYSTEM COMPOSITION\n\nIntegrateWise is composed of two legally distinct boundaries:\n\n- PLATFORM — capability\n- PRODUCT — L1 experience\n\nThese are not stylistic adjectives. They are architectural boundaries.\n\n```text\nPLATFORM INTERNAL ARCHITECTURE\n≠\nPRODUCT NAVIGATION ARCHITECTURE\n```\n\nThe platform may retain internal layers and runtime identities. The frontend product does not expose L2-L7 as separate user layers.\n\n```text\nL1 = where the human works\n```\n\n---\n\n## 2. ARCHITECTURAL LAWS\n\n1. No model owns canonical truth.\n2. No agent writes to Spine directly.\n3. The product asks WHAT it needs. The platform determines HOW it is produced.\n4. Packages are independently published reusable language and libraries.\n5. Services are independently deployed runtime identities.\n6. Runtime boundaries follow authority, scaling, security, trigger, and failure domains.\n7. The human product is L1.\n8. AI is a silent operational partner.\n9. Governance appears when policy requires it.\n10. Continuity is a system behavior, not merely a page.\n11. Repository presence does not prove operational readiness.\n12. Deployment success does not prove end-to-end operation.\n13. A route or client name does not prove canonical authority.\n14. Observed fact, inference, proposal, approval, execution, and canonical result are distinct semantic states.\n15. Historical implementation is evidence, not automatic architecture.\n\nThese laws are binding across documentation, platform design, and product design.\n\n---\n\n## 3. DOCUMENTATION LIFECYCLE LAW\n\nEvery architectural statement in documentation must distinguish between CURRENT, TARGET, MIGRATING, HISTORICAL, PROPOSED, and UNKNOWN.\n\nThese exact lifecycle labels are system-wide requirements.\n\nDefinitions:\n\n- CURRENT = verified to exist in repository or runtime; current does not automatically mean operational\n- TARGET = approved canonical architecture, may not yet be implemented or deployed\n- MIGRATING = current implementation is actively moving toward the approved target\n- HISTORICAL = retained for compatibility, evidence, migration, or archival reasons\n- PROPOSED = discussed but not canonically frozen\n- UNKNOWN = insufficient evidence to classify accurately\n\nUsage restrictions:\n\n- Never describe a TARGET service as CURRENT unless repository/runtime evidence proves it\n- Never describe a deployed Worker as canonical merely because it exists\n- Never describe a route named `/spine/*` as Spine-backed without tracing its downstream authority\n- Never describe frontend flow completion as platform activation completion\n- Never describe repository presence as operational readiness\n\n---\n\n## 4. HISTORICAL ARCHITECTURE LINEAGE\n\nThe repository previously contained multi-layer, multi-product architectural narratives. Those remain useful for lineage, but they are classified HISTORICAL unless explicitly marked otherwise.\n\nExamples requiring historical classification:\n\n- Seven-layer user navigation/product architecture when used to describe product boundary structure\n- Multi-Workbench product doctrine when used to describe separate user-facing surfaces\n- Twin Workbench / Governance Workbench / Knowledge Workbench / Domain Workbenches as product surfaces\n- Supabase-driven SSOT when used as canonical product definition\n- Vercel-first app hosting when used as canonical product target\n\nHistorical architecture should be marked HISTORICAL with scope notes and replacement targets rather than deleted.\n\n---\n\n## 5. AUTHORITY AND PROOF LAW\n\nDocumentation must distinguish declared architecture from verified architecture.\n\nA document may declare:\n\n- a target topology\n- a desired feature\n- a canonical service role\n\nVerification requires one or more of:\n\n- repository manifest evidence\n- runtime behavior evidence\n- persisted state evidence\n- verified traffic evidence\n- end-to-end readback evidence\n\nAbsent verification, the statement remains TARGET, PROPOSED, or UNKNOWN, never CURRENT.\n"}