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?

Yes, that is the metric. I had run it before you posted the heatmap, and the two grids are the same grid.

Independently, from results/*.scores.jsonl and data/positives.parquet, each detector held at its own 1% point, best member per cell:

                        mine      your figure
integral recall       0.6077          60.8%
cells                     92             92
detectors owning >=1       6              6

Cell by cell it matches on all 92: same owner label, same rounded recall, including the ones that are close. Owner census:

piguard 55   bastion 26   wolfdefender 5   proventra 4   picket 1   promptguard 1

One thing the match pins down that the title does not say. 60.8% is row-weighted. The unweighted mean of the 92 cells is 0.6106. Those differ by a third of a point, and you took the first, which is the right one, because the cells run 80 to 240 rows and a cell mean would quietly upweight the small ones.

The one thing still open is the second half of your title

FPR 1% is pinned for the positives and undefined for the negatives, because a benign input has no cell. There is no family x action to look up, so there is no detector to route it to. The two ways to close that price the same 0.6077 very differently:

A) the cell is a property of the serving surface, so benign routes the same way   0.9956% FPR
B) cannot route benign, so run every detector the oracle ever picks               4.4746% FPR

The oracle picks 6 of your 8. Under (A) the router is a 1%-budget system and it beats every single detector you shipped, so the title is exactly right. Under (B) it is a 4.5%-budget system, and at that same budget the plain union of those same six gets 0.8368 against the router's 0.6077.

So what you are proposing is a pick-one ceiling, not an ensemble ceiling. Which side of the union it lands on is decided entirely by whether the deployment knows the cell for clean traffic, not just for the attacks. Your footnote says "needs the cell known in advance", and I think that is doing more work than it looks like, because it is the benign half that decides the budget.

Growing the pool

piguard                                            0.5689
+ bastion                                          0.6029
+ proventra                                        0.6051
+ picket                                           0.6062
+ wolfdefender                                     0.6071
+ promptguard                                      0.6077

One added model buys 87% of the routing gain. The remaining four buy half a point between them. deepset and protectai own no cell at all, so (B) never runs them, and the alarm they would add is the plain union's price for carrying them.

As a share of the ceiling rather than a gap, which is what your metric makes possible:

piguard 93.6%   bastion 83.3%   proventra 69.5%   promptguard 51.7%
wolfdefender 44.3%   protectai 24.3%   picket 20.5%   deepset 11.9%

picket is at 0.0857% FPR, not 1%, because it is binary and runs at its own fixed point. Same for the one cell it owns.

One cost to price before you publish it as a comparison metric

The owner is chosen on the same rows it is scored on, 8 candidates per cell. Split-half, pick the owner on half a cell, score on the held-out half, mean of 20 splits:

in-sample half   0.6108
held-out half    0.5972

About 1.4 points of selection at half the data, less at full. Your cells being 80 to 240 rows is why it is that small and not larger. The ceiling is real, it just is not free.

Also worth saying: the ownership map here is not the 51/31 I quoted you last time. That one held everybody at a common 0.768% FPR, this one gives each detector its own 1%. Same files, different question, and the map does not survive the change. Which is an argument for publishing the metric with its operating point attached rather than as a single number.

I re-ran your own integrity check rather than trusting my copy: MANIFEST.json at fingerprint 3ee970d160449aae, 24 of 125 files held here, 0 mismatches on sha256 and bytes. Repo sha a8e7c1c, unchanged since 21 Aug.

Does your serving surface know the cell for clean traffic, or only for the attacks?