Moderation

How the project keeps the data trustworthy at scale, with a volunteer moderator team that grows linearly while submission volume grows much faster. The system has to be fast enough that contributors don't lose interest, careful enough that bad data doesn't get published, and transparent enough that decisions can be appealed.

For context on the contributor trust tiers referenced here, see CONTRIBUTORS.md.

What moderation does

Three jobs:

  1. Approve or reject submitted edits before they enter the live dataset.
  2. Resolve disputes between contributors who disagree about a fact.
  3. Handle abuse — spam, vandalism, coordinated manipulation, conflicts of interest.

The system is designed so that the first job — the bulk of the work by volume — is mostly automated and trust-graduated. Disputes and abuse, which require judgment, escalate to humans.

The edit queue

Every submitted edit lands in the queue with a state. The states are:

  • pending — newly submitted, awaiting review or auto-approval check
  • auto_approved — approved without human review (trusted contributors, low-risk fields)
  • approved — approved by a moderator
  • rejected — rejected with a reason code
  • disputed — flagged as conflicting with existing data or with another submission
  • withdrawn — the submitter took it back

Edits in pending are visible to moderators sorted by priority. Edits in any other state are visible in the public change log.

Auto-approval rules

The faster the queue clears, the more contributors stay engaged. So as much as possible is automated, with safety nets.

Auto-approval happens when all of these are true:

  • The contributor is at trust tier Regular or higher
  • The edit affects a field classified as low-risk
  • The edit doesn't conflict with another recent edit to the same field
  • Schema validation passes
  • The required source field is present and the source URL resolves
  • The contributor has not exceeded their daily edit cap
  • The submission doesn't trip any abuse heuristics

Low-risk fields are those where wrong data is annoying but not consequential: notes, photos (subject to image moderation), translations of existing strings, success-rate votes, typical-wait-time votes. The exact field classifications are documented in flighthelp/governance/MODERATION-POLICY.md and updated through the governance process.

High-risk fields always queue for human review, regardless of trust tier: compensation numbers, fee amounts, contact methods, regulation interpretations, baggage dimensions and weights, anything in the rules engine.

Auto-approved edits are still logged with full provenance and are subject to post-hoc moderation. If a moderator later flags an auto-approved edit, it gets reviewed and potentially reverted.

Human moderator workflow

Moderators see a queue prioritized by:

  1. Edits flagged as urgent (multiple recent reports of the same data being wrong)
  2. Edits from contributors who recently had rejections (more scrutiny while their pattern is established)
  3. Edits to high-traffic pages
  4. Older edits (the queue is FIFO past the priority bands)

Each queue item shows:

  • The submitted change (diff view, before/after)
  • The submitter's profile and recent history
  • The source URL/photo
  • Any prior versions of the same field
  • Quick action buttons: Approve / Reject (with reason) / Request more info / Dispute

A skilled moderator can process 20–40 items per hour. The team is sized to clear the queue within 24 hours under normal load. During high-traffic events (strikes, major airline policy changes), the queue can balloon; the system flags this and the core team can deputize extra moderators temporarily.

Reason codes

Rejections must cite a reason code. The codes are stable enums published in flighthelp/governance/MODERATION-POLICY.md:

  • missing_source — no source URL or photo
  • unreliable_source — source is forum, social media without verification, or other tertiary
  • source_unrelated — source doesn't actually support the claimed fact
  • outdated_source — source predates a known later change
  • schema_violation — structural error caught by schema, with details
  • duplicate — already exists in the system
  • conflicts_existing — contradicts existing high-confidence data without sufficient evidence
  • out_of_scope — fact doesn't fit the project's scope
  • policy_violation — violates code of conduct (with sub-code)
  • needs_clarification — moderator wants more detail before approving
  • suspected_abuse — flagged for the abuse review path

Reason codes are visible to the submitter. The system also surfaces aggregate rejection statistics so contributors can see which codes are common and adjust.

Moderator time, in practice

Moderators are volunteers. The system respects their time:

  • No moderation quotas. Moderators work as much or as little as they want.
  • The queue is shared, not assigned. Any moderator can pick up any item.
  • Each item shows time-in-queue so older items get attention.
  • Moderators can flag items for the core team without resolving them.
  • Burnout signals (declining activity, increased rejection rates, public complaints) are tracked privately and the core team checks in.

Disputes

When the same field is edited to a different value by a different contributor within a short window, or when an existing fact is challenged by a new submission with contrary evidence, the system creates a Dispute.

A Dispute is a queued conflict with:

  • The current value and its sources
  • The new value and its sources
  • The contributors involved
  • A public comment thread

Disputes are resolved in one of three ways:

  1. Trusted contributor vote. Any contributor at tier Trusted or higher can vote for the current value, the new value, or "needs more evidence." A simple majority of at least 5 votes resolves the dispute.
  2. Moderator decision. If the dispute remains unresolved after 14 days, a moderator decides based on the evidence.
  3. Core escalation. Disputes involving policy interpretation, repeat offenders, or contentious legal claims escalate to the core team.

All Disputes and their resolutions are public. The data on every page shows when a dispute affected the current value, with a link to the resolution.

Photo moderation

Photos (especially gate-sizer photos) go through a separate review path because they have additional risks: privacy (other passengers visible), provenance (photo could be from anywhere), and copyright (claiming someone else's photo).

Auto-checks:

  • EXIF data stripped on upload
  • AI moderation pass (faces blurred if visible, weapons/inappropriate content flagged for human review)
  • Reverse-image search to detect photos previously published elsewhere
  • Timestamp and location plausibility (does the geolocation match the airline/airport claimed?)

Auto-flagged photos go to a separate queue with moderators who have opted into photo moderation. Approved photos enter the dataset. Rejected photos are deleted from storage.

Abuse detection

Several layers, increasingly invasive in proportion to the signal of bad behavior.

Spam detection

  • Rate limiting on submissions per contributor per day
  • Pattern detection (bursts of edits from a single account, repetitive content)
  • New-account scrutiny (first 10 edits get extra moderator attention)

Most spam is opportunistic and dies at the rate-limit. Determined spammers require more.

Coordinated manipulation

Detected through:

  • Time-correlated edits across multiple accounts (clustering)
  • Shared device fingerprints or IP ranges across accounts
  • Edits that push particular commercial narratives (favoring/disfavoring specific airlines or claims services)
  • Reports from honest contributors who notice patterns

When a cluster is detected, the moderation team investigates. Penalties scale with severity: from "increased scrutiny on these accounts" to "all edits from this cluster rolled back, accounts banned, IP range temporarily blocked."

Coordinated manipulation by claims-company employees or airline employees is a particular concern — the project's neutrality is its core value. Detected attempts result in permanent bans and, where evidence exists, public disclosure of the source (without naming individual employees).

Conflicts of interest

Contributors are required to disclose conflicts: employment by an airline, by a claims service, by a comparison site, by an OTA, by a travel insurance company. Disclosure does not disqualify them from contributing but restricts which entities they can edit.

The conflict-of-interest registry is private (to protect employees from employer retaliation) but is consulted by moderators when reviewing edits.

Personal targeting

Contributors who become targets of harassment (in-app or off-platform) can opt into stricter privacy: their profile becomes private, their edits are attributed to "Anonymous," and the moderation team monitors their account for follow-on attacks.

Appeals

Every rejection and ban is appealable.

  • Edit rejection appeal: The contributor can request a second review from a different moderator. The second decision is final unless the contributor escalates to the core team with new evidence.
  • Ban appeal: Banned contributors can appeal to the core team. The core team reviews the full history and either upholds the ban, modifies it, or overturns it. Appeals are answered within 14 days.

Appeals exist for two reasons: to catch moderator mistakes, and to ensure that bans feel like decisions rather than dismissals. A community that can appeal trusts the system more than a community that cannot.

Transparency

The moderation system is private in its tools (see REPOSITORIES.md for why) but transparent in its outputs:

  • Every approved edit is in the public change log with attribution.
  • Every rejected edit appears in the contributor's private "My edits" view with the reason code; aggregate rejection statistics are public.
  • Every dispute and its resolution is public.
  • Every ban is logged (anonymized) in a public ban statistics report published quarterly.
  • The full moderation policy (criteria, reason codes, appeals process) is in a public repository.

The principle: contributors should be able to predict what will and won't be approved. Surprises in moderation are a failure of the system.

Adversarial scenarios

A few scenarios the moderation system explicitly anticipates:

Airline employees coordinating to suppress unfavorable data. Detected through cluster analysis and shared-source patterns. Counter: bans plus public disclosure of the pattern (without individual names).

Claims companies astroturfing scenario pages to drive traffic to themselves. Detected through link patterns and content style. Counter: bans plus public disclosure.

Vandalism (vandals replacing data with garbage). Auto-detected through outlier values and pattern matching. Counter: rapid rollback, ban, IP block if severe.

State-sponsored manipulation. Hypothetical but possible — a state actor inserting incorrect data about a national carrier. Counter: same as commercial manipulation, plus transparency disclosure to the press.

Insider compromise. Moderator account compromised or moderator goes rogue. Counter: every moderation action is logged with full audit trail; rollback is possible up to 30 days back; moderator privileges can be suspended by any other moderator pending core review.

The system does not assume good faith from every contributor. It assumes good faith from most contributors and builds safeguards for the few who aren't. The safeguards are quiet enough that good-faith contributors don't notice them.