How we work / Engineering standard
285 rules.
168 refuse the commit.
Most « engineering standards » are a document nobody reopens. Ours is executable : on every commit a mechanical pass evaluates the code against a registry of rules and refuses what does not hold. Not a reminder. A refusal.
285
rules in the registry
registry.json
168
blocking — they refuse, they do not warn
blocking = true
132
backed by an executable script
96 of them blocking
148
evaluated before the commit even exists
trigger = pre-commit
A standard you can ignore is not a standard.
Three things break a written standard. We met all three, so we stopped writing it and started executing it.
The document nobody reopens
A standard in a PDF starts ageing the day it is signed. A registry runs : a rule that no longer matches the code fails, and gets fixed or retired.
The review that depends on who reads it
Two reviewers, two verdicts. A mechanical rule returns the same verdict at 3 a.m. as it does in a meeting — the only way a standard survives fatigue.
The « just this once » exception
It becomes the rule within three weeks. Here the exception exists, but it is named, written into the file, and visible in review — not muttered.
Five moments, earliest to latest.
The earlier a rule bites, the less it costs. Half the registry runs before the commit exists ; what needs the whole repository waits for the night.
A standard that always says yes proves nothing.
This is the real output of the last pass on this very site. We publish it whole — including the column saying a third of the rules did not apply.
Evaluated
147
The rules whose trigger matched what was being staged.
Passed
106
72%. The rest were corrected before the commit existed — which is the point.
Not applicable
41
They did not bite on this slice. Counting a « not applicable » as a pass would be theatre.
What that number means, and what it does not.
106 of 147 is not a quality score : it is a count of applicable rules satisfied at commit time. A rule that does not apply says nothing good or bad. And a pass that never refuses anything is a signal to go read the registry, not to celebrate.
A new rule warns before it refuses.
Making a rule blocking overnight breaks a team and gets routed around. Every rule goes through the same loop — that is what makes it survivable.
A defect repeats
The same incident lands twice. We write the rule that would have caught it, in warning mode, wired to the right trigger.
It warns, and we count
Calibration window : the rule runs without blocking and we measure its false positives. A rule that cries wolf is fixed or retired — it does not graduate.
It refuses, and we prove it
Once blocking, it is mutation-tested : we reintroduce the defect on purpose and require the rule to fail. A guard that never fails proves nothing.
You are not buying our discipline. You are buying its trace.
The deliverable carries its proof
Every delivery arrives with the verdict of the pass that let it out — evaluated, passed, not applicable. Not an assertion of quality : a reading.
Quality does not depend on who was there
The same rule applies to a newcomer's first day and a senior's tenth commit. That is what lets a team change without the bar moving.
What we did not verify is written down
Coverage gaps are declared, not hidden. A report listing no limits is a report worth re-reading.
Ask for the verdict before you sign.
We will show you the pass on a real repository — rules evaluated, refused, corrected. Not a demo : an output.
285 / 168 / 101 / 132 / 96 and the trigger split are counted in the engineering registry. The 147 / 106 / 41 verdict is the output of the pre-commit pass run on this repository on 2026-07-28. No figure is rounded or arranged.
What this page does not claim : no certification, no third-party audit, no external norm. It is an internal standard, mechanically applied. That is the entire claim.