Data Methodology v1.0

• Grid systemEquirectangular latitude/longitude grid snapped to 0.5° latitude by 0.5° longitude. Cells are identified by their south-west corner. No equal-area or H3 grid is used. The cell label is computed on the node and accepted as sent; the platform does not recompute it from raw positions.
• Window durationNodes submit pre-aggregated integrity reports stamped with a window_start. The platform does not impose a window length; the observed node cadence is 60s and is displayed alongside each peak figure rather than assumed. Cells are aggregated by summing aircraft counts and low-NIC counts across all reports sharing a cell in the selected period, so the displayed cell percentage is a count-weighted mean, not a mean of percentages.
• Minimum unique-aircraft sample5 distinct aircraft in a cell/window. Below this the cell is treated as low-sample: it is forced to the nominal band and excluded from peak figures.
• Headline display thresholdA peak is only headlined as a network peak at 10 or more aircraft in the contributing window. Between 5 and 9 it is labelled "highest single observation" and is explicitly distinguished from network alert state.
• Band thresholdsLow-NIC share of a cell: below 10% nominal, 10–30% caution, above 30% alert. These bands drive map colouring and the peak card; they do not by themselves open an event.
• BaselineRolling 7-day count-weighted mean low-NIC percentage for the same cell, computed from all integrity reports in that period. Displayed as the comparison figure in cell popups. No seasonality, time-of-day, or traffic-mix correction is applied.
• Trend resolution2-minute buckets over the last 6 hours for cell trend curves; buckets with no reports are rendered as no-data, distinct from zero.
• Node livenessA node is reported offline when its last accepted report is older than 10 minutes. The same threshold is used by the watchdog and by every public surface.
• ADS-B version and missing fieldsadsb_version, nac_p, nac_v and sil are stored per observation when broadcast and displayed as received. Missing fields are stored as null and rendered as unavailable; they are never defaulted to zero and never imputed. No filtering by ADS-B version is applied.
• Position-inconsistency checkReported routes are validated against observed geometry using a great-circle corridor with 150 km tolerance between origin and destination; failures mark the route unverified in the UI.

• NIC/NACp numeric thresholdNot yet implemented in the platform. Nodes submit a pre-computed low_nic_count; the numeric cut-off (conventionally NIC < 7) is applied in node firmware and is not re-derived or re-validated server-side. The platform therefore cannot currently republish a per-aircraft NIC threshold as its own parameter.
• Persistence requirementNot yet implemented as an automated rule. Events are currently opened and curated by an operator. The persistence, spatial-concentration and sample rules described below are the criteria applied by that operator; they are not yet coded as an automatic detector.
• Event open / merge / revise / close automationNot yet implemented. Event records carry status, severity, cell, region, start and end timestamps, and involved nodes, but transitions are made manually and no merge or revision policy is codified.
• Habitually low-quality airframesNot yet implemented. No per-airframe reputation, exclusion list, or weighting is applied; a persistently low-NIC airframe contributes to every cell it flies through.
• NormalisationsNone yet. No traffic-density normalisation, altitude banding, geometry weighting, or receiver-sensitivity correction is applied to cell statistics.
• Validation against controlled testsPending. No controlled jamming or spoofing test has been run against the network, so no measured false-positive or false-negative rate is published. Until such a test is completed and published, all classifications should be read as observational, not validated.

The full validation status and the ordered roadmap to characterised detection performance are published on the Validation Status & Roadmap page.

• ADS-B integrity anomaly

  A statistically unusual cluster of aircraft reporting degraded navigation integrity. Cause not established.

• Jamming-consistent ADS-B anomaly

  A persistent, spatially bounded integrity degradation whose shape is consistent with a ground-based emitter. No direct RF measurement available, so jamming is not asserted.

• RF-corroborated jamming

  An ADS-B integrity signature accompanied by a direct GNSS-band RF measurement from a PNTMAP node covering the same volume and period.

• Position inconsistency

  Reported position or timing inconsistent with observed geometry, seen by a single node. No cause implied.

• Multisensor-corroborated position inconsistency

  The same inconsistency between reported position/timing and observed geometry is seen independently by two or more nodes.

• Spoofing-consistent anomaly

  A corroborated inconsistency whose pattern, for example aircraft converging on identical false solutions, is consistent with spoofing. Spoofing is not asserted.

• RF-corroborated suspected spoofing

  A spoofing-consistent anomaly accompanied by a direct GNSS-band RF measurement from a node covering the same volume and period.

• Confirmed spoofing

  Reserved for controlled tests, waveform-level evidence, or incidents independently verified by a third party. Never assigned automatically by the platform.

"Confirmed spoofing" is reserved for controlled tests, waveform-level evidence, or incidents independently verified by a third party. No automated PNTMAP™ classification reaches this rung.

• v1.0 · 2026-08-14
  First versioned publication. Exact implemented parameters listed (grid resolution, aggregation, sample floors, bands, baseline, liveness, missing-field handling). Graded spoofing ladder introduced. Unimplemented parameters marked explicitly rather than described as active. SIL role stated. Controlled-test validation recorded as pending.
• 2026-08-15T16:56:00Z
  Telemetry signing scheme documented: SHA-256 over the raw ingest body, ML-DSA-65 (FIPS 204) signature verified at ingest against the per-node registered public key. Initially live on MAN-2 (key b13fca48275021c1); superseded by full-network coverage in the next entry.
• 2026-08-15T17:28:00Z
  MAN-1 telemetry signing live (key 4f8a732ccad8fa4a), verified at ingest under the same scheme. Signature verification now covers every node in the network.
• 2026-08-15
  Independent evidence anchoring live. Every sealed ledger block header is timestamped by an RFC 3161 timestamp authority (DigiCert) within seconds and submitted to the OpenTimestamps calendars on the hourly anchoring run. First confirmed Bitcoin attestation: ledger block 55 in Bitcoin block 962625 (2026-08-15 21:00:27 UTC), verified externally against two independent block explorers. Recent blocks are anchored on the next scheduled run.