Runway Condition Codes: FICON and GRF OCC Test Matrix

Executive Summary

Runway condition codes, FICON and GRF describe related assessment and reporting concepts, but an operations control centre (OCC) should preserve their jurisdiction-specific meaning. In the United States, Field Condition (FICON) Notices to Airmen (NOTAMs) distribute information for pilots and flight planners under the Federal Aviation Administration's (FAA) Takeoff and Landing Performance Assessment (TALPA) framework. ^[1] For the Global Reporting Format (GRF) comparison, International Civil Aviation Organization (ICAO) SNOWTAM guidance uses a code from 0 through 6 for each runway third. (Source: www.icao.int) That general scale must not become a universal parser rule: the FAA Aeronautical Information Manual (AIM) explicitly prohibits publishing 0 in a FICON NOTAM. ^[2]

The integration decision concerns identity, direction, time and revision, rather than another decoder. European Union guidance orders runway thirds from the lower runway designation, while Canadian reporting can include separate directional reports. (Source: www.easa.europa.eu) ^[3] A dashboard should retain the original ordered values, the source runway end and any separately derived viewing direction. It should also distinguish assessment time, source issue time, receipt time and validity. NAV CANADA explicitly distinguishes condition-report validity from the NOTAM end time. ^[4]

Validity rules also require separate profiles. ICAO and UK guidance specify a maximum eight-hour SNOWTAM validity, rather than a universal freshness guarantee. (Source: www.icao.int) ^[5] This report proposes an original, synthetic acceptance suite covering direction reversal, absent codes, delayed assessments, partial parsing, replacement, expiry and source outages. Its expected states deliberately withhold a usable normalized summary when required evidence is missing. They do not determine whether an aircraft may operate, calculate runway performance or replace approved procedures and authoritative briefing.

Procurement should test the full handoff. NOTAC already documents decoding SNOWTAM, FICON and Canadian runway surface condition reports, so this report's contribution is a source-to-display acceptance contract. (Source: notac.aero) Notamify documents a NOTAM application programming interface (API), but its public feature description alone cannot establish every runway-condition field or replacement rule required here. ^[6] Obtain representative payloads, licensing terms and withdrawal behavior before accepting a feed. The proposed source-of-truth badge identifies the linked issuing record and synchronization state; it does not confer authority on a custom dashboard. Quantitative evidence below consists of published format constraints and explicitly synthetic test measurements, with no claimed vendor performance benchmark.

Introduction and Background

A runway-condition panel can reproduce the visible codes and still lose their meaning. The immediate engineering question is whether the complete evidence survives transport: which airport and runway were assessed, where the ordered segments begin, when the surface was assessed, and whether that assessment remains the current source record. These questions define runway condition code data integration for an OCC or dispatch data owner.

The underlying reporting chain is broader than a NOTAM parser. ICAO describes standardized terminology across runway-condition reporting, and SKYbrary describes assessments by trained observers followed by a handoff to air traffic services (ATS) and aeronautical information services (AIS). (Source: www.icao.int) (Source: skybrary.aero) A custom application is downstream of that chain. Its quality is judged by whether it preserves and explains the information it receives.

The intended readers are US airline and charter dispatch data owners, safety managers and integration engineers, including teams supporting Part 121 and Part 135 operators. The international comparison is separately identified throughout. Nothing here changes operational control responsibilities or establishes a new flight-release procedure. The proposed controls concern software acceptance; operational decisions remain within the operator's approved procedures, manuals, operations specifications and authoritative briefing arrangements.

The analysis is anchored to 18 October 2026. The FAA's current orders index lists Order 7930.2U, including Change 2 dated 30 September 2026; its transmittal confirms the change's effective date. ^{[7] [8]} FAA identifies AC 150/5200-28G, issued 25 May 2022, as active airport-operator NOTAM guidance. ^[9] These references establish the US baseline, rather than an assumption that an older decoder example remains definitive.

From LANDING.AERO's publisher perspective, the relevant subject is the boundary between an existing data source and an operator-specific workflow. This report examines that boundary through a reproducible test contract. It does not review a proprietary implementation, certify a display, or claim that any provider has passed the tests.

Key Changes: Preserve Jurisdiction Before Normalizing

United States: FICON NOTAM parsing

The FAA requires runway condition codes to follow the direction of assessment, with one set per runway surface. ^[10] A parser should therefore retain the reported runway direction. Sorting the runway's paired end designators and attaching the original triplet to the sorted label can silently change the first and last segments.

Missing values require their own representation. AC 150/5200-28G explains that a runway condition code (RwyCC) is not generated when overall contamination is 25% or less. ^[11] Absence is consequently not sufficient evidence of a parsing defect, dry conditions or a particular numeric value. The FAA also tells controllers to provide factual surface information when a RwyCC is absent. ^[12] Preserve that description even when a code-only widget cannot be populated.

There is a documentary nuance worth retaining in validation specifications: the FAA NOTAM reporting chapter describes the general generated scale as zero through six, ^[10] while the AIM expressly prohibits a zero in a published FICON. ^[2] An adapter can recognize the general scale while flagging an unexpected US published zero for review. It must not convert an absent value into zero or silently repair a received record.

International comparison: GRF runway condition report

The Global Reporting Format (GRF) is a harmonized assessment methodology; the runway condition report (RCR) carries the resulting information. SKYbrary describes the RCR moving to ATS and AIS for dissemination. (Source: skybrary.aero) The RCR is not synonymous with every possible transport message or vendor schema.

ICAO SNOWTAM guidance specifies the lower runway designator and an ordered code for each third. (Source: www.icao.int) European Union guidance likewise uses the lower designation as the reporting orientation. (Source: www.easa.europa.eu) That creates a concrete transformation boundary when a dashboard offers the opposite runway-end view. Reverse the entire segment objects together, including contaminants and coverage, while retaining the original source order.

Implementation dates differ. The European Union Aviation Safety Agency (EASA) identifies 12 August 2021 as the European Union applicability date. (Source: www.easa.europa.eu) This date is not presented as a universal legal implementation date. The article uses freely retrievable ICAO guidance and the applicable European implementation text; it does not claim to reproduce the complete current, paid Procedures for Air Navigation Services, Aerodromes (PANS-Aerodromes) standard.

Canada and other national implementations

Canadian runway surface condition (RSC) reporting is a separate profile. Transport Canada permits two surface descriptions per third and separate directional reports when reporting in thirds; full-length reporting does not include RWYCCs. ^[3] NAV CANADA says RSC NOTAMs replaced its former SNOWTAM and NOTAMJ formats. ^[4] These differences defeat a single global assumption about message cardinality or missing codes.

National transport arrangements also vary. Airservices Australia's March 2026 guide describes runway-condition elements in the NOTAM's Field E, rather than issuing SNOWTAM through the National Aeronautical Information Processing System (NAIPS). ^[13] New Zealand's guidance adapts ICAO Circular 355 and describes submitting RCRs through its Internet Flight Information Service. (Source: www.aviation.govt.nz) These examples establish why a feed contract needs a named jurisdiction and message profile, rather than a generic “GRF compliant” flag.

Implementation Considerations and Process Changes

For GRF runway condition data handoff and FICON integration, a normalized record should contain both source facts and adapter metadata, with their origins distinguishable. The Aeronautical Information Exchange Model (AIXM) provides useful concepts: its runway-section contamination model defines observation time as completion of the surface measurement and identifies lower-designation ordering. (Source: aixm.aero) That does not establish that a particular supplier uses AIXM or follows its semantics.

Table 1 proposes a minimum field map. Source references describe reporting semantics; field names and validation states are this report's design recommendations, not mandated FAA or ICAO API keys.

The table's central constraint is no silent substitution. A provider's “updated” timestamp may describe a database record, not the runway assessment. NOTAC's detail reference explicitly distinguishes source issue/update times from its record timestamps, an example of documentation the buyer should request from any supplier. (Source: notac.aero)

A source URL can also be misleading if it opens a continuously changing result. Retain a stable report locator and, where the agreement permits, the exact received evidence. If a public permalink is unavailable, show the issuing authority, source identifier and authorized retrieval route rather than inventing a public URL.

Recommended implementation controls are:

• Profile selection: Choose jurisdiction and format before applying field rules.
• Immutable receipt: Retain the original licensed payload and delivery metadata.
• Explicit null reasons: Distinguish missing source content from unsuccessful extraction.
• Whole-segment mapping: Transform codes, depths, coverage and descriptions together.
• Timestamp provenance: Record where each normalized time came from.
• Versioned interpretation: Attach parser and schema-profile versions to derived records.
• Replayability: Rebuild the display from retained events without editing source evidence.
• Human correction: Record an annotation separately, with actor and reason.

This provenance approach is consistent with the World Wide Web Consortium's (W3C) general description of provenance as information about the entities, activities and people producing data. ^[15] W3C PROV is a conceptual reference here, not an aviation approval requirement.

OCC Acceptance Test Matrix

Synthetic feed event sequence (Hypothetical Example)

The following fixture is deliberately synthetic. Its airport token TEST-A, event identifiers, timestamps and triplets are software-test inputs, not a valid operational NOTAM or an assessment of an actual runway. All times belong to the same synthetic UTC day. The locally configured age rule is intentionally unspecified; it must come from the operator's accepted process.

Table 2 follows a single source stream. It separates a current-looking delivery from a current assessment, a distinction grounded in assessment-time semantics. (Source: aixm.aero)

The decisive case is C1. Keeping B1's attractive triplet on the main card after accepting its supersession would conflate a known old report with an unread current report. The proposed fail-closed behavior withholds the normalized summary while exposing C1's original evidence and the escalation route. Here, “fail closed” concerns eligibility for a trusted summary; it is not a runway closure instruction.

NOTAC documents keeping an unrecognized phrase as filed, and its search API says reports that cannot be fully read are excluded from a worst-code filter. (Source: notac.aero) Accordingly, testing only a numerically filtered feed can miss exactly the partial cases that the downstream system needs to display or escalate.

Acceptance tests and expected display states

Table 3 turns the event sequence into an operator-system acceptance suite for runway condition report validation. Each expected result is a proposed engineering requirement. Jurisdiction-specific format facts are cited where they motivate the test; the suite has not been executed against a licensed production feed.

Direction tests should use asymmetric fixtures. An identical triplet can pass even when reversal is broken. The same principle applies to contaminants, timestamps and revision order: make the inputs visibly different so the asserted mapping can fail observably.

For T12, Canadian guidance confines NR to an absent Canadian Runway Friction Index (CRFI) measurement in its RSC terminology, while EU guidance uses NR for relevant unreported information positions. ^[4] (Source: www.easa.europa.eu) A global string replacement cannot preserve both meanings.

The test runner should capture:

• Input evidence: Exact payload, profile and delivery order.
• Expected source state: Current, historical, ended or unresolved.
• Expected field values: Including null reasons and ordering.
• Expected display text: Badge, assessment time and source access.
• Escalation behavior: Which workflow receives an unresolved report.
• Reconciliation proof: Why reconnect restored continuity.

Passing the suite demonstrates the specified information behavior under these fixtures. It does not demonstrate operational approval, real-world source completeness or an aircraft performance outcome.

Dashboard States and Human Escalation

A source-of-truth badge should answer a bounded question: which issuing record supports this panel, and how much of its handoff has been verified? It should not imply that a secondary interface is the issuing authority. EUROCONTROL's OPADD guidance identifies the latest SNOWTAM using the aerodrome, serial number and observation time, supporting an identity model richer than a single visible number. (Source: www.eurocontrol.int)

The recommended display separates these dimensions:

• Source identity: Issuing authority, message profile, record identifier and retrieval route.
• Assessment age: Time since the stated assessment, with explicit unknown state.
• Transport continuity: Last successful synchronization and unresolved gaps.
• Interpretation quality: Complete, partial, unsupported or inconsistent.
• Record lifecycle: Active according to source, superseded, cancelled or expired.
• View transformation: Selected runway end and whether source order was reversed.
• Human action: The approved briefing or escalation workflow associated with the state.

Display states should be readable without depending on color. “SOURCE LINKED” can coexist with “ASSESSMENT TIME UNKNOWN”; the presence of a source does not resolve missing time. Likewise, successful transport does not mean that every field was interpreted. A details drawer should explain the failed assertion in plain language and expose the original evidence to authorized users.

Keep conditions not monitored distinct from surface conditions not reported. FAA reporting text distinguishes the absence of current observations and reporting from a monitoring limitation. ^[10] The interface should preserve the source wording and its time interval rather than reduce both situations to an empty card.

International handoff also includes human feedback. SKYbrary describes a flight-crew feedback mechanism for changing conditions. (Source: skybrary.aero) The custom dashboard should route such information through the operator's accepted process; it should not alter the airport's source assessment or manufacture a replacement condition code.

Reconnection deserves its own visible state. After an outage, replay retained events, apply explicit withdrawals and replacements, and resolve gaps according to the provider's documented mechanism. NOTAC's terms explicitly require local copies to apply API updates and withdrawals. (Source: notac.aero) That is a concrete contractual example, not evidence that every supplier offers an equivalent recovery interface.

Record the escalation outcome as a separate workflow object. An acknowledgement confirms that someone handled the alert; it does not make the underlying assessment newer, reactivate an ended report or change the source's condition description. Keep that distinction visible in both logs and the main panel.

Feed Procurement and Custom Adapter Boundaries

A licensed authoritative feed needs careful terminology. Identify the authority originating each report, the licensed distribution path and the supplementary services added by an intermediary. Purchasing access does not turn every enrichment into an official source fact. NOTAC's terms explicitly state that the official notice prevails over its reading. (Source: notac.aero) Notamify likewise directs users to verify against current official aeronautical sources. ^[16]

Public product pages are useful for discovery, but they are not payload acceptance evidence. NOTAC documents decoded runway-condition output and differentiated timestamps. (Source: notac.aero) Notamify advertises categorization and scheduling-related NOTAM integration features. ^[6] These are vendor statements about their services, not independent benchmarks or proof that the proposed suite passes.

Before selecting an existing provider or commissioning a custom adapter, request:

• Origin chain: State originator, redistribution path and any transformations.
• Representative messages: Complete, absent-code, multi-runway and partly interpreted cases.
• Direction rules: Source end, reported ordering and any provider normalization.
• Time definitions: Assessment, issue, update, receipt, validity and monitoring semantics.
• Revision contract: Replacement, cancellation, correction and identifier reuse behavior.
• Recovery mechanism: Snapshots, replay boundaries and continuity reconciliation.
• Evidence retention rights: Permitted raw-payload storage and audit retention.
• Display rights: Internal dashboards, mobile views, contractors and external recipients.
• Redistribution rights: Whether another system may receive raw or transformed records.
• Acceptance access: A lawful test environment and agreed payload examples.

Licensing differs by service. NOTAC's terms distinguish display from onward supply and require updates and withdrawals to be applied to local copies. (Source: notac.aero) Notamify's terms restrict making raw or substantially unmodified API output available as a standalone third-party feed or dataset. ^[16] Review the actual agreement for the proposed architecture; neither a public sample nor a general API subscription settles every downstream use.

A custom adapter's responsibility is to preserve the contracted evidence, implement documented mappings, expose uncertainty and support the operator's workflow. The source remains responsible for its published record. The acceptance package should identify which party owns each boundary and which unresolved source or contract questions prevent production acceptance.

The implementation choice can therefore remain neutral: a provider may already supply the needed fields; an adapter may be needed to bridge an existing feed and dashboard; an established operational application may be needed when the requirement extends beyond data integration. Require the same source-to-display evidence in each case. Do not infer a need to replace an approved briefing product simply because a custom panel can render the codes.

Data Analysis and Evidence

The useful numbers for this topic are format constraints and traceable timestamps, rather than market-size estimates. No licensed live-feed sample or independently measured vendor latency dataset was obtained for this report. Consequently, it offers no availability percentage, accuracy ranking or time-saving claim.

The published quantitative baseline is:

• International code range: ICAO guidance specifies a digit from 0 through 6 for each third. This is a coded assessment scale, not a direct aircraft stopping-distance measurement. (Source: www.icao.int)
• US code omission threshold: AC 150/5200-28G describes no generated RwyCC when total runway contamination is 25% or less. ^[11]
• SNOWTAM duration: ICAO guidance and UK Civil Aviation Publication (CAP) 2173 specify a maximum eight hours; a replacement can end the previous report earlier. (Source: www.icao.int) ^[5]
• US FICON validity: The current FAA order generally limits validity to 24 hours from start of activity, with specified exceptions, including certain contaminants and conditions-not-monitored reports. This is not an assessment freshness target. ^[8]
• Canadian message structure: NAV CANADA says an RSC NOTAM contains all runway observations in one message; each runway's condition validity remains separate from the enclosing NOTAM end time. ^[4]
• Model evolution: AIXM identifies 5.2, released in January 2025, as its latest version, while its implementation advice says current Digital NOTAM coding specifications remain based on 5.1.1. A version label alone therefore cannot prove the required field mapping. (Source: aixm.aero)

These quantities must not be combined into a single “fresh enough” timer. Message validity, surface-assessment age, source replacement and transport continuity measure different things. EUROCONTROL describes one valid SNOWTAM per affected aerodrome at a time; that is a lifecycle constraint, not a service availability measurement. (Source: www.eurocontrol.int)

The synthetic timeline supports reproducible local measurements. At receipt of A1, 06:12 minus 06:00 equals 12 minutes of assessment age. At receipt of B1, 06:20 minus 06:15 equals 5 minutes. Its duplicate at 06:21 makes that age 6 minutes, rather than resetting it. These values are arithmetic on Table 2's invented inputs, not observations of an airport or supplier.

An acceptance run should publish the fixtures, execution environment, parser/profile versions, expected outputs and actual results. Report pass counts by failure class rather than only an aggregate percentage. A direction failure and an unavailable source time warrant separate explanations even if most other tests pass. Measure processing delay independently from assessment age; a fast parser cannot make an old assessment current.

The proposed matrix contains 12 tests, all unexecuted against a licensed feed in this report. Its value is specificity: the operator can ask a supplier to demonstrate the same cases and retain the resulting evidence. Any later benchmark should disclose the sample period, message population, excluded records and sponsor, rather than generalize a small demonstration to operational reliability.

Implications and Future Directions

The engineering implication is a move from displaying decoded values to accounting for evidence throughout the handoff. That need not require a new global data format. A documented adapter contract can retain original identifiers, ordered segments, time meanings and source state while adding the workflow metadata the operator actually needs.

Schema evolution still matters. AIXM's current specification page identifies alignment with ICAO runway-condition requirements among its changes. (Source: aixm.aero) Buyers should ask which elements a supplier actually populates, which version governs the mapping, and how unsupported fields survive round trips. Declared schema support should be demonstrated with the same fixtures used for acceptance.

Jurisdiction profiles should remain independent release artifacts. Australian guidance, for example, describes cancelling the RCR NOTAM when the runway returns to normal dry conditions. ^[13] A cancellation event must retain its source context; a custom system should not create a new measured triplet merely because the prior record ended. The meaning of an event must come from the applicable source profile and accepted operational process.

Provenance can also be made portable. W3C PROV offers representations for exchanging provenance information. ^[15] The proposed application is modest: carry the source record, transformation activity and responsible component across service boundaries. Adopting that vocabulary would not establish aviation compliance, but it could make cross-system audit questions easier to answer consistently.

A practical release process should require:

• Profile review: Confirm the current official source and jurisdiction assumptions.
• Fixture replay: Exercise changed and unchanged failure classes.
• Display review: Verify badges and escalation wording with the operator's responsible users.
• Rollback evidence: Retain the prior adapter and a reproducible event history.

EUROCONTROL explicitly identifies its guidelines as nonmandatory guidance. (Source: www.eurocontrol.int) That distinction illustrates the broader publication discipline: cite what each source actually establishes, label proposed engineering controls, and leave operational acceptance with the operator's responsible process. The same discipline should govern artificial intelligence (AI) assisted explanations: retain authoritative text and make derived interpretation visibly separate.

Conclusion

For OCC and dispatch data owners, the decisive acceptance question is whether a displayed runway-condition summary can be traced back to the correct source assessment without losing direction, time or revision. A technically successful fetch and a plausible triplet do not answer that question.

The evidence supports a jurisdiction-first design. International SNOWTAM guidance, US FICON reporting and Canadian RSC reporting have important differences in direction, code availability and message structure. NAV CANADA's distinction between runway-report validity and NOTAM end time is a particularly clear example of why a single dashboard timestamp is inadequate. ^[4] The appropriate response is explicit mapping and validation, rather than a universal decoder assumption.

The proposed acceptance package consists of an immutable source record, a documented field map, a synthetic sequence and observable expected states. It should prove that reversed views preserve complete segments, unknown values remain unknown, partial current reports do not revive superseded summaries, and source outages remain visible until continuity is established. These are software evidence requirements proposed by this report, not operational runway-performance instructions.

Procurement should use the same tests whether the implementation relies on an existing provider, a custom adapter or a broader operational application. The actual agreement must support the intended retention, display and onward handoff. Public product descriptions establish candidate capabilities; representative payloads and reproducible results establish whether the operator's contract is satisfied.

The final boundary remains human and procedural: the dashboard exposes the evidence and routes exceptions. Approved operator procedures and authoritative briefing govern its operational use. No source-of-truth badge, automated explanation or successful parser changes that boundary.