Cascadia Early Warning.

The queue orders attention; a person decides what is in it. A flag is a departure from expected reporting volume and nothing more: it does not say why, and it is not a statement about any device or firm.

Report counts are not incident rates or measures of device safety. This independent public-data demonstration provides no medical, legal or regulatory advice.

• Counts, not rates. In FDA's own words, from the openFDA documentation: MDR data alone cannot be used to establish rates of events; a causal relationship cannot be established between product and the reactions listed in a report; and every API response says to assume all results are unvalidated. Reporting is passive and batched, and a count carries no denominator. A quiet code is not a safe code.
• Summary reports. NPT is on FDA's list of product codes eligible for voluntary malfunction summary reporting, and DSP, DSQ, LWS, NIK, OZD and PYX are not. 4,179 of NPT's 72,845 reports are summary reports standing for 149,569 events, so its count can move with reporting practice and is not a count of events.
• The snapshot. Receipts run through 2026-08-31, as the source had loaded them on 2026-09-29. This is a retrospective test using the October 2026 data snapshot. It does not reconstruct exactly what was publicly available at each historical date.
• Reports without an event date. 13,375 of the headline code's eligible reports carry none; they are counted in charts 1 to 4 and left out of chart 5 only.
• What public data cannot supply. Exposure by lot and site, verification and validation results, the defect backlog, supplier and process measures, and complaint intake before it becomes a report.
• What this page refuses to do. It names no manufacturer or brand, publishes no rate and no risk, and does not read the recall timeline as a validation of the rule.

The decision

The decision this page serves is a quality team's monthly choice of where to look first: which product codes are reporting as expected and which are not.

The snapshot and the live edge

• Receipts run through 2026-08-31; the source had loaded them as of 2026-09-29, and this page was built from a snapshot taken 2026-10-06.
• September 2026, one month ahead, is an elapsed-period estimate: the month had ended when it was issued and the source had not loaded it. It is in none of the locked or recent scores; the live edge scores it, on raw counts, when the source first shows the month. November 2026, three months ahead, is the forecast this page leads with.
• Live edge. Last run 2026-10-13 23:38 UTC, status ok, 27 checks, 0 failed. Source last_updated seen 2026-10-07. Months loaded beyond the freeze: 2026-09, as raw counts with no exclusion applied. Forecasts scored as their months elapsed: 7, mean absolute error 70, 80% coverage 100%. Latest live outlook issued from origin 2026-09. The frozen months re-read from the latest vintage: 15 of 896 read higher, by 19 reports in total; 6 read lower. The source has revised 2 frozen months downward since the freeze, by 4 reports in total; each is dispositioned in the decision record (D24) and the frozen table is unchanged. The record is governance/reconciliation.md.

What is counted

• One report is one record the source holds, in the month FDA received it.
• NPT is on FDA's list of product codes eligible for voluntary malfunction summary reporting, and DSP, DSQ, LWS, NIK, OZD and PYX are not.
• Of NPT's 72,845 reports, 4,179 carry the source's summary-report flag and together stand for 149,569 events; 3,375 of them summarize more than one event, up to 3,108 in a single report.
• A change in how summary reporting is used can move NPT's count with no change in events; the target stays the count of reports.
• The other codes carry four summary-flagged reports between them, each for a single event.

The models and the headline code

• The headline code is among the codes whose review rule is enabled, the largest-volume code for which the candidate earned use: DSQ, Ventricular (Assist) Bypass.
• The candidate earned use on 2 of 7 codes (DSQ, NPT); the trailing mean is in use on the rest (OZD, PYX, NIK, LWS, DSP).
• Promotion was decided on one-month-ahead errors in the development period.
• Every code's outlook is in the table under chart 1.
• Chart 2's largest miss is chosen as the largest absolute error of the model in use and nothing else: May 2024, 2,237 reports against 749 expected.

The test's chronology

Model selection used target months through December 2023 and was registered in October 2026 before generating the retained test results. This is a retrospective test using the October 2026 data snapshot. It does not reconstruct exactly what was publicly available at each historical date.

• Selection period: targets 2022-01 to 2023-12; the harness was committed to config/model.json at df36abd and the promotion decision at 582a857, before any locked-period forecast existed.
• Locked test: 24 months, 2024-01 to 2025-12, from origins at or after 2023-12. One corrected result was frozen after a documented harness repair; promotion and point forecasts were unchanged.
• Recent check: 2026-01 to 2026-08, scored beside the locked test. It was not used for model selection or for the coverage gate; the review rule runs over it, and its errors join the history behind later ranges, November 2026's among them.
• Issue dates: Every back-test row carries a nominal issue date, the first day of the month after its origin, which the harness assigns rather than records: all of them were computed on 2026-10-06 from that day's snapshot. Only the outlook rows carry the date they were actually issued, 2026-10-06.

The review rule

• Registered before the first forecast existed (governance/pre-registration.md, commit fbf0f41), under the model in use at one month ahead.
• The rule. A month is flagged when the observed count exceeds the 80% upper bound and is at least five reports above the point forecast. Two consecutive flagged months open an episode. One run is one episode, and an empty queue is a valid result.
• One-sided. The rule is one-sided by design: a month below its range is never flagged.
• The floor. The five-report floor is a workload heuristic, chosen so that a departure of a handful of reports in a small series never opens an episode; it is not a calibrated threshold.
• By chance. An illustration, not a measured false-alarm rate: if a model's 80% ranges were correctly calibrated and its errors independent from month to month, a month would land above the upper bound about one time in ten and two consecutive months about one time in a hundred, so about one episode per hundred evaluated months would open by chance before the five-report floor. Neither condition is guaranteed here, and no false-alarm rate was measured.

When the rule is on (the coverage gate)

• The gate. Each code's rule was enabled from its 80% coverage in the 2024-01 to 2025-12 locked test: the first 24 of the 32 months, 2024-01 to 2026-08, that the rule then runs over.
• With the gate the rule ran on four codes, 128 code-months, and opened 1 episode.
• Without it the same rule, over all 224 code-months, opens 7 (DSP 1, OZD 2 and PYX 4) and flags 30 months.
• Against chance, as the pre-registration says the workload is read: at about one episode per hundred evaluated months, chance alone would open about 1.3 in the 128 code-months with the rule on and about 2.2 in all 224; the rule opened one and seven. The illustration's conditions do not hold for the codes whose ranges failed the gate.
• Reading coverage. An 80% range should hold about four months in five; across the seven codes the model in use's ranges held between 33% and 100% of locked-test months, and ranges too wide and too narrow are both calibration failures. A code with the rule off is not reviewed by this module.

Recall events, as retrospective context

FDA's recall record for these codes is shown beside the queue, not as its validation. Association only: no shuffled-dates null was run, and the page claims no prediction.

• 175 recall events in these codes over 2016-01 to 2026-08, 77 of them Class I.
• 23.2% of the 784 in-scope product records, of any date, carry a 510(k) number, so clearance links are not drawn.
• 24 Class I initiations in forecast codes in the evaluated span, thirteen of them in codes whose rule is off, where the queue opens nothing.
• The pre-registered count, episodes whose start falls in the eighteen months before a Class I initiation, is 0: 0 of 24 initiations were preceded by the start of a queue episode.
• Against what. The trivial rule that flags every month would have preceded 23 of them, at one flag per month, which is why "preceded" alone means nothing; and no published multi-code figure exists to compare the count against.

Counts, forecast arithmetic, scores and review episodes were re-derived down a second path

• The freeze. 649,080 distinct reports across the seven codes (649,083 report-code memberships: three reports carry more than one of the codes), pulled from openFDA in 696 pages whose SHA-256 is recorded in the manifest and listed in the source register. The monthly counts reconcile with zero variance, on every one of 896 code-months, against the source's own daily count series pulled separately.
• The exclusion. A private token list, kept outside the repository, removed 1 report whole; its SHA-256 (5fa19c0913152ef4...) and the counts removed per field are published, and no firm is named anywhere.
• Two paths. A separately written path, DuckDB SQL over the staged FDA pages plus its own Python arithmetic, recomputes the monthly and lag-matched counts, the distinct report totals, every forecast point and range, the scores, the review episodes, and the queue with and without its coverage gate as this page publishes it, and they must agree before anything is published. It does not refit the ETS model: candidate points are recomputed from the model's exported states, and ranges and scores from the published points. The recall timeline is checked only against fourteen independently verified Class I events, and the cohort gate, the exclusion receipt, the reports without an event date, the promotion decision, the pre-registered recall count, the summary-report composition, the remedial-recall counts and the outlook's twenty dots are carried from the build without a second derivation. The second path is validate_measures.py.
• Golden fixtures, computed outside both engines and committed before any engine code: both baselines on a made series, the ETS recurrence from fixed states, the review rule with a reset, the lag-matched count and the interval scores, passing on both paths.
• Proof the checks can fail. The validation report re-runs the 25 checks of the domain gate against deliberately corrupted copies of their input in 55 scenarios, from a missing partition and a moved hash to a page that states the wrong device class, and records that every one tripped. Every check has at least one scenario. The second path has no such proof mode of its own.
• Chronology. The git log shows the pre-registration and the frozen harness before the first forecast row and the promotion decision before the first locked row. One corrected result was frozen after a documented harness repair; promotion and point forecasts were unchanged.
• The chart review and two reading panels of simulated AI reviewer seats, under VIZ-PRINCIPLES v2.8 and CHART-REVIEW v2.8, recorded in the chart review.