How it works

Three layers. One context supply chain for regulated AI.

xflow sits between your governance stack and your AI systems, data products, and regulated workflows, converting governed metadata into executable context. The architecture is straightforward. The result is a business process that can explain itself to a regulator.

The architecture

Governed metadata, context layer, governed execution

Each layer has a distinct role. xflow connects governed meaning to the systems, products, and workflows that need to use it.

Layer 1
Your governance stack

Your existing data governance investment: business glossaries, data lineage, policy frameworks, quality metrics, and catalogued metadata. This layer knows what your data means, where it comes from, and who is responsible for it. xflow reads from this layer. It does not replace it.

Collibra Informatica Alation Apache Atlas Custom metadata stores
Layer 2 — xflow
The context layer

xflow reads governed metadata from your governance stack and converts it into structured context that AI systems, data products, and regulated workflows can use. It maintains cell-level lineage between outputs and source metadata, updates context as governance data changes, and enforces policy constraints on what context is delivered. This is the layer that did not exist before.

Executable context Cell-level lineage Continuous updates Policy enforcement
Layer 3
Your systems, products, and workflows

Your AI models, agents, data products, reporting flows, and regulated processes consume context from xflow rather than raw or ungoverned data. Every output carries a traceable path back through the context layer to the governed metadata that shaped it. When a regulator asks how a conclusion was reached, the answer exists.

Risk aggregation AI Regulatory reporting AI Underwriting AI Actuarial AI Credit decision AI
Inside the context layer

What xflow actually does between governance and execution

Four capabilities that close the gap. Each addresses a specific failure mode of ungoverned context in regulated environments.

Context conversion

Reads metadata from your governance layer (business definitions, lineage graphs, data quality scores, policy tags) and converts it into structured context packages that systems and workflows can consume directly. The format is semantically coherent, consistently structured, and optimised for the specific task consuming it.

Cell-level lineage

Every piece of context delivered to AI is tagged with its governance provenance. When AI produces an output, xflow maintains the link from that output back through the context to the source metadata. This is not document-level attribution. It is field-level, cell-level traceability: the kind regulators expect under BCBS 239 and the EU AI Act.

Continuous context synchronisation

When your governance layer changes — a business rule updates, a data definition is revised, a quality threshold is adjusted — xflow propagates that change to the context your systems and workflows consume. No manual reprocessing. No stale snapshots. Execution reflects current governance reality, not the state of metadata at a point in time.

Policy-aware context delivery

Governance platforms define data access policies, sensitivity classifications, and usage restrictions. xflow enforces these at the context level: systems do not receive context they are not authorised to use. Policy compliance is built into the context supply chain, not added as a post-processing layer.

The digital twin wedge

The digital twin is the difference between describing context and making it executable.

Most tools around xflow stop at description: catalogue metadata, visualise lineage, enrich a semantic layer, retrieve documents, or manage model controls. A digital twin goes further: it creates a working model of how a governed process actually uses meaning, rules, controls, and evidence.

A digital twin is a live model of how a business process works.

It represents the decisions, actors, data elements, definitions, calculations, controls, approvals, and evidence that make up a real workflow. For xflow, the twin is built from governed metadata, not interviews or static process diagrams.

It knows which context belongs to which decision.

The twin maps definitions, lineage, policies, thresholds, rule logic, ownership, and source systems to the task they support. That is what makes context optimisation possible: AI receives the governed context needed for the specific decision, not the whole enterprise in every prompt.

It records what happened when AI used that context.

The twin preserves the context version, source metadata, policy checks, rule paths, and evidence attached to each AI-assisted output. That is what makes context governance possible: context becomes an enterprise asset with ownership, versioning, access control, auditability, and change history.

Getting started

50 days to one governed context flow

Three focused phases. Connect the governed metadata, activate it as executable context, then execute it where AI, data products, or regulated workflows need to use it.

Phase 1
Weeks 1–2

Connect

xflow connects to your governance stack: Collibra, Informatica, or custom metadata stores. We identify the governed metadata that matters for one priority flow, map the definitions, lineage, ownership, rules, and policies, and confirm the context boundary. No data migration required.

Phase 2
Weeks 3–5

Activate

xflow converts governed metadata into executable context. We build the context package and process twin, test context quality, validate end-to-end lineage, and confirm that policy constraints, ownership, and versioning are applied correctly.

Phase 3
Weeks 6–7

Execute

The governed context is used by the target AI system, data product, or regulated workflow. Outputs carry traceability to the definitions, lineage, rules, policies, approvals, and context version that shaped them, so evidence is produced as the work happens.

What stays the same

xflow does not require you to replace anything

Keep your governance platform

Collibra, Informatica, Alation. xflow reads from these systems. They continue to be your source of truth for metadata governance. Your governance team's work does not change.

Keep your models and workflows

xflow is not a model or workflow engine. It is a context layer. Your existing AI systems, data products, and regulated processes connect to xflow for context. Their design, deployment, and operation remain under your control.

No data migration

xflow reads metadata from your governance stack in place. No data needs to be moved, copied, or re-ingested. The context layer works with your existing metadata architecture.

No new governance processes

xflow works with the governance processes you have already built. If your data is governed, xflow can activate it for AI. The context layer extends what you have; it does not require a parallel governance programme.

See this for your use case

Tell us which AI system, data product, or regulated workflow you are targeting. We will walk you through what the context layer looks like for your governance stack and regulatory context.