How we do it

Pick one number on your last regulatory return.How long would it take to show how it was produced?

Watch the video
xflow: process context · 2 min 22 s
See how to build process context
The order of work

Question first. Then the process that answers it, including the code and the data.

Context is not a property of data. The same figure answers different questions for different people. xflow starts from the question: who is asking, which decision it serves and what the number has to include. That is consumer intent. Each question gets its own process, and the steps and rules inside it are producer intent: how the answer is produced, down to the code, data, spreadsheets and people at each step.

Held together, the two cannot drift apart. Shared steps can still be reused, but every process knows which steps it depends on and why.

CONSUMERINTENT PRODUCERINTENT The question Process that answers it Step Step Step WHAT THE STEP IS MADE OF Code Data Spreadsheets People Components of the step, not stages after it
Where context goes missing

Governance describes the process. Your business runs it differently.

Take the retail outflows line on a liquidity coverage return. The policy and the catalogue describe how it should be calculated. The figure itself is produced somewhere else: in code, in a month-end workbook and in the judgement of the analyst who runs it.

Driver 1

The rules sit in code.

Whether a deposit counts as stable is decided in deposits/classify.py, and the run-off rate is applied in outflows/retail.py. The rules survive in the code, but the reasons they were written that way do not, and the catalogue cannot see either.

Driver 2

The last step sits with people.

At month end a liquidity reporting analyst overrides one product's run-off rate in Treasury adjustments.xlsx, from 5% to 10%. It may be the right call, but it lives in one cell and one person's knowledge, outside the system and outside any control.

Governance and operations run on separate platforms. Nothing joins them.

The catalogue lists the steps and the data. The code, the workbook and the people who actually produce the figure sit elsewhere, so every audit or change starts by rebuilding the picture by hand. Process context joins the two, so each figure is traced to its objective and validated as it runs, not reconstructed later.

The documented process
PROCESS Step 1 Code ? Data Step 2 Code ? Data ! Step 3 Spreadsheet ? People ? Question ? Figure

The question lives in a requirements document; the steps live in optimised code. The catalogue lists steps and data, but not which question the figure answers or the code, spreadsheets and people that produce it.

Process context with xflow
PROCESS Step 1 Code Data Step 2 Code Data Step 3 Spreadsheet People Question Figure

The question anchors its own process, and every step carries its real components. The figure can be explained from either end: which question it answers, and how it was produced.

Why it holds

Context you can trace is context you can trust.

Every link shows its evidence.

Each connection between question, rule, code and data carries the source it was found in, so a process owner, an auditor or a supervisor can check it.

Owners hold the gate.

Gaps and remediations are reviewed by the people accountable for the process before anything is relied on.

It adds to what you have.

xflow sits alongside the governance you already run, and writes corrections back to the catalogue you already use.

Three institutions, three outcomes. See where it is working →

Questions

What technology leaders ask.

What is process context?

Process context is the question a number answers and the process that produces it, held together at the level the business actually runs. The question is consumer intent: who is asking, and which decision the number serves. The process is producer intent: the rules, steps, code, data, spreadsheets and people that produce the answer.

Why do we have several different numbers for the same thing?

Because different teams ask different questions with the same word. Treasury, risk, finance and regulatory reporting can each hold a correct but different figure for the same balance on the same day. xflow names each figure by the objective it serves and ties it to the process that answers it, so you reconcile only when the same question gives two numbers.

How is this different from data lineage or a data catalogue?

A catalogue records registered lineage: what the organisation says happens, usually named by noun. It rarely records which question a figure answers, or the path the value actually takes through code, spreadsheets and manual steps. Process context joins those, so you can see and test how each answer is produced.

What does xflow read?

Code repositories, catalogue and lineage metadata, spreadsheets and other manual routines, and the knowledge of the people who run the process. Code-to-lineage is proven on Python and Java, with COBOL in progress.

How quickly do we see results?

At a G-SIB, xflow read the first code repository in a day and delivered end-to-end regulatory lineage in under two weeks.

Do we have to replace our data catalogue?

No. xflow sits alongside the governance you already run and writes corrections back to your catalogue.

Why does process context matter for AI agents?

An agent has no tribal knowledge. Ask it for exposure to a client and it will find a field called exposure and answer fluently, with whichever number it found first. A bigger context window just gives it more candidate numbers. Process context lets the question be routed by intent to the process built for it, with the approved rule and the evidence behind the answer.

Request a demo

Which number matters most to you?

Tell us the number and we will expose the process context on which it is built: the objective it serves, and the code, data, spreadsheets and people that produce it.

Request a demo

See it on a number you already report.