Reading the provenance panel

Open any result’s detail panel and below the itinerary and the prices sits a section most tools do not have: “Where this came from”. It is the product’s receipts. Every field on it exists because, at some point, we needed exactly that fact to work out whether a number could be trusted — and if we needed it, you are entitled to it. Here is the tour, field by field.

The freshness badge

The age of the observation, always attributed to a clock. The badge names which clock it is showing: source checkedmeans the program itself published when its availability engine last looked, and we fetched means only our own retrieval time is available. The two are never averaged, and a result past its freshness window says stale on its face rather than quietly resembling a fresh one. The badge never uses the word “live”, because nothing in this product is a real-time feed and we will not imply otherwise.

Program, source, and how it was retrieved

Program names the loyalty program whose answer this is — one observation never merges programs. Source is the hostname the bytes actually came from, so a claim can be traced to a place. How it was retrieved states the acquisition method in plain words: an official API, an ordinary HTTP fetch, or a browser. There is no method we use and decline to name.

Adapter and parser versions

Every observation records which versions of our reading code produced it. This is the “numbers with signatures” idea from our essay on reading an airline’s answer: if a parser bug is ever found, these two fields are how we — and you — know exactly which results it could have touched.

Point of sale and locale

A price is an answer to a question, and the question includes where it was asked from. These fields record the country and language context the observation was fetched under; where the source does not state them, the panel says “Not stated” rather than assuming.

Source timestamp

The program’s own last-checked time, shown only where the program publishes one. Where a source gives us a time we had to interpret — a relative “checked 2 hours ago”, say — the value is marked (estimated), because a derived timestamp is not the same kind of fact as a stated one. And where the source publishes nothing, the field reads “Not published by this source”. That line is the whole site in miniature: an absence, rendered as an absence.

Every field on the panel is the same question asked a different way: who says so, and since when?

Availability scope and married segments

Availability scope records what the seat information describes: the whole itinerary as a unit, each segment separately, or — honestly — not stated. Married segments shows whether the source declared this itinerary’s availability as a unit that cannot be split into standalone legs; “No” means the source made no such declaration, not a promise that the legs are independent. Both fields exist because a seat count without its scope invites you to multiply it wrongly — the theme of our married-segments essay.

The seat chips, briefly

Above the panel, every price option carries a seat chip whose wording is load-bearing. An exact count reads “4 seats”. A capped display reads “4+ seats” and never rounds up to a count. A party-level answer reads “Fits 2” — the source confirmed your party fits and published no number. And where the program says nothing, the chip says “Seats unknown” with no number at all. Five shapes, five renderings, as we argued they must be.

Source reference

Where the program assigns its own identifier to an offer, we keep it and show it. It is the field you hope never to need: if a result ever looks wrong, the reference lets a report name the exact thing we saw, so the dispute is about a specific observation rather than a memory of one. A panel like this is not decoration. It is the product agreeing, in writing, to be wrong checkably.