PHAROS Ai is flight data monitoring software, in development, that lets FDM/FOQA analysts and safety teams find unstable approaches, hard landings and engine exceedances in ARINC 717 recordings, measure every flight against an expected band, and track safety performance indicators. Each event is tied to the recording and the decoder, dataframe and definition versions that produced it, and crew identity stays behind the gatekeeper named in the FDM Agreement, released only on its terms.
Email me the brochure, PHAROS Ai
PHAROS Ai is FlightAtom's flight data monitoring (FDM/FOQA) software, in development. It decodes ARINC 717 recorder data through an open, versioned dataframe, detects exceedance events such as unstable approaches and hard landings, records measurements on every flight, and tracks safety performance indicators for FDM analysts and safety teams. Crew identity is held behind a gatekeeper under the operator's FDM Agreement.
Decoding, flight phases and event detection are deterministic. Triage and investigation drafts can be switched on for an operator only after a recorded passing evaluation, and an analyst signs every investigation.
Follow events from the triage queue to the recorded traces, a backtested threshold change, a dual-control re-identification request and the phone disposition sheet. The screens are live renders on a synthetic flight-data corpus, except the gatekeeper console, which shows the interface's demonstration fixtures.
New events are listed oldest first with severity, flight phase, age and a fixed-weight (untrained) triage score that high-severity events never receive, while 3,055 data-gap records are kept out of the queue. The preview shows the values captured for the selected unstable approach, that its dossier is in draft, and the analyse run, event set, dataframe and decoder that produced it. Synthetic demonstration data.
A high-energy approach opens with its event window shaded across nine synchronised traces, read against the 1,000 ft gate, Vapp, rate-of-descent, N1 and one-dot reference lines, beside the plan view and the approach profile against a 3° path. The health panel lists the decode, derive and analyse runs, dataframe, derived set, phase logic and event set that produced the values. Synthetic demonstration data.
This recording lost 171 of 2,096 frames to destroyed sync words and stray bytes, and the decoder re-acquired sync 170 times. Every trace breaks where frames are missing instead of joining across the gap, and with the cursor inside a lost frame every lane's readout shows a dash rather than a value. Synthetic demonstration data.
A draft that lowers the crosswind guideline from 25 to 20 kt was backtested over the 96-sector synthetic corpus: it would raise 61 events against the published version's 42, all 19 additions low severity, and the backtest lists each flight as new or unchanged. Synthetic demonstration data.
A request to re-identify crew for one event has one of its two approvals. Beside it are the agreement terms it is judged against, the circumstances that are always refused, and recent access to the data, where each disclosure of crew identity follows a request both gatekeepers approved. Rendered from the interface's demonstration fixtures, because the web screen cannot yet read the shipped API's gatekeeper responses. Synthetic demonstration data.
On a phone the seven dispositions that keys 1 to 5, e and d apply at the desk sit in a sheet, each with the reason code the audit log records. Synthetic demonstration data.
Every result carries the decoder, dataframe and definition versions that produced it, and data quality stays visible from the raw file to the chart.
At a bit slip the decoder marks only the damaged span invalid and re-locks, keeping the data on either side; it reads ARINC 717 at 64 to 1024 words per second, detects the word rate itself and handles BNR, BCD, discrete, signed and superframe parameters. A missing sample stays missing from decode to chart: traces hatch the gap, and an event whose inputs are missing becomes a data-gap record, listed apart from the triage queue, rather than a false event. Zoomed-out traces keep each interval's minimum and maximum, so the sample that triggered an event stays visible.
The queue opens on the highest-severity, oldest event, and data-gap records are listed separately as decode health instead of crowding it. Analysts validate, mark a false positive or data artefact, escalate or defer each event with one key, every disposition is written to the audit log, and on a phone the same actions sit in a disposition sheet.
Crew identifiers become per-operator tokens at ingest and sit in a separate, separately keyed identity store, and a write that would put a crew identity into an analytical record is refused. Re-identification is accepted only for a circumstance the agreement permits, with a reason tied to a specific event or investigation, a named gatekeeper's approval and a second authoriser above the agreed threshold, and a reason that describes a prohibited use is refused. FlightAtom staff have no standing access; support uses a time-boxed grant the operator approves and the gatekeeper is told about.
Every event records the definition version that fired it, along with the recording's hash and the decoder and dataframe versions, and a definition change publishes only with a rationale, a backtest on current data, review by someone other than the drafter, and FDM Manager approval. The starter library for Embraer E-Jets covers unstable approaches at the 1000 ft and 500 ft gates, hard and bounced landings, rejected takeoffs above 80 kt, TCAS RA, EGPWS, overspeeds and engine N1, N2 and ITT exceedances. Each definition carries hysteresis and a recorded threshold source, with arming and suppression rules where the event needs them.
Follow unstable approaches continued below the gate, go-arounds, hard landings, rejected takeoffs, level busts, EGPWS and TCAS activations, and runway-excursion precursors as rates per 1,000 sectors with targets, alert levels and trends, with data gaps never counted as occurrences. Beside them, a per-tail strip of daily decode quality shows a degrading recorder as a visible drift, and degraded decodes are counted apart from clean ones rather than folded into coverage.
PHAROS Ai records measurements on every flight, including threshold crossing height, touchdown vertical acceleration, speed at 500 ft, flare duration and runway remaining at stop. Each is held against an expected band, and a value that cannot be computed is stored as invalid with its reason rather than left out. The explorer opens on the measurement with the most flights outside its band and plots the fleet's distribution and percentiles against that band, so a shift shows before any flight crosses a limit.
The aircraft dataframe is a versioned, validated document in an open format, and validation reports every defect at once. Sector data exports as Parquet, CSV or Arrow and dataframes as JSON or XML. Raw recordings are stored unaltered, and a built-in check re-decodes a sample of them and confirms the decoded output matches byte for byte.
Uploads are hashed for duplicate detection, resumable, scanned and structurally checked before decoding. Failures go to quarantine, and a file whose tail is missing, not in the fleet, or contradicted between sources waits in a manual queue instead of being assigned a guessed tail. The fleet view shows how many received files decoded cleanly, decoded degraded, failed or are still waiting, and how many are quarantined or have no tail.
A deterministic flight-phase engine, sector splitting that recognises touch-and-gos, and a runway matcher that declines to choose between parallel runways feed derived energy, wind, glidepath and stabilisation-gate parameters. A manual phase correction is written to the audit log before it takes effect.
Each AI capability starts switched off and can be enabled for an operator only after a recorded passing evaluation, with switches to turn it off per operator or system-wide at once. The conventional FDM workflow runs unchanged with every AI capability off, and drafts use deterministic templates unless the operator connects its own self-hosted language model, pinned to an exact weight digest.
Every figure in an investigation draft is a citation to a recorded query of the flight data. A validator outside the writer re-runs each query, and a draft that fails twice is replaced by a plain fact sheet. Weather or NOTAM context that is not available is stated as missing rather than assumed.
Drafts set an approach beside the most similar approaches on record, matched on height-normalised speed, descent rate, thrust and glidepath profiles. From readable rule tables they propose an ADREP/ECCAIRS occurrence category, contributory factors, a cell on the ICAO 5x5 risk matrix and a candidate hazard reference from a built-in starter list. At sign-off the original draft and a record of the analyst's changes are kept, and the investigation exports as a tamper-evident PDF.
Triage scores how likely a lower-severity event is to be real rather than a recording artefact and shows the factors behind the score. Until a gradient-boosted classifier has been trained on the synthetic corpus and the operator's own dispositions, the score comes from an inspectable weighted rule set over decode-health features, and every score names the model that produced it. It never changes an event's status and never scores high-severity events, so dispositions stay with the analyst.
Agree a representative sample and a baseline from your current process. These are proposed evaluation measures, not published performance results.
Synthetic fixtures and independent reference decodes for an agreed aircraft layout.
Inspect provenance, event definitions, synchronized traces, and analyst review.
Decode agreement; event detection errors; data-quality coverage.
No. PHAROS Ai is in development and has not been deployed with an operator. Its pipeline is verified on synthetic flights, and aircraft dataframes, event thresholds and outputs require operator and independent reference validation before operational use.
The starter event library for Embraer E-Jets covers unstable approaches at the 1000 ft and 500 ft gates; hard, bounced, deep and off-centreline landings; high- and low-energy approaches; tailstrike margin; crosswind and tailwind landings; rejected takeoffs above 80 kt; rotation rate, climb gradient and pitch after takeoff; autopilot disconnect below 500 ft and autothrottle override; TCAS RA, EGPWS and stick shaker; flap, gear and VMO/MMO overspeeds; and engine N1, N2 and ITT exceedances. Each definition records its threshold source, and any change publishes only after a backtest, review by someone other than the drafter, and FDM Manager approval.
PHAROS Ai tracks unstable approaches continued below the gate, go-arounds, hard landings, rejected takeoffs, level busts, EGPWS and TCAS activations, and runway-excursion precursors. Each is a rate per 1,000 sectors with a target, an alert level and a trend, and data gaps are never counted as occurrences.
Yes. Sector data exports as Parquet, CSV or Arrow, the aircraft dataframe as JSON or XML, and investigations as a tamper-evident PDF. The dataframe is a versioned, validated document in an open format, so the operator holds the decoding definition as well as the data.
Crew identifiers become per-operator tokens at ingest and are held in a separate, separately keyed identity store. Re-identification needs a reason tied to a specific event, approval by the gatekeeper named in the FDM Agreement, and a second authoriser above the agreed threshold. FlightAtom staff have no standing access to flight or crew data, and every re-identification and every support access grant is written to a hash-chained audit log.
AI in PHAROS Ai is optional and starts switched off. After a recorded passing evaluation, an operator can enable triage scores for lower-severity events and investigation drafts in which every figure is re-checked against the flight data by a validator outside the writer. Decoding, flight phase and event detection are deterministic, and analysts amend and sign every investigation.
Flight data monitoring is the practice called flight operational quality assurance (FOQA) in the United States and flight data analysis in ICAO material. PHAROS Ai is being developed for that practice: decoding recorded flight data, detecting events, and supporting analyst review.
No. PHAROS Ai has its own analyst interface and processing pipeline. Passing validated events to a safety system, AURORA Ai or another, is defined with the operator for each programme.
As your fleet, routes, rules or teams change, we adapt PHAROS Ai to match, and you approve each change before it goes live.
A focused walkthrough, with the people and decisions that matter to your team.