AriakiAcross thirty-seven simulated years, characters rolled dice 68 times trying to cross a major rank threshold. Twelve of those rolls succeeded. The number of people who actually crossed was zero.
The dice were fine. All twelve successes were recorded properly — written to logs, filed into history. The promotion function existed too, and its unit tests were green. It had simply never executed, not once.
That was the worst of six cases I dug out of the same engine on the same day. The other five look identical: an injury system with four severity tiers that fired 0.79% of the time over thirty-four years; a cache layer written two months earlier, with exactly four call sites across a five-thousand-line read path; a module with a complete incremental index whose comment read "never scan 2.7GB inside a request path" — and whose index directory was empty; a method name that didn't exist at all, swallowed silently by a fallback handler for a full year of calls; and a threshold set so high that thirty-four years of real data could never reach it.
All six share one signature: silent, no errors, tests green.
The test is in section 2, and it's just a division. I got it wrong the first time I used it myself — that's section 3.
1. One misordered branch ate twelve successes
To cross a major rank threshold in this world, a character needs a dice roll: an adjudicator proposes the promotion, the dice decide whether it lands.
Here's what the data showed. One character reached the threshold in year ten. In years eighteen, twenty-two, twenty-three, twenty-seven, thirty, and thirty-three, she rolled a success — six times, and crossed zero times. Another character rolled five successes with the same result. The rank field for all thirty-odd characters stayed constant for thirty-seven years. Nobody in this world had ever seen what the second tier looked like.
The root cause was the order of one branch. The first guard in the promotion function is "if the proposed value isn't higher than the current value, return unchanged" — and that guard sits ahead of the dice result. Crossing a major threshold depends entirely on the adjudicator proposing it, the adjudicator's criteria are all subjective prose, and the dice result was never in its field of view. It had no idea the character had just rolled a success.
The irony is that minor steps within a rank had an engine-side forced override already. The major-threshold edge was explicitly excluded, with a comment saying "major thresholds continue to use adjudicator + dice logic." The design was deliberate. In practice it was a prohibition.
The fix was one line: change which die the branch reads, from "the minor-step die" to "the die selected by edge type." Replaying the full history: twelve successes → twelve out of twelve crossed.
One line. Twelve swallowed successes. Thirty-seven years.
2. The test: count how many times it happened in production data
This is the most useful section, and it's a division.
fire rate = number of artifacts this mechanism produced
÷ number of cycles it claims to have been running
To be clear about what this is: it isn't a heuristic, it's just a division. The numerator is a row count of whatever the mechanism writes to disk. The denominator is how many cycles it's been live.
Plugging in all six:
| Mechanism | Numerator (artifacts) | Denominator | Fire rate |
|---|---|---|---|
| Rank promotion | 0 actual crossings | 12 successful rolls | 0 |
| Estate settlement | 3 ledger rows | 37 years | 0.08/yr |
| Death adjudication | 1 real outcome | 38 invocations | 2.6% |
| Injury system | 576 snapshots | 73,372 state snapshots | 0.79% |
| Paid healing | 0 | 7,806 person-periods | 0.0% |
| Cache layer | 4 call sites | ~5,000-line read path | — |
The death adjudication row deserves a second look: thirty-eight invocations, and thirty-seven of them returned "nobody died." It ran diligently. Its logs looked great. Its output was approximately nothing.
Artifact count ≈ 0 while the mechanism claims dozens of live cycles = that path is untested code. However green its unit tests are.
The second division: which percentile does your threshold sit at?
The first division tells you it never fired. This one tells you why it never will.
The injury system's design was entirely sound: four tiers, independent recovery curves per tier, feeding four kinds of checks. Measured: of thirty-seven characters, only nine were ever injured, peak value 30 out of 100, and the top two tiers were never reached in thirty-four years.
The reason was in the input distribution, and had nothing to do with the code:
single damage event median 4 / p90 9
single healing event median 1 / p90 2
but healing events outnumber damage events 3.30 to 1 ← high-frequency trickle flattens it
total healing / total damage = 1.02
Over thirty-four years and twenty-nine thousand points of damage, 100% went down a path that only touches the health value. The one channel that writes to the injury field fired sixty-one times in thirty-four years, and events with a single-hit drop large enough to register as "serious" happened zero times. It was all one-and-two-point daily wear.
So the test looks like this: take your trigger threshold and check it against the percentiles of your actual input distribution. If the threshold exceeds the observed maximum, the trigger probability is identically zero — at which point code quality is irrelevant. It's a door installed ten feet up a blank wall.
The fix followed the distribution too: only single-hit drops above the measured p75 accumulate as persistent injury, which leaves daily wear completely untouched.
This world was tedious, never dangerous.
3. I got this test wrong the first time I used it
This is the section I least wanted to write, and it's the one that decides whether you should trust the two above it.
While chasing the promotion bug, my first claim was "thirty-five successful checks, zero promotions." That was wrong.
I had queried the "major rank" field and not the "minor stage" field. Those are two different landing sites, and twenty-six of those thirty-five actually did advance someone. The data corrected me on the spot. The only true zero was this one specific edge: major thresholds.
So the lesson gets nailed down: before claiming "this mechanism never fired," enumerate all of its landing fields and query every one. Miss one and you'll report "partially working" as "completely broken."
That mistake and the division I'm selling in section 2 are the same disease — a wrong numerator. The division has no power to stop you from picking one.
4. Green tests can't save you, because they measure something else
This section is a weapon you can take with you.
When you see any claim of the form "this feature is live" or "this has been verified," skip the coverage number and ask three:
- How many artifacts does this mechanism have in production data?
- How many times was it invoked, and in how many of those did it actually produce something?
- What percentile of the real input distribution does its trigger threshold sit at?
Three common instruments, none of which answers any of those:
- Unit tests measure "this code is correct on inputs I constructed." Constructed.
- Mutation tests measure "my assertions have discriminating power." Assertions.
- Design review measures "this design makes sense." That injury system — four tiers, independent recovery curves, entirely sound design — would pass any review on earth. It fired 0.79% of the time.
After fixing the promotion bug I wrote twenty-four assertions and sixteen mutants with zero escapes. That's solid verification, and what it proves is that the fix is correct. It says nothing whatsoever about whether that path had ever run before. The thirty-seven years of zero firings happened entirely upstream of that verification.
A nastier variant from the same system: the default dataset was selected by "largest directory in bytes," and one deletable raw-output dump accounted for 99.27% of that directory. So the sort order was permanently pinned to whichever old dataset had the fattest dump. HTTP 200, UI renders fine, no errors, displaying the wrong world. Delete the dump once and it silently switches to a dead archive frozen at an early year — and renders that just as happily.
"No errors" was never evidence. The test has to be "how many times has this path been walked in real history."
5. The moment it finally did fire, four downstream consumers had no idea
I deployed the fix and waited for year-end settlement. The character who rolled a success was the one with the lowest success rate in the entire world, the thinnest savings, and not a single bonus item — the first person in thirty-seven years to cross. She had been standing at that door for thirteen years. She got through by a hair.
Then four branches blew up, each more absurd than the last:
- The adjudicator didn't know it had approved anything. Its prompt still said "if and only if all conditions are met, you may approve," while the engine had been changed to force promotion unconditionally. It ruled "conditions not met," wrote "no breakthrough this year," and the engine pushed her through behind its back.
- The world didn't know. The public-events budget was fully consumed every year, and across all one hundred fifteen historical entries, the count of personal-achievement events was zero. The twenty public events surrounding her breakthrough were about scrubbing old manuscripts, sorting ore tailings, and copying ledgers.
- She didn't know. The profile rendered for her own eyes reads from a shadow copy written at character creation, and no code anywhere in the engine ever updates it. She saw herself as "first tier, early stage" — even the stage name was wrong. That bug had been dormant for thirty-seven years because nobody had ever crossed. She was the first person to trigger it.
- Crossing was a net penalty. Her fixed periodic fee went from 40 to 100, annual surplus dropped from 620 to 20, and her stipend and position didn't change by a single character.
The third one is this whole article in miniature: a system that has run stably for thirty-seven years may be stable only because most of its state space was never visited.
That same night the engine actually crashed, failing three gates in a row — all of them code reached for the first time in thirty-seven years:
- Chained ledger reconciliation — checking each entry's result value against the account's current balance breaks the moment two estates chain into the same account. The data was entirely correct; the shape of the assertion was wrong.
- New-entrant single-row check — initialization required the state file to have exactly one row, but an entrant arriving at year-end had already saved state of their own.
- A config deadlock (not a code bug at all) — max deaths per year 5, max intake per year 2, so once you lose more than two you can never catch up, while the population target increments annually.
The first gate came with an extra lesson that cost me real time: that check had four copies in the repository, and the apply path and the audit path are two independent validators. My first patch only fixed the audit side, so on restart it hit the apply-side precheck and never reached the audit at all. The new-entrant check had two copies.
Before touching any validator, grep out all of its siblings. Otherwise you fix it once, watch it crash again, and start questioning your sanity.
6. What's wrong with this data
In the interest of honesty, here's what I won't state as settled until it's filled in.
- The section 3 error is already written up, but it's worth repeating: my original "zero firings" claim was half an artifact I manufactured myself, by pulling the wrong field into the numerator.
- The denominator behind 0.79% is state snapshots, not "opportunities to be injured." Change the denominator and the number changes. The direction of the conclusion holds (the top two tiers being unreached in thirty-four years is a direct observation), but don't quote that specific percentage.
- The 12/12 fix validation is a replay over the same historical data, not a freshly generated world. It proves the branch ordering is fixed. It does not prove the resulting crossing frequency is reasonable.
- Paid healing at 0/7,806 only counts person-periods that have records. If some recovery path writes no record at all, it would be miscounted as "never happened." I did not rule that out.
- This is a closed simulation whose input distribution is generated by the engine itself. In a system with real external inputs, the shape of "threshold unreachable" will be completely different — don't copy "p75" as a number, go measure your own distribution.
- The "annual net change stayed within ±100" figure covers eleven years, not all thirty-seven. I never worked out why that window stopped at eleven.
7. The checklist
Next time you inherit a mechanism that's "been live for ages," ask in this order:
- How many artifacts does it have in production data? Zero means treat it as unwritten.
- How many invocations, and how many produced something? The ones returning "nothing happened" don't count. Thirty-eight calls with thirty-seven no-ops is set dressing.
- What percentile of the real input distribution does the trigger threshold sit at? Above the observed maximum means it can never fire, regardless of code quality.
- How many landing fields does it write? Query all of them. Miss one and "partially working" gets reported as "completely broken."
- How many copies of this validator are in the repo? The apply path and audit path usually each have one; patching a single site means it crashes again on restart.
- When it fires for the first time, how many downstream consumers are there? Every one of them is zero-coverage code. Trust none of them.
The first character ever to cross that threshold received, as her reward, an invoice raising her periodic fee from 40 to 100, dropping her annual surplus from 620 to 20 and pushing her savings below the protection floor. This world's gift for getting stronger is bankruptcy.