DataFab / Governance
Accountable by construction
Eight properties, enforced at the graph.
Classification, need-to-know, human authority and a complete record are enforced at the graph itself — on every read and every action, for every person and every agency. Who is authorised to do what is answered before the question is asked.
Governance at the graph
Eight properties, enforced not advertised.
Because governance is a property of the graph rather than a layer on top of it, the answer to “who did what, why, and were they allowed to?” is always available — recorded as it happened, not reconstructed after the fact.
Classification-aware
Every record, edge and product carries its marking. Handling and release rules are enforced, not advisory.
Need-to-know
Role- and attribute-based access at the graph. Each user and agency traverses only the slice it is cleared for — one fabric never means one undivided view.
Compartmentation
Ethical walls and compartments enforced across the connected environment. A shared picture that respects every barrier.
Human authority
Consequential decisions are gated to an accountable person. Agencies prepare, people decide, and the gate itself is logged.
Explainable
No black box. Every answer is grounded, cited to source, and reconstructable — the reasoning is inspectable.
Tamper-evident audit
A cryptographic hash chain prevents log tampering. Logs are encrypted at rest, require the auditor role, and have no delete capability.
Full lineage
Every fact traced from source to judgement. Every merge reversible and provenanced.
Oversight-ready
The defensible record is produced as the work happens — ready for an inspector, a court, an auditor or a client.
Where control is applied
Nothing enters unentitled. Nothing acts ungated.
Three points of control, each answering a different question, each inspectable rule by rule.
The entitlement filter
Every source access-control list feeds one consolidated permission model — authored and signed off by the enterprise rather than the vendor. Inherited entitlements are the floor: stricter, never looser. Reasoning runs over a view that already excludes what it may not see.
A wall around knowledge
A document wall asks whether you may open something. A knowledge wall also asks whether you may reconstruct what it would have told you. Declared over entity and relationship types, with derived edges and aggregates bounded by the same policy. Ontology governance in detail →
The deterministic gate
Between a proposal and an effect. A model proposes; a deterministic gate disposes. Bounded authority, contained blast radius, reversible, with a complete record of what was traversed and what was excluded.
Proof, not assurance.
Every traversal, disposition and output is stamped with its source, and the whole decision can be replayed under the rules in force at the time — a different standard from an audit logSecurity controls
Woven through every layer.
Authentication and role-based access at the top, encrypted credentials at the connectors, sandboxed execution in the middle, and a tamper-evident trail throughout.
| Control | Implementation | Property |
|---|---|---|
| Authentication | OAuth 2.0 with OIDC, mTLS, SAML 2.0, API keys | 15-minute access tokens |
| Access control | Viewer, contributor, editor, admin, auditor — with attribute-based scoping | Five roles, enforced at the graph |
| Credentials | AES-256, hardware-security-module backed, just-in-time and scoped | Separation of duties; never in an agent definition |
| Data protection | Public through highly restricted, with masking and tokenisation | Five classification tiers |
| Execution isolation | gVisor sandbox, read-only filesystem, allowlisted network, time and memory limits | No exfiltration path |
| Tool authorisation | Read-only automatic, writes logged, administrative actions multi-party | Scoped per use case |
| Audit trail | Hash-chained, encrypted at rest, auditor role only, no delete capability | 1–2 year retention |
| Lineage | Technical, business, column-level and operational | Serves as compliance and audit evidence |
| External enrichment | Approved sources only, per-source credential isolation, rate limiting, data minimisation, time-limited caching | Full lineage from source to graph |
The record
The assessment and the evidence are the same artefact.
The hardest question is not what the system found. It is whether you can defend how you found it. Every judgement carries its evidence, its authority and its lineage — so the finished product and the record behind it are not two documents that have to be reconciled later.
Evidence, attached
Every conclusion links to the source it rests on. Nothing floats free.
Authority, logged
Every gated decision names the person who made it and the basis they had.
Lineage, complete
From raw source to finished product, the chain is unbroken and inspectable.
Replay, years later
The data state, rule versions and execution path that produced a result — not an approximation of it.
Nothing an agency does becomes enterprise truth on its own. Knowledge climbs through governed states — observed, proposed, validated, approved — and is superseded when the evidence changes. The fabric is never polluted by raw model output.
Questions
Answered plainly.
01Is our data ever sent to DataFab?
Two things are true in every edition: raw records never leave the system of record that owns them, and the control plane holds only metadata, policy and configuration — never raw data. What an edition changes is whose environment the data plane runs in. In Foundation it is a single-tenant environment DataFab operates in the region you choose; from Professional upward it is your own cloud account, tenancy or premises, and key custody moves with it. The full definition, per edition →
02Do you train models on our data?
No. DataFab does not train on client data. The value comes from resolving what you already hold, in place, under your own controls — not from absorbing it into a model that other organisations then benefit from.
03What stops an agent from inventing something?
Extraction and derivation are constrained by seed schemas — entity, relationship and attribute types. The system can enrich and extend the model but cannot invent entities outside it. That is hallucination prevention by construction rather than by prompt. Where confidence falls below threshold, the system flags rather than fabricates.
04Can it run air-gapped?
Yes. Full functionality inside an isolated network, with agent-based, outbound-only connectivity where a boundary must be crossed at all, and the control plane self-hosted where required. The picture and the guarantees both travel forward to a disconnected edge.
05Who holds the keys?
You do, from the Professional edition upward. Key management and hardware-security-module choices are set by your security team at deployment, and the identity and key custody model is inspectable rather than described.
06How do you prove the enforcement points rather than assert them?
Each enforcement point is demonstrated against an engineering evidence pack and recorded in a confirmation register signed off by engineering, so the claim and the proof are the same document. Deployment-specific values are populated per environment rather than promised in a brochure.
07Which models does it use?
DataFab is model-agnostic, so the platform compounds as general models improve rather than depending on one vendor’s roadmap. Model selection is a per-agent configuration, and for sovereign deployments the model rule is fixed by the architecture at deployment.
08What happens when a source system changes?
Change detection in active metadata keeps the knowledge state current. Downstream assets inherit upstream restrictions, and lineage makes the impact of a schema change visible before it propagates. A hand-built ontology goes stale on the day a system changes; a derived one adapts.
Next step
Bring your security team to the first conversation.
The architecture is designed to be examined, not accepted. Editions, enforcement points, key custody and the audit stream are all set against your controls at design stage.