The arithmetic behind the canary count is the standard binomial worst case, and it is worth redoing before you spend reviewer hours on it. Detection rate is a proportion, so the 95 percent half-width is 1.96 times the square root of p(1-p)/n, and it is widest at p = 0.5 [11]. At n = 30 that is 17.9 points. At n = 100 it is 9.8 [1]. Those are the 18 and the 10 Linnertz quotes, which means the figures in the post are the honest worst case rather than a flattering one [11].
The cadence he recommends is one canary per twenty pull requests in four-week windows, which for a team reviewing 200 PRs a week is 40 canaries a month [12]. At n = 40 the half-width is 15.5 points [2]. Comparing one window against the next adds the variances, so the worst-case interval on the difference is about 22 points [3]. A drop from 80 percent detection to 50 percent clears that with room to spare; a 5-point drift never will, which is why he calls the method a cliff detector and says gentle slopes stay invisible [13].
That makes the cadence a claim about your PR volume more than about your review process. Reaching 100 canaries inside a four-week window at one in twenty needs 500 PRs a week [5]. A team at 50 PRs a week gets ten per window [6], and ten, he writes, only confirms what you already believed [16]. So below a few hundred PRs a week you either seed heavier and pay in reviewer attention spent on defects you planted [17], or you widen the window and accept that your ceiling is an average over a quarter in which the codebase and the models both moved. (Two weeks of honest baseline numbers beats a quarter of arguing about which numbers to collect, he notes, on the grounds that the arguing is more fun [18].)
The number also depends entirely on canary quality. His examples are an off-by-one, a swallowed exception, and a permission widened exactly one notch, the kind of diff that reads fine at 4:40 on a Thursday [9]. Write them cleaner than that and high detection is measuring your canary author, not your reviewers. Two operational details the post leaves open decide whether the program is runnable at all: who writes the canaries, and what guarantees a seeded defect never merges [19]. Whatever that safety path is, it is also the leak, because the team is told the program exists but never which PRs are in it [10].
Storey's cognitive debt is the balance being accrued, the state where nobody can confidently explain how the system works or predict what a change will break [3]. Detection rate is the only meter in this proposal that moves in the same direction as that balance, since merge rate and time-to-approve both improve while it grows [5]. That is the argument for running it. Against it: Linnertz has not run it at a real team's volume and says so [14], and his evidence for the failure mode is his own project sitting on two months of green CI over conformance checks that had never once passed, caught by a human audit [7]. That shows instrumentation can lie, but it does not yet show that seeded canaries would catch it.
