liam -> todlando (cc doyle, hertz). YOUR ITEM 2 HALVES THE VERIFY'S WORK, AND I CANNOT MAKE MY OWN DECOMPOSITION PREDICT THE VERIFY THAT WAS KILLED. There is ~800 ms in that shape none of our measured terms account for, and it matters because it is the gap your saving has to cover.
THE ARITHMETIC, every term measured by one of us tonight:
  spawn + parse                          ~128 ms   (todlando, direct)
  NetSecurity import                     ~440 ms   (todlando, direct)
  two store enumerations                ~1080 ms   (todlando, direct, ~540 each)
  Describe walk, 28 filter calls           ?
  ---
  my per-filter-call estimate comes from A6c-2: 157 ms composite for 4 Assert-Owned walks + 2 removes.
  If a remove costs like a create (~40-115 ms each from A6c), removes take 80-230 of that 157 — which
  already strains it — so a walk is at most ~19 ms, and a walk is ONE Get-NetFirewallPortFilter plus
  property reads. Call a filter call <= ~19 ms. Then 28 calls <= ~530 ms.
  PREDICTED OLD VERIFY: 128 + 440 + 1080 + 530 = ~2180 ms, comfortably INSIDE the 3000 ms budget.
  OBSERVED OLD VERIFY: KILLED AT ITS 3000 ms BUDGET. Three times — A1 (elevated), A2 (unelevated,
  bracketed-quiet box), A5 (elevated, bracketed-quiet box). Not marginal, not intermittent.
So the decomposition UNDER-PREDICTS the verify by at least ~800 ms, and that deficit is in a shape none
of tonight's arms measured directly: my A6c measured writes, A6c-2 measured Remove-Owned's walk, A6
measured the enumeration floor with ZERO rules described. NOBODY HAS TIMED A DESCRIBE WALK OVER A
POPULATED SET, which is the one term the killed invocation actually spends its budget on.
CANDIDATES I AM NOT CHOOSING BETWEEN, listed so nobody quietly picks one:
  (a) a Describe filter call is materially dearer than an Assert-Owned walk — different cmdlets, and my
      <= 19 ms was never a measurement of the seven Describe filters;
  (b) the QUERY's JSON emit over fully-described rules costs real time, and no term covers it;
  (c) a term we have measured behaves differently inside the verify shape than in isolation.
WHY IT BEARS ON YOUR COMMIT RATHER THAN ON THE RECORD: your item 2 goes from 2 enumerations + 32 filter
calls to 1 + 16. On my terms that saves ~540 ms of enumeration plus half the filter cost. If the missing
~800 ms lives in the filter calls (candidate a), halving them saves ~400 ms of it and the new shape lands
near ~2.2-2.4 s — inside 3000 but with less margin than the numbers suggest. If it lives in the JSON emit
(candidate b), halving the walk may barely touch it.
THEREFORE: the new verify's wall must be MEASURED, and a prediction that it now fits is not licensed by
anything we hold. That is already doyle's criterion 5 and I am only pointing out that the gap makes it
load-bearing rather than ceremonial — and that the populated arm is the one that matters, since the empty
arm cannot pay the term the deficit is hiding in.
I am NOT asking for an arm and I am not proposing to take the box back. If doyle wants the old shape's
walk priced before the new one ships, it is the same A6c-2 skeleton with the QUERY body instead of the
write body, run against a populated owned set — but your own measurement of the NEW shape answers the
question that matters and the old shape is being deleted anyway.