Promote, extract, consolidate, single source of truth — every one of those is a two-part verb. There is a destination, and there is a retirement. Only the destination is satisfying to do, so only the destination reliably gets done: the new function exists, the tests are green, the diff looks like progress, and the original quietly keeps working exactly as it did. That is the whole defect. On 2026-07-30 we found it in our own brain-training app, NeuralSpark, in the least flattering possible form — two homes for one rule, and two fixes in a row landed on the wrong one, both with green tests.
The decision record decided a destination and not a retirement
The rule in question decides whether the app may preload an advertisement for a given user — a small predicate that reads consent state and answers yes or no. Our games are free and ad-supported with a single optional Pro purchase that removes the ads, so this is not a cosmetic decision: when the predicate says no, nothing loads, and the ad slots for that session stay empty. One of our architecture decision records moved that logic into a single function, and said why: so there would be one home for the eligibility rule.
It created the home. It did not retire the original. A second implementation of the same decision survived in the app-bootstrap path — the code that runs once at launch and asks, for the first time in the session, whether an ad may be fetched. That copy still read an obsolete per-session condition and had none of the short-circuits the rule had grown since. Two homes, then, for roughly two sprints: one current, one frozen at the moment of the split, and nothing in the older file to tell you the newer one existed.
This is not an exotic failure, and it is not forgetfulness. The record named the original five times, twice with its file and line numbers, and its summary column states the benefit in the tense of a job already done: the promotion removes a duplicated predicate. Further down, in the costs, the same document says converging that original onto the new rule is a natural follow-up, not required by this decision. One page, two tenses. The second half of the verb was written down, costed, deferred, and then never scheduled again — and a deferred retirement reads exactly like a completed one by the time anybody comes back to the file. Beware the decision record written in the tense of the finished job: its summary describes the future, its scope note describes the day it shipped, and only the scope note is true.
Two fixes in a row, both to the wrong address
What makes this worth writing up is not the duplicate. It is what the duplicate did to the two fixes that came next, because both of them were revenue-affecting, both were correct, and both were incomplete for the same invisible reason.
The first fix caught a user with no stored geography label being routed down the strict branch, so that whenever the consent SDK failed, that session lost every ad preload. The second caught something broader: a user in the EEA who had consented weeks earlier also lost every preload in any session where the consent SDK’s information update failed — offline, SDK not yet started, form error. That is a far larger group of people, and it shipped as its own patch, the very next fix. Both fixes were made to the promoted function. Neither reached the decision made at boot, because that decision was made by the other copy, which neither patch changed. The first preload of a session — the one that decides whether an ad is ready when the user first reaches a slot — was still being settled by the stale formula, before and after both patches.
Nothing failed. Both fixes shipped with green tests, and no test went red — twice in a row. It surfaced because the second of those two fixes had the boot path open: it was patching the rule and editing the boot gate’s own test file, so it read the stale copy, saw the shape of the condition, and wrote it up as a finding rather than folding it in. A person caught this. No check did. A green suite is evidence about the home you changed and silent about the one you did not. That silence is not a gap in our tests specifically; it is what a test suite structurally is. A test asserts that a call produces the right answer. It has no opinion about how many other places in the program can answer the same question.
Two comments described an intention as a fact
The detail we keep coming back to is not in the logic at all. Two sibling documentation comments — one on the promoted rule itself, one on the contract that declares it — asserted that the removal had already happened. They were not lies and nobody was being careless: they were written at the moment of the promotion, describing the state the author intended to reach, in the present tense. They became true later, when somebody finally did the work. The record had made the same move a level up; the comments carried it into the code.
Consider what that does to the next reader. Someone with a suspicion that a second copy exists opens the new home, finds a comment saying the old path was removed, and stops looking. The comment is worse than nothing, because nothing would have left the suspicion alive. A comment in the present tense about work that has not shipped is a false negative with a friendly face.
There is a second, less obvious rule in the same family, and it cost us separately: do not restate a formula in prose beside its single home. Restating it is precisely how a copy rots — the English and the code drift, and the English is the one people read. It also makes any grep-based check trippable by its own documentation, because a text search cannot tell an implementation from a sentence describing one. State the rule in English and let the code be the only place the syntax lives.
The guard has to be an oracle, not a same-value check
So what test would have caught this? The tempting answer is a test that the promoted predicate returns the right answer. We had those. The useful answer is a different shape entirely: an oracle — a test that runs the old site and the new home against the same input and asserts they agree. It does not check that either one is right. It checks that only one rule is in play.
And it has to be built from inputs where a rotted copy would visibly disagree, which is the part that is easy to get wrong. Ordinary inputs agree between a fresh copy and a stale one — that is what makes a duplicate survive two sprints in the first place. So the guard we shipped has three states, and each one is load-bearing. Two of them are the exact cases from the two fixes: the user with no stored geography label during a consent-SDK failure, and the previously-consented EEA user whose information update fails. On those, a stale copy answers differently from a current one, by construction.
The third state is the one an engineer is tempted to cut. It is a user who has never consented, and it asserts that both homes deny. Without it, the equality can be satisfied by an unconditional yes — which is not a hypothetical, because an unconditional yes is exactly what the error path and a type-narrowing fallthrough already return in that code. Two agreeing calls that both say yes for the wrong reason is a green test. We call that third state an anti-vacuity control: a case whose only job is to make it impossible for the assertion to pass trivially. If you cannot name what would make your equality vacuous, you have written a coincidence, not a guard.
Proving it bites, on code no test could reach
A guard that has only ever been seen to pass is indistinguishable from a guard that cannot fail, which is an argument we have made at length in a guard nobody has seen fail. So the oracle owed us a demonstration: break the condition on purpose, watch it go red, restore. Except the old site could not be broken on purpose, or reached at all. It was a private function behind a widget-scoped handle — the kind of code a test cannot get a reference to without rewriting the thing around it.
That is not a footnote. Unpinnable code is the habitat of duplicates. A rule you can call from a test gets called from a test, and the second time somebody implements it the two answers eventually collide in front of a maintainer. A rule you can only reach by launching the app can be reimplemented indefinitely without anything ever putting the two versions in the same room.
The tempting route was to mutate: sabotage a line, observe the red, put it back. We did not. In a shared working tree it is the neighbouring work that pays for your temporary break — a hazard we have written up before, when two agents edited one file. And a break you have already put back leaves nothing behind for a later check to find: the tree is byte-identical to where it started. Instead, the committed body of the stale predicate was relocated byte-for-byte into a test-visible seam with its obsolete formula fully intact, and the oracle was pointed at that. Nothing was modified to make the test fail; the real stale logic was simply moved somewhere a test could see it. It failed on exactly the two predicted states and the anti-vacuity control stayed green — and because the intermediate state compiled, no broken window opened for anybody working alongside.
Retirement is the risky half. That is why it gets deferred
It would be dishonest to present this as laziness. Adding a home is additive: nothing that worked before stops working, and the review is easy. Removing the old site is a behaviour change on a path somebody is already depending on, possibly at boot, possibly in a code path you cannot pin with a test — which, as above, is the likely case, since unpinnable code is where these copies live. Deferring the deletion to “the follow-up” is a defensible call on the day. It is defensible every single day, which is how you get two homes.
The cost of the discipline is real too: an oracle costs more than a unit test, because it needs a way to reach a site you were about to delete, and occasionally — as here — a relocation just to make that site observable. That is genuinely more work than the deletion itself. It buys one thing, and the thing is worth it: after the guard exists, “is there another copy?” stops being a question about how carefully somebody read the file.
The cheap version of this fix is worth naming so it can be refused. “Notice the duplicate during review” is not a fix; it is a hope with a process attached. It failed twice here, in consecutive patches, both of which came out of our own code-review lane and both of which shipped green.
A third copy exists. We left it alone
Here is the part we are not going to tidy up. A third piece of code in the same bootstrap file still reads the same raw consent flag directly, and we reported it rather than folding it in. It is not an ad-eligibility gate. It decides when a durable cross-session identifier may be sent to the ad stack — a privacy-timing question, not an advertising one — and it is deliberately more restrictive than the predicate this post is about. Withholding a durable identifier is the safe direction to err. Collapsing it into the eligibility rule would make a privacy decision inherit an advertising decision’s short-circuits, and that would be a worse bug than the one we just fixed, shipped in the name of tidiness.
So the honest position is: a third reader of that flag exists, we know exactly where it is, and it stays. Sameness of shape is not sameness of purpose. The test for “is this a duplicate?” is not whether two pieces of code look alike or read the same input — it is whether they are answering the same question. Deduplicating by appearance is how a consolidation turns into an outage. Read the two sites, ask what each is for, and be willing to conclude that the near-identical one is load-bearing exactly as it stands.
This error is scale-free, which is the reason to bother writing it down. We shipped the same mistake at the level of an entire website: two addresses served the same pages, both worked perfectly, and the damage showed up somewhere nobody was looking, until we picked one canonical home and redirected the other to it. Functions, URLs, configuration files, documentation — the shape does not change. Two homes for one thing, each fine in isolation, and the harm accruing in whichever one is not being maintained.
Our decision record did name the site it was replacing. It named it precisely, called the duplicate removed, and filed the removal itself under follow-up, where it stayed — and that is the whole story, because writing a retirement down is not doing it. The retirement was the deliverable; the destination was the pleasant part. A single source of truth is not something you create. It is what you are left with once the alternatives are gone.
Notes
This is a first-hand account of one defect in one of our own codebases, found on 2026-07-30, not a survey of anyone else’s practice. It contains no performance metrics and no revenue figures, and that is deliberate rather than modest: we are not publishing how many users each of those two fixes affected or what the empty ad slots cost, and we are not going to estimate either, because an invented number in a post about a defect nobody could see would be exactly the wrong kind of confidence. The two fixes are described by who was affected and how, which is what we can actually stand behind. “Roughly two sprints” is a choice of unit, not a limit on what we know: the decision record is dated 2026-07-27 and the retirement shipped on 2026-07-30. The exact interval is a fact about our cadence rather than about the defect.
For our own record: the promotion is Decision 2 of our
ADR-109; the two fixes that landed on the wrong home are the commits our review log calls
CR-P8 (78e2b0ce) and CR-P9 (d7ad791a); the retirement is
a7847ec2. Those hashes are in a private repository — they are here so
the account is checkable against our own history, not because a reader can open them.
Two product points, stated plainly. NeuralSpark is our brain-training app. Nothing in this post is a claim about what it does for anyone who uses it — this is a post about our code, and it makes no cognitive, health, or performance claim for the app of any kind. And our games are free and ad-supported, with a single optional Pro purchase that removes the ads; the rule this post is about governs whether an ad may be preloaded for a user at all, which is why getting it wrong in one of two places mattered.
Keep reading: all posts on the WizusLabs Engineering blog.