We Removed a Safety Setting on Purpose and the Check Stayed Green

The safety check passed, and the setting it guarded was gone.

We had found a gap. A safety setting that was supposed to always be on had gone missing from a piece of automated work, and nothing had caught it. We put the setting back. Then we wrote a check so it could never silently disappear again.

The first version of that check searched the nearby text for the setting’s name. It passed. To test it, we removed the real setting again, on purpose, and ran the check.

It still passed. A comment sitting near the code explained what the setting did, and that comment contained the same words the check was looking for. The check agreed with the comment. It had nothing to say about the setting itself, which was gone.

Why a keyword search feels safe

A check that searches for a keyword is fast to write and easy to reason about. Most of the time it happens to line up with the thing you care about. The gap shows up in the one case that matters: someone removes the setting but leaves an explanation of it behind. That is one of the most likely ways a setting like this goes missing in practice. A comment explaining a rule does not mean the rule is being followed.

What we changed

We rewrote the check to look for the setting’s actual presence in the structure of the work, instead of scanning nearby text for its name. That was more careful to build, and worth it, because the whole reason the check existed was to catch the failure a text search could not.

The rewrite was only half the job. We did not trust the new version just because it looked more careful. We broke the setting again, with the same explanatory comment still sitting right there, and confirmed the check failed this time. Only after watching it fail on that exact problem did we trust it to catch the next one.

Who decides a check is proven

Writing the check can be done quickly, and much of it can be handed off. Deciding that it has been proven cannot. That takes a person choosing to break the exact thing the check protects, on purpose, and watching what happens. A check nobody has tried to fool is a check nobody has tested.

If you own a safety check, ask whether anyone has ever watched it fail when the protected setting was removed. If the answer is no, have someone remove that setting on purpose, leave any explanatory comment in place, and see whether the check fails. A check that only matches text near the setting can pass after the setting is gone.

dxdev LESSON · paste into your AI coding agent
LESSON: A Check That Only Reads Text Can Be Satisfied By The Comment Explaining The Rule
SOURCE: dxdev.com/everyday-ai/a-check-that-reads-only-the-comment
WHAT HAPPENED: A required safety setting had gone missing from a piece of automated work, and the only defense until then was cleaning up the mess after the fact. The fix was adding the setting back and writing a check to make sure it could never quietly disappear again. The first version of that check searched the surrounding text for the setting's name. It passed even after the actual setting was removed, because an explanatory comment nearby still contained the same words. The check was rewritten to look at the real, structural presence of the setting, not just whether its name appeared somewhere nearby, and it was proven by deliberately breaking the setting again and confirming the check now failed.
THE RULE: A check that only searches surrounding text for a keyword can be satisfied by a comment that merely explains the rule, without the rule actually being followed. Prove any check by breaking the exact thing it's supposed to catch, with an explanation still nearby, and confirm it actually fails.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any safety or configuration check that searches surrounding text for a keyword rather than verifying the real, structural presence of the thing it's checking.
  2. Any required setting whose presence has never actually been tested by removing it and confirming the check catches the removal.
  3. Any guard or lint that has never been deliberately broken on purpose to prove it still works.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.