Where the drawings stopped matching the plant

There is a moment in the life of every operation when the documentation stops describing it. Nobody announces it. A workaround becomes permanent, a line is added to a spreadsheet instead of a system, a step is skipped because the person who insisted on it left. The drawings are still on the wall and they are no longer the plant.

The gap is invisible until it is expensive. This piece describes how we go looking for it deliberately, and why the result is a ranked list rather than a report.

Documented state and operating state

Two descriptions of the same operation exist in every business of a certain age. The documented state lives in process documents, system configuration, org charts, contracts and specifications. The operating state lives in what people actually do, which is recorded, if at all, in logs, spreadsheets, message threads and habit.

Most diagnostic work samples one of these and assumes the other. Interviewing people gives you the operating state and none of the constraints it is supposed to satisfy. Reading the documents gives you the constraints and no evidence about compliance. The useful object is the difference.

Divergence as the unit of discovery

We treat a divergence as a first-class finding: a specific, named place where the documented state and the operating state disagree, with the evidence for both sides attached.

On a recent engagement, mapping a cross-border supply operation produced 25 of them. That count is not the point. The point is that each one is a concrete artefact a client can act on, argue with, or dismiss, rather than a paragraph of consultancy prose about alignment.

A finding that cannot be disagreed with is not a finding. If the client cannot look at a divergence and say "no, that one is deliberate", the analysis has not said anything specific enough to be wrong.

Extracting entities and relationships

The documented state is spread across formats that were never meant to be read together: PDFs, workbooks, system exports, contracts. The first step is extracting the entities each describes, suppliers, products, sites, roles, approval thresholds, and the relationships asserted between them.

This is deliberately not full-text search. Search answers questions of the form "where is this mentioned". The questions that matter here are of the form "what does the paperwork claim the approval chain is for a purchase of this size at this site", which is a graph traversal, not a keyword match.

Building the graph

The extracted entities and relationships assemble into a graph of the documented state: what the operation is supposed to be, according to its own records, as one connected object rather than forty disconnected files.

Two things become visible immediately, before any comparison. Documents that contradict each other about the same relationship, and relationships asserted by nothing at all, where a step everyone performs has no documentary basis anywhere.

Comparing it to what is actually happening

The operating state comes from three sources with different reliability. System logs are accurate about what the system saw and blind to everything outside it. Spreadsheets are precise and unversioned. Interviews are the only source that explains why, and the least reliable about what.

Reading the graph against all three is where divergences surface: an approval threshold that the records say is $50,000 and the logs say is never enforced; a supplier the contract says is sole-source and the ledger says is one of three; a quality step that is documented, believed by management to happen, and has no trace anywhere.

Ranking by cost, not by count

A list of 25 divergences is not a plan. Most divergences are benign, and several are improvements the operation made and never wrote down.

Each one gets an estimate of annual exposure: what it costs, or risks, per year, given current volume. That single column reorders the list completely, and it is the column that turns a diagnostic into something a decision can be made against. In practice a handful of items usually account for most of the value, and the rest are worth fixing only if they are nearly free.

Why a graph rather than document search

Retrieval over documents answers questions whose answer sits in one place. The interesting questions about an operation are almost never like that. They are questions about paths and consistency: does every route from order to payment pass through an approval, is any supplier reachable by two different contracts with different terms, which records would have to be wrong together for this figure to be right.

Those are structural questions, and a structure is the right representation for them.

Limits

The graph is only as honest as the interviews behind it. If people describe the process they are supposed to follow rather than the one they follow, the operating state is wrong in exactly the places it matters most, and the method will confidently report agreement.

The mitigation is not methodological, it is social: interview the people doing the work, alone, and ask what they do when the system will not let them do the right thing. That question surfaces more divergences than any extraction pipeline.