KNOWLEDGE

Process context vs. data context

Both are real, both are needed, and they answer different questions. Where the boundary falls, and what happens to the questions that land on the wrong side of it.

These two terms get used interchangeably, and they are not the same thing. The distinction matters because it predicts which questions your context layer will answer well and which it will answer badly, or confidently and wrongly, which is worse.

Data context

Data context describes your information assets. It grew out of the data catalog discipline and it is genuinely good at what it came from.

It holds: what tables and fields exist, what they mean, where the data came from and what it feeds, who owns each asset, how fresh it is, what quality rules apply, and which classifications govern access.

Questions it answers well:

Where does this figure come from, and what feeds it?
What does this field actually mean?
Who do I ask about this table?
If we change this column, what breaks?

This is real work and it is worth doing. Nothing below is an argument against it.

Process context

Process context describes your work. It holds: the steps, the things that move through them, the events that change those things, who performs and who approves each step, what policy constrains it, which system it runs on, what it is measured against, and what is supposed to happen next.

Questions it answers well:

Which step creates this record, and why?
Who is allowed to approve this, and above what threshold?
What is supposed to happen next, and what happens when it does not?
What does this role actually do on a Tuesday?
Where is the control, and where is the evidence that it is real?

The difference in one line

Data context describes the nouns. Process context describes the verbs, and attaches the nouns to them.

A data catalog can tell you that billing_document exists, which system owns it, and what feeds it. It cannot tell you that the exception path adds two approval steps, that the second one only applies above a threshold written in a procedure document, or that the reason the step exists is a regulatory commitment made four years ago.

That information was never in a table. It was in a document, and it stayed there.

Where the boundary actually falls

The test is simple. Ask whether the answer is a property of a thing or a property of what happens to a thing.

| The question | Which layer | |---|---| | What does "active customer" mean here? | Data | | Where does this number come from? | Data | | Who owns this table? | Data | | Which step writes this record? | Process | | Who approves it, and above what amount? | Process | | Why does this exception path exist? | Process | | What should happen next? | Process | | Which steps have no documented control? | Process |

Most organizations have invested in the left column and almost nothing in the right. Then they are surprised when the questions arriving from the business, and now from their own AI tools, are overwhelmingly from the right.

The failure mode when the layers are confused

The characteristic failure is not an error message. It is a confident, plausible, wrong answer.

Give a language model a catalog and ask it a process question. It has tables, lineage and definitions, so it will produce something fluent. It will infer the approver from whichever field looks most like a person. It will infer the sequence from foreign keys. It will not know about the threshold, because the threshold is in a PDF.

Nothing signals that the answer is a reconstruction rather than a lookup. That is what makes it expensive.

The same failure happens with people. A new analyst given only the data model builds an impressively wrong mental picture of the business.

They are complementary, not competing

Process context does not replace data context. It needs it: the things that move through a process resolve to real records in real systems, and knowing which is a data-catalog job.

The argument is about order and organizing principle. Attach data to a process spine and the data inherits meaning: this field, on this step, constrained by this policy, owned by this role. Attach process to a data spine and you get a well-documented pile of columns with some notes about work stapled to the side.

One layer holds the nouns. The other holds what the organization actually does. You need both, and only one of them can be the spine.

The six layers behind one ordinary question →

Try it on one of your own documents.

One process, free. You will know within an afternoon whether this is useful to you.

Request access

No credit card. Five design partner places. A person replies.

Upload one document. See what comes back.

FOR THE PERSON DECIDING

One ordinary business question, and the six layers needed to answer it →