01 · runtime channel check
When the written rule and the running code diverge
A rule excluded a feature from the public build. The code did not: a flag returned true unconditionally, so every release build would have shipped it. The fix reads the build channel at runtime and fails closed on anything unknown, so the rule holds without anyone remembering to flip a switch.
What it means for youPolicy and implementation drift apart in every business. The system checks for it rather than assuming it away.
02 · re-verification rule
When an automated report restates something that never happened
A daily review restated two items from an earlier report — a filing made, an email sent. Neither had occurred. Both were caught by reading the source rather than the summary. The standing rule since: no claim is carried forward without re-verification against primary source.
What it means for youAutomated systems repeat their own errors until they harden into accepted fact. Verification has to be designed in, not added after.
03 · promotion ledger
When the system invents a record
The system generated entries for items that did not exist and propagated them. Deleting them was not enough. A guard now prevents their restoration, and a promotion ledger governs what may enter the canonical record and by what process.
What it means for youChange control is usually built after something ships wrong. In your engagement it is part of the design.
04 · scope discipline
When the right answer is to not build it
On its own product, Chromatic declined features that would have traded user trust for growth — engagement mechanics, share-gated value, claims the product could not stand behind — at a cost to speed and revenue. Each refusal was recorded and has held.
What it means for youThe hard part of advising on AI is knowing what to decline, and making the refusal stick.