DATAFAB
Reference Playbook · Edition-aware

Deployment Architecture

A reusable, interactive deployment playbook. Six views — from the logical reference to network, resilience, release and key topology — each edition-aware, each component inspectable. Deployment-specific values appear as [set at deployment] placeholders, not fixed numbers.
Try it: switch views below · switch editions to morph any view · click a component for detail · on the reference view, click C1–C5 for the evidence that proves it.
Edition
Enforcement
CONTROL PLANE — VENDOR-OPERATED (PROFESSIONAL) schedule · configure within pinned policy · observe allow-listed · offer signed updates single-tenant · private link · customer-managed keys EGRESS BOUNDARY — DEFAULT DENY · FAIL-CLOSED control signal ↓ telemetry ↑ (allow-listed) signed updates ↓ ⊘ no customer data crosses CUSTOMER BOUNDARY — DEDICATED / PRIVATE (no customer-data exposure) SYSTEMS OF RECORD Core systems Mainframe / legacy Documents / content Case / records Reference / lists Read-only connectors source-granted · cannot write · no egress DATA PLANE — RUNS ON YOUR COMPUTE ENTITY GRAPHone graph, multiplegoverned lenses Policy engineversioned · signedcustomer-approved Deterministicenginedecides / gates outcome Model runtime in-boundary · assists NO egress route never finalises Resolutionactive metadata · read in place Governance — RBAC · lineage · tamper-evident audit MCP GATEWAY — the single governed route to data datastore accepts the gateway identity only · fail-closed DATAFAB Agencies · Knowledge & Agentic Studio Governed Agentic Utilities (domain packs, reusable) scoped · logged · revocable agencies & console reach data only through the gateway (governed calls) → Console / UI no customer data at rest private in-boundary console BOUNDARY INTEGRATIONS IdPidentity KMS / HSM your keys (KMS) SIEMaudit export C3 C2 C1 C5 C4
Reference deployment · click any component or enforcement point
Request lifecycle

Step a governed request, start to finish.

GOVERNED AGENTIC UTILITY — REUSABLE DOMAIN PATTERN Policy Studiono-code authoringby domain experts DAG policy enginepolicy assembles intoa governed graph Agenciesgoverned agency teamsscoped · logged Deterministicvalidationgates every action Governedactions /outputs Knowledge estateresolved graph +data in place Model (assist)extract · summarisenever finalises Audit & lineageevery decision → source + policy versionreproducible · defensible THE PATTERN Domain experts author policy in a no-code Studio → the policy compiles into a deterministic DAG → agencies execute the workflow through the governed gateway → a deterministic engine validates every action → outputs and every decision are audited to source and policy version. The model assists; it never decides. The same skeleton is reused per domain — the domain lives in the ontology, logic, processes, sources and semantic context, authored as configuration, not built as new code.
Governed utility · the reusable pattern behind every domain utility
VENDOR CONTROL PLANE reached over PRIVATE LINK (no public path) REGION — [dedicated region · set at deployment] Egress control — allow-list / firewall · default deny AVAILABILITY ZONE A Ingress subnet — private endpoints only[CIDR set at deployment] · no public ingress (P/S) App subnet — data plane computeresolution · engine · gateway · console[CIDR set at deployment] Data subnet — graph storeno egress route · encrypted at rest[CIDR set at deployment] AVAILABILITY ZONE B (HA replica) Ingress subnet — private endpoints only[CIDR set at deployment] App subnet — data plane computehorizontally scaled · same identity model[CIDR set at deployment] Data subnet — graph replicasynchronous / async per RPO[CIDR set at deployment] replicate
Network topology · placeholders are populated by engineering per deployment
PRIMARY REGION — ACTIVE Data plane · gateway · agencies (live)HA across AZs (see Network view) Graph store — primarypoint-in-time snapshots + resolution log DR REGION — WARM (PASSIVE) Data plane · stood by (IaC, same build)promoted on failover Graph store — replicareplication per RPO target replicate (RPO) ← failover (RTO) · promote DR to active Backup vaultin-boundary · customer-keyimmutable · retention-bound Re-derive from sourcesthe graph is derived, never the master —worst case is rebuild, not data loss Corruption recoverysnapshot rollback +integrity validation before serving RPO / RTO targets are set in the service schedule · [set at deployment] — see the SLO section of the dossier.
Resilience & DR · recovery for loss (replicate/failover) and for corruption (rollback/re-derive)
Source& IaC repo CI buildreproducible SBOMSPDX/CycloneDX Signimage signature ProvenanceSLSA / in-toto Signedregistry Customerapproval gatemandatory Deploy Runtimeverify CHAIN OF CUSTODY Nothing runs in your environment that isn't built reproducibly, inventoried (SBOM), signed, provenance-attested, and explicitly approved by you. In Sovereign the approval and verification are performed offline. Runtime verify re-checks signature + identity and runs the deployment bypass scan — the same scan that proves fail-closed (C5).
Build & release · signed, inventoried, provenance-attested, customer-approved
IDENTITY — WHO MAY ACT IdP / SSOyours FederationSAML / OIDC Service identitymTLS · workload id Gateway identitythe only principal Datastoreauthz(C1) C1 CUSTODY BOUNDARY — P: customer holds keys (KMS) KEYS — WHAT PROTECTS DATA AT REST Root of trustyour KMS (customer-managed)root key never leaves Key-encryption keyenvelope (KEK)wraps data keys Data keys (DEK)per store / per scoperotatable Encrypts at restgraph · audit · backupscrypto-shred = destroy the key Identity decides who may act; keys decide what stays readable. From Professional upward both roots sit on your side of the custody line — so revoking access or destroying a key is entirely in your control, and crypto-shred gives erasure even where audit is immutable.
Identity & keys · who may act, and what protects data at rest — custody shifts to you from Professional up
DISCOVERY DESIGN SETUP BUILD TEST GO-LIVE gate gate gate 1Discoveryscope + sources 2Editionselection 3Environmentsetup 4Network·KMSIdP·SIEM 5Sourceconnection 6Graphbuild 7Utilitydeploy 8TestingC1–C5 9Go-livecutover Three gates: design approval (2→3) · ready-to-test (7→8) · go-live sign-off (8→9). Testing (8) is where the evidence pack proves C1–C5.
Deployment journey · click a phase for what happens, who owns it, and the exit gate
Deployment-time choices

Fixed architecture vs. decided at deployment.

The architecture is fixed; these seven choices are not. Each has an owner and a stage — click a row to see it and the journey phase where it lands.

DecisionSet byWhen
EditionCustomer + DataFabDesign
Region / enclaveCustomerDesign
CIDRsCustomer infraSetup
KMS / HSMSecuritySetup
SIEM targetSOC teamSetup
RPO / RTOBusiness + ITDesign
Source listData ownerDiscovery

Everything else — the boundaries, the gateway, the model policy, the enforcement points — is fixed by the architecture and does not change per deployment. That is what makes these seven the whole of the deployment-time surface.