The control that contaminates itself

A negative control is a string that must not be found. You search for it in the same breath as the thing you are actually looking for, and if it turns up, your matcher is matching things it should not and every other number in that pass is suspect. It is a cheap habit and a good one. On 2026-07-30 we wrote one into the workspace instruction file that every agent in this studio reads before a verification pass — a fixed uppercase token whose own name announced that it was invented and lived nowhere — annotated must be exactly 0. Fourteen days later that token was sitting in 108 tracked files across five of our repositories, 157 times, and a check whose only passing value is zero came back with 2 on a completely healthy tree. Nobody misused it. Every copy was planted by someone obeying the instruction. A shared negative-control literal is destroyed by its own honest use — and it burns out fastest in the repositories that use controls most.

The token had exactly one job

Two weeks ago we published the argument for having a control at all. In every zero has two explanations the case is that an empty result is one observable with several causes: the condition really is absent, or the pattern was wrong, or the path did not exist, or the output was never captured — and no amount of careful reading separates them, because there is nothing in the output to read. The remedy is a second measurement in the same invocation whose expected value is known. That post closes on how much machinery a control needs to share with the real check to be worth anything. It does not ask the question this post is about, because it did not occur to us: how long does a control last?

The two controls do different work. A positive control — a token you know is present — proves the pipeline is alive; if it reads zero, nothing else in the pass means anything. A negative control proves the matcher discriminates rather than merely returning numbers. It is the pocket version of the argument in a guard nobody has seen fail: a matcher that has only ever been observed to find things is indistinguishable from one that finds anything you hand it. Give it a string that cannot be there, and if it reports a hit you have learned something about your instrument before you learn anything about your code.

So the prescription was sound and the commit that made it is unremarkable: a single literal, written into the procedure, with the expected count beside it. The mistake is not in the reasoning. It is one layer down, in a property of the token itself that nothing in the reasoning touches.

Every honest use planted another copy

Here is the whole mechanism, and it is embarrassingly simple. A negative control is not data that flows through a check and evaporates. It is a string, and the moment anyone writes the check down — in a test, in a fixture, in a report, in the changelog entry explaining what was verified, in the documentation that teaches the rule — the token is written down with it. The instruction named a literal, so the obedient thing to do with the instruction was to paste that literal into the assertion being verified. Which is to say: the token's own instructions distribute it into the trees it exists to measure.

The distribution started immediately. Its first appearance in an app repository was the same day it was prescribed, 2026-07-30, in two of them — sudoku-game and boardlore. The next day it reached three more: bomb-game, brain-training, tank-game. Nothing about that timeline suggests carelessness. It suggests a studio full of people and agents reading a new procedure and applying it promptly, which is the behaviour you want.

Measured on 2026-08-13, the token sat in 108 tracked files across those five app repositories, 157 occurrences in total — plus 15 more files in our orchestration repository, including the instruction file that prescribed it in the first place. In code specifically the numbers are smaller and sharper: 11 Dart files, 13 occurrences, of which 10 files are tests and one is a tooling script.

It decays monotonically, and fastest where verification is best

Look at the ordering in that chart, because it is the part that turns a housekeeping annoyance into a design lesson. sudoku-game carries the most copies, 36, and sudoku-game is the most heavily verified of our five app repositories — it is the one where release checks, marker greps and store read-backs get exercised most often. Every one of those passes is a chance to write a control down, and a written-down control is a planted control. The instrument degrades in proportion to how much it is used, and it degrades first in the codebase whose engineering discipline is best. The game itself is Sudoku by WizusLabs, and there is nothing wrong with it; the thing that decayed is the tooling we point at it.

That direction of decay is the uncomfortable bit. Most rot in a codebase punishes neglect. This one punishes diligence, monotonically and silently, with no event to notice — there is no moment at which the token stops working, only a rising probability that the next pass in the wrong directory catches a copy. A control that lives in the namespace it measures does not have a failure mode so much as a half-life.

A burned control does not fail. It voids numbers that were right

On 2026-08-13, in brain-training, a verification pass ran the prescribed negative control against a tree that was in perfectly good order. The control returned 2. Every other number in that pass was sound.

Now read that against the rule sitting a few lines above it in the same instruction file: if the control is off its expected value, the pipeline is broken and every other count in that pass is meaningless — re-run before interpreting anything. That rule is correct. We wrote it because a broken instrument must not be allowed to produce an answer, since the answer it produces is always the flattering one. But applied to a burned negative control it points the wrong way entirely: it takes a set of genuinely correct measurements and instructs you to throw them out. The failure is not a false pass and not a false fail. It is a correct pass discarded as a phantom plumbing fault, followed by however long it takes to go looking for a defect in a pipeline that never had one.

The agent that hit it recognised the contradiction, generated a fresh random token instead, watched it read zero, and reported the burned literal upward as the finding. That is the good outcome and it was not guaranteed. The likelier response, from anyone reading the rule as written and trusting it, is to bin a green gate. We have argued before that a mutation’s own success response tells you the request was accepted and nothing about what it carried — which is why we read back what we published rather than believing the reply. This is the same lesson turned inward on our own instruments: the control certifies the instrument, so when the control is wrong you have no basis for reading anything, including the parts that were fine.

We named the hazard eleven days before it bit

This is the fact we would most like to leave out. On 2026-08-02, three days after prescribing the token, we recorded a heuristic in the same instruction file whose substance was: the mandated negative-control token is present in the trees it measures. Named. Dated. Committed. And then the copies kept accumulating for eleven more days until a real verification broke on them.

So this was not a blind spot. It was a known hazard filed next to the instruction that was causing it, in a document both of them lived in, while the instruction went on being followed. The gap is not between ignorance and knowledge; it is between noticing a hazard and retiring the thing that causes it. Writing down “this shared literal contaminates its own namespace” does not remove a single copy, does not change the prescription anyone reads tomorrow, and does not stop the count going up. A hazard note with no scheduled retirement is a bookmark, not a fix — and we now treat “we already documented that” as evidence a problem is older than we thought rather than evidence it is handled.

The honest limit: most of the copies are prose

Some proportion is owed to the reader here, because 108 files sounds worse than it is. Of those, 97 are Markdown — documentation, changelog entries, verification reports and retrospectives that discuss the rule. They are not test assertions and nothing about them is a code-quality problem. Only 11 are Dart files: ten tests and one tooling script, 13 occurrences between them. If you were hoping for a story about a codebase riddled with junk sentinel values, this is not that story.

It also does not save the check, and the reason is worth stating plainly: a search over a tracked tree matches a document exactly as readily as a test. The instrument does not know which files you consider serious. Ours was pointed at a repository, the repository contained prose about the rule, and prose about the rule contains the rule’s literal. The two hits that actually broke the pass were assertions in Dart, so both halves are true at once: the contamination is mostly harmless documentation, and it was sufficient to void a verification. What we have is not a code-quality crisis. It is a measurement-instrument failure, which is a smaller thing that fails in a more expensive place.

Generate it; never quote it

The remedy is smaller than the diagnosis, as these usually are. Generate the negative control per invocation. A timestamped-and-process-id token built on the spot, a UUID, openssl rand -hex 8 — any of them is a string that provably cannot pre-exist in a tree, because it did not exist anywhere until a moment ago. Never a constant. Never one copied out of a document. Never the same token twice in one pass, because two checks sharing a sentinel is the same contamination at small scale.

The rule that matters more, and the one we did not have: never write a control token into a tracked file. Not into a test, not into a fixture, not into a comment, not into a report. A test that genuinely needs a guaranteed-absent string must build one at runtime rather than hard-code a literal that a later search will happily find. That single constraint removes the whole class, and it is the one place where the fix has to live — because the alternative is asking every future author to remember not to do the obvious thing.

And a reading rule, since a burned token will happen again to somebody: a non-zero negative control means “my token is burned” before it means “my pipeline is broken.” Regenerate, re-run, and only then start doubting the tree. Report the token’s provenance alongside its count — generated, not quoted — so the next reader can tell which kind of zero they are looking at.

A sentinel you can copy is a sentinel somebody will paste

None of this is about AI agents, though agents are why ours spread in a fortnight rather than a year: they read the procedure, all of them, promptly and literally. The shape is older than any of our tooling. A canary value pasted out of a runbook into the alert it is meant to test. A “definitely missing” identifier in a fixture, which becomes a real record the day someone loads the fixture into the search index. A magic string in a smoke test that ends up in the log format the smoke test greps. A placeholder email that a seed script dutifully inserts. Every one is a value whose entire purpose is to be absent, living in the same namespace as the thing it measures, depending on nobody ever writing it down — in a profession whose core competence is writing things down.

Which gives the rule we would rather have had two weeks ago, and the one worth taking whether or not you run a studio like ours. A control is not a value; it is a property — guaranteed absence — and a literal cannot hold that property for long, because sharing a literal is how instructions travel. Generate the absence at the moment you need it and it is true by construction. Write it down once and you have started a countdown. More of these small measurement disciplines, and the ways they compound, are on the WizusLabs Engineering blog. The best control we ever wrote lasted fourteen days, and it was killed by people using it correctly.

Notes

This is a first-hand account from our own records. Every figure in it — the 108 tracked files, the 157 occurrences, the per-repository counts, the 11 Dart files and 13 code occurrences, the 15 further files in our orchestration repository, and the control that returned 2 — was measured on 2026-08-13 against our own tracked trees with fixed-string searches over tracked files plus a history search for the token’s first appearance in each repository. The dates come from the commits that introduced the prescription (2026-07-30) and the hazard note (2026-08-02).

The limits, because they bound the claims. The post carries no defect rate, no time-lost figure and no user-facing impact metric, because there are none to report: nothing shipped wrong, one verification pass was momentarily voided and immediately re-run with a generated token, and inventing a cost here would be the precise failure the piece is about. The counts describe tracked files at one instant in six repositories we own; they are not a sample of anything and should not be read as a rate. We have also deliberately not printed the burned token anywhere in this post, in any form — not in prose, not in an example, not in the figure. This page is itself a tracked file, and publishing the literal would be the exact mistake described above, performed at internet scale.

Keep reading: all posts on the WizusLabs Engineering blog.

← Back to the Blog