What is enterprise process context?

Enterprise process context is the structured, evidenced record of how an organization actually works: organized around its processes rather than around its data.

That definition contains a claim, and the claim is the interesting part. Every attempt to build an organizational context layer eventually needs an organizing principle: something to hang meaning off. The choice of principle determines what the layer can and cannot answer.

Why an organizing principle is unavoidable

Context is not a pile of facts. A pile of facts is a document graveyard, which most organizations already have.

Context is facts in relation to something. "Approval threshold: $50,000" means nothing on its own. It means something when attached to the step it constrains, in the process it governs, for the role that performs it.

So the question is not whether to pick a spine. It is which one.

The usual choice, and its ceiling

Most efforts pick the data model, for an understandable reason: it is already machine-readable. The tables exist, the columns have names, lineage can be traced automatically.

The ceiling is that a data model tells you what tables exist, not what the company does. It holds the nouns and almost none of the verbs. It can tell you that a billing_document table exists and which system writes to it. It cannot tell you which step creates that record, who is allowed to approve it, what policy constrains the amount, or what is supposed to happen next.

The schema knows your columns. It does not know your company.

The claim: process is the spine

The thing that actually organizes an enterprise is how the work runs.

capability
  └─ process group
      └─ process
          └─ the things that move, and the events that change them

Attach everything else to that spine and it holds, because every one of these is a fact about a step:

| Plane | Meets the process as | |---|---| | People | roles, owners, approvers, experts, escalation paths | | Organization | who is accountable for which step, where the handoffs are | | Data | the objects that move and the events that change them | | Systems | what each step runs on, the transactions, the integrations | | Policy | the rules and controls the step must obey | | Performance | the targets and service levels the step is measured on | | Human decisioning | the judgment calls, and who may make them | | Agentic decisioning | the same decisions, with a machine allowed as far as you let it go |

No other plane holds all eight. A data model holds two. An org chart holds one. A diagram holds a picture of one.

What makes it a record rather than documentation

Three properties separate a context record from a well-organized wiki.

It is structured. The things that move through a process are first-class entities with typed relations to the events that change them, not prose describing them. That is what makes it queryable: "who owns every event that touches an invoice", "which steps have no job aid", "which controls have no evidence".

It is evidenced. Every element carries whether it was stated in a source document or inferred, a confidence score, the quoted sentence, and its human review state. A record you cannot challenge is a record you cannot rely on. Inferred elements stay visually distinct until a person confirms them, and nothing human-confirmed is silently overwritten.

It is human-confirmed. Drafting is automated; acceptance is not. This is what makes the record usable as a statement of intent rather than as a probabilistic summary.

Why this became fundable

Organizations had this problem long before they had an AI problem. New hires took six months. Institutional knowledge walked out at retirement. Four teams held four definitions of the same term. None of that was ever a technology problem.

What changed is that the same missing layer now also blocks something with a budget attached. Give a language model your catalog and it knows the shape of your data and nothing about your business. The process layer is what supplies the why, the who decides, and the what happens next.

So the accurate framing is: context is a human prerequisite that AI made fundable. Build it for the people. The agents are the second beneficiary.

How process context compares to data context →

• 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.

• What to do before your process expert retires

  One person knows how it really works. They are leaving in March. Here is what to do with the time you have left.