Deployment Topology Canonical URL: https://babadook.tech/modules/deployment-topology Entity: modules Content hash: 394b93e34af7b6baf5f8ce878a0882b9184f3f15fedfae2595d8b7cd0d1960a8 Your data stays where your lawyers say it must — with proof on every request. Regulated operators don't get to shrug about where data lives — and auditors have learned to ask. Deployment Topology makes residency an attribute stamped on every request, audit event, and metric instead of a diagram nobody can verify. Self-hosted, cloud, hybrid, air-gapped, or edge: you choose per site, and the system proves compliance continuously. Why topology is a runtime attribute Regulated operators do not get to shrug about where data lives. A pharmaceutical plant, a defense supplier, and a retailer have different answers — sometimes for different sites of the same company. XRP records the chosen topology per deployment and stamps it on every request, audit event, and metric, so residency questions get answered from attributes instead of architecture diagrams. data Viz data View section: thesis Topology options - Self-hosted and BYOC: Data and runtime stay in your environment under your controls - Managed dedicated and SaaS: Babadook-operated infrastructure with hard tenant isolation - Hybrid: Local primary with cloud overflow or disaster recovery, cutover proven - Air-gapped and edge: Signed bundles, local trust roots, no public-network dependency - section: capabilities Who answers for Deployment Four roles, four anxieties, one topology record answering each. data Viz data View section: personas Section 1 col Title: CIO col Cont: Residency proven per request instead of asserted per diagram. Mixed estates — SaaS headquarters, air-gapped plants — run one product with attributes intact. Section 2 col Title: CFO col Cont: Infrastructure spend matches control needs: SaaS where commodity, self-hosted where strategic, edge where operations demand it. No blanket premium for control needed in one corner. Section 3 col Title: COO col Cont: Plants keep running through outages with local trust roots and queued evidence. Connectivity is a sync schedule, not a survival requirement. Section 4 col Title: Compliance Leader col Cont: Data-residency answers come from request attributes, not architecture reviews. Examiners get continuous proof instead of annual attestations. From hosting anxiety to proven residency subtitle: What each stage feels like after adoption. layout: alternating enable Slideshow: false slideshow Interval: 5000 Topologies declared date: Phase 1 status: in-progress Each site records its model with residency attributes stamped per request. has Learn More: false Edge goes independent date: Phase 2 status: upcoming Disconnected sites run on local trust with evidence queued for sync. has Learn More: false DR stops being theoretical date: Phase 3 status: upcoming Failover proves before it switches, with lineage intact across the cut. has Learn More: false Examiners query, not tour date: Phase 4 status: upcoming Residency and continuity evidence arrives as queries, not site visits. has Learn More: false Deployment sub-modules subtitle: Topology chosen, performance proven. data View: deployment-topology:sub-modules Performance Substrate desc: Tiered compute with receipts at every tier. link: /sub-modules/performance-substrate Topologies in practice Each model below runs the same product with different residency and connectivity contracts — chosen per deployment, stamped on every request. data Viz data View section: applications Self-hosted and BYOC Your servers or your cloud account with your controls. Upgrades on your schedule, data never leaving your boundary, full audit access to the runtime. Managed and SaaS Babadook-operated infrastructure with hard tenant isolation. Dedicated tenants get single-customer runtimes; shared SaaS gets row-level enforcement with the same guarantees. Hybrid and DR Local primary with cloud overflow or standby recovery. Replication carries evidence lineage so failover never forks the truth — cutover proves before it switches. Air-gapped and Edge Signed offline bundles with local trust roots for disconnected plants, vessels, and field sites. Ruggedized edge hardware runs the full ledger; evidence syncs when connectivity returns. Deployment questions Section 1 Can air-gapped sites still audit centrally? Yes. Evidence bundles export with signatures and lineage for later verification without requiring a live connection. Section 2 Can different sites use different topologies? Yes. Topology is per deployment, so a headquarters SaaS tenant and an air-gapped plant operate under one product with their residency attributes intact. Section 3 What happens when connectivity drops mid-shift? Edge and offline-capable deployments keep validating against local trust roots and queue evidence for sync. No work stops waiting for the network. Section 4 Are we locked into Babadook's cloud if we start SaaS? No. The same product runs self-hosted with your data exportable with lineage. Topology changes are migrations with evidence, not re-implementations. Section 5 When was DR last actually tested? Continuously: replication carries lineage and cutover proves before switching, so the answer is always the last successful proof — not last year's tabletop exercise. data View section: faqs content section value: You choose where the runtime and data live — self-hosted, your cloud, managed dedicated, shared SaaS, hybrid, air-gapped, or ruggedized edge. Compliance and ownership ride every request as explicit attributes, not assumptions buried in a hosting contract. Section 9 Seven deployment models from shared SaaS to air-gapped edge Section 10 Customer-owned runtime with explicit data-residency attributes Section 11 Signed offline bundles with local trust roots for disconnected sites Section 12 Hybrid overflow and disaster-recovery patterns with proven cutover Section 13 Ruggedized edge operation without public-network dependency Section 14 Per-request topology attributes on audits, events, and metrics Section 15 Managed dedicated isolation alongside self-hosted control Section 16 Evidence export for central review from disconnected deployments Relationships products - XRP — https://babadook.tech/products/xrp sub modules - Performance Substrate — https://babadook.tech/sub-modules/performance-substrate