69 of 80 is a statement about the OR, not about the field. One of your eight, on its own, leaves 58.

Your cell reproduces exactly off the shipped scores. pretext / unauthorized_action, 80 rows, all email, each detector at its own 0.1% point: 11 caught by at least one, 69 by nothing. bastion 6, promptguard 3, piguard 1, proventra 1, wolfdefender 1, the other three zero.

Then I priced the OR.

"Caught by nothing" spends eight budgets

union of the 8, each at its own 0.1% point
  recall            0.5743   (9648/16800)
  pooled FPR        0.00768  (484 of 63 000)   = 7.68x the 0.1% budget
  caught by nothing 0.4257

Give a single detector those same 484 false positives and ask your cell again:

on pretext/unauthorized_action, everything at 0.768% FPR
  bastion alone        22/80      uncaught 58
  union of all eight   11/80      uncaught 69
  wolfdefender alone   10/80      uncaught 70
  piguard alone         3/80      uncaught 77

Your hardest cell is one where the eight-way union is beaten by one of its own members, at the alarm rate the union was already paying. Nearly two to one.

I nearly missed that. I checked piguard first because it leads the grid at 1%, and it is the worst thing on this cell. The global leader was the wrong baseline.

Two detectors, routed, get most of the way to eight

Everything at that same 0.768%, best member per cell:

piguard alone                          0.5208
bastion + piguard, routed per cell     0.5657
+ proventra                            0.5684
best of all eight per cell             0.5714
union of all eight                     0.5743

Two models cover 84% of the distance from one model to eight, and the eight-way OR's whole margin over knowing which of them to ask is 0.29 points. Per cell it is 51 to 39 for the router, 2 tied. Cell ownership is a duopoly: piguard 51, bastion 31, everything else 10.

So your README line "a stack of two covers more than either alone" is right, and the number says two is also where it stops.

The same correction on the article's headline

union of 8, each at 1%          0.8476 @ 5.768% FPR    (article 84.8% @ 5.8%)
caught by nothing               0.1524                 (article 15.2%)
best single at 1%, piguard      0.5689                 published gap +27.9
piguard at the union's 5.768%   0.7973                 iso-FPR gap  + 5.0
best of eight per cell, 5.768%  0.8114                 iso-FPR gap  + 3.6

81.9% of the published +27.9 is budget rather than stacking. And of the 2 560 injections nothing catches at 1% each, piguard alone at 5.768% catches 1 069, so 41.8% of the field's blind spot is one of those same eight detectors, underfunded.

You wrote the caveat yourself: "a union adds up false positives, and in production those are what limits you." I think it bites harder than the sentence it sits in, because the comparison immediately after still gives the union 5.8% and the single 1%.

This is your own conclusion, taken literally

Your README says the winner map comes out patchwork, and that to assemble a stack "you have to know where each is blind." The numbers say the second clause is the whole result. Knowing where each is blind is worth about as much as running all of them, at a quarter of the cost.

One honest limit: routing per cell is an oracle. It needs a labelled grid to know which detector owns which cell, and yours is the only set I know of that is built to give you that. So this is an argument for the dataset, not against the union.

All of it re-derives files you shipped. Nine card recalls reproduce to three decimals at 0.1%, eight at 1%, and MANIFEST.json checks clean on the 29 files I hold, byte-identical to main and unchanged since 21 Aug.

Would a per-cell routing row fit in reports/, beside the per-detector ones? Or does one-class-one-method make a router someone else's job?