Inbox

TravStats never overwrites your data behind your back and never corrects it silently. When something outside your own typing has an opinion about a record — an enrichment API with a different aircraft, a geocoder with a different country — the result is a question, and the questions live in the Inbox (Posteingang), always in the System menu. The badge on the entry says whether anything waits; the entry itself is always there, so an empty inbox has a way in.

The inbox is what the pending-updates page became in 2.6.0. It holds the flight proposals it always had plus the data-quality questions the new checks raise — one list for you, two tables underneath. The badge counts both halves independently, so one failing cannot hide the other.

Flight proposals

Three sources produce proposals about a flight you already have:

• Live auto-update. For scheduled flights, the auto-update job polls the flight-data providers around the flight. A different gate, a changed departure time, a new registration becomes a proposal.
• Historical enrichment and the backlog refresh. A nightly job fills in what older flights lack — aircraft type, actual times, tail number — on never-overwrite terms: your own text wins, an empty column is filled. A provider may not rename the carrier you flew with; on a codeshare the marketing and the operating carrier are two true answers. A flight that landed without its actual times is asked about one last time, through the one provider that answers for a past date, exactly once.
• Re-parse. Reading a confirmation again after a template update and getting a different answer.

Each proposal shows what is in the database, what the source suggests, a per-field diff, which source proposed it, and a preview of what applying would do to your headline statistics — distance, flight time, the airlines and airports it adds or removes. Proposals expire after a day, or after the flight ends, whichever is later.

Three actions per proposal:

Action	What happens
Apply	The proposal is written to the flight; derived fields recompute; achievements re-check
Edit & apply	You change fields in the proposal before applying — the API has the gate, you know the terminal
Reject	The proposal is discarded; the flight stays as it was, and the same proposal is not re-created on the next poll

Several proposals can be answered in one request: POST /pending-updates/apply and /reject take a list of ids and report an outcome per id — a flight edited meanwhile, one already applied, one that is not yours — rather than one success flag that would drop changes you believe you accepted. A read-only access token cannot apply a proposal; applying writes to the flight underneath, so it needs write scope like every other mutating route.

Why no auto-apply

Provider data is not always right — one provider has been observed swapping aircraft on codeshare flights — and a manual edit (“I was in Premium Economy”) should not be silently undone. Historical enrichment is heuristic. The default is propose, don’t overwrite, and there is no per-source auto-apply setting.

Data-quality questions

Four checks fire only where two sources inside one record disagree:

1. An address whose country differs from the stored country
2. Coordinates that fall outside the claimed country
3. A country resting solely on records that carry no date
4. A check-out before its check-in

A nightly sweep and every import run the checks. A third-party geocoder does not get a veto over your own data, so the record is written and the question waits. A flag never changes a number by itself. A pin in the sea, or in a territory the offline outlines do not attribute, is not a disagreement and raises nothing.

Each flag states both conflicting values and marks neither as correct. The two answers are different kinds of statement, and each carries its consequence:

Answer	What it means	What follows
I corrected it	You fixed the record	If the contradiction survives — you fixed one half — the flag can come back
This is right	Both values are true as they stand	Never asked again for this record — the escape hatch for a district that shares a country’s name

A flag disappears on its own when its cause does: un-marking a hotel as visited removes the country from the passport and the question from the inbox at the same moment, rather than leaving the inbox asking about a country that no longer exists.

Programmatic access

The flight half is under /api/v1/pending-updates, the quality half under /api/v1/data-quality-flags (list, POST /run to run the checks now, POST /:id/resolve, POST /:id/dismiss). Both are in the OpenAPI spec.

Cleanup

Expired proposals go on their own; applied and rejected ones are kept with their status so the counters stay meaningful, and a daily job deletes proposals older than 90 days regardless. Answered quality flags are kept as the record of the decision.

What it does not do

• No three-way merge. A proposal compares against the flight as it is now, not as it was when the last proposal was made — almost always what you want, occasionally a surprise.
• The statistics preview is a preview, not a lock. A recomputation between preview and apply can shift the delta slightly.
• It does not judge. A flag says two values disagree; it never says which is wrong.