The field that makes a swap explainable
Record the model, the version if one is given, and the date, once per delivered file. That is the whole habit. It costs one field at the time, cannot be reconstructed later, and it is what turns a mysterious change in output into a short list of causes. As of 2026-09-12.
| Recorded | The question it answers |
|---|---|
| The model family | Whose retirement notices concern you |
| The version, where given | Whether a dated row applies to this file |
| The date generated | Which side of a suspected change it sits on |
| The tier or plan, if no version | What to compare against a later reading of the page |
Inclusion rule. Fields worth keeping per delivered file, in a register of models that get switched off. Order. From the most durable field to the most situational.
1The question always arrives at the worst moment
When a retirement is announced, the first thing anybody asks is how much of the delivered work is affected. With this record it is a filter. Without it, somebody watches hours of footage trying to guess.
The same question arrives when output starts looking different with nothing announced. A record settles whether the model changed or something else did, which is the difference between a diagnosis and an argument.
2On some arrangements it already exists
Where each model carries its own price, the invoice records which engine produced what as a side effect of billing. That is the cheapest version of this habit and it is available on only a few of the entries in this register.
Everywhere else it has to be deliberate: a column in a spreadsheet, a field in a project file, a line in a delivery note. The form does not matter and the discipline does.
3Keep the outputs, not the ability to remake them
The instinct is to preserve prompts and settings so anything can be regenerated. In this field that is backwards, because the thing that will not exist later is the model, and a prompt without its model reproduces nothing.
Archive the delivered files at the quality delivered, somewhere that is not the vendor's account. Material kept only inside a product is subject to whatever that product does at retirement.
4The record is also what makes a claim checkable
Anybody quoting a figure or describing a change can say when it was observed, which matters because several of these pages are edited without notice. An undated claim ages silently.
That is the same reason every row in this register carries the day the page was read. A fact with a date can be checked; a fact without one has to be believed.
5Where each vendor's own wording lives
None of the above is a date. Announced end dates, and the apps still carrying the models they apply to, are kept on the calendar with the announcement each one came from.
- Model version — why the family name alone cannot be matched to a dated row
- The notices as a file — the same discipline applied to this register itself
Guidance rather than a dated entry. No line here is a vendor statement, and none should be read as an announcement. The sourced material is on the calendar. Related: A frozen test set, Hosted or downloaded.