AI Content Policy

Effective2026-08-03 · Last updated2026-10-07

FlightFinder uses language models to turn official accident records into readable summaries at a scale no single editor could reach — roughly a quarter of a million occurrences drawn from more than a hundred investigation authorities. This page states plainly where models are used, the limits of automated checking, and which publication gates their output has to clear before it is stored or indexed.

Where models are used

  • Plain-language accident summaries. Generated from the official narrative and the structured record for that occurrence.
  • Structured extraction. Pulling fields (phase of flight, occurrence category, occupant counts) out of report prose into a fixed taxonomy.
  • Directory and digest text. Short descriptive passages on aircraft, airline, and airport pages, derived from data we already hold.

Long-form data stories are written by a person and carry a named byline. Statistics inside them are computed from the database, not produced by a model.

Publication checks and their limits

  • Numeric grounding. Article ingest compares numeric tokens with resolved facts and source narratives when a nonempty allowed set is available. With no grounding data, this check is skipped. A token appearing in the source does not prove that a sentence uses it correctly. Flagged new articles can be held for review.
  • Cause attribution. Official findings should be attributed to their source. Automated checks do not establish that every causal statement in an accident summary is supported. Readers should verify findings against the investigation report.
  • Invent a field value. Extraction is validated server-side against fixed taxonomies; a value outside the taxonomy is refused outright rather than stored.
  • Carry a fabricated byline. Machine output is published under the collective FlightFinder Editorial, never under an invented person.
  • Generation failures. Known model preambles and refusal patterns are stripped or rejected. Detected generation-failure articles are withheld from public article retrieval. Pattern checks can miss other kinds of inaccurate prose.

Why the gates are deterministic

Server-side checks use code to detect specific failures; they do not certify the whole text as correct. Numeric grounding, taxonomy validation and publication thresholds have different scopes. They cannot verify all identities, chronology or causal claims, and an indexable page is not evidence that a person has checked every sentence.

What this policy does not claim

We do not claim that a person reads every machine-generated summary; at this volume that would not be true. Bulk generated pages are governed by the automated gates described here and by the numeric floors in our Editorial Standards — output that fails them is not stored, or is stored but kept out of the index. Human review is applied to data stories and curated digests before they are marked indexable.

We also do not generate photorealistic imagery of real people, aircraft, or accident scenes. Photography is credited to its source; see Attributions.

Precedence

Where a generated summary and the official report disagree, the official report is authoritative. Report a discrepancy so that the summary can be corrected or removed. Source links are shown where available; missing or inaccessible source reports limit independent verification.

Reporting a problem

If you find a generated passage that misstates a record, email [email protected] with the page URL. Factual corrections are verified against the upstream dataset and applied to the source of the error, so the same fault does not regenerate.

See also: Editorial Standards · Methodology · Attributions · About · Contact