FAA Holdover Time Tables 2026-27: Release Control Checklist

Executive Summary

The FAA's winter 2026-27 ground deicing package was issued in two steps: Notice N 8900.784 on 3 August 2026, which replaces the 2025-26 notice ^[1], and the Holdover Time (HOT) Guidelines, regression information and Degree-Specific Holdover Time (DSHOT) database, which carry an "Original Issue" date of 11 August 2026 ^[2]. For a US operator, the practical question is not which holdover time applies. It is whether the approved edition reached every authorized display, ground record and offline cache in a form that can be proved after the fact.

The authority chain matters for that proof. Under 14 CFR 121.629(c), an approved ground deicing/anti-icing program must sit in the operations specifications ^[3], and holdover times must be supported by data acceptable to the Administrator ^[3]. The FAA's own documents describe themselves as guidance that is not legally binding on its own ^[4], and the notice tells inspectors only to recommend that the applicable tables be incorporated into operator programs. The HOT Guidelines also place the duty to check for updates on the end user. A software team therefore inherits an evidence problem, not a computation problem.

This brief proposes a source-to-deployment release ledger: one row per source file, revision, extraction hash, reviewer, acceptance case, deployment target, acknowledgement and retirement date. It draws on the FAA's statement that reformatting DSHOT data can compromise integrity and that a record of verification should be kept, on the EFB guidance that crews should be able to confirm database revisions and dates, and on NIST guidance that cryptographic hashes can accompany release files ^[5]. A SHA-256 digest proves that bytes match, and nothing more ^[6]. Table content review by authorized specialists remains the control that matters most.

On the buy-versus-bridge decision, vendors such as No-ICE, sQRH and APS say on their own pages that they provide annual season updates (vendor claims, not independently verified here) (Source: feel.aero) ^[7], but one vendor claims that neither Transport Canada nor the FAA certifies or approves holdover apps ^[7]. A supported tool is the better default when the vendor can answer the acceptance questionnaire in this report with documents. A local data bridge is defensible only when the operator owns the extraction review, the version display and the retirement date. Transport Canada publishes a separate 2026-27 edition by request ^[8], so FAA evidence cannot be reused across the border. This brief is a data-governance analysis, not operational guidance, and it reproduces no holdover values.

Introduction and Background

Winter deicing data has an unusual release profile. A new FAA edition appears once a year, typically in early August, and the FAA states that updates may follow at any time ^[2]. When a new document is published, the previous one becomes obsolete. The consumers are not one database but a spread of places: crew electronic flight bag (EFB) applications, dispatch and operations control (OCC) references, ground-crew procedures, training material, printed fallback binders and archived records. Each can hold a different edition for weeks, and nothing in the FAA package tells an operator which have been updated.

The audience is the group that owns the gap: EFB and data leads, safety managers, directors of operations and the IT staff who support US Part 121 and Part 135 operations. The scope is the United States, with a short cross-border caution, and the report covers FAA publications, 14 CFR, FAA advisory material and the vendor documentation operators meet when deciding whether to buy a supported tool or bridge a local data handoff.

What this report does not do is equally important. It does not tell anyone how to choose a holdover time, it does not evaluate a cockpit calculator, and it does not claim that any custom application is approved for operational use; approval belongs to the operator's FAA oversight office under the operator's own program. Disclosure: this brief is published by LANDING.AERO, a Montreal custom flight operations software studio that holds no design approvals.

The analytical question is narrow: when the FAA publishes a new season or a mid-season revision, what evidence shows that the source document, extracted tables, fluid identifiers, footnotes and deployed versions match?

Key Changes in the 2026-27 Source Package

Change 1: A new notice and a new authority chain

Notice N 8900.784 states that it replaces N 8900.747, the Winter 2025-26 notice, and the FAA record page lists it as an active notice issued on 2026-08-03 by Flight Standards office AFS-200. The notice states that it is designed to be used together with the HOT, DSHOT, regression data and allowance time guidelines ^[1]. Its audience is inspectors: the Principal Operations Inspectors responsible for approving an air carrier's deicing program. It cites 14 CFR 121.629(c), 125.221(b) and 135.227(b)(3) as the regulatory context.

For an operator, a useful reading of the hierarchy has six layers. The regulation comes first. The operator's approved program in its operations specifications ^[3] comes second. The annual FAA notice, which is inspector-facing, comes third. The FAA HOT Guidelines and companion files come fourth. The operator's manuals and EFB program documents come fifth. The software display comes last. A display is evidence that an operator followed its program only if each layer above it can be traced.

The regulation itself keeps the operator's tables inside the program. Section 121.629(c)(3) requires "the certificate holder's holdover timetables" and the procedures for using them ^[3], and it defines holdover time as beginning when the final fluid application commences ^[3]. The FAA's Advisory Circular (AC) 120-60B, which describes one means but not the only means of obtaining approval, says the FAA develops HOT tables for Type I fluid and for generic Type II and Type IV fluids ^[9]. The ledger therefore needs a column showing which FAA edition the operator's approved timetables derive from, so that "the operator's table" and "the FAA table" are not treated as the same object.

Part 121, 125 and 135 are structured differently. Section 135.227(b) offers three routes, and route (b)(3) is an approved deicing/anti-icing program that complies with 121.629(c) ^[10]. Part 125 mirrors that structure in 125.221(b) ^[11]. Part 121 also provides for operation without a full program under a pretakeoff contamination check, which must be conducted within five minutes before beginning takeoff ^[3]. Each operator should confirm in its own operations specifications which route applies to each fleet and operation. This brief does not state an operations specification paragraph number for the deicing program.

Change 2: A manifest of files, not one table

The FAA hub for 2026-27 lists a General Information document, Holdover Times Tables (Word and PDF), Regression Information (Word and PDF) and a DSHOT database (a spreadsheet), each labelled "Original Issue". No separate allowance-time file appears in that list; allowance times sit inside the HOT Guidelines. Each file has its own edition marker. The HOT Guidelines cover reads "Original Issue: August 11, 2026", while the General Information document is "Issue 4", its record of revisions showing a release on 08/11/26. A ledger that records only "2026-27" collapses five distinct edition labels into one.

Table 1 below summarizes the manifest as observed on 20 October 2026, with the identification fields a ledger needs. It lists the FAA's own edition markers and says nothing about content values.

The table shows that "the FAA table" is a set of files with independent edition labels, some of which an operator may not adopt. A ledger row per file records which files the operator adopted and which it excluded, and the exclusion is itself evidence.

Change 3: Seasonal and in-season revisions

The HOT Guidelines state that a new version appears each season and describe a subscription route for update notifications. As of 20 October 2026, the hub lists only "Original Issue" entries for the 2026-27 files, so no in-season revision is listed. A ledger should therefore include a recurring check recorded with a date and the name of the person who performed it, not a one-time conclusion. Sidebars in the FAA files mark added, deleted or modified text; they are a review aid, not a complete change list, so a full-document comparison remains necessary.

Change 4: What changed in the content structure for 2026-27

The 2026-27 HOT Guidelines add fluid-specific tables for four new fluids ^[2] and remove the guidelines for one fluid. The regression document records matching changes. Additions and removals are the highest-risk class of change, because a mapping table keyed on fluid name can silently retain a fluid that no longer has guidelines, or lack one that now does.

Names are the next risk. Fluid names appear in several documents and the strings are not always identical; in the FAA files, some company-name suffixes are shortened between the HOT Guidelines and the regression tables. That is ordinary publishing variation, but a mapping table should store a stable internal fluid identifier alongside each source spelling, and acceptance cases should include every variant.

Mapping Questions: Fluids, Dilution, Conditions, Footnotes and Blank Cells

Fluid identity and type

The HOT Guidelines are divided by fluid type (I, II, III and IV), by aircraft construction material for Type I only, and by fluid brand for Types II, III and IV ^[2]. SAE International specifications define the fluid families: AMS1424 covers Type I fluids ^[12], and AMS1428 covers Types II, III and IV with initial qualification, site or unit qualification, periodic requalification and lot acceptance in scope ^[13]. SAE AS6285 ties the ground process to fluids qualified to those two specifications ^[14]. Manufacturers publish named products with a type and a statement of conformity, for example a Type IV product page stating that it meets or exceeds the current revision of AMS 1428 ^[15] and a Type I page stating qualification to AMS 1424 ^[16].

The mapping question for software is whether a fluid is identified on the display by the same brand and type the applicator reports. The General Information document tells applicators to inform the air carrier and flight crew of the specific fluid name applied. A mapping table should be reviewed against the fluid-list tables in the HOT Guidelines, which carry the fluid name, glycol type, expiry and dilution fields. The expiry field is a data element with a date and therefore needs a retirement rule.

Dilution

Manufacturers describe fluids as applied neat or diluted ^[15], and the first footnote of the active frost table requires confirming that the fluid and dilution in use is listed in the fluid-testing tables ^[2]. Dilution is therefore part of the identifier, and a ledger acceptance case should exist for each fluid-and-dilution key the tool exposes and each key it deliberately hides.

Conditions, footnotes and cautions

The tables are arranged with precipitation categories across and temperature and dilution down, each with its own numbered notes, and section-wide cautions sit on flysheets before each section. The flysheets state that responsibility for application of the data remains with the user, and the FAA says flight crews should not determine HOTs for mixed icing conditions unless procedures are supported by acceptable data. A mapping review must therefore check the existence of each category as well as each cell, because a display that offers a condition the table does not cover is a mapping defect even if every offered cell is right. Footnotes are part of the data: acceptance cases should confirm that, for each tested cell, the associated note numbers are reachable in the same view or one step away, as the operator's program specifies.

No-value cells

The FAA tables express absence in more than one way. A cell can state that no holdover time guidelines exist for the condition ^[2], and other cells use placeholders or "not tested" notes. A software team that stores a blank, a null or a zero for these states loses the difference between "the FAA says no guideline exists", "the manufacturer did not test" and "the extraction failed". The ledger's extraction hash should cover a normalized export that preserves each of these states as a distinct token. An acceptance case for each token is cheap and catches the most dangerous class of transformation error.

Allowance times and derived data

Allowance times are gated by a validation-status table, and the General Information document says operators may use them only with a deicing program updated to include them. The DSHOT database is published as a spreadsheet that the FAA describes as impractical for direct use in its published format, and any presentation should be updated annually or whenever the database is updated. Regression information says developers must still build comprehensive verification and validation.

Implementation Considerations and Process Changes

Extraction review and two-person release evidence

The FAA gives the clearest statement of expected review. When DSHOT data are reformatted, data integrity can be compromised, so a detailed verification by manual check against the most recent FAA publication is called for ^[4], and a record of the verification should be kept and maintained. The FAA does not prescribe a hash, a tool or a two-person rule. Those controls come from software practice. NIST's Secure Software Development Framework lists, as examples, posting cryptographic hashes for release files ^[5], securely archiving release files with their integrity data ^[5] and having the code owner review and approve changes ^[5].

A workable evidence pattern has five steps:

• Capture. Download the FAA file from the hub, record the retrieval time and the hub's last-updated date, and compute a SHA-256 digest of the exact bytes received.
• Extract. Produce the structured tables with a documented procedure, and compute a second digest over a normalized export that preserves no-value tokens and footnote identifiers.
• Review one. An authorized specialist compares each table, fluid identifier, footnote and no-value cell against the source, using the FAA's own minimum checks for derived data as a pattern.
• Review two. A second person who did not perform the extraction signs the acceptance-case results, so no single reviewer both builds and approves the release.
• Approve and archive. The release is archived with its source file, digests and review records, and its identifier is entered into the ledger.

NIST's hash standard defines the algorithm family used in such digests ^[17], digests are used to detect whether messages changed since they were generated ^[6], and conformance to the standard does not by itself assure a secure implementation ^[17]. The FAA documents do not require a specific digest or hash ledger. The ledger is a control the operator chooses, and its value lies in making the comparison cheap and repeatable.

Distribution, offline caches and client versions

The FAA's EFB advisory material is the closest primary guidance on distribution. AC 120-76E describes operators obtaining A061, the Electronic Flight Bag program authorization, and lists icing holdover time tables among Type B EFB applications. The AC says the EFB program catalog is how the operator maintains configuration management of program elements ^[18], that changes to application software and settings should be controlled and tested, and that updates should include system verification. Crews should be able to confirm revision numbers or dates for each flight ^[18], and the loaded revision cycle should be readily evident. Changes to the catalog should be retained for at least three months, per the AC's stated figure. Updates of Type B applications are treated as minor modifications the operator may incorporate under its authorization.

Manuals add a parallel obligation. A Part 121 electronic manual must display its date of last revision so a person can immediately ascertain it ^[19], and each person furnished a manual must keep it current ^[20]. Part 135 requires the certificate holder to keep its manual current ^[21] and its appropriate parts accessible to personnel ^[21].

For a deployment, these requirements translate into five questions per target:

• Displayed edition. Does the screen show the FAA edition label and date, not only an app version?
• Offline behavior. What does a device that was offline during the release window show?
• Acknowledgement. Who or what acknowledged that the target holds the new edition, and when?
• Retirement. What rule removes the prior edition, and what evidence shows it was removed?
• Fallback. Which printed or PDF source is the fallback, and is it from the same edition?

The last question tracks FAA language: electronic devices that determine eHOTs may be used as part of the operator's winter operations plan submitted for approval, and printed tables sourced from the FAA guidelines are the fallback if the user has any concern about displayed accuracy ^[4]. Fallback material needs the same edition control as the primary display.

Rollback and replay

Rollback in this domain does not mean returning to the last season's data. The previous FAA document becomes obsolete when a new one is published. Rollback therefore means reverting to the last-known-good build of the same edition, or to the fallback source, and the ledger should state which. Replay means reconstructing, after the fact, what a target displayed on a given date.

The Update Framework, an open specification for secure software updates, gives fitting vocabulary: its clients must not replace a trusted metadata file with a lower version ^[22] or trust expired metadata ^[22], and it names rollback and freeze attacks as threats it addresses ^[22]. SLSA describes verifying artifacts by checking the signature on a provenance envelope (Source: slsa.dev). These are software-supply-chain references, not aviation requirements, but they show that a signed edition with rollback protection is a recognized design pattern and supply questions a vendor should be able to answer. The ledger records the build identifier, the data edition and the signing evidence, so a replay can name all three. Retention should follow the operator's records program; the three-month catalog figure in AC 120-76E is guidance, and an operator may keep deicing data records longer.

Vendor acceptance questionnaire versus custom bridge

Selecting a commercial application is outside this brief; what the operator needs is a standard set of questions that makes any vendor's release practice comparable. Vendors document different things, and each statement below is a vendor claim:

• Edition labelling. No-ICE states that its product carries the Winter 2026-27 edition of FAA and Transport Canada tables (Source: feel.aero), and an App Store release note for sQRH states that the holdover data were updated to the new season for both sources ^[23].
• Update and offline behavior. APS states that mid-season authority updates trigger an update of the current-winter app ^[7] and that no internet connection is required to obtain holdover data ^[7].
• Version consistency. No-ICE states that sharing works only between devices carrying the same table season (Source: feel.aero), and sQRH states that paired devices must use the same aircraft and QRH version ^[23]. sQRH also describes a versions module that checks for newer versions (Source: feel.aero).
• Verification and approval posture. APS states it undertakes a process to verify all data in its app ^[7], No-ICE states that the approval belongs to the operator, not the app (Source: feel.aero), and sQRH describes itself as a reference tool whose operational use depends on airline EFB policy (Source: feel.aero).

The operator should ask for the documents behind such claims. A seven-question acceptance questionnaire, answered in writing and filed with the ledger, is the core of the buy decision:

• Source edition. Which FAA files and issue labels does each release contain, and is the label visible in the interface?
• Source hash and extraction review. Can the vendor give the digest of the FAA file it used, and who reviewed the extraction?
• Mapping. Does the vendor keep a mapping from FAA fluid spellings to its own identifiers, and is it provided?
• Mid-season revisions. How quickly and through what channel does a mid-season FAA revision reach installed clients?
• Signed edition and rollback. Are releases signed, and can a client be forced to a known-good build?
• Expiry and retirement. What does the app do when the edition is superseded or the device has not updated?
• Evidence export and customization. Can installed versions be exported per device, and is any content removal recorded as a deviation from the FAA edition?

Table 2 compares the options on the dimensions a ledger owner cares about. It describes categories of option, not product rankings.

An App Store listing for a 2026-27 holdover app shows how vendors present edition labels publicly ^[24]. Table 2 shows that the decision turns on who owns verification. A supported application moves some extraction and update work to the vendor but not the operator's obligations. A bridge moves the work to the operator, along with the need for the same ledger. The bridge is a data-handoff mechanism and is not a calculator or an approved application. If an operator wants a computing tool, the established-vendor category is the appropriate route, and any authorization still runs through the operator's FAA oversight office.

Data Analysis and Evidence

The quantitative core is a set of dates, counts and retention figures that a ledger can hold as fields. No holdover values or calculations are included.

Timeline of the 2026-27 package. The 2025-26 notice N 8900.747 expired on 1 August 2026, as stated in its replacement. Notice N 8900.784 was issued 3 August 2026. The HOT Guidelines carry an Original Issue date of 11 August 2026, eight days after the notice. Three dates therefore exist for one season: a notice date, a file issue date and an operator deployment date. A ledger that stores only the first two cannot prove the third. Transport Canada's separate 2026-27 edition is also dated August 11, 2026 on its page ^[8], which shows how similar dates can attach to different documents.

Size of the artefact. The HOT Guidelines run to 91 pages according to the PDF footer, and No-ICE states that its current edition holds 56 tables per authority (Source: feel.aero). A page-count or table-count mismatch between source and extraction is a cheap reason to stop a release before any cell is compared, though a matching count does not prove correctness.

Retention and expiry figures. AC 120-76E gives three months as the retention figure for catalog change records. APS states a hard app expiry on 1 November of the year after the winter. Transport Canada's advisory circular requires that eHOT data intended for operational use be current ^[25] and that apps not allow expired data to be used ^[25]. ICAO's store offers Doc 9640 with digital access valid for five years from purchase (Source: store.icao.int), a reminder that some reference documents carry licence terms rather than a single edition.

Illustrative checksum comparison. Table 3 below uses dummy strings and is not derived from any FAA file. It shows the behavior a ledger relies on: the digest of the input changes completely when a single character changes. The values are the SHA-256 digests of the stated sample strings, truncated to sixteen hexadecimal characters for display.

Table 3 shows why digests belong in the ledger, and their limits. A matching digest says two byte sequences are identical, not that they are the correct FAA edition or that an extraction preserved the source. Two digests are needed: one over the exact source file and one over a normalized export of the extracted tables. Comparing the second across the build server, the vendor package and the deployed device shows whether every target holds the same extracted content. A mismatch triggers the human review described above and never computes or alters a holdover time.

Release Ledger Template and Sample Acceptance Cases

The ledger turns the process into records. Table 4 shows the proposed columns with example rows. Every value in the example rows is illustrative, uses placeholder identifiers, and contains no operational holdover values.

The columns work as a chain: source file and revision fix the input, the hash fixes the transformation, the reviewers fix accountability, the test cases fix coverage, and the target, acknowledgement and retirement fields fix the output. If any column is empty, the chain cannot show a match between document and deployment.

The sample acceptance cases below are illustrative templates with no operational values; authorized specialists choose the specific fluids and conditions.

• AC-01 Edition label. The display shows the FAA edition label and date exactly as the source cover states them, matching the ledger row.
• AC-02 Fluid coverage. Every fluid-and-dilution key in the source fluid-list tables appears in the tool's mapping, and no key appears that is absent from the source.
• AC-03 Spelling variants. Each source spelling of a fluid name resolves to one internal identifier.
• AC-04 Added and removed fluids. Each fluid the season's Highlights list as new is present, and each listed as removed is absent or shown with the source's removal statement.
• AC-05 No-value tokens. One cell of each no-value type (no guideline exists, not tested, not applicable) shows a distinct message, never a blank or zero.
• AC-06 Footnotes and cautions. For a sample of cells with footnotes, each note resolves to its text in the same view or one step away, and flysheet cautions are reachable.
• AC-07 Condition categories. The precipitation and temperature categories offered equal those in the source for the selected table.
• AC-08 Allowance-time gating. Allowance-time content appears only where the source and the operator's program allow it.
• AC-09 Offline and stale device. A device that missed the update displays a clear stale-edition state, not the prior edition without warning.
• AC-10 Rollback. A forced revert to the last-known-good build shows the same edition label and passes AC-01 to AC-09.
• AC-11 Document library. Each General Information copy in the OCC and training libraries matches the ledger.
• AC-12 Derived data. For any derived dataset, the minimum manual checks the FAA lists for DSHOT reformatting are repeated and recorded.

Two-person evidence means the person who ran each case and the person who approved the result are different individuals, both named in the ledger. Cases are re-run for every table an in-season revision touches.

Implications and Future Directions

For software teams. The FAA publishes its HOT data as documents that describe themselves as non-binding on their own. The enforceable layer is the operator's program and the requirement that holdover times be supported by acceptable data ^[3], so software cannot claim authority of its own; it can make the chain from document to display auditable.

For cross-border operators. Transport Canada publishes its own annual edition and says it sometimes publishes a revision in the same year ^[8]. Its guidelines are provided by request through a form requiring an e-mail address, and its regression information is a separate request item ^[8]. The page describes its purpose as helping flight crews make ground decisions ^[8], and older editions are archived as no longer used ^[8]. Its advisory circular for electronic holdover applications asks for checksums on electronically transferred files ^[25], a manufacturer declaration that verification and testing show compliance ^[25], and states that using an eHOT does not relieve the operator's responsibility ^[25]. A fluid supplier's resource page lists the FAA and Transport Canada charts as separate references ^[26]. The two publications are under separate access terms, so contents and permitted uses should not be assumed to match, and an operator with US and Canadian operations needs separate ledger rows and rights checks. The Transport Canada page footer date should not be treated as an edition indicator ^[8]. Canadian regulatory analysis is out of scope here.

Future directions. A machine-readable FAA release with a published digest and change log would let operators automate the first ledger steps, and a standard fluid identifier across the FAA files would remove spelling reconciliation. Neither exists in the FAA files described here, and neither should be assumed. ISO 11078 for Type II, III and IV fluids places responsibility for limitations on the operator ^[27]. RTCA DO-200B covers the processing of aeronautical data ^[28], and EFB guidance recommends it for database quality, but this brief does not assert that it applies to deicing tables, so operators should confirm applicability with their oversight office.

Frequently Asked Questions (FAQs)

Did the FAA update the holdover time tables for 2026-27? Yes. Notice N 8900.784 replaced the 2025-26 notice, and the HOT Guidelines were issued on 11 August 2026 with changes listed in a Highlights section, including four new fluid-specific tables. As of 20 October 2026 the hub lists only original issues.

What do FAA holdover time guidelines for winter 2026-27 consist of? The package consists of the notice, the HOT Guidelines with allowance times, General Information, Regression Information and the DSHOT database, and the notice says it is used in conjunction with these materials.

What is holdover time data release control? It is the practice of recording the source file, edition, extraction hash, reviewers, tests, deployment targets, acknowledgements and retirement dates for each release, as in the ledger above. It is an operator-chosen control, not an FAA-mandated format, and an in-season revision adds a ledger row, a diff against the prior issue, re-run tests and a retirement date for the superseded file.

Does an aircraft deicing holdover time calculator need to be approved? This brief does not decide that. The FAA says eHOT devices may be used as part of a winter operations plan submitted for approval, and one vendor states that neither the FAA nor Transport Canada certifies or approves holdover apps. Operators should confirm with their FAA oversight office.

How should flight operations software handle deicing data updates? Treat each edition as a controlled release: display the edition label, keep the program catalog current, maintain a same-edition fallback and record acknowledgements per target.

Do Type I, II and IV tables update separately? The types share one document, but fluid-specific tables can be added, changed or removed independently, as the 2026-27 Highlights show, so test cases should be organized by fluid key.

Conclusion

The FAA's 2026-27 deicing package gives operators authoritative documents with clear dates and leaves the proof of distribution to the operator. The notice, HOT Guidelines, General Information, regression information and DSHOT database each carry their own edition markers, and the guidelines place the duty to check for updates on the end user. The regulations require an approved program supported by acceptable data, and the EFB and electronic-manual guidance asks that crews can see which revision is loaded.

A source-to-deployment release ledger addresses the gap between those statements. It ties each FAA file and revision to an extraction digest, two named reviewers, acceptance cases, deployment targets, acknowledgements and retirement dates, and it treats fluid identifiers, dilution keys, footnotes and no-value cells as first-class data, because those are where transformations lose meaning. Digests prove that bytes match, not that content is correct; review by authorized specialists remains the control that cannot be automated away.

For the buy-versus-bridge decision, the test is documentary. A supported tool is preferable where the vendor can answer the questionnaire with records, and a custom bridge is appropriate where the operator accepts ownership of extraction review, version display and retirement. Neither route confers approval, which rests with the operator's program and its FAA oversight office, and operational decisions remain governed by the operator's approved procedures, manuals and operations specifications.