Ask any operations leader in an NBFC a simple question: does your floor run the process the manual describes? Watch the pause before the answer. That pause is the subject of this column.
Here is the uncomfortable structure of the situation. In every regulated institution there are three versions of every process. There is the process as written — the SOP, board-approved, audited annually, formatted beautifully. There is the process as executed — what trained people actually do, including the workarounds and judgment calls the SOP never anticipated. And there is the process as assured — the version audit can evidence, sampled and reconstructed after the fact from emails, trackers and memory.
These three are different. Not occasionally different. Structurally different. And the cases where the documentation matches the floor are usually the cases where the documentation was written after the floor settled — paper drafted to mirror practice, not practice derived from paper.
Drift is not a failure of discipline. It is what happens when a living process is described by a dead document.
Why twenty years of BPM didn't fix this
This is not a new observation, and the industry has tried to fix it before. The promise of the BPM era — Pega, Appian, Camunda, an entire generation of "the model is the execution" platforms — was precisely that the documented process would become the running process. It is worth being honest about why that promise underdelivered.
Every operational process splits into a head and a long tail. The head is the seventy-odd percent of cases that fit the happy path; rules engines handle those well. The tail is everything else: the 1989 sale deed where the owner's name is spelled three different ways across Telugu, Hindi and English records; the property that passed through an unregistered family partition; the customer whose restructuring request arrives entangled with a billing dispute. The tail cannot be expressed as rules in advance — which is why BPM automated the routing of exception work and never the work itself. Headcount in operations stayed where it was, and the formalisation cost of modelling everything killed the economics.
So institutions made a rational adaptation: keep the SOP general enough to survive audit, and let the floor handle the tail through experience. Drift was not a bug in this arrangement. Drift was the design.
What changed
Two things, and they only matter together.
The first is that language models can now do tail work — read the deed, recognise the transliteration variance, weigh the electricity bill and the Aadhaar lineage as corroboration, and produce a reasoned, cited recommendation. The judgment-heavy middle that resisted formalisation for two decades has become executable. That alone, however, is not enough; an unreliable reasoner attached to a regulated process is a liability, not a transformation.
The second is a discipline for containing the first: a thin deterministic boundary in which the model proposes and the harness disposes — where agents act only inside declared steps, where the checker's independence from the maker is enforced mechanically, and where the transcript of every run is the audit trail rather than something reconstructed for the auditor later.
Put these together and a different contract with documentation becomes possible. The SOP stops being a description of the process and becomes the source of it:
# one artifact, two skins artifact "kyc-exception-handling": prose: what the auditor reads code: what the harness runs invariant: drift(prose, code) == detectable
We call this a ProcessSkill: one spine, two skins. The prose the regulator can print and the code the engine executes are projections of the same document. Edit one and the other must follow; delete a control point from either side and the artifact refuses to deploy. The annual exercise of asking whether the manual matches the floor is replaced by a property of the system: it cannot not match.
The honest caveat
A spine eliminates drift between the document and the execution. It does not, by itself, eliminate drift between the document and reality — the workarounds may have been wiser than the SOP. Which is why the discipline begins with mining, not with writing: put the as-executed evidence beside the official process before codifying anything, and force every divergence to a decision. Codify the workaround, because it was a legitimate adaptation. Or ban it with a control point, because it was a quiet breach. Either answer is respectable. Leaving the divergence undecided — the current industry default — is the only indefensible option.
That is the premise of this practice, and of this column. In the coming weeks: why the examiner must never read the build, what maker–checker means when both are machines, and what an organisation should be allowed to learn from its own memory.