FAA Circling Icon Removal: Audit Legacy Operations Flags

Executive Summary

FAA circling icon removal is a U.S. chart-publication transition with a specific downstream data question: does a ground reference system still infer procedure criteria from a symbol? The Federal Aviation Administration's May 14, 2025 notice says removal starts with the August 7, 2025 publication. ^[1] The Terminal Procedures Publication (TPP) legend effective October 1 through October 29, 2026 explicitly allows users to ignore the presence of the symbols. ^[2] The later FAA issue history records final validation in 2025 and initiation of Aeronautical Information Manual (AIM) and Instrument Procedures Handbook updates. ^[3]

The evidence does not establish a date on which every chart became icon-free. Older explanations remain easy to encounter: Advanced Aircrew Academy's 2021 article identifies applied expanded criteria through the symbol, while Code7700's 2019 reference describes the earlier distinction. ^{[4] [5]} These are dated explanatory sources, not current airport records. A data owner should preserve the distinction between chart appearance, procedure identity and revision, publishing authority, design regime, source criteria reference, published notes, and operator-approved applicability. World Wide Web Consortium (W3C) provenance concepts provide a useful model for recording the source, transformation and responsible party. ^[6]

The practical response begins with the contracted provider and installed functionality. Garmin documents a calendar view of current and future database cycles; ForeFlight documents Content Pack version and effective/expiration metadata. ^{[7] [8]} Neither establishes the meaning of an unidentified circling field in an operator's export. Request its documented semantics, applicable editions, licensing and treatment of unknown values before commissioning a narrow adapter. In particular, a missing property and an explicitly null property are distinct data states in JSON Schema, used for JavaScript Object Notation (JSON) data. ^[9]

This report supplies a dated evidence matrix, a proposed source contract and eight synthetic acceptance cases. The cases test source age and unresolved metadata discrepancies, never protected areas, operating minima, flight eligibility or a go/no-go decision. They are author-designed fixtures, not observations of any operator or vendor deployment. The desired outcome is a traceable ground display that can explain its source and flag unresolved interpretation. A metadata migration cannot establish equipment compatibility or operational approval; the European Union Aviation Safety Agency's (EASA) separate database-provider framework illustrates why those scopes must remain explicit. (Source: www.easa.europa.eu)

Introduction and Background

For flight-operations data owners, the useful question is narrower than how to fly a circling approach: what does an existing ground-system label actually mean today? A briefing administrator may encounter a field called “expanded,” a chart-symbol indicator or a locally derived classification. This report does not assume that any such field exists in a contracted product. It examines how to establish its meaning if the operator finds one.

The starting hypothesis is that an old symbol-driven mapping could misdescribe a ground reference after publication conventions change. No live operator system, export or business rule was inspected. There is no measured error prevalence or demonstrated safety benefit. EUROCONTROL's description of an aeronautical data chain with numerous actors and transaction points explains why checking the transformation path is a reasonable audit activity. (Source: www.eurocontrol.int)

This is a U.S. transition, not a global reclassification of procedures. The FAA names its design standard United States Standard for Terminal Instrument Procedures (TERPS). ^[10] International Civil Aviation Organization (ICAO) Procedures for Air Navigation Services, Aircraft Operations (PANS-OPS), includes a procedure-construction volume intended for specialists. (Source: store.icao.int) Canada separately publishes instrument-procedure design criteria through Transport Canada. ^[11] A ground-reference migration should retain the publishing authority and design regime instead of assuming that an FAA chart convention applies everywhere.

The analysis addresses U.S. Part 121 and Part 135 data owners, business-aviation flight departments, chief pilots and their information-technology teams. Its recommendations concern source handling and display acceptance. It supplies no regulatory interpretation of an operator's particular authorization. The distinction also matters commercially: a vendor may offer charts for ground applications without documenting an arbitrary export field or a customer's right to redistribute it. Jeppesen explicitly describes ground applications among the uses of its electronic terminal charts. ^[12]

LANDING.AERO's editorial perspective here is adjacent ground-software integration. Chart supply, procedure design and operational approval remain separate responsibilities. Before specifying custom software, the operator should establish whether an existing display, configuration, report or provider-supported update already answers the question. Garmin's documented cycle view is one concrete native capability to inspect. ^[7]

Key Changes

Removal changes the meaning of symbol-based inference

The FAA notice identifies a publication change, with removal beginning in the minima section of approach charts and radar approach minimums. It states that all circling areas have been evaluated and describes removal on a day-forward basis. ^[1] For the proposed ground audit, the consequence is straightforward: neither the presence nor absence of an icon should independently select a current criteria classification.

That statement is deliberately limited. It is not a procedure-design calculation, a replacement for a chart legend or a conclusion that published restrictions disappeared. The audit should ask whether the system stores an observed symbol, a provider classification or an operator interpretation. Those are different assertions and should have different provenance.

A useful review separates these questions:

• Appearance: What symbol, if any, appears in the supplied chart edition?
• Identity: Which publisher procedure and revision does the record represent?
• Authority: Which state or organization publishes the procedure?
• Criteria: What current source identifies the applicable design reference?
• Publication: Where are the published minima and notes retained?
• Applicability: Where is the operator's approved interpretation documented?

The distinction between versions also has a general data-model basis. W3C's provenance primer treats the result of each revision as a new entity, allowing related versions to retain separate histories. ^[13] A system can therefore retain an old symbol observation without turning it into a permanent attribute of the procedure.

Retrieval freshness cannot establish source revision

A page downloaded today may contain text written before a transition. Conversely, a future-effective package may be available before it becomes applicable. NAV CANADA explicitly distinguishes its currently effective Aeronautical Information Publication (AIP) issue from its next issue. ^[14] That example is Canadian publication practice, not an instruction for applying Canadian data to U.S. procedures; it illustrates why retrieval and applicability deserve separate fields.

Historical training material belongs in the same disciplined framework. AOPA's older explanation tells readers to identify expanded areas using a symbol on the circling line. ^[15] An integration team should retain such material as dated background rather than silently promote its symbol mapping into a current data contract.

A software update is not a source-definition update

Application version, downloaded content and record interpretation should be checked independently. ForeFlight expressly separates app updates from chart and data downloads. ^[16] Installing new software therefore does not, by itself, answer whether a local export mapping, cached reference or derived field was revised. The required evidence is the actual installed behavior and its documented source semantics.

Dated Evidence and Publication Conflicts

Table 1 compares the evidence relevant to the transition. “Verification owner” names the party from whom the operator should obtain clarification; it does not imply that any party reviewed this report. All listed pages were retrieved during this research session. Where a web passage lacks a displayed revision date, its age remains unknown.

The matrix supports a clarification request, not an invented rule to reconcile the documents. The effective legend and dated notice are strong evidence for retiring symbol-only classification from a ground display. The conflicting web wording should remain visible in the source record until the responsible parties confirm how the contracted product represents the transition.

Document status also deserves a separate check from institutional reputation. EUROCONTROL explicitly warns that many documents supporting a former aeronautical-data regulation lost their legal basis after repeal. (Source: www.eurocontrol.int) That European example does not govern this U.S. migration; it demonstrates why a familiar official URL cannot substitute for checking current applicability.

The source register should preserve a short exact passage, document title, effective edition and reason for selection. It should also retain the competing reference. Deleting the older source from a library may hide how a legacy mapping arose; keeping it with a historical label makes the mapping explainable without continuing to treat it as current authority.

Implementation Considerations and Process Changes

Inspect the installed path before specifying an adapter

Begin at the actual ground display and trace backward. The proposed chain is authority publication → contracted provider package → licensed export → ingestion mapping → ground display. It is a discovery model, not a claim about any vendor's architecture. EUROCONTROL's data-chain description supports examining transaction boundaries; it does not establish the fields or responsibilities in a particular contract. (Source: www.eurocontrol.int)

Collect evidence at each boundary:

• Displayed label: Capture its wording and the source link offered to the user.
• Dependency: Identify the rule, report or filter that reads the suspected field.
• Raw value: Preserve what the provider actually supplied, including unknown states.
• Transformation: Record any lookup, parser default or local derived classification.
• Edition: Match the package to its effective publication and procedure revision.
• Ownership: Identify who can explain and approve the mapping's intended meaning.

If no ground rule depends on the symbol, the change may require only a documented finding and an update to reference text. If a dependency exists, reproduce it with synthetic data before choosing a remedy. An issue in a hypothetical mapping is not evidence of a defect in a named supplier.

Native controls should be demonstrated using the operator's installed versions and entitlements. Garmin Aviation Database Manager documents current/future cycle views and automatic downloading. ^[7] Those functions may answer a currency question for supported products; they do not prove a local ground export's semantic interpretation.

ForeFlight documents recurring updates for regions selected in Downloads, while Pack data does not automatically update unless the relevant regions are selected there. ^[16] Its Content Packs support manifest metadata, and expiration notices do not make the pack cease functioning. ^[8] A review should consequently distinguish availability, an expiration warning and whatever acceptance rule the operator has defined for the ground display.

Request meaning and rights, not just a renamed field

A provider reply should answer a concrete example: “In this licensed product and edition, what does this raw value mean, and may this application display the proposed interpretation?” Public product descriptions cannot settle that contract. Navigraph's developer restrictions, for example, confine its data and charts to flight simulation. ^[20] Convenient access to a dataset is not sufficient evidence that it is appropriate for a real-world ground application.

Ask the contracted provider:

• Definition: Is the field a chart-symbol observation, a design classification or another concept?
• Transition: Which package or effective edition changed its interpretation?
• Unknowns: How are missing, null, unavailable and explicitly absent values distinguished?
• Revisions: Which identifiers connect a chart, procedure revision and export record?
• Distribution: What caching, transformation and redistribution rights cover this use?
• Native remedy: Is a supported field, configuration or report already available?

Only then scope an adapter. Its acceptance criteria should name the exact input contract, output label and handling of unresolved sources. Do not assume that changing a boolean's display name changes the underlying meaning.

A Source and Version Contract for Ground Reference Data

A source/version contract is proposed here as a written agreement about what a record asserts and how that assertion is traced. It is not an aviation standard, an avionics interface or a certified navigation-data format. W3C defines provenance through the entities, activities and people involved in producing information, a useful conceptual basis for this ground audit. ^[6]

Table 2 specifies a candidate audit record. The names are illustrative worksheet labels, not claimed native fields in any supplier's export. A provider may supply a criteria-reference document at package level rather than a value on every procedure record; the contract should state that relationship explicitly.

The table separates evidence from inference. A raw symbol value may be retained for traceability even when it has no role in choosing a criteria label. Conversely, a populated criteria-reference field should not be accepted merely because it contains plausible text. It needs an identified source, applicable version and confirmed relationship to the record. NAV CANADA's distinction between current and next issues illustrates why applicability must be explicit. ^[14]

Use explicit exception labels rather than a generic warning:

• SOURCE_CONFLICT: Applicable-looking documents disagree on the interpretation.
• PROVIDER_MEANING_PENDING: The supplied field has no confirmed definition for this edition.
• EDITION_MISMATCH: The displayed record and supporting source editions differ.
• REVISION_REVIEW: Published content changed and needs source alignment.
• JURISDICTION_OUT_OF_SCOPE: The proposed U.S. mapping has reached another authority's record.
• UNKNOWN_VALUE: A required semantic value cannot be established.

These are proposed internal workflow labels. They do not prohibit or authorize flight. Explicit required-property checks can help enforce the agreed record shape, but JSON Schema's required mechanism says nothing about the operational truth of a field. ^[9]

Time handling needs the same discipline. ForeFlight documents a local-time default for Content Pack manifest times unless a Z suffix is supplied. ^[8] RFC 3339 describes the Z designator in relation to a zero UTC offset. ^[22] The worksheet should specify its own timestamp convention and keep validity start/end separately; an ingestion instant cannot stand in for a publication interval. RFC 3339's date-time scope is an instant rather than an interval. ^[22]

Synthetic Acceptance Fixture for Circling Metadata Migration

The following is a Hypothetical Example for a ground airport/procedure reference. Every procedure token, criteria-reference token and package date in this fixture is invented. SYN-PROC-A is not an airport procedure, and SYN-CRITERIA-CURRENT identifies no real design document. No operational numbers are supplied.

The core invariant is that two records with the same confirmed source identity, revision and criteria reference receive the same ground reference classification even when their observed icon values differ. This is a proposed test of the display contract, not proof about a live feed. An enum can constrain the allowed symbol states; it cannot determine their aviation meaning. ^[21]

Table 3 defines the eight fixture cases. “Review” means an unresolved source/contract mismatch remains in this deliberately constructed input. It is not an operational decision.

F01 and F02 demonstrate the essential equality test. A difference in appearance alone must not create a difference in the confirmed criteria reference. F03 then tests a separate change: an amended procedure may need revised published-content references even if symbol treatment remains identical. W3C's revision model supports retaining these versions separately rather than overwriting their history. ^[13]

For F08, JSON Schema documents that boolean values are specifically true or false and that null is not equivalent to a property being absent. ^{[23] [9]} The proposed parser should preserve the original state before applying a documented interpretation. The test should fail if a missing input silently becomes a negative assertion.

Suggested acceptance evidence includes:

• Input snapshots: Synthetic payloads and the exact expected labels.
• Transformation record: The mapping version and preserved raw values.
• Equality assertion: F01 and F02 retain identical confirmed criteria references.
• Revision assertion: F03 exposes the mismatch between source revisions.
• Exception routing: Each unresolved case names its review owner.
• Boundary assertion: No test emits protected area, operating minima or eligibility.

The fixture should be adapted only after inspecting native functionality and receiving provider definitions. AIXM's progressive-implementation statement is a useful reminder to verify deployed capability rather than assume it. (Source: aixm.aero) It does not establish how any commercial navigation database encodes circling information.

Data Analysis and Evidence

The quantitative core is document timing and synthetic mismatch counting, not an estimate of operational risk. The audit date is October 23, 2026, the report's stated reference date. Calculations use whole calendar-day differences, excluding the starting day. Their inputs and formulas are stated so a reader can reproduce them.

For the documentary timeline, the notice date of May 14, 2025 precedes the audit date by 527 days, and the announced removal start of August 7, 2025 precedes it by 442 days. These are author calculations from the dates in the notice, not FAA performance measures. ^[1] Neither elapsed duration reveals how many icons remain or whether a particular provider has completed its implementation.

For the Hypothetical Example, source age is audit date minus synthetic package date. The October 1, 2026 package is 22 days old; the September 3, 2026 package is 50 days old. These invented dates demonstrate arithmetic only. Age does not determine validity: a package's effective interval and the selected publication contract must still be checked. RFC 3339 distinguishes timestamp instants, while the W3C primer separately records document-version creation. ^{[22] [13]}

The fixture contains eight records, of which six intentionally retain unresolved source/contract mismatches. The count is the sum of the “Yes” cells in Table 3, counted once per record even if a record could have multiple labels. It is an acceptance-workload count for this invented set. It is not a defect rate, a representative sample or evidence that any operator experiences a similar distribution.

Published update cadences provide another useful distinction. Jeppesen describes 28-day NavData updates and 14-day electronic terminal-chart updates on the same product page. ^[12] The FAA describes its digital TPP publication as 28-day. ^[24] NAV CANADA describes AIP Canada as 56-day. ^[14] Those are separate product/publication schedules, not interchangeable validity guarantees. A single universal “latest data” timestamp would conceal these distinctions.

A disciplined review should measure only what its evidence supports:

• Source age: Use a named publication or package date, never an unlabeled timestamp.
• Processing delay: Compare identified receipt and ingestion events if available.
• Unresolved records: Count records awaiting source/contract clarification.
• Reconciliation status: Record which questions have a documented provider response.
• Coverage boundary: State which exports and displays were actually inspected.

No live export was available for this report. There is consequently no observed mismatch total, incident analysis, measured time saving or forecast reduction in errors. The evidence establishes a source-reconciliation task and a reproducible test design.

Implications and Future Directions

Govern the interpretation, not only the file transfer

A source update can arrive successfully while a local label retains an older meaning. The proposed governance response is to maintain an approved interpretation alongside the mapping version, then recheck that interpretation when its source or applicable edition changes. Provenance records can represent responsible agents and the times associated with data production. ^[6]

Lufthansa Systems' July 2012 documentation supplies a historical example of why boundaries matter: it distinguishes its ARINC 424 navigation-data file-content requirements from procedures removed by a downstream data packer. ^[25] This is not a claim about today's contracted Lido schema. It supports asking which production stage a particular exclusion, transformation or field definition describes.

Specification release also differs from deployed capability. AIXM, the Aeronautical Information Exchange Model, describes progressive implementation of its newer version according to operational needs. (Source: aixm.aero) A provider should therefore confirm its actual deployed schema and interpretation; a published standard alone cannot establish what an operator receives.

Keep jurisdiction and operational responsibility explicit

The U.S. icon-removal transition should not be propagated as a rule for ICAO or European procedures. ICAO identifies PANS-OPS Volume II as a procedure-construction document; Transport Canada maintains its own published criteria. (Source: store.icao.int) ^[11] The useful software behavior is to preserve authority and source references, then route out-of-scope records for the appropriate interpretation. NAV CANADA's distinction between current and next issues further illustrates why another jurisdiction's publication must retain its own applicability metadata. ^[14]

Likewise, a ground metadata adapter should not present itself as an approved airborne database. EASA's Type 2 database-provider description explicitly addresses determined equipment compatibility and agreed data quality requirements. (Source: www.easa.europa.eu) That framework is cited to illustrate the scope distinction, not to impose European certification requirements on this proposed U.S. ground worksheet.

Maintain references as a separate workstream

The General Aviation Joint Safety Committee's (GAJSC) safety-resource listing includes OPSGROUP's circling explanation as an April 2026 resource. ^[26] OPSGROUP explicitly places an update above an earlier article. (Source: ops.group) This is relevant editorial selection and evidence of updated explanatory context. It is not a new measured dataset, proof of search-demand growth or an endorsement of a proposed software implementation.

Training-reference administrators and integration owners should coordinate their source registers while keeping their responsibilities distinct. A current explanation can point to the latest authority and provider response; the integration record can show exactly which edition and interpretation the display uses. Neither should silently convert a historical figure into a current airport record.

Conclusion

The central answer to FAA circling icon removal is a source-and-meaning check. The transition gives ground-reference owners a concrete reason to inspect any rule that still treats icon appearance as a current criteria classification. The effective FAA legend explicitly permits users to ignore symbol presence, while the documentary comparison exposes why an old explanatory mapping may remain visible elsewhere. ^[2]

The first deliverable should be a documented finding about the operator's actual display and dependencies. If no rule uses the symbol, record that result. If one does, identify the supplied field, preserve its raw state, match its procedure revision and source edition, and obtain the provider's interpretation. Check the installed product's native controls before specifying additional software.

Where clarification is unresolved, use a precise source/contract exception with a responsible owner. Keep chart appearance, design-reference evidence, published minima and notes, and operator-approved applicability distinct. A field that is missing, explicitly unknown or absent should retain that distinction through ingestion and display. Versioned provenance makes the resulting assertion explainable. ^[6]

The synthetic fixture provides a reviewable starting point: symbol-present and symbol-absent records with identical confirmed references should remain equivalent, while edition, revision, jurisdiction and parser mismatches should remain visible. The worksheet produces source ages and review counts only. Decisions about procedure design, operating minima, equipment suitability and flight authorization remain with the applicable authorities, contracted providers and operator-approved processes.