The Enterprise That
Understands Itself.
DataFab turns the systems, data, knowledge and decisions already inside an organisation — continuously enriched by external intelligence — into a living, governed knowledge layer that discovers what the enterprise knows, lets humans and agents jointly operate against that knowledge, and compounds every validated insight, decision and outcome into a continuously richer understanding of the organisation and the world around it.
Governed utilities
Ready-made agentic applications on top of the platform. The Financial Crime Unit is one of several — and you can build your own.
Knowledge & Agentic Studio
Where the enterprise composes, tests and publishes governed agents — in language, or with full control.
Knowledge Fabric
Discovers and resolves the systems you already run into one governed, cumulative knowledge state — read in place.
Don’t rebuild the enterprise. Draw it.
DataFab discovers and resolves the systems you already run into a governed knowledge state, then gives your people and agents the tools to operate, refine and compound it.
Your enterprise already knows — DataFab makes it usable. The complete Knowledge Fabric follows — every slide, live. It is the ground every agent and utility stands on.
The Knowledge
Fabric.
The foundational data-integration and intelligence layer of DataFab. It discovers and resolves the systems you already run into one usable knowledge graph — the ontology is derived from your estate, read in place, and kept current by the fabric itself.
What the Knowledge Fabric is
A metadata-driven layer that gives unified access to distributed data assets — maintaining mappings and relationships rather than duplicating data.
Knowledge Graph
Graph-native storage with entity resolution
Entity Resolution
Cross-source matching and linking
Connectivity
Direct DB / API / MCP connectors
Data Flow
Read from and write back
Discovery
Automated identification and cataloging
Active Metadata
Continuous analysis and enrichment
External Sources
OSINT and external integration
Data Lineage
End-to-end tracking of data flow
MCP Creation
Model Context Protocol generation
Monitoring
Health, performance and security
From connection to knowledge.
Point the fabric at a source. The discovery, resolution, ontology and upkeep happen inside it — the knowledge state forms, and maintains, itself.
Six governed layers
Each layer carries its own controls. The Semantic Layer is the Fabric’s primary output — the derived model everything above consumes. Requests flow down to the source; data is read in place and resolved on the way back up. Click a layer to open it.
A living graph of entities
Person, Organization, Matter, Document, Address and Identifier nodes — connected by typed, dated relationships. Hover a node to trace its edges.
A name match is never an identity
Records from every source are blocked, scored, clustered, reviewed and merged into one authoritative golden record — with a confidence score and full provenance.
registry p.2 · CRM #7741 · matter 4821
The resolution pipeline
One identity, in every language.
The pipeline above closes the first gap — but real estates do not speak one language. The same identity arrives rendered across scripts and spellings, and different people arrive sharing one name. The Fabric handles both at the ontology level: it reasons over entities, not strings, so every rendering resolves to one record — and one name never collapses two people — with provenance and a confidence score on every decision.
Transliteration, native
Not translation — the same name written in Arabic, Cyrillic, Han or Latin script matches phonetically and semantically, as one entity.
Disambiguation
Different entities that share a name held apart by context — biography, relationships, geography, time.
Cross-lingual
100+ languages and every major script — matched phonetically and semantically, not by spelling.
At the ontology level
Resolution is a property of the graph, not a feature of one tool — so every layer and every utility inherits it.
Disambiguation, done right.
A name-match that merges two different people is worse than no match at all. DataFab splits entities that share a name by weighing the context around them — biography, relationships, geography and source — and surfaces the network behind each, revealing the hidden hierarchy.
Link analysis
The network behind each entity — who is connected to whom, and how.
Pattern of life
Movement, contact and behaviour over time — anomaly surfaced, not buried.
On the record
Every merge and every split provenanced, scored and reversible.
Resolve in place
Direct access without ETL or replication. The fabric reads from source systems and resolves on the way back — the records never leave, and there is no integration layer to engineer.
Stored in the fabric
Remains in source
Enrichment, with provenance
A registry of approved sources feeds an enrichment engine — each field schema-bound and traced from source to graph.
Corporate Registries
Incorporation, officers, filings
Identity Verification
ID document validation
Business Data
Company info, financials
Sanctions Lists
Designated persons/entities
Data Providers
Professional information
Adverse Media
News, public information
Court Records
Public litigation records
Public Databases
Government data sources
News & Gazettes
Official gazettes & public notices
OSINT
Open-source web & social signals
Every system, one protocol layer
The fabric both consumes and generates MCP connectors for federated queries. Filter the catalog.
Connectivity patterns & assurance
| Pattern | Use case |
|---|---|
| Direct TLS | Cloud-hosted sources |
| VPN Tunnel | On-premises sources |
| Private Link | Same-cloud sources |
| Agent-Based | Air-gapped environments |
| Activity | Frequency |
|---|---|
| Release monitoring | Continuous |
| Breaking-change alerts | As announced |
| Compatibility review | Per vendor release |
| Pre-release testing | Where available |
| Severity | Response |
|---|---|
| Critical — flow stopped | 24 hours |
| High — degradation | 72 hours |
| Medium — workaround | 7 days |
| Low — cosmetic | Next release |
It catalogs itself, continuously
Crawlers and profilers catalog the estate you already run — metadata and statistics only, no manual inventory — while active metadata classifies, monitors quality, tracks lineage and detects change, so the knowledge state maintains itself.
| Component | Function |
|---|---|
| Crawler Engine | Traverses source structures |
| Schema Extractor | Read-only table/column metadata |
| Profiler | Statistical profiles, sampling only |
| Classifier | ML-based PII / sensitive detection |
| Category | Handling |
|---|---|
| PII | Restricted access, masking |
| Legal Privileged | Highly restricted |
| Financial | Confidential, encryption |
| Health | Restricted, HIPAA controls |
| Custom | Configurable handling |
| Lineage type | Security use |
|---|---|
| Technical | Impact analysis |
| Business | Compliance mapping |
| Column | Sensitive-data tracking |
| Operational | Audit trail |
The ontology builds itself.
You don’t hand-build the model. It emerges from what the fabric has already extracted — source structures, data profiles and resolved entities become a governed domain model — the Semantic Layer, the Fabric’s primary output. A hand-built ontology is a specialist programme measured in months; a derived one forms in place and stays current.
An ontology is a graph of knowledge: entity types linked by relationship types, each carrying attributes. This is the derived model — the Persistent Knowledge Graph then fills it with your resolved records.
- Authored up front by a specialist team
- Months before the first unit of value
- Every new source is a fresh modelling project
- Goes stale the moment a system changes
- Emerges from the estate you already run
- Value in weeks — no modelling programme
- Schema-bounded — it never invents entities
- Human-refined, then self-maintaining
Corporate memory
A durable knowledge base the fabric derives and accumulates from your sources over time — organized as a four-level knowledge tree.
Attributes
Entity property information — names, dates, values
Relations
Entity-to-entity relationship triples
Keywords
Semantic keyword indexing for search
Communities
Hierarchical clustering for global context
Source provenance model
| Element | Description |
|---|---|
| Connector ID | Source-system reference |
| Document reference | Document ID, title, URL |
| Precise location | Page, paragraph, offset, cell range |
| Extracted text | Exact text the entity came from |
| Confidence score | 0–1 |
| Timestamp | When extraction occurred |
The fabric is not enriched only from source systems. Governed schemas, accepted relationships, approved human decisions, workflow outcomes and reusable operational knowledge created through the Studio can cascade back into the persistent knowledge state, with provenance, authority and version attached. The enterprise representation therefore compounds as work is performed.
Governance, measured
The fabric tracks its own governance health against clear targets.
Governed at every layer
Security is woven through the stack — authentication and RBAC at the top, encrypted credentials at the connectors, and a tamper-evident trail throughout.
Where it runs, and how it is proven. The same platform, delivered against your estate and your controls — two planes with one boundary, three editions from managed to sovereign, and a signed chain of custody from source to the gate that is yours.
The whole architecture, end to end.
Interactive — switch views along the top: the reference deployment, the reusable utility pattern, where it physically runs, recovery for loss and corruption, the chain of custody, who may act, and discovery to go-live. Click any component for its enforcement, trust and failure mode; click a red badge for the evidence that proves it.
Where the work goes.
The modelling, the mapping and the upkeep of an enterprise representation happen inside the fabric — drawn from the sources you already run.
Value before modelling is finished.
The estate is discovered and resolved into a usable representation as the fabric goes — you refine while already using it. There is no enterprise model to complete before value appears; it emerges from what is already there.
No mandatory ontology + ETL programme.
Data is read in place, so there is no bespoke ontology-engineering or pipeline programme to build and maintain. The cost is operating the fabric — not funding a transformation programme to construct the enterprise representation by hand.
Continuously maintained by the fabric.
Connect a source, set policy and schema where they matter, and the fabric discovers, resolves and keeps the knowledge state current as the estate changes — run by the people who run the business, not a standing bench of specialists.
The Fabric grounds — the Studio enriches.
↑ Fabric → Studio · grounded
Every agent queries the resolved graph — entities, relationships and provenance — instead of raw, unresolved sources.
↓ Studio → Fabric · governed
Schemas, accepted relationships, approved decisions and outcomes cascade back into the knowledge state — provenance, authority, version.
The complete Knowledge & Agentic Studio follows — every slide, live. It is how the Fabric is put to work, and how it is enriched.
The Knowledge & Agentic Studio.
The build surface of DataFab — where the enterprise composes its own governed agents from its documents, in its own language, and on its own schemas. Every agent schema-bound, sandboxed, human-gated and audited.
Where governed agents are built
Build, test and publish Data-Driven Agents, design workflows, define widgets and orchestrate multi-agent solutions — the complete builder experience.
Domain Discovery
Extract schemas from your documents
Data-Driven Agents
Schema-bound processing units
Visual Pipeline Builder
Drag-and-drop, no code
AI Planning
Build a DDA from a description
Chain of Agents
Orchestrate with human gates
Graph of Agents
Non-linear graph orchestration
Widget Types
Visual interface components
Datasets
Structured, schema-bound data
Utilities
Reusable API + DDA components
MCP Integrations
Connect — and author — connectors
Unified Tool Catalog
Every tool, one searchable place
Template Library
Pre-built workflows
From words to a governed agent.
Describe the outcome. The Studio derives the schema, plans the pipeline, and hands you something to test — built from what you already have.
Two hands on the same tool
The Studio meets a business user and a platform engineer where each is strongest — and both routes converge on the same governed artifact.
Build it in language.
Compose it with full control.
The builder stack
A gateway over core builder services, a testing engine, a governed execution engine, AI planning, and integration into the Knowledge Fabric. Click a band to open it.
The Studio doesn’t only consume the Fabric. It enriches it.
“Grounded in the Fabric” is only half the picture. Every governed schema, accepted relationship, published agent, workflow, human decision and execution outcome can cascade back into the Fabric — with provenance, version and authority attached. The enterprise doesn’t merely automate work; its operational knowledge compounds as the work is performed.
Discovers the enterprise.
Draws the estate you already run into one resolved, governed knowledge state.
Formalises & executes.
Lets the enterprise define and run how it works — then feeds the validated result back.
What cascades back
Governed, not self-taught
Nothing an agent does becomes enterprise truth on its own. Knowledge climbs through governed states before it is authoritative — and is revised when the evidence changes.
Drawn and authored
The Fabric begins drawn — discovered automatically from the estate. Through the Studio, people also author: schemas, business rules, approval structures, workflow logic, domain interpretation and reusable agents. Those authored objects become part of the persistent knowledge state. The architecture is neither purely drawn nor purely authored.
The unit of execution
A DDA pairs a language model with a structured query plan for schema-bounded processing — not a loose prompt, but a governed, reusable agent.
Definition
Query plan
Placeholders & runtime config
Lifecycle
How an agent is built
Start a new agent
User initiates creation — “create a new Data-Driven Agent.”
Pick or discover a domain
Select an existing business domain, or create one by uploading documents — schemas are extracted automatically.
- Existing — entity schemas ready
- New — via domain discovery
Review the schema
View the generated schemas and shape them — entities, attributes, constraints and relationships.
- Entities — add / modify / remove
- Attributes — types & constraints
- Relationships — define links
- Domain — assign
Define the agent
Name, description, plain-language instructions, model and prompt — then the query plan and configurable placeholders.
- Instructions — plain language
- Model — LLM selection
- Query plan — datasets · MCPs · DDAs · scripts
- Placeholders — configurable slots
Draft & test
Save as a draft and test interactively — run with sample files, validate output against the schema, iterate.
- Sandbox — isolated run
- Sample files — real inputs
- Validation — against schema
- Apply draft — when satisfied
Publish & govern
Set it published, configure runtime placeholders, set access permissions, and make it available to others.
- Publish — DRAFT → PUBLISHED
- Runtime — placeholder mapping
- Permissions — scoped access
- Reuse — available to others
Your schemas, from your documents
Upload the documents you already have — specifications, policies, contracts, forms — and the Studio extracts the schemas. The domain model is derived, not declared by hand.
Schema-driven processing
Once bound, schemas govern every agent: input, output, internal and validation bindings enforce types, constraints and references — and DDAs pin to explicit schema versions.
| Document type | Extraction focus |
|---|---|
| Data specifications | Data models, field definitions |
| Policies | Workflows, rules, roles |
| Contracts & agreements | Parties, terms, obligations |
| Regulatory documents | Requirements, controls |
| Forms & templates | Input fields, validations |
| Binding | Purpose |
|---|---|
| Input schema | Validates incoming data structure |
| Output schema | Ensures output conforms |
| Internal schema | Controls intermediate transforms |
| Validation schema | Enforces business rules |
Describe it. See the pipeline.
Write the workflow in a sentence; the Studio generates a pipeline you can preview, refine and run — or drag it together from the node palette. Either way, no engineering bench required.
The node palette
Twelve building blocks, validated in real time — type checking, cycle detection, reachability and permission checks as you build.
Agencies, not agents
Compose multiple agents into a workflow — with human review gates wherever judgement belongs. Governed teams of agents, each with one job.
Sequential + gate
Branching
Hierarchical
Graph of AgentsPlanned
The next step extends the linear chain into a full directed graph — conditional branching, parallel fan-out / fan-in, cycles with exit conditions and dynamic routing, with a human gate available at any node.
The level of automation is a dial.
The Studio does not force one mode. Each use case — and each step within it — runs at the level of autonomy its risk allows, from fully deterministic to fully agentic.
Author your own connectors
Connectivity is MCP-first. When a firm-specific system has no built-in connector, you don’t wait for the platform — you author one, have it validated, and publish it to the catalog yourself.
Governed by construction
Every agent runs inside an isolated sandbox, calls only the tools it is authorised for, receives credentials only at execution, and writes a tamper-evident trail. Governance is not configured on — it is the default.
Who builds it.
The agents that run the firm are built by the firm — from its own documents, in its own language, on its own schemas.
You build them.
Domain discovery, AI planning and the visual builder mean the people who know the work compose the agents — from documents they already have. Not a bench of specialists, and not a vendor engagement for every new workflow.
From words, not code.
Describe an outcome and the Studio derives the schema, plans the pipeline and hands you something to test. Templates and a node palette do the wiring — so a working, governed agent is a short step from an idea.
Governed by construction.
Every agent is schema-bound, sandboxed, permission-scoped, human-gated where judgement belongs, and fully audited — by default. The governance isn’t a layer you add later; it is how the agent is made.
A utility is the platform, pointed at a problem.
↑ Studio → Utility · assembled
A utility is agents, workflows and widgets composed in the Studio and published — the same build surface, packaged for a domain.
↺ Utility → Fabric · sharpens
As a utility runs, its governed decisions and outcomes enrich the Fabric — the platform gets better at the work the more work it does.
Enterprise intelligence, without the transformation programme.
DataFab draws the enterprise from the systems already running, turns that knowledge into governed execution, and continuously compounds what the organisation learns — without a new data estate, a hand-built ontology, or a permanent specialist army.
Governed utilities.
Ready-made agentic applications that ship on top of the Fabric and the Studio. Each is grounded in the graph, governed by construction, and enriches the Fabric as it runs. Click a utility to expand it.
Financial Crime & Compliance
Due Diligence
Car-Finance Remediation
Legal CLM
Insurance Claim Handling
Gov Intelligence & Investigation
Build your own
Deploy it where you need it.
The same governed platform, delivered against your estate, your controls and your operating model.
Cloud
DataFab-hosted, single-tenant, in your region.
Private cloud / VPC
Your cloud account, private connectivity.
On-premises
Inside your data centre; read-in-place to sources.
Air-gapped
Agent-based, outbound-only for isolated estates.
BPO / Managed Service
Run as a managed service or embedded in a BPO — outcome- or per-case pricing, with DataFab operating the agencies to a guaranteed margin.
Price the outcome, not the headcount.
Delivered as a managed service or inside a BPO, the governed agencies do the work and a person sits on the gate. That moves pricing from per FTE to per case — and because the Fabric compounds, unit cost falls as volume grows instead of staying flat.
- Cost driven by analyst time
- Margin competed away head-by-head
- Unit cost flat as volume grows
- Throughput means more hires
+ human gate
- Agencies do the work; analyst on the gate
- Margin designed in, with a floor
- Unit cost falls to ~45% of today’s at volume
- Throughput scales without headcount
Governed & certified by construction.
Security is woven through every layer — and independently certified.
Resolve in place
Records never leave source systems.
Human-gated
Judgement stays with people.
Schema-bounded
No entities invented outside your schema.
Tamper-evident audit
Hash-chained, no delete, Auditor-only.
The whole machine.
Sources stay in place and are discovered and resolved into one governed knowledge state. Agencies, built in the Studio, ground on it and run — with humans at the gates. Utilities ship on top. And every governed result flows back, so the whole thing compounds.
One governed knowledge fabric.
Any critical workflow.
Connect the enterprise. Understand it. Build how it works. Let governed agents do the work — and let every validated result compound. The Financial Crime Unit is one utility; the same platform produces the rest, and any you build.