{"slug":"operations/TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL","title":"Tenant Spine: Fortress, Operational Cache and Flow Model","section":"operations","sectionLabel":"Operations","status":"current","type":"document","path":"operations/TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.mdx","bytes":34878,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** current derived implementation contract  \n**Date:** 2026-07-29\n\n**Authority:** `ARCHITECTURE_LOCK.md` → `IMPLEMENTATION_CONTRACT_v1.1.md` → `CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md`  \n**Implementation:** `migrations/035_canonical_spine_schema_fortress.sql` → `037_pure_entity_spine_tables.sql` → `038_tenant_lifecycle_entity_tables.sql` → `039_tenant_network_scope_and_promotion_flow.sql` → `040_scope_global_events_provenance_and_evidence.sql` → `041_app_category_entity_domain_classification.sql` → `042_real_tenant_rls_and_runtime_scope.sql`\n\n## 1. Resolved model\n\nIntegrateWise stores one tenant-level entity model. It does **not** create a\ndatabase schema, table family, or cache partition for a department.\n\n```text\nTenant\n→ Tenant Account\n→ Spine Network\n→ canonical entities, relationships, events and evidence\n→ RBAC-scoped Workbench projections\n```\n\nRole, department, industry, team, work objective and active context determine\nthe projection a user receives. They never determine where canonical truth is\nphysically stored.\n\nThis preserves cross-functional work. A single account, person, task, document,\nrisk, decision or outcome can be projected in the relevant user views without\ncopying its truth into a Sales, Finance, Customer Success, Engineering or any\nother department database.\n\nThe supplied Spine references are applied as follows:\n\n- Account Intelligence's field-rich tables become typed, tenant-scoped entities\n  and relationships; they are not a separate customer-success database.\n- The Workbench IA's tables, views and pages remain three different primitives:\n  entities hold truth; views are RBAC lenses; pages/canvases hold narrative and\n  may propose governed changes.\n- The Mental Model's evidence chain, connector schema expansion and contextual\n  Twin are retained, subject to the frozen Gateway, Pipeline and Governance\n  boundaries.\n- The Company Wiki's company, initiative, work-item, decision and knowledge\n  lifecycles are modeled as tenant lifecycle events with evidence and exit\n  criteria, not merely user activity logs.\n\n## 2. Two stores, one source of truth\n\n| Store                          | Technology and owner                                                       | Contains                                                                                                                                                       | Does not contain                                                                                                  |\n| ------------------------------ | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| **Canonical Spine / Fortress** | Neon Postgres, written only by Pipeline promotion / Governed Spine Writers | governed entity state, typed relationships, version history, lifecycle events, evidence links, approvals, audit, promotion records and canonical change outbox | short-lived UI state, a browser-owned source of truth, raw provider credentials, or unreviewed AI memory as truth |\n| **Operational Spine**          | D1 and KV, managed by Pipeline and Projection Engine                       | bounded entity/projection cache, active context, idempotency, sync receipts, connector health, candidate staging and expiry-bound runtime activity             | independent truth, permanent durable memory, authority decisions, or a direct path into canonical tables          |\n\nThe operational store is a cache and staging boundary. It is rebuildable from\nFortress and R2 evidence. If an operational record matters after its expiry, it\nmust be promoted through the governed path; it must not be retained merely\nbecause it happened to exist in a cache.\n\n```text\nFortress commit\n→ canonical change outbox\n→ Pipeline / Projection Engine\n→ D1/KV operational cache and invalidation\n→ Workbench projection\n\nOperational candidate or connector intake\n→ evidence + promotion queue\n→ policy and required approval\n→ Governed Spine Writer\n→ Fortress commit\n```\n\n## 3. Tenant scope and stable identifiers\n\nEvery tenant-owned entity, relation, event, evidence link, promotion, cache\nentry and log uses this scope envelope.\n\n| Scope concern             | Physical field                              | Meaning                                                                                                                                                            |\n| ------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Isolation boundary        | `tenant_id`                                 | The tenant that owns the record and policy context. Always required.                                                                                               |\n| Tenant operating account  | `tenant_account_id`                         | References `spine_tenant_accounts.account_id`. This is the tenant's root account identifier.                                                                       |\n| Tenant Spine Network      | `spine_network_id`                          | References the tenant-account-specific `spine_networks` record. It groups the entity graph, connector bindings, events and projections for that operating network. |\n| Workspace context         | `workspace_id`                              | Optional active working scope within the tenant; never replaces `tenant_id`.                                                                                       |\n| Entity identity           | `<entity>_id` and `canonical_id`            | Stable row identity and deduplication/merge identity.                                                                                                              |\n| Connector install binding | `connector_binding_id`                      | The authenticated user/tenant/provider-workspace installation binding.                                                                                             |\n| Connector connection      | `spine_connection_id`                       | The canonical connection for one provider connection. It is lineage for imported data, not the tenant network root.                                                |\n| Traceability              | `trace_id`, `correlation_id`, `source_flow` | The end-to-end route through a Flow A-D operation.                                                                                                                 |\n\nEvery entity additionally carries a provider-neutral classification address:\n\n```text\napp_category → business_domain → lifecycle_stage\n```\n\n`app_category` classifies the entity source, `business_domain` is the RBAC\nclassification, and `lifecycle_stage` is the cross-domain routing key. The\nfull registry is [APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md](APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md).\n\nThe distinction matters:\n\n```text\nspine_network_id     = the tenant's IW-Spine-Network\nspine_connection_id  = one connector/provider connection inside that network\n```\n\n`spine_connection_id` remains correct for connector-specific lineage. It cannot\nsubstitute for `spine_network_id`, because a tenant network has many connector\nconnections and also includes user-created, imported and governed entities.\n\n`tenant_account_id` is deliberately used on tenant-scoped tables rather than a\ngeneric `account_id`: `spine_accounts.account_id` already identifies a business\naccount/customer entity. The two are different concepts and must not collide.\n\n## 4. Entity-first lifecycle model\n\nEvery durable lifecycle object gets a typed canonical entity table. Generic\n`spine_entities` remains the compatibility graph/identity layer while typed\ntables become the canonical materialized home for their entity families.\n\n| Lifecycle family                          | Canonical typed tables                                                                                                                                                                   | Typical lifecycle events                                                                   |\n| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |\n| Tenant identity and authority             | `spine_organizations`, `spine_workspaces`, `spine_users`, `spine_memberships`, `spine_roles`, `spine_permissions`, `spine_tenant_accounts`, `spine_networks`                             | tenant created, membership granted, role changed, policy changed                           |\n| People and organizational operating model | `spine_persons`, `spine_teams`, `spine_processes`, `spine_objectives`, `spine_projects`, `spine_outcomes`                                                                                | person identified, team formed, objective set, project advanced, outcome verified          |\n| Work and coordination                     | `spine_tasks`, `spine_work_items`, `spine_workflows`, `spine_approvals`, `spine_decisions`, `spine_timeline_events`                                                                      | work created, assigned, blocked, proposed, approved, completed                             |\n| Communications and evidence               | `spine_messages`, `spine_calendar_events`, `spine_meetings`, `spine_calls`, `spine_documents`, `spine_conversations`, `spine_activities`, `spine_evidence_links`, `spine_provenance`     | message ingested, meeting completed, document linked, evidence attached                    |\n| Continuity and knowledge                  | `memory_items`, `memory_promotion_queue`, `org_memory_items`, `knowledge_documents`, `knowledge_chunks`, `spine_signals`                                                                 | observation triaged, memory proposed, promoted, superseded, signal resolved                |\n| Customer and commercial lifecycle         | `spine_accounts`, `spine_leads`, `spine_opportunities`, `spine_contracts`, `spine_subscriptions`, `spine_invoices`, `spine_renewals`, `spine_orders`, `spine_campaigns`, `spine_vendors` | lead qualified, opportunity advanced, contract signed, invoice paid, renewal decided       |\n| Product, delivery and operations          | `spine_products`, `spine_features`, `spine_releases`, `spine_sprints`, `spine_tickets`, `spine_incidents`, `spine_budgets`, `spine_expenses`, `spine_assets`                             | requirement proposed, feature built, release verified, incident resolved, expense approved |\n| Integration and platform control          | `spine_connector_catalog`, `integration_connections`, `spine_connector_installations`, `integration_provider_schemas`, `integration_schema_mappings`, `spine_schema_version_events`      | connector authorized, binding validated, schema discovered, sync completed, scope revoked  |\n\nThe Account Intelligence reference maps cleanly into this tenant model:\n\n| Reference entity               | Tenant canonical representation                                                      |\n| ------------------------------ | ------------------------------------------------------------------------------------ |\n| Account Master                 | `spine_accounts`                                                                     |\n| People Team                    | `spine_persons` + tenant-scoped relationships to `spine_accounts`                    |\n| Business Context               | typed business-context entity associated to an account through `spine_relationships` |\n| Strategic Objectives           | `spine_objectives`                                                                   |\n| Capabilities and API Portfolio | `spine_assets` / capability registry plus typed relationships                        |\n| Value Streams and Initiatives  | `spine_processes` and `spine_projects`                                               |\n| Health Metrics and Signals     | `spine_signals`, timeline events and entity-specific measurement records             |\n| Risk Register                  | typed risk entity linked to affected entities and mitigation work                    |\n| Engagement Log                 | `spine_activities`, linked messages, meetings and calls                              |\n| Success Plan and Task Manager  | `spine_projects` / plans plus `spine_tasks` and `spine_work_items`                   |\n\nThe typed entity expansion is additive. A future table is added because it owns\na stable business entity and lifecycle—not because a user interface introduces\na new tab.\n\n## 5. Flow A-D: one routing model, four kinds of material\n\nAll flows carry the same scope envelope. Flow classification decides handling\nand promotion policy; it never creates a departmental partition.\n\n| Flow                                 | Material                                                                                                                                                          | Operational handling                                                                                     | Canonical promotion                                                                                                                           | Canonical output                                                                                         |\n| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |\n| **A — structured operational data**  | Provider records, tuples, state changes, metrics and lifecycle updates                                                                                            | Connector intake, idempotency, schema validation and a bounded normalized candidate                      | Deterministic normalization creates a candidate. The promotion queue and policy decide whether it can be system-promoted or requires review.  | Typed entity/version/relationship/event rows with external identity, provenance and connector lineage.   |\n| **B — documents and communications** | Emails, messages, meetings, calls, transcripts, documents, attachments and raw provider artifacts                                                                 | Preserve raw evidence in R2; cache only retrieval metadata and extracted candidate links in D1/KV        | Triage and policy promote only validated entity links, extracted actions, decisions, signals or knowledge.                                    | Evidence record, source link, permitted structured entity changes and searchable knowledge references.   |\n| **C — AI and cognitive context**     | Twin sessions, plans, reasoning outputs, agent tool results, brainstorming and memory candidates                                                                  | Store bounded session/context and proposal staging. No Flow C component writes canonical business truth. | Always through Triage → promotion record → the required human approval → Governed Spine Writer.                                               | Approved memory, knowledge, decision, task, signal or other explicitly typed entity with cited evidence. |\n| **D — platform binding and control** | Authenticated identity, tenant/account/network resolution, RBAC, consent, connector bindings, schema compatibility, policy, entitlement and runtime configuration | Verify and cache only short-lived resolved context; record operational health and idempotency state      | Governed platform write for binding/control records. Flow D validates the authority envelope for A/B/C; it does not partition business truth. | Connector and schema binding records, consent, policy/audit and resolved scope for every other flow.     |\n\n### Flow event record\n\nEvery material event is represented in `spine_flow_events` with:\n\n```text\ntenant_id + tenant_account_id + spine_network_id\n+ flow (A | B | C | D)\n+ phase (received | normalized | triaged | queued | approved | promoted |\n         projected | reconciled | rejected | expired)\n+ subject entity/event + connector/binding lineage + trace/correlation IDs\n```\n\nThis is the requested operational record for system, connector, agent and\nhuman activity. It is broader than a user action log and supports a complete\ntrace from external source to Workbench projection and back to a verified\noutcome.\n\n## 6. Promotion and sync rules\n\n### Operational to Fortress\n\n1. A connector, user action, page/canvas proposal, or agent produces an\n   operational candidate.\n2. The candidate includes the scope envelope, evidence references, affected\n   entity IDs, source flow, trace/correlation IDs and proposed operation.\n3. It is recorded in `spine_promotion_queue`; raw content remains in R2 or its\n   bounded operational reference, never copied blindly into a truth table.\n4. The policy determines the appropriate route:\n   - deterministic, low-risk Flow A data may be promoted by the governed\n     system route once schema and provenance are valid;\n   - Flow B derived meaning, Flow C cognitive material, material record merges,\n     decisions, memory and consequential changes require the applicable human\n     approval;\n   - a rejected or expired candidate never becomes canonical.\n5. Only the Governed Spine Writer commits canonical entities, versions,\n   relationships, evidence links and audit records atomically.\n\nNo browser, page/canvas, Twin, connector runtime, MCP tool or operational D1\nworker writes a Fortress entity table directly.\n\n### Fortress to operational\n\n1. A canonical commit creates `spine_canonical_change_outbox` record and a\n   `spine_flow_events` entry.\n2. Pipeline and the Projection Engine consume the outbox, invalidate affected\n   D1/KV keys and build fresh, RBAC-safe cache entries.\n3. A cache receipt records the canonical entity version applied.\n4. The Workbench requests the projected shape through Gateway; it never reads\n   Fortress or a connector/provider model directly.\n\nAn operational cache miss is a partial-evidence/read-rebuild condition. It is\nnever permission to substitute seed data or to fabricate a new truth record.\n\n## 7. Evidence, audit and lifecycle accountability\n\n| Need                                      | Canonical record                                                            |\n| ----------------------------------------- | --------------------------------------------------------------------------- |\n| What happened and where in the route      | `spine_flow_events`, `spine_timeline_events`                                |\n| What durable entity changed               | typed entity row + `spine_entity_versions`                                  |\n| Why it changed                            | `spine_provenance`, `spine_evidence_links`, source/evidence reference       |\n| Who/system made or requested it           | `actor_type`, `actor_id`, connector and binding lineage in the flow event   |\n| Who authorized it                         | `spine_decisions`, `spine_approvals`, `spine_audit_log`                     |\n| How an operational candidate became truth | `spine_promotion_queue` linked to decision/approval and target entity       |\n| How truth became a current view           | `spine_canonical_change_outbox` plus operational sync receipt/cache version |\n\nThe required line of evidence is therefore:\n\n```text\nsource artifact or user/system action\n→ Flow A/B/C/D event\n→ candidate and evidence\n→ promotion decision / approval where required\n→ canonical entity version\n→ outbox\n→ operational projection cache\n→ RBAC-safe Workbench view\n```\n\n## 8. Projection and RBAC\n\nThe Workbench receives a projection, never a raw table or a department schema.\nThe Projection Engine applies:\n\n1. resolved tenant, tenant account and Spine Network;\n2. authenticated user membership and permissions;\n3. workspace, object, relationship and context scope;\n4. entity visibility, field visibility and capability policy;\n5. role/department/industry only as view-composition inputs.\n\nThis makes cross-projections safe: the same canonical account can appear as a\nrenewal risk, an invoice context, a project dependency, a support incident\nrelationship or an executive outcome only when the reader's RBAC policy allows\nit.\n\n## 9. Implementation and enforcement sequence\n\n`039_tenant_network_scope_and_promotion_flow.sql` establishes the root account\nand network tables, the universal entity scope map, promotion queue, canonical\noutbox and all-flow log. It also adds `tenant_account_id` and\n`spine_network_id` to existing tenant-scoped rows without rewriting legacy\ndata. `040_scope_global_events_provenance_and_evidence.sql` applies the same\nenvelope to the generic event, provenance and evidence logs that predate the\ntenant-scoped model.\n\n`041_app_category_entity_domain_classification.sql` adds the versioned\nclassification registries and entity classification record. It gives the\nProjection Engine a domain filter and lifecycle routing key without turning\ndepartment into storage.\n\nThe companion D1 migration creates only rebuildable cache/staging/receipt\ntables. It carries the same scope envelope but cannot become a source of\ntruth.\n\nThe safe cutover is:\n\n1. create and backfill tenant account/network records;\n2. attach scope rows to existing canonical entities and active connector\n   bindings;\n3. make Gateway/Pipeline require the complete scope envelope on new writes;\n4. backfill/repair legacy rows conservatively;\n5. add validated `NOT NULL`/foreign-key enforcement only after the migration\n   report has no unresolved active records;\n6. switch operational cache readers and writers to the new scoped cache tables;\n7. prove isolation with cross-tenant, cross-account, cross-network,\n   cross-connector and RBAC projection tests.\n\nNo department migration is part of this sequence.\n\n## 10. Closed four-flow lifecycle\n\nThe four flows operate through one closed lifecycle in Development, Customer\nZero and Customer Production. Flow D is the authority envelope for every Flow\nA, B or C event; it is not a fourth business-data partition.\n\n```text\nExternal source / Workbench / AI or MCP consumer\n→ Gateway and Flow D authority binding\n→ raw evidence preservation + immutable scoped event\n→ Flow A deterministic normalization\n  or Flow B deterministic extraction/link preparation\n  or Flow C adaptive Triage\n→ Operational Spine candidate/cache\n→ promotion policy + required human approval\n→ Governed Spine Writer\n→ Neon Fortress\n→ canonical change outbox\n→ Operational Spine/search/projection rehydration\n→ RBAC-scoped Workbench\n→ contextual Silent Twin\n→ Capability → Governance → approval token → Hermes\n→ provider outcome\n→ re-ingestion → verification → reconciliation\n→ Governed Spine Writer → Neon Fortress\n```\n\nThis sequence resolves several wording traps:\n\n- **Customer Zero is an operating tenant and isolated environment**, not a\n  separate product, database model or control-surface application.\n- **Twin is the AI Co-worker behavior.** “Co-worker” is positioning for the\n  Twin when it accepts delegated work; it is not another runtime beside Twin.\n- **Triage prepares and routes candidates.** It does not approve its own\n  candidate and does not commit canonical truth.\n- **A Projection is not a copy of truth.** D1/KV projection state may be stale\n  or rebuilt; the versioned Neon entity remains authoritative.\n- **Aging never causes truth promotion.** Promotion is caused by evidence,\n  schema/provenance validity, policy and required authority.\n\n## 11. OODA, search and context organization\n\nThe Four Buttons remain the exact user-facing OODA grammar:\n\n| OODA        | User control              | Runtime responsibility                                                                                                     |\n| ----------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| **Observe** | **Store in Spine**        | Capture an observation through Gateway, evidence preservation and the governed write path.                                 |\n| **Orient**  | **Ask Your Twin**         | Assemble permitted context and retrieve/rank relevant entity, relationship, timeline, document, memory and evidence state. |\n| **Decide**  | **Assign Your Twin**      | Create a bounded assignment, draft, proposal or immutable action plan. No external mutation occurs.                        |\n| **Act**     | **Approve Twin's Action** | Governance validates authority and issues the token used by Hermes for execution.                                          |\n\nNormalizer and Triage prepare material that can later be searched, but they are\nnot the whole search runtime:\n\n```text\nFlow D tenant/RBAC binding\n→ relational + relationship + timeline + full-text + vector retrieval\n→ evidence/freshness/authority filtering\n→ relevance and work-priority ranking\n→ bounded Active Context\n→ Projection Engine or Twin\n```\n\nTenant and permission filtering occurs before ranking. Search indexes and\nembeddings are derived structures; they never own truth. A material click may\nrefresh or reuse Active Context, but it does not automatically start expensive\nmodel reasoning or open a permanent Twin panel.\n\nTriage participates in context organization by classifying, linking,\ndeduplicating and prioritizing incoming unstructured/cognitive candidates.\nProjection-time search participates by cumulatively retrieving the already\npermitted material needed for the active work. These are complementary\nresponsibilities, not one combined authority.\n\n## 12. Retention, aging and historical evidence\n\nRetention is policy by material class and tenant. The values below are safe\ndefaults to validate, not a replacement for tenant, contractual, regulatory,\ndeletion or legal-hold policy.\n\n| Data class                                            | Authoritative store                      | Default operational posture                          | Aging effect                                                                                                        |\n| ----------------------------------------------------- | ---------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |\n| Sessions, temporary signals and transient context     | D1/KV                                    | Minutes to 7 days                                    | Expire; reconstruct where possible. Never promote because of age.                                                   |\n| Active operational projection/cache state             | D1/KV                                    | Up to 30 days by class                               | Rebuild from Fortress/outbox or expire when no longer active.                                                       |\n| Candidate memory, knowledge, decisions and proposals  | Operational staging + evidence reference | Until reviewed, rejected or policy-expired           | Promotion requires the applicable policy and human authority.                                                       |\n| Canonical entities, relationships, outcomes and audit | Neon Fortress                            | Tenant/record-class retention policy                 | Version, supersede, export or delete only through governed retention operations.                                    |\n| Raw artifacts and immutable evidence bytes            | R2                                       | Evidence policy, lifecycle and legal hold            | Transition storage class, retain or delete through explicit R2 policy; Spine retains governed metadata and lineage. |\n| Embeddings and search indexes                         | Vector/search services                   | Same or shorter lifetime than their permitted source | Delete/rebuild when the source is deleted, revoked, reclassified or re-embedded.                                    |\n\nThe long-horizon tier is a **Historical Evidence/Analytics tier**, not a second\ncanonical Spine. R2 lifecycle policies may transition evidence to lower-cost\nstorage classes, while bucket locks may enforce minimum retention. Neon remains\nthe authoritative metadata, policy, lineage and entity record. Tenant export,\nright-to-delete, legal hold and residency requirements must be resolved before\nany fixed production retention schedule is enabled.\n\n## 13. Development, Customer Zero and Customer Production\n\nAll three environments run the same logical contracts and four flows. They do\nnot share data, credentials, queue state, cache state, evidence or deployment\nauthority.\n\n| Environment             | Data and purpose                                                       | Canonical truth                                                                             | Operational state                                                                              | Release rule                                                                                                                              |\n| ----------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |\n| **Development**         | Synthetic fixtures, approved redacted reproductions and test providers | Disposable Development Neon branch/database when persistence tests require it               | Dedicated Development D1/KV/R2/queues/search                                                   | Code/configuration may be promoted after tests. Development data rows never promote.                                                      |\n| **Customer Zero**       | IntegrateWise's real internal operations                               | Dedicated Customer Zero Neon database/branch and credential boundary                        | Dedicated Customer Zero D1/KV/R2/queues/search and audit                                       | Proves production behavior. Only reviewed code/configuration/policy may move toward Customer Production; internal memory/data never does. |\n| **Customer Production** | External tenant data and customer-authorized providers                 | Production Neon with enforced tenant scope/RLS, or a dedicated customer cell where required | Production tenant-scoped D1/KV/R2/queues/search; dedicated resources for contractual isolation | Receives versioned releases only. No customer data flows into Customer Zero or another tenant.                                            |\n\nThere is no per-department D1, Neon schema, Worker or Spine. Department,\nindustry and role remain projection dimensions. A dedicated tenant cell may be\nselected for contractual isolation, residency, scale or regulatory reasons;\nthat is a deployment policy, not a different logical schema.\n\nThe default compute plane is the shared, stateless Cloudflare Platform services\nwith trusted tenant resolution at Gateway and tenant-aware bindings underneath.\nDurable Objects may coordinate strongly consistent per-tenant or per-workspace\nruntime state. **Workers for Platforms is optional** and is used only when\nIntegrateWise must deploy and isolate customer-supplied or agent-generated code,\nsuch as a governed coding-agent or extension runtime. Ordinary multi-tenant\nGateway, Pipeline, Projection, Governance and Hermes execution does not require\none Worker script per tenant.\n\nCloudflare Workers may connect to the Neon Fortress directly with the approved\ndriver or through Hyperdrive. This does not change storage authority: D1 remains\nbounded operational state and Neon remains the Fortress.\n\nCurrent Cloudflare implementation references:\n\n- [Workers for Platforms](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/)\n  and its\n  [user-Worker deployment examples](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/reference/platform-examples/);\n- [Neon from Cloudflare Workers](https://developers.cloudflare.com/workers/databases/third-party-integrations/neon/);\n- [R2 object lifecycle policies](https://developers.cloudflare.com/r2/buckets/object-lifecycles/)\n  and [R2 bucket locks](https://developers.cloudflare.com/r2/buckets/bucket-locks/).\n\n## 14. Cross-environment release and replay\n\nOnly release artifacts cross environment boundaries automatically:\n\n```text\nDevelopment proof\n→ reviewed code/schema/configuration/policy artifact\n→ Customer Zero validation\n→ reviewed production release\n→ Customer Production\n```\n\nData movement follows stricter rules:\n\n- Customer Zero data and memory never seed Customer Production.\n- Customer Production tenant data never enters Customer Zero or another\n  customer tenant.\n- A production incident may become a Development reproduction only after\n  authorization, redaction and synthetic reconstruction. It is a new\n  Development ingestion event, not a cross-environment Spine promotion.\n- Aggregated product telemetry may enter an internal observability scope only\n  under an explicit telemetry/privacy contract. It is not tenant continuity or\n  business truth.\n- Every replay is scoped, idempotent, auditable and prevented from performing\n  provider side effects unless its governed replay policy explicitly permits\n  them.\n\nNo `dev=true`, `cz=true` or `prod=true` row marker is an isolation boundary.\nIsolation is enforced by environment-specific resources plus the complete\ntenant/account/network authority envelope.\n"}