# Control selection and event-discovery method

Status: frozen before the Phase 0 study metrics and plots were generated.

## Study clock and scope

- Study interval: `2026-01-20T00:00:00Z` (inclusive) to `2026-03-11T00:00:00Z` (exclusive).
- Analysis clock: UTC. Portugal continental was on WET (UTC+0) throughout this interval, so civil and UTC hour labels coincide.
- Station: the single primary EDS station represented in the preserved BSON snapshot. Public artifacts use the alias `station_primary`; no device identifier or coordinate is exported.
- Minute records are the acquisition layer. Hourly summaries require at least 50 valid sea-level-pressure samples in an hour.

## Event discovery

Discovery is telemetry-first and name-blind:

1. Aggregate valid minute readings to hourly means/minima/maxima.
2. Exclude sea-level-pressure values outside 940-1060 hPa from pressure-derived discovery metrics.
3. Calculate backward changes in hourly mean sea-level pressure over 3, 6 and 12 hours.
4. Mark an hour when either:
   - the pressure change is at or below −6 hPa / 3 h, −10 hPa / 6 h, or −16 hPa / 12 h; or
   - the corresponding window minimum is at or below 995 hPa and the fall is at least half the relevant threshold.
5. Group adjacent marked hours into candidate episodes. A break longer than one hour starts a new episode.
6. Only after the station candidates are fixed, compare them with dated IPMA/ANEPC/APA material. A storm name is assigned only when an authoritative source explicitly associates that name with the overlapping period. Otherwise the record remains an unnamed frontal/adverse-weather candidate.

The thresholds reproduce the pre-existing, repository-local `eds_core/scripts/analyze_major_event_windows.py` discovery contract. They are screening thresholds, not a meteorological storm-classification standard.

## Official windows used for attribution

The external timeline defines broad comparison windows, not exact arrival times at the station:

- Ingrid: 21-24 January, supported by ANEPC Notice 1 dated 22 January.
- Kristin: 27-29 January, supported by ANEPC Notice 2 and the IPMA technical note identifying explosive cyclogenesis from 21:00 UTC on 27 January to 03:00 UTC on 28 January.
- Leonardo/Marta sequence: 3-8 February. Leonardo is explicitly supported by ANEPC Notice 4; the broader 4-7 February sequence is supported by the IPMA February climatological bulletin.
- Nils/Oriana frontal sequence: 10-14 February, supported by the IPMA bulletin and ANEPC Notice 8 for Oriana.
- March adverse-weather period: 5-7 March, supported by ANEPC Notice 9. No storm name is assigned.

## Controls

For each official event window, the control pool comprises same-duration windows whose starts are aligned to 00:00 UTC and which:

- sit wholly inside the study interval;
- do not overlap any official event window plus a 72-hour exclusion buffer;
- contain at least 90% of the expected minute readings; and
- have at least 90% of expected hours meeting the 50-sample pressure-validity rule.

The deterministic selection takes up to three mutually non-overlapping eligible windows with the smallest absolute temporal distance from the event start, breaking ties by earlier start. Controls are not selected for benign pressure, humidity or temperature values. Non-overlap prevents the same hours from being counted as independent exemplars.

## Repeatability and comparison

Each event is compared with all eligible controls of identical duration. For peak pressure fall, minimum pressure, mean humidity and minimum dew-point spread, the output records:

- the event value;
- median and range across controls;
- percentile rank within the pooled control distribution; and
- a robust standardized difference using `(event − control median) / (1.4826 × MAD)` where MAD is non-zero.

These comparisons describe how unusual the station trace was relative to nearby complete windows. They do not estimate storm probability, regional severity, causal attribution, forecast skill or impacts.

## Historical versus retrospective output rule

- `as-served historical` means a timestamped record actually preserved from the runtime at that time.
- `current retrospective` means replaying a later model/configuration over old telemetry.

The two are never merged. Current retrospective model scoring is not used as evidence in this phase because current and archived model metadata show training/calibration windows overlapping candidate dates, and the runtime automation ledger begins only on 10 March 2026.