May 2025 onsite–town descriptive comparison protocol

Protocol fixed before calculating paired results, 5 September 2026. This month is selected because its complete printed onsite daily tables were already recovered and visually checked, and the verified town hourly archive overlaps it. It is a construction-phase comparison, not a chosen flare event or a representative annual sample.

Inputs and quantities

Use the exact native onsite Table B.1 transcription and saved original May PDF identified by the freeze manifest. Retain its date labels and one-decimal concentration strings. Use the original provider-verified 2025 Squamish Elementary station CSV; reconstruct time from native DATE and TIME, preserving hour-ending 24 on its labelled day. No graph digitization, gaps filled, source exclusions, negative clipping, instrument correction or fitted calibration is permitted.

Compare exactly three quantities, separately:

  1. Onsite pm25_24h_ug_m3 versus mean valid town hourly PM25, µg/m³.
  2. Onsite no2_24h_ppb versus mean valid town hourly NO2, ppb.
  3. Onsite no2_daily_max_1h_ppb versus maximum valid town hourly NO2, ppb. The two daily peaks need not occur in the same hour.

Do not join passive SO2/VOC exposure-period samples to calendar days. Do not compare PM10 or TSP because the acquired town record has no matching series. The onsite observations have Level 0 validation and report-described earlier zero adjustment; the town RAW_VALUE column is full precision from a provider-verified archive, not a preliminary live feed. Distinct measurement methods and unresolved dated configuration remain part of interpretation.

Nominal pairing, clocks and completeness

Use each onsite label D from 1–31 May. Primary town window: [D 00:00, D+1 00:00) fixed PST (UTC−8), with a town hour included by interval start. Native TIME is hour-ending 1–24; interval start is labelled DATE plus ending-hour minus one. Store all 24 native town row identifiers and validity flags for each pollutant/window.

Onsite timezone/day-boundary settings are unconfirmed. Always call these nominal daily pairs. Recalculate town windows shifted −1 hour and +1 hour, including adjacent April/June hours at the edges. The −1-hour PST window is the hypothetical May PDT civil day. The +1-hour window is a separate indexing sensitivity. Neither establishes the actual onsite clock, and neither recovers onsite hourly timing. Do not choose the closest shift or use a whole-day lag.

Require at least 18 originally observed town hours for each mean or maximum and report every window's actual count. Preserve all calendar rows with null aggregate when the guard fails. This is this comparison's town-data guard; no matching onsite completeness rule/counts are available. A daily maximum may miss a peak in an unobserved hour. No common hourly mask between stations can be established.

Arithmetic and summaries

Use decimal arithmetic with precision 50 for primary RAW_VALUE and a separately labelled ROUNDED_VALUE sensitivity. No conversion between ppb and mass units is needed. Missing provider tokens are not zeros; unexpected tokens, units, duplicate rows or missing native time rows halt calculation.

Each date/metric/window/precision record contains the printed onsite token, full-precision town aggregate, count and signed contrast (onsite minus town), with source/window provenance. There will be 558 records if all 31 printed dates and all native hours are present (31 ×3 metrics ×3 window shifts ×2 precision streams); missing aggregate values still remain as records.

For every metric/window/precision combination report pair count, eligible dates, means of the paired daily onsite and town values, mean and median signed contrast, mean absolute contrast, minimum/maximum contrast with all tied dates, and counts with positive, negative and zero contrast. Also retain counts beyond ±0.1 concentration units as an explicitly labelled numerical guard for interpreting one-decimal printed values, not an analytical uncertainty estimate. Do not describe contrasts as model error or source increments. The mean of daily values is not automatically an hourly-weighted monthly mean.

Calculate day-boundary sensitivity using only dates valid in all three windows for the same metric/precision. Report every window's mean contrast on that shared date set, largest absolute daily town change from the primary window and all tied dates. Separately compare primary versus provider-rounded town aggregates on dates valid in both streams; report largest absolute daily difference and all tied dates. Do not select a shift or stream from the results.

No ratios, fitted slopes, correlation significance tests, causal attribution, travel-time inference, statistical objective attainment, whole-domain background assignment or dispersion validation will be calculated from this one month. Display values at about one decimal while retaining full arithmetic in downloadable tables. Do not represent a ±0.05 rounding interval as measured analytical uncertainty.

Review, presentation and decision

An independent calculation must start from the original native town CSV and checked onsite table, without importing the producer's hourly or daily derived data. Check paired counts, times, all aggregates/contrasts and summary values. Any comparison mismatch must be resolved before a public quantitative finding.

Use dated plots of the three distinct quantities, with equal units within each panel and both stations clearly identified. If showing the span of shifted town windows, label it as day-boundary sensitivity, not measurement uncertainty. Preserve dates with missing data as gaps.

The result may describe this month at the two monitors and inform what observations are needed to assess an offsite background choice. It cannot establish that one monitor represents the other, attribute differences to flaring/construction/shipping, or validate community concentrations. The next data requests should be specific: final onsite hourly data and QA masks; clock and aggregation conventions; inlet/instrument history; local weather and source/activity logs; multiple seasons. Do not send requests or add these daily values to the simulation automatically.