Mathew McKie

The process is documented. Sarah owns it.

This can sound like a reassuring governance conversation. It may tell you less than it seems.

“Documented” might mean a two-page flowchart, a 200-page procedure, a RACI, a set of work instructions or a few slides describing how somebody thinks the process works. “Owns” might mean Sarah has the authority to change the whole process, or that she coordinates several teams who actually control it, or simply that she is the person everyone calls when something goes wrong.

All of those arrangements can be perfectly reasonable. More importantly, in the simple yes-or-no form that much governance reporting eventually takes, all of them can end up with exactly the same status:

Process documented: Yes. Owner assigned: Yes.

We use documents to stand in for processes and people to stand in for networks of responsibility and dependency. Both are useful. Without them, complex organisations would be impossible to manage. But they share an uncomfortable feature: the label can look much more precise than the thing underneath it.

A great deal of organisational complexity can be represented by a document and a name.

I think of this as semantic elasticity: the property that materially different things can satisfy what appears to be the same organisational requirement.

The flexibility itself is not necessarily a problem. In fact, organisations need it. The problem comes when meaningful variation goes unmonitored or unassured, while the status reporting completion gives no hint that the variation exists. The governance built on top can then look solid while being more fragile than it seems.

A document and a name

Imagine Sarah really does own customer onboarding.

The process crosses Sales, Operations, Finance, Technology and perhaps an external supplier. There are regulatory requirements, data flows, system integrations and exceptions. Somebody asks for the process to be documented, so a perfectly competent person produces a process document. It is reviewed, approved and put under document control.

What does that actually tell us?

Potentially a great deal. But it depends entirely on what the organisation meant by “document the process”. Does the document show the systems involved, the information that moves between them, the decisions each team makes, the exceptions, the dependencies and what happens when one part fails? Does it identify which data is authoritative?

Or does it describe the main sequence of activities well enough for a reviewer to approve it?

Either could legitimately be called a documented process.

The same problem appears when we say Sarah owns it. Can Sarah change the systems? Does she control the operational teams? Can she change the policy or move the budget? What happens when an important dependency belongs to somebody else?

There may be good answers to all of those questions. The point is that the word owner does not contain them.

I have worked in organisations with large libraries of controlled and approved documents where answering a question that crossed several processes still meant finding the right experienced people and working out what those documents meant when put together. Nothing was necessarily wrong with any individual document. What was missing was the relationship between them.

The same happens with organisational roles. The formal structure can look quite clean while the organisation works because experienced people know which spreadsheet is really authoritative, which named owner does not actually control a particular decision, which meeting resolves a particular conflict and who needs to be called before changing something that appears unrelated on the organisation chart.

The organisation works because people carry the missing connections in their heads.

Documents compress processes. Names compress networks.

Neither is necessarily a problem until nobody is checking what has been compressed.

The status trick

The really interesting part comes when a flexible requirement becomes a precise-looking status.

“Document the process” leaves room for interpretation. “Process documented” does not appear to.

“Assign an owner” leaves room for interpretation. “Owner assigned” looks objective.

Somebody has made the missing decisions in between. They have decided what counts as a good enough document, what ownership means in this case and which exceptions are acceptable. Often that is exactly what we want: capable people using judgement rather than senior leaders specifying every detail.

The problem is that once the status turns green, there may be nothing prompting anyone to check whether those choices still make sense, whether different teams made the same choices, or whether the process actually works as the document suggests.

A March 2026 National Audit Office review, Managing the government’s financial investments: the Financial Transaction Control Framework, contains a useful example. For one control, different public financial institutions were allowed to meet the underlying aim in different ways. Some had explicit annual transaction limits; others used different arrangements suited to their business model.

The NAO’s assessment kept those differences visible. Rather than treating implementation as simply complete or incomplete, it used several statuses, including cases where improvements were needed or HM Treasury had agreed an exception. That is a useful illustration of what assurance can do: look underneath the headline status and keep important qualifications visible.

There is an important fairness point here. HM Treasury (HMT) told the NAO it had not set out to design a formal control framework, but to set “guardrails”. The NAO assessed it as a control framework because of its name and its stated purpose of managing risks to responsible government investment.

The same report contains a related, but importantly different, example. HMT knew that the organisations it had designated as public financial institutions did not all meet every designation criterion. Of the four examined in detail by the NAO, only two met all of them. The published Framework did not show how each institution met the criteria, so a reader could reasonably infer that the designated institutions met them in full.

Strictly, that is not semantic elasticity. The criteria existed and were met to different degrees. It is a different problem, but the compression is similar: a decision with caveats became a simple status.

The reality was qualified, while the status was simply Designated: Yes. Information existed about the decision and its caveats, but it did not travel with the status.

The organisation had not necessarily made a bad decision. It had made a complicated decision and then represented it as a simple fact.

I do not know how often semantic elasticity leads to real organisational failure. I do think it is worth looking for.

Why organisations do this

Here are three plausible reasons.

First, it is easier to establish that a procedure exists than to prove that the process reliably produces the intended result. It is also easier to confirm that an owner has been appointed than to establish that the owner really controls all the decisions and dependencies needed to deliver the outcome.

Second, organisations have to simplify. A chief executive cannot understand every interface in every process, and boards cannot inspect thousands of controls in detail. They need owners, risks, actions and statuses because those shortcuts make the organisation manageable from a distance.

Third, there is a defensive advantage. “We documented it”, “we assigned an owner” and “we closed the action” show that recognised management activity happened, whereas showing that those activities actually changed how the organisation worked is usually much harder.

These shortcuts survive because they are useful. The danger starts when we forget they are shortcuts.

Tests worth running

Start by checking whether the elasticity is there at all. Choose one process that matters and ask three colleagues separately what would count as “documented”. If they describe materially different things that would all receive the same status, you have found semantic elasticity. Then ask one more question: what data would show which version is actually running?

Two further tests mirror each other: one is for the document, the other for the name.

The first is the stranger test. Could a competent newcomer who understands the business, but was not involved in creating the process, use the document to understand how the important parts of the system are supposed to work? Not every detail, but the states, interfaces, decisions, exceptions and dependencies that matter.

That tells you whether the document contains enough information. It does not tell you whether people actually work that way, which is a different question.

There is a stricter version: could you monitor it? Could you identify the events, identifiers, states and data that would tell you whether the process was actually running as documented? If you had to automate it, what would you have to specify that the document currently leaves to human interpretation?

This is where technology provides a useful discipline. A notation such as BPMN gives business and technical people a shared way of drawing and discussing a process, but using the notation does not decide what needs to be included. A process can still leave out the data, exceptions or state changes needed to observe how it actually works.

Conventional automation exposes those gaps because somebody eventually has to specify what triggers the process, what information moves, what decisions get made, what state changes and what happens when something goes wrong.

The second is the absence test. If Sarah disappeared for a month, what would stop happening? Which decisions could nobody make, which dependencies would become unclear, which meetings would lose the person who knows how the pieces connect, and which workarounds exist only because Sarah knows whom to call?

This is not simply key-person risk. If Sarah’s absence means knowledge disappears, that is one problem. If her absence shows that nobody else has the authority to make a decision the organisation depends on, that is an authority gap. The word “owner” can hide both.

There is another question that works particularly well for leaders:

How do we know this is controlled?

If the answer is that there is a procedure, keep going: how do we know the procedure describes what actually happens? If the answer is that there is an owner, keep going: what can the owner actually decide? If the answer is that there is assurance, keep going again: what did the assurance actually test?

At some point the answer should reconnect with something observable, ideally in data: an event, a state change, a behaviour or an outcome that tells us whether the process is actually working as intended. If it never does, you may have a sophisticated description of control rather than control itself.

Reporting can help as well. Where different routes to completion matter, say how the requirement was met and how it will be monitored or assured, rather than recording only that it was. “Implemented using an agreed alternative because…” tells us far more than “complete”. The point is not to invent another set of labels, but to stop throwing useful information away on the journey to the dashboard.

The conundrum

The flexibility that makes a large organisation workable is also what can make some of its statuses hard to interpret. People need judgement, different situations need different solutions, and not every interface should be dictated from the centre. Nor should every process become a 300-page manual.

The NAO describes essentially the same trade-off in its review of the Financial Transaction Control Framework. A principles-based approach gives organisations flexibility but can lead to inconsistent interpretation and application; a rules-based approach creates more clarity and consistency but can encourage people to focus on following prescribed steps rather than thinking about the best way to achieve the intended result.

Remove too much flexibility and the organisation becomes rigid and bureaucratic. Allow too much without monitoring or assurance, and the organisation can become confidently imprecise.

That is the conundrum.

The answer cannot simply be more rules. A better question is:

How precisely does this need to be specified for us to know whether it is working?

For an important process, that may mean being able to identify the data needed to monitor it. For a critical decision, it may mean being explicit about who has authority. For something we intend to automate, it may mean specifying the process much more precisely than we needed to when experienced people were quietly filling the gaps.

The answer will be different in different situations because greater precision has a cost. The level of specification, monitoring and assurance should depend on the consequences of getting it wrong.

A document and a name make a complicated organisation feel manageable, and often they genuinely do make it more manageable. But sometimes the precision is in the label rather than in the system.

“Document the process” becomes “process documented”.

“Assign accountability” becomes “owner appointed”.

“Put controls in place” becomes “controls complete”.

The first statement in each pair leaves substantial room for interpretation, while the second appears to describe a fact. That change in language is small, but the change in implied certainty is enormous.

The ambiguity has disappeared from the dashboard.

It has not disappeared from the organisation.

That is the Semantic Elasticity Conundrum.