The Casebook · Entry 01
Standard Operating Procedures
A thick library of procedures reads as discipline. Through the Native Constraint lens, it is a record of work that was never encoded, and a bill that comes due in attention.
The conventional reading
The standard operating procedure is treated as a sign of maturity. A function with a documented procedure for every recurring task is held to be organized, repeatable, and ready to scale. Knowledge moves out of people's heads and onto the page. Onboarding is faster. The auditor is satisfied. The more complete the library, the more mature the function is judged to be, and building it out is counted as progress.
Through the Native Constraint lens
Read through the Native Constraint lens, the same library says something else. A standard operating procedure is an imperative instruction: it lists every step a person must perform, in order, and depends on that person performing each one correctly, every time. The existence of a procedure for a task is evidence that the task was not built into the environment. The outcome is not produced by the system. It is produced by a human following steps, and it holds only as long as attention does. The distinction between a procedure someone has to follow and a rule that simply holds is the difference between imperative and declarative, and it is the whole of the matter.
What it really costs
The cost is not the paper. It is the standing claim on attention. Every procedure is a task the organization has agreed to keep performing by hand, to keep remembering, and to keep training, and each one runs on a person not slipping. Human attention is the most expensive and least reliable fuel a function can run on, and a library of procedures bills it every period, in fragility and in key-person risk. A growing library is not the function getting stronger. It is the function accumulating manual obligations and calling the pile a system. The word for the pile is technical debt.
Where it puts the burden
The burden lands where it is most expensive: on a person's finite judgment, downstream, re-spent on every run, without end. The outcome holds only as long as someone reads the steps and follows them correctly, which makes a procedure that only one person truly performs right a single point of failure with a cover sheet. And because a procedure is easy to write and hard to keep current, the library drifts: the steps and the system separate a little with each change no one carried through, until the document describes a process that no longer exists.
How to see past it
Read each procedure as a map of decisions that were never moved upstream. Every step a person must remember is a step that could be built into the environment so the outcome happens by default. Some steps encode cleanly into a rule, a check, or a tool. A few do not, and those edge cases are the ones that actually need a person.
Procedures do not disappear in a well-built function. They change character. The thick manual of steps a human executes by hand gives way to a short record of how the system is changed and kept: how a threshold is reset, how a check is added, how an edge case is handled when the rule did not anticipate it. The document stops being a script for producing the outcome and becomes the control on the system that produces it. The goal is not a better procedure. It is a shorter list of them, written from the system's side, because the work the old library described is now encoded and no longer needs a person to carry it.
The procedure is one case. The habit is to read any practice twice: once at its reputation, and once for where the work actually sits, what it costs to keep it there, and whether the system could produce the outcome instead of a person holding the line.