Model identifier: the string a schedule is written about
An identifier is the exact string a request names. It matters because retirement schedules are written about identifiers rather than about products: a dated row names a string, and a customer whose purchase never mentioned one has nothing to match the date against. As of 2026-09-22.
| With an identifier | Without one |
|---|---|
| A dated row can be matched to your code | A published date may or may not apply to you |
| An audit of your own systems is possible | Exposure has to be guessed from output |
| A retirement fails closed, on a known day | A change arrives as output that looks different |
| A vendor can notify the right customers | Notices go to people who cannot act on them |
Inclusion rule. Distinctions drawn from the lifecycle pages in this register, all of which list identifiers rather than product names. Order. With an identifier first, then without.
1Explicit identifiers are the precondition for a schedule
A retirement schedule is only actionable if somebody can tell which of their systems uses the retiring version. That is why the platform with the most detailed schedule in this register also has no default engine.
The two facts are one design decision seen from two sides. A product that hides the identifier cannot publish a useful schedule, because no reader could tell whether a row applied to them.
2An identifier is also a liability
A string written into code eighteen months ago is still being sent, and nobody remembers putting it there. That is the effective default on every programmable entry here, and it fails on the maker's date.
Failing closed is the right behaviour and it is still a failure. A notice period is what turns it into a scheduled edit instead of an outage.
3Products name families; schedules name strings
Several entries in this register name a maker or a family rather than an identifier, so even a diligent customer cannot connect a dated row to a purchase. The information exists on both sides and not in the same vocabulary.
That gap is the reason this site keeps model pages and entry pages separate and links them to each other rather than merging them.
A definition rather than a dated entry: no line above is a vendor statement. Where this word turns up in a real notice, the wording and the date are on the reading on explicit deployment. Nearby terms: Model card, Changelog, Successor model.