Description
Organisations write standards. Conventions in a wiki, practices agreed in a retrospective, expectations described at onboarding. Then they do not enforce them, and the gap between the two is invisible from inside a meeting, because in a meeting a documented standard and an enforced one sound identical.
The clearest evidence for what that gap costs comes from one organisation running the same analyses two ways. In advisory mode, where the tool reported problems and left the decision to people, the great majority of what it found was never fixed. Engineers agreed the warnings were valid. They still did not act on them. When the same checks were moved to a place where they could refuse a change, fixes started happening daily. Same company, same engineers, same code. The only variable was whether the check could say no.
This is not a discipline problem, it is a design one. Engineered safeguards fail rarely and predictably. Administrative controls depend on human vigilance at every commit, every review, every merge, and vigilance is the weakest component in any system. It also decays: the first violation that slips through an unenforced standard is the signal that the standard is optional, and the next one is easier.
Then the reader changes. A person absorbs the unwritten rules slowly, imperfectly, by osmosis, and an agent absorbs none of them, because it never sat in your standup and does not read your wiki. Rules files and prompts help and are not enforcement: even prompted directly with a policy, a model applies it most of the time rather than all of the time, while a gate that blocks has a miss rate of zero for the check it runs. So the exercise this dimension scores is simple to describe and uncomfortable to do. List your standards. For each, ask whether something mechanical stops a violation reaching production. The column where the answer is no is your exposure.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nobody has asked the question. There is no inventory of standards, so there is no way to tell which ones the pipeline enforces and which ones survive on memory. People will tell you sincerely what the team does, and there is nothing to check that answer against.
The tellAsk three engineers to name your coding standards. If you get three different lists, and not one of them marks which items the build would refuse, you are here.
- 2
Tacit
The people who have been here longest know which standards will actually stop a merge and which are aspirational, and they take the difference into account without thinking about it. That knowledge is entirely personal. A new joiner learns it by breaking something, and an agent never learns it at all.
The tellAsk someone who joined this year which of your standards the pipeline enforces, then ask a five-year veteran. If the two answers are not close, the sort exists only inside the veteran.
- 3
Visible but inert
Somebody did the exercise. There is a page listing what is enforced and what is agreed, from a workshop or an audit, and it is accurate. Nothing has moved between the columns since it was written, so it documents the exposure rather than reducing it.
The tellFind that page and find its date. If nothing has moved from agreed to enforced since it was written, it is a record of the problem rather than a practice that shrinks it.
- 4
Acted on
The sort is maintained rather than performed once. A standard that matters enough to write down carries a decision about how it is enforced, and the agreed column is worked down deliberately: the costly entries get a gate, a hook or a check, so the pipeline refuses what the wiki used to request.
The tellFind the last standard your organisation added. Something mechanical refuses a violation of it today, and that gate arrived with the standard rather than a year later when somebody finally broke it badly enough to matter.
- 5
Durable
Enforcement holds while the estate changes. A new repository, a new language or an acquired team arrives inside the same gates instead of outside them, exceptions carry a name and a date, and the checks are maintained well enough that nobody has quietly turned one off to get a release out.
The tellCount the pipelines where the gate is disabled or set to warn instead of fail. Zero, or every one of them carrying an owner and an expiry date, is durable. Anything else is enforcement in name only.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Sadowski, Aftandilian, Eagle, Miller-Cushon and Jaspan, Lessons from Building Static Analysis Tools at Google (Communications of the ACM, 2018)
Reported what changed when the same organisation ran the same analyses first as advice and then as checks that could refuse a change. Warnings engineers agreed with sat unfixed for years in advisory mode, and were fixed daily once the tool could say no.
Gu and Solar-Lezama, Study maps roadblocks to autonomous software engineering (MIT News, 2025)
Found that a company's own conventions sit outside the distribution a model was trained on, so generated code looks plausible while quietly breaking standards that were never written anywhere a model could read them.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Hard guardrails vs cultural agreements →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.