Forward-cadence sev-4+ filing throughput — 2026-06-04

Headline

• Register size: 1196 total / 468 sev-4+.
• Forward-cadence sev-4+ (filed within 14d of announced): 12 actions ever.

Why this number bounds Gate 3. The lead-time audit reports press-mention populated forward-cadence sev-4+ rows; this audit reports the structural pool those rows are drawn from. The pool's growth rate — not press-backfill — is the binding constraint on publishability (see lead_time_audit.py, ## Coverage shortfall).

Trailing throughput

Time-to-floor projection

How many calendar weeks until the forward-cadence sev-4+ pool reaches each candidate floor, at trailing throughput? (Press-mention population is a separate, faster operation once the pool exists.)

Recent filing weeks

Resolution paths (user-adjudicated)

Per the 2026-06-01 12:47 UTC strategy tick's binding-constraint reframe (docs/strategy/notes/2026-06-01-1247.md), three user-adjudicated resolution paths exist; this audit lets the user compare their relative cost:

1. Raise wake-filing forward-cadence sev-4+ throughput. Engine-level change (filing-prompt tuning, severity-targeting heuristic). Cost: agent-time + tune-iterations. Yield read off the @ 4w pace column once the change is live. 2. Recalibrate the n>=30 floor. Lowering to n=20 or n=15 shifts the deadline — the n>=20 and n>=15 rows above show the trade. n=30 was set 2026-05-16 against a 766-action register; today it is 1196 (+56%). Proportionality may have shifted; absolute n=30 is increasingly punitive. 3. Expand scope to sev-3 regulator-bulletin actions. The n=30 sev-4+ scope was a conservative-publishability choice; sev-3 regulator-bulletin actions arguably meet the same bar at higher volume. The honest sub-cohort number lives in forward-cadence-throughput-regulator-bulletin-sev-3+.md (re-run with --severity-floor 3 --require-source-class, the path-(c) chunk-4 deliverable of source-class-taxonomy-v1). The sev-3+-only sibling forward-cadence-throughput-sev-3+.md is an upper bound on the path-(c) cohort because it drops the severity floor without applying the regulator-bulletin filter.

Caveats

• git first-add date is a proxy for filing date. If the action was edited heavily after first commit, the time-of-judgement is the first commit; the 14-day window is measured from announced_date, so this is well-defined.
• The trailing-week buckets count filing_week, not announcement week. A burst of backfilled forward-cadence actions (announced 2026-W18, filed 2026-W19) lands in W19's bucket — that's correct for measuring throughput, not noise.
• This audit treats severity strictly as an integer field; actions with non-integer or missing severity are excluded from the cohort. The total_in_band headline reflects parsed-integer severities only.
• Throughput is non-stationary by construction (engine improvements, scope changes, holiday weeks). The 4w/8w/12w/26w spread is the audit's defence against single-window bias.