FOQA flight data monitoring that validates every event by morning and keeps every crew anonymous
Every flight data event validated by morning, explained plainly, crews kept anonymous.
See one case, screen by screen ↓FOQA flight data monitoring is an airline's routine analysis of the data its aircraft record on every flight, to find exceedances such as unstable approaches and hard landings and act on them before they become accidents. Flight Data Monitoring (FOQA) is FOQA software that puts eight agents on that work: they validate every exceedance against redundant sensors, explain each real event in plain words with every clause cited, link voluntary reports without names and find trends against baselines. The FOQA analyst confirms each event and decides which trends go to the Safety Review Board; the gatekeeper alone holds crew identity.
How to choose AI for airlines: a buyer's guide to agentic AI solutions →
Updated
FOQA flight data monitoring starts every morning with a list. Each aircraft records hundreds of parameters on every flight, and the event library turns last night's flights into a few hundred exceedances: unstable approaches, hard landings, flap overspeeds, TCAS resolution advisories, low tail clearance on rotation. Many are not real — a radio altimeter that jumps to zero for a second, a lost data frame, a check flight, the wrong parallel runway. The real ones say what the airplane did, not why. Exceedance analysis is still done by hand: the FOQA analyst replays and validates them one by one, then goes looking for the ATIS, the METAR and the clearance to find the context.
The rest of the flight data analysis program sits in other hands. A union-appointed gatekeeper is the only person who may link an event to a crew, and ASAP and FOQA run as separate programs: voluntary ASAP reports stay with their own Event Review Committee, so the analyst looks for a matching report by hand, and a pilot's report and the trend that matches it are often read by different people. Meanwhile the precursors are in the data: about 97% of unstable approaches are continued to a landing, and one airline put a single tail strike at $12 million. Found late, a trend becomes an event.
Estimated split of one analyst's morning on a night like the demo's 214 events, by hand and with the solution.
Eight agents validate, explain, link and trend every flight data event; the FOQA analyst decides and the gatekeeper alone holds crew identity.
Corvane Airways flies 304 aircraft from its DEN hub. On Wed 14 Oct at 23:47 PDT, CV 1910 from Chicago, a 737-9, lands on SEA runway 16R at night. Here is what happens next in the working solution, screen by screen.
Elise opens Today: overnight the agents read 1,388 flights, found 214 events, cleared 37 that were data errors or duplicates, counted 151 small ones to trends and left 26 for a person — 9 Level 3 and 17 Level 2. The lead item is CV 1910 into SEA, and beside it the agents talk to her in plain words: the Event validator on what it cleared, the Trend finder on a new trend, the Validation checker on an event it disagrees about.
“CV 1910 into SEA last night: unstable at 500 ft with an 11-knot tailwind.”
“How they worked overnight” shows every step in order. The Flight data reader decoded 1,388 flight files from 296 aircraft; the event library found 214 events; the Event validator cleared or corrected 37; the Validation checker re-checked all 9 Level 3 events and a 5% sample, and disagreed on LK 3318; the Event explainer wrote 26 explanations; the Report linker proposed 5 links; and at 05:40 the Trend finder raised T-26-019.
“From the first file at 00:12 to the trend at 05:40. Every step is on the audit trail.”
The event replay puts height, airspeed, sink rate and tailwind on one axis from 5 nm to touchdown, with the 1,000 ft and 500 ft gates and the window where the approach was not stable. At the 500 ft gate: 171 kt (+19 over the target of 152), 1,240 ft/min, 1.6 dots high, an 11-knot tailwind, gear down and flaps 30. She can press Play or jump to any gate. The crew shows only as “Crew sealed · gatekeeper only”.
Level 3 events always need a person. Clock: decide by Fri 16 Oct 00:40, 24 hours after the data arrived.
The Event explainer writes the cause chain, each clause cited to its source: cleared for the visual at 9 nm and 5,000 ft, about 2,100 ft above a 3° path; a tailwind nearly twice the 6 kt surface wind on the ATIS; landing flaps only at 1,180 ft; stable at 310 ft; touchdown 2,640 ft past the threshold. Below it, the Event validator's checks: both air data computers agree within 1 kt, both radio altimeters and GPS height within 5 ft, 16R matched to the track and 16C ruled out, no lost frames, a revenue flight. Valid at 97%.
“The flight data shows what the airplane did; it never says who flew it or why they decided.”
Elise asks the agents in the conversation beside the replay. The Event explainer answers within the limits of the data: the approach was not stable at 500 ft, the company manual calls for a go-around, and across the industry about 97% of unstable approaches are continued. For the crew's reasons it offers to draft a request for the gatekeeper, with the crew still sealed.
“The flight data cannot say what the crew decided or why.”
Data quality shows why each of the 37 was cleared: 12 radio altimeter spikes, 9 lost data frames, 6 air data or attitude spikes, 2 ground runs, 1 maintenance check flight, 4 runway corrections and 3 duplicates. Each clearance carries its evidence — on CV 1207, a pitch rate of 14°/s on rotation came from one attitude source for one sample while the other read 3.1°, so the validator cleared it as a data spike at 95% confidence. Six radio altimeter jumps are one 737-8, aircraft A-0143, so it proposes sending the fault to maintenance: the aircraft, never the crew. Elise can restore any clearance to review or accept it with the others.
“One sample on one source, nothing on the other or in vertical g: a data spike, cleared with 95% confidence.”
Trend T-26-019 overlays the 11 approaches: 11 of 212 night arrivals on 16R, 5.2% against 1.1% across the network, 4.7 times. All 11 had a late visual clearance on the arrival from the north and were not stable until below 500 ft; 9 of 11 had a tailwind of 8 kt or more. Two ASAP reports describe the same thing — “ATC kept us high on the arrival from the north” — matched on airport, runway, hour and fleet, never on who wrote them.
“The ASAP program keeps the reports and the reporters' names.”
Confirming adds CV 1910 to the program's record and to its trend. Elise chooses V1, valid as detected — the other choices are V2, level changed, and V3, merged — adds a note if she wants, and signs electronically. The crew stays sealed; no agent can mark a Level 3 valid or invalid.
“I confirm this event as Elise Navarro, FOQA Analyst — electronic signature.”
Elise sends T-26-019 to the Safety Review Board meeting on Tue 20 Oct at 09:00 with reason S1, a trend beyond its baseline with reports. The decision package carries the trend, its baseline, the 11 approaches de-identified, the 2 linked reports and three proposed mitigations: a pilot briefing for 737 and A321neo pilots, a request through the ATC liaison to Seattle approach about late visual clearances, and a company approach brief item for tailwinds above 10 kt. The Identity guard checked it: no flight numbers or dates.
“The board decides; owners act; the agents measure for 90 days.”
The Briefing writer drafted B-26-07, “Night arrivals to SEA runway 16R with a tailwind”, for 737 and A321neo pilots, 2,240 and 610 of them. Before it reached Capt. Brandt, the Identity guard removed three details and said why: “CV 1910 on 14 Oct” became “one of our night arrivals”, because a flight number and a date together identify a crew. He can edit it or ask the writer to change it, then approves and publishes it with his signature.
“A go-around from an unstable approach is the expected outcome here, never a mark against you.”
The same night's flight data, seen by five of the people who carry it — what their week looked like, and what it looks like now.
Eight agents validate, explain, link and trend every flight data event; the FOQA analyst decides and the gatekeeper alone holds crew identity.
Takes each flight file from the ground data link or a card download, decodes it with the fleet's frame layout, checks completeness and time alignment, and matches it to the scheduled flight — with the crew sealed.
Does the FOQA event validation: tests every exceedance against the redundant sensors — both air data computers, both radio altimeters, GPS height — the runway and phase, the schedule, check flights, ground runs and duplicates, and grades its level.
Re-checks every Level 3 event and a 5% sample of what the validator cleared, on the same sources, and says so when it disagrees.
Writes each valid event's cause chain in plain words, every clause cited to a trace sample, the ATIS, the METAR, a NOTAM or the clearance on the track.
Matches ASAP and other voluntary safety reports to events and trends on what they share: airport, runway, hour, fleet, phase and words.
Rates events by airport, runway, hour, fleet and phase against their own baselines, raises a trend only when the difference is beyond ordinary variation, and measures each mitigation the board approves.
Drafts Safety Review Board submissions, pilot briefings and evidence packages for the FAA aggregate submission from confirmed events and trends.
Checks every screen and every outbound file — briefings, board submissions, FAA submissions, exports — for combinations that identify a crew, such as a flight number with a date, and removes them, explaining each removal.
Confirms each event; the gatekeeper alone links a crew. The agents propose; a named person decides.
Every screen carries a conversation with the agents about what is on it. They answer with their sources, sort or pre-select when asked, and open a decision — but the reason code and the signature stay with a person.
What should I look at first?
CV 1910 into SEA: a Level 3 unstable approach with a tailwind, the 11th on 16R at night in 30 days. Then LK 3318, where my checker and validator disagree, then the BOS hard landing, which needs a maintenance inspection.
Why did you clear 37 events?
30 data errors: 12 radio altimeter jumps, 9 lost data frames, 6 air data or attitude spikes, 2 ground runs, 1 check flight. 4 were measured on the wrong parallel runway and re-run; 3 were duplicates. Six of the radio altimeter jumps are one 737-8, aircraft A-0143: I propose a maintenance write-up.
Is the tailwind real or a sensor?
Real. It is ground speed minus true airspeed along the runway: 11 kt at 500 ft, while the ATIS gave 6 kt at the surface. Both air data computers agree within 1 kt.
Are we going around when we should?
Not often enough. 31 of every 1,000 arrivals were unstable at some gate this quarter, and 14% of those were flown as a go-around. The industry figure is about 3%, so we are better than most, below our own target of 20%.
14 screens from the working solution, on its sample data. Pick one to see it large.
Event thresholds — the stable approach criteria behind unstable approach monitoring, hard and long landings — identity rules, clocks and agent autonomy are settings. Changes are versioned and logged, and threshold changes need the FOQA Monitoring Team.
| Setting | Default | Choose from |
|---|---|---|
| Stable approach gate in visual conditions | 500 ft | Step 100 ft at a time; the 1,000 ft gate in instrument conditions is fixed by the manual |
| Speed above target | Target −5 / +10 kt | Step 1 kt at a time |
| Hard landing, Level 2 / Level 3 | 1.6 g / 1.8 g | Step 0.05 g at a time |
| Long landing, Level 2 / Level 3 | 2,500 ft / 3,000 ft past the threshold | Step 100 ft at a time |
| Clear data errors without review | On — Level 1 and 2 only, at 95% confidence or more | On · Off |
| Level 3 events always go to a person | On | Locked: no agent marks a Level 3 valid or invalid |
| Delete identifying data after a contact closes | 10 days | Set by the FOQA agreement |
| Level 3 event decided within | 24 hours | Level 2 within 72 hours; gatekeeper contact answered within 72 hours |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published figures (Flight Safety Foundation go-around decision-making project — about 97% of unstable approaches continued to a landing; Boeing AERO, “Preventing Tail Strikes” — $12 million for one tail strike). Regulations named as context: FAA AC 120-82 (FOQA), 14 CFR 13.401 (FOQA data and enforcement), 14 CFR 5.71 (safety performance monitoring). Corvane Airways, Larkspur Air and the people named on this page are fictional — characters and sample data in the working solution.
FOQA flight data monitoring is an airline's routine analysis of the data its aircraft record on every flight, to find exceedances such as unstable approaches and hard landings and act on them before they become accidents. Flight Data Monitoring (FOQA) is FOQA software that puts eight agents on that work: they validate every exceedance against redundant sensors, explain each real event in plain words with every clause cited, link voluntary reports without names and find trends against baselines. The FOQA analyst confirms each event and decides which trends go to the Safety Review Board; the gatekeeper alone holds crew identity.
They name the same practice. FOQA, Flight Operational Quality Assurance, is the FAA's term (AC 120-82); flight data monitoring (FDM) is the wider industry name, and ICAO calls it a flight data analysis program (FDAP). The solution works the same way whichever name your program uses.
The Event validator tests every exceedance against both air data computers, both radio altimeters and GPS height, matches the runway to the track, and checks for lost data frames, check flights, ground runs and duplicates. It clears Level 1 and 2 data errors only at 95% confidence or more, each with a reason the analyst can reverse. The Validation checker re-checks every Level 3 and a 5% sample, and a Level 3 is always decided by a person.
The FOQA gatekeeper is the only person who can link an event to a crew. Crews are sealed from the moment a file is read, and screens show “Crew sealed · gatekeeper only”. Each reveal needs a reason code and is reported to the FOQA Monitoring Team and the union safety chair, and the link is deleted 10 days after the contact closes. The Identity guard checks every outbound file for combinations such as a flight number and a date, and removes them.
Under 14 CFR 13.401, except for criminal or deliberate acts, the FAA will not use an operator's FOQA data, or aggregate FOQA data, in an enforcement action against that operator or its employees when the data comes from an FAA-approved FOQA program. In the solution, an event that may fall outside that protection goes to the FOQA Monitoring Team with the union safety chair — no agent and no single person decides it — and published briefings state that the program cannot be used to discipline any pilot.
The Report linker matches voluntary reports to events and trends on what they share — airport, runway, hour, fleet, phase and words — and shows the match reasons and a score. The analyst sees that a report exists and what it says, never who wrote it, and the ASAP program keeps the reports. Each link is a proposal until a person confirms it.
Yes. The FOQA analyst confirms or rejects each event with a reason code and an electronic signature and decides which trends go to the Safety Review Board; the board decides mitigations and owners; a fleet technical pilot approves each briefing. The agents never reveal a crew, mark a Level 3, publish, submit or change a threshold.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your FOQA program plan, event library, frame layouts and a sample of de-identified flight data — and it goes live once every quality gate has passed. We will walk you through it on your own data first.
Every report routed the same day, every repeat linked before it is scored.
1-min demoAviation Safety Action Program (ASAP)Every ASAP report ready before the ERC meets, every action tracked to closure.
1-min demoSafety Investigation ManagementReports drafted in days, not weeks, with every finding tied to its evidence.
1-min demoWe'll run Flight Data Monitoring (FOQA) on a sample of your own de-identified flight data and event library.