{"slug":"architecture/RUNTIME_CONSTITUTION","title":"Runtime Constitution","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/RUNTIME_CONSTITUTION.mdx","bytes":2988,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: SUPERSEDED / ABSORBED — historical subsystem constitution. Current authority: [`INTEGRATEWISE_ARCHITECTURE.md`](INTEGRATEWISE_ARCHITECTURE.md) v2.2.\nScope: Cloudflare runtime substrate, service primitives, communication hierarchy, and decommissioned infrastructure.\nCanonical Owner: IntegrateWise Platform\nLast Verified: 2026-07-20\n\n---\n\n## 1. Purpose\n\nThis document defines the runtime layer for IntegrateWise.\n\nAll Workers, storage, queues, and inter-service routing must follow this contract.\n\n---\n\n## 2. Primitives\n\n| Primitive       | Purpose                                 |\n| --------------- | --------------------------------------- |\n| Workers         | Compute, routing, ingress               |\n| D1              | Structured relational state             |\n| KV              | Derived, reconstructable views          |\n| R2              | Immutable large binaries                |\n| Queues          | Async processing and retry              |\n| Durable Objects | Real-time consistency and session state |\n\n---\n\n## 3. Communication Hierarchy\n\n1. In-process function call\n2. Repository — D1/KV/R2/DO\n3. Service binding — same-account Worker\n4. Queue — async propagation\n5. External HTTP — browser/SaaS boundary only\n\nAnti-pattern: Worker-to-Worker HTTP on the same account.\n\n---\n\n## 4. Naming Separation\n\n| Product Brand             | Runtime Contract               | Infrastructure Binding          |\n| ------------------------- | ------------------------------ | ------------------------------- |\n| IW-Continuity-Bridge      | Context Gateway                | Cloudflare Workers Ingress      |\n| Twin                      | Twin Runtime Engine            | Durable Object Interaction Loop |\n| Action Center             | Capability Execution Interface | Worker Async Queue Routing      |\n| Automated Delivery Engine | Execution Platform             | Hermes Queue Processing Loop    |\n\n---\n\n## 5. Tenant Isolation\n\n- Each tenant receives an isolated D1 database via Workers for Platforms dispatch.\n- Cross-tenant SQL access is eliminated because each tenant runtime is bound to a\n  different D1 database resource (independent database-resource isolation with\n  separate D1 namespaces, independent lifecycle controls, and encryption at rest).\n- Authorization remains necessary for user and workspace isolation within a tenant.\n- Every durable D1 business record carries `tenant_id` even in a per-tenant database\n  (defense in depth, portable exports, forensic inspection).\n- Row-level partition verification is mandatory in Workspace Activation.\n\n---\n\n## 6. Decommissioned Infrastructure\n\n- Supabase\n- OpenWebUI\n- n8n\n- Python runtime services\n- CouchDB\n\n---\n\n## 7. Invariants\n\n1. External HTTP is allowed only at browser/SaaS boundary.\n2. Internal state flows through repositories or service bindings.\n3. Runtime identity never leaks into product branding.\n4. Infrastructure choices are replaceable without changing product contracts.\n"}