Model card: where a per-model fact gets published
A model card is a page describing one model. It matters in this register because it is where several facts turn out to live that a policy page does not carry: a licence, download commands, and in one case the notice period that applies to that particular model. As of 2026-09-22.
| Published on a card | Why it belongs there |
|---|---|
| A licence for the weights | Permission differs per release |
| Download commands | The route differs per repository |
| A notice period for that model | The figure varies, so a rule cannot state it |
| A lifecycle state | It changes per model, over time |
Inclusion rule. Read from the model cards and repository listings used as sources in this register. Order. From the most durable fact to the most changeable.
1A per-model figure is more specific and more work
Publishing a notice period on each card means the answer is exact and has to be looked up per model. Publishing it in a policy means the answer is a rule and may not fit every case.
One platform in this register does each. Both are readable before choosing a model, which is what separates them from every application here.
2For downloadable weights the card is the whole contract
Where a publisher offers weights rather than access, the card states the licence and prints the commands. That is what makes a held copy usable rather than merely present.
It settles permission and not capability. Nothing about a licence guarantees the weights keep running on next year's toolchain.
3Cards are also where a fact can hide
A figure on a card is easy to miss and easy to change, and a reader comparing two entries has to open one page per model. That is a real cost of the arrangement rather than a criticism of it.
The register records what each card said and the date it was read, which is the only way a per-model fact stays checkable. The sourcing page sets out the rest.
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 per-model notice reading. Nearby terms: Changelog, Successor model, Silent update.