DataFab //  artificial proprietary intelligence T+00:00:00 ISO/IEC 27001:2022 · SOC 2 Type II — certified Raw egress  0 B 

DataFab  /  Architecture & deployment

Where it runs, and how it is proven

The architecture, in full technical detail.

The same platform, delivered against your estate and your controls — a managed control plane that never holds raw data, a data plane that runs inside your environment, four editions from managed to sovereign, and a signed chain of custody from source to the gate that is yours.

Control plane holds no raw dataData plane inside your boundarySigned, provenance-attested releases

The core architecture

Cloud-grade capability, without cloud-grade loss of control.

The control plane manages orchestration, governance, metadata, configuration, deployment, observability and policy. It understands how the estate is structured, what sources exist, what rules apply, and who — human or agency — may access what. It is not where raw data goes.

Fig. 01  //  reference deployment — switch the edition● custody shifts as you move right
CONTROL PLANE — AN OPERATING MODEL, NOT A PLACE YOUR DATA GOESPolicy as codecompiled · versionedMetadata & catalogueno raw data, everFleet & upgradessigned releasesObservabilityhealth · telemetryMETADATA & CONTROL SIGNALS ONLYDATA PLANE — INSIDE YOUR ENVIRONMENTAPI gatewayauthN · routing · limitsKnowledge & Agentic Studiocompose · test · publishKnowledge Fabricdiscover · resolve · deriveExecution runtimesandboxed · gatedKey managementHSM · BYOKAudit & lineage sinkhash-chained → your SIEMIdentity brokeryour provider, your groupsPolicy cachecompiled policy as codeRAW EGRESS 0 B
DataFab-operatedCustomer-held
Fig. 02  //  a governed request, start to finish● step it, or let it play
1Request2Entitlement3Plan4Read in place5Resolve6Gate7Answer & record
Step 1 · Request

A person or an agency asks a question. The caller is authenticated at the gateway and the request is typed against the semantic layer.

Step 2 · Entitlement

The consolidated permission model resolves what this caller may see. Inherited source entitlements are the floor — stricter, never looser.

Step 3 · Plan

A query plan is produced against the derived ontology, not against raw tables. Walled entity and relationship types are excluded before planning, not filtered after.

Step 4 · Read in place

Connectors read the source systems directly, under your credentials, over the pattern your network allows. No record is copied out.

Step 5 · Resolve

Records are matched and resolved on the way back. Confidence, source and date are carried on every edge.

Step 6 · Gate

If the request would cause an effect rather than return an answer, a deterministic gate holds it for an accountable person.

Step 7 · Answer & record

The result returns with its evidence, and the traversal, the exclusions and the disposition are written to the tamper-evident trail.

Not a thin metadata agent. A runtime.

The data plane runs inside your own cloud, VPC, on-premises or air-gapped environment. That is where data is read, processed, indexed, enriched and activated. Query, transformation, enrichment, feature engineering and agency workloads execute on compute inside your environment, close to where the data already sits, with CPU and GPU capacity available where required.

The managed control loop, delivered as a product.

The control plane compiles policy as code, coordinates many private data planes, brokers identity, manages upgrades, monitors health and runs the fleet — the platform-engineering function you would otherwise have to assemble, integrate and staff yourself. That is the difference between ordinary self-hosting and this: self-hosting hands you the burden; here it arrives as a product.

The claim, defined

What raw egress 0 B actually means.

The phrase appears on every page of this site, so it should mean exactly one thing. It does not mean the platform has no network. It means two invariants hold in every edition, and a third thing — where the data plane physically sits — is a choice you make.

Invariant 01 · true in every edition

Raw records never leave their system of record

The fabric reads in place, over read-only connections, with your credentials. What persists in the fabric is the resolved layer — mappings, derived insight, typed relationships and a snapshot of each cited record. The underlying rows, files and documents are never lifted out of the systems that own them, whichever edition you run.

Invariant 02 · true in every edition

The control plane never holds raw data

Policy, metadata, catalogue, identity brokering, fleet management and observability. That is the whole of what crosses from the data plane to the control plane — in Foundation exactly as in Sovereign. There is no edition in which your records reach DataFab’s management layer.

The choice — where the boundary is drawn

What an edition changes is whose environment the data plane runs in. Zero egress is always measured at that boundary. In Foundation, the boundary is a single-tenant environment DataFab operates in the region you choose — your records still never leave their source systems, but the runtime that reads them is ours to operate. From Professional upward the boundary is your own cloud account, your own tenancy, or your own premises, and custody of the keys moves with it. If the distinction matters to your risk function — and in a regulated or classified estate it should — the honest answer is Professional or above.

EditionData plane runs inOperated byKey custodyLeaves the source systemReaches the control plane
FoundationSingle tenant, your chosen regionDataFabDataFab, or BYOK on requestNothingMetadata and control signals only
ProfessionalYour cloud account and VPCDataFab, in your accountYouNothingMetadata and control signals only
In-tenantYour tenancy, your identity providerYou, with managed upgradesYouNothingMetadata and control signals only
SovereignOn-premises or air-gappedYouYouNothingNothing — control plane self-hosted

Every claim in this table is demonstrated against the engineering evidence pack at the assurance stage and recorded in the confirmation register. Deployment-specific values are populated per environment.

Fig. 01c  //  what crosses the boundary, and the in-boundary path◆ the gate
SOURCE DOCUMENTS — SOURCE OF RECORD, NEVER MIGRATED Customer agreements · broker correspondence · commission statements · signed forms · scanned records PDF · DOCX · JPG / PNG / TIFF · multi-page · degraded scans · handwritten annotation READ ON REQUEST FABRIC SERVICE · DOCUMENT EXTRACTION TRANSIENT — NO RETAINED CORPUS Classification gate Resolved from metadata BEFORE dispatch — never by inspecting content Then: machine-readable or OCR · cost · latency CLEARED BACKENDS On-premise GPU inference Only path for sensitive documents · no bytes leave self-hosted vision model External OCR service receives a transient copy · boundary crossed complex layouts · handwriting · forms Library extraction · traditional OCR machine-readable path · in boundary tried first where a text layer exists TRANSIENT COPY LEAVES THE BOUNDARY — GATE-CLEARED DOCUMENTS ONLY Returned: structured Markdown Headers, tables, lists and emphasis preserved — returned to the caller Returned with it: provenance Method · backend · classification basis · confidence · checksum · timestamp NOW READABLE BY Knowledge Fabric — entities resolved in place The document becomes one more source the graph can resolve Governance ontology — ethical walls, permissions, lineage and immutable audit NO DATAFAB DOCUMENT STORE · NO SECONDARY CORPUS

Editions

Four editions. One architecture.

The architecture is fixed. What changes between editions is where the planes run, who holds the keys, and how much of the operation you take on. Custody shifts to you from Professional upward.

Fig. 03  //  six governed layers, each with its own controls◆ the semantic layer is the primary output
REQUESTS FLOW DOWN TO THE SOURCE. DATA IS READ IN PLACE AND RESOLVED ON THE WAY BACK UP.01PresentationSearch UI · API gateway · integration APIsAuthentication · rate limiting · input validation02ServiceSearch · lineage · quality · discovery · governanceService-to-service authN/authZ · mTLS03Semantic layerDerived ontology · entity, relationship & attribute types · mappingsSchema-bounded · human-approved · versionedTHE FABRIC’S PRIMARY OUTPUT04Knowledge graphEntity store · relationship store · query engineEncryption at rest · access-control lists05ConnectivityDatabase · API · MCP · event streamsCredential vault · secure connections · sampling06Source systemsCustomer-managed data — read in placeCustomer-managed · customer credentialsREQUESTRESOLVED RESULT
Edition 01

Foundation

Single-tenant and DataFab-hosted in the region you choose. Your records still never leave their source systems, but the runtime that reads them is ours to operate — see what 0 B means.

Edition 02

Professional

Your cloud account and private connectivity, with key custody moving to you. Suited to enterprises with an established cloud landing zone.

Edition 03

In-tenant

Data plane fully inside your tenancy, integrated with your identity provider, your key-management service and your security-operations tooling.

Edition 04

Sovereign

On-premises or air-gapped, in your accredited environment, under your keys and your jurisdiction. No cloud dependency, no vendor tenancy, no third-party custody.

Edition names describe the deployment posture, not a feature ladder: the enforcement points, the boundaries, the gateway and the model rule are fixed by the architecture and do not change per edition.

The reference deployment, as engineered

Editions, enforcement points, and the journey.

Fig. 02a  //  deployment journey with enforcement points C1–C5
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 · 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
Fig. 02b  //  request lifecycle, start to finish
GOVERNED AGENTIC UTILITY — REUSABLE DOMAIN PATTERN Rule Studiono-code authoringby domain experts DAG rule enginerules assemble intoa governed graph Agenciesgoverned agent teamsscoped · logged Deterministicvalidationgates every action Governedactions /outputs Knowledge estateresolved graph +data in place Model (assist)extract · summarisenever finalises Audit & lineageevery decision → source + rule versionreproducible · defensible THE PATTERN Domain experts author rules in a no-code Studio → the rules compile 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 rule version. The model assists; it never decides. The same skeleton is reused per domain — the domain lives in the rules and lenses, not in new code.
Fig. 02c  //  identity and keys — 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-time choices

Fixed architecture. Seven decisions.

The architecture is fixed; these seven choices are not. Each has an owner and a stage. Everything else — the boundaries, the gateway, the model rule, the enforcement points — is fixed and does not change per deployment. That is what makes these seven the whole of the deployment-time surface.

DecisionSet byWhenWhat it determines
EditionCustomer + DataFabDesignWhere the planes run and who holds custody
Region / enclaveCustomerDesignResidency and jurisdiction
Network CIDRsCustomer infrastructureSetupAddress space and connectivity pattern
Key management / HSMSecuritySetupWhat protects data at rest, and who holds the keys
SIEM targetSecurity-operations teamSetupWhere the audit and telemetry stream lands
Recovery objectivesBusiness + ITDesignRecovery point and recovery time targets
Source listData ownerDiscoveryWhat the fabric connects to first

The deployment journey

Each phase has an owner and an exit gate.

A data plane stands up in hours. Connecting the first sources is typically same-day. Governance is authored as code and evolves from there. What follows is the shape of the engagement, not a multi-year programme plan.

01
design

Design

Edition, region or enclave, and recovery objectives agreed. The reference architecture is instantiated against your controls, not redrawn.

02
setup

Setup

Address space, key management, identity integration and the security-operations telemetry target configured by your teams, with the platform deployed by declarative infrastructure.

03
discovery

Discovery

The first sources are connected read-only. The fabric catalogues, profiles and classifies; the derived model is presented for review rather than authored from a blank page.

04
resolution

Resolution & approval

Entity resolution runs at thresholds you set; uncertain matches route to your people. The semantic layer is reviewed, corrected and approved.

05
build

First governed agency

Your own people compose the first agency in the Studio, test it in a sandbox against sample files, and publish it scoped and gated.

06
assurance

Assurance

Enforcement points are demonstrated against the engineering evidence pack, and the audit and lineage stream is proven end to end into your own tooling.

07
expand

Expand

Each new source deepens the graph, sharpens the semantic layer, and makes the next utility cheaper than the last.

Resilience & disaster recovery

Two failure modes, two answers.

Loss and corruption are not the same problem and do not have the same remedy. Loss is answered by replication and failover. Corruption is answered by rollback and re-derivation — and because the knowledge state is derived from sources that never moved, re-derivation is a real option rather than a restore from a backup of a copy.

Loss

Replicate & failover

Recovery point and recovery time objectives are set by the business at design stage and engineered to, not assumed.

Corruption

Rollback & re-derive

The semantic layer and the resolved state can be rolled back to a version, or re-derived from sources that were never modified.

Identity & keys

Custody is explicit

Who may act, and what protects data at rest. Custody shifts to you from Professional upward, and the model is inspectable.

Network

Topology per deployment

Direct TLS, VPN tunnel, private link or agent-based for air-gapped estates — populated by engineering per environment.

Fig. 04  //  two failure modes, two remedies◆ re-derivation is only possible because nothing moved
LOSS AND CORRUPTION ARE DIFFERENT FAILURES AND DO NOT SHARE A REMEDY.FAILURE MODE 01 — LOSSReplicate and fail overStandby plane held in a second zone or regionResolved state and semantic layer replicatedRecovery point and recovery time set at designFailover exercised, not assumedFAILURE MODE 02 — CORRUPTIONRoll back, or re-deriveSemantic layer and resolved state are versionedRoll back to any approved versionOr re-derive from sources that were never modifiedPossible only because nothing was ever migratedA PLATFORM THAT INGESTED YOUR ESTATE CAN ONLY RESTORE A BACKUP OF A COPY. ONE THAT READS IN PLACE CAN REBUILD FROM THE TRUTH.
Fig. 05  //  connection patterns and the data-plane boundary● reference pattern, populated per environment
FOUR CONNECTION PATTERNS. THE ARCHITECTURE IS FIXED; THE PATTERN IS CHOSEN PER SOURCE.PATTERN 01Direct TLScloud-hosted sourcesmutual TLS, pinned, egress-restrictedCRITICAL SLA · 24HPATTERN 02VPN tunnelon-premises sourcessite-to-site, customer-terminatedCRITICAL SLA · 72HPATTERN 03Private linksame-cloud sourcesno public route at allCRITICAL SLA · 7DPATTERN 04Agent-basedair-gapped estatesoutbound-only, no inbound listenerCRITICAL SLA · NEXT RELEASECUSTOMER BOUNDARY — DATA PLANERuntimequery · resolve · executeCredential vaultHSM-backed, scopedAudit sinkto your SIEMSource systems — read-onlycustomer credentials · nothing copied outVALUES SHOWN AS PLACEHOLDERS ARE POPULATED BY ENGINEERING PER ENVIRONMENT — A REFERENCE PATTERN, NOT A NETWORK DRAWING

Build & release

Signed, inventoried, customer-approved.

In a regulated estate, what runs matters as much as what it does. Releases are signed, the software inventory is published, provenance is attested, and the customer approves what is promoted into their environment.

Signed artefactsSoftware inventory publishedProvenance attestedCustomer-approved promotionRelease monitoring, continuousBreaking-change alertsCompatibility review per vendor releasePre-release testing where available
Proven, not asserted

Enforcement points are demonstrated against an engineering evidence pack and recorded in a confirmation register, so the claim and the proof are the same document.

Fig. 06  //  signed, inventoried, attested, customer-approved◆ nothing promoted without your approval
WHAT RUNS MATTERS AS MUCH AS WHAT IT DOES.01Buildreproducible, pinned02Signartefact signature03Inventorysoftware bill of materials04Attestprovenance recorded05Approvecustomer gate06Promoteinto your environmentRELEASE MONITORINGcontinuousBREAKING-CHANGE ALERTSas announcedCOMPATIBILITY REVIEWper vendor releasePRE-RELEASE TESTINGwhere availableNOTHING REACHES YOUR ENVIRONMENT WITHOUT YOUR APPROVAL — THE CLAIM AND THE PROOF ARE THE SAME DOCUMENT
Fig. 08  //  network topology — placeholders populated 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.
Fig. 09  //  resilience and disaster recovery
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).
Fig. 10  //  build and release — signed, inventoried, attested, 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.

Document extraction

Extraction, not ingestion.

Most of what an enterprise knows sits in documents no query can reach. Document processing normally builds the very thing the fabric exists to avoid — a second copy of the estate, in a new store, under a new access model. This service accumulates nothing.

The principle

No secondary corpus

The source of record is never migrated or duplicated into a DataFab document store, and no secondary corpus is retained. A document is processed and its text returned with the evidence of how that text was produced.

The gate

Classified before dispatch

A document cannot be inspected in an external service to decide whether it was too sensitive to send there. Classification resolves from metadata the organisation already holds — before any byte moves. Unclassifiable is treated as sensitive.

The evidence

Every extraction is defensible

Direct extraction or OCR and by which backend; the classification basis and the routing decision it drove; model version, confidence, source hash, timestamp and duration — captured at processing time rather than reconstructed later.

Fig. 07  //  the classification gate resolves before dispatch◆ unclassifiable is treated as sensitive
A DOCUMENT CANNOT BE INSPECTED IN AN EXTERNAL SERVICE TO DECIDE WHETHER IT WAS TOO SENSITIVE TO SEND THERE.INPUTS TO THE GATE· Classification held in the fabric· Repository policy & entitlements· Caller assertion, where trusted· In-boundary first pass, optionalTHE GATEresolves before dispatchSENSITIVE — IN-BOUNDARY PATH ONLYNever dispatched. Processed inside your environment, or not at all.ROUTINE — APPROVED BACKEND, TRANSIENTLYA representation is transmitted for the duration of the call. Nothing is retained.UNCLASSIFIABLE IS TREATED AS SENSITIVE. MOST RESTRICTIVE INPUT WINS.The source of record is never migrated or duplicated into a DataFab document store, and no secondary corpus is retained. Every extraction carries the backend used,the classification basis, the routing decision it drove, model version, confidence, source hash, timestamp and duration — captured at processing time.
Behaviour that matters most

Where confidence falls below the acceptance threshold, the service flags the region rather than inventing plausible text. Low-confidence output is routed for review, and reprocessing is supported.

Throughput and accuracy targets are drawn from the service specification and are set per engagement. They are targets, not measured results.

Next step

Stand up a data plane and connect one source.

Hours to a running plane, same-day to the first connected sources, and governance authored as code from there. Bring your controls; the architecture is designed to meet them, not to be argued with.