What a register of published statements cannot settle
A register of published statements can say what a vendor stated, where, and when. It cannot say whether the statement is true, whether the output is good, whether a plan is permitted, or what a value will be next month. As of 2026-09-12.
| Question | What it needs |
|---|---|
| Is the figure reproducible | A run on that hardware |
| Is the output usable | A viewer, and a purpose |
| Is this plan permitted | The licence read against a jurisdiction |
| Will the value hold | A later reading of the same page |
Inclusion rule. Questions a register of published statements cannot answer. Each row names what would have to be done instead, so the boundary is actionable rather than rhetorical. Order. From the question closest to the published value to the furthest.
1A quoted figure is not a verified figure
Nothing here has been reproduced. A vendor's memory figure is recorded because the vendor published it, and the only claim the register makes is about the publication. Reproducing it would need the same card, the same code version and the same settings.
That is a real limit and it is preferable to the alternative. A register that claimed verification it had not done would be worse than one that quotes carefully.
2Quality is deliberately absent
No release here is ranked, scored or described as better than another. Quality would need a benchmark, a benchmark would need a harness, and the results would need to be reproducible by anyone who disagreed.
The columns hold licence, size, hardware, resolution and length because those are the things a repository states. What a face looks like across a cut is not among them.
3Licence text is not read on anyone behalf
The register quotes a licence name and links the page. It does not paraphrase terms, because the paraphrase is the sentence a reader would rely on and the one that would be wrong in a particular case.
Whether a plan is permitted depends on the document, on the jurisdiction, on any agreement signed with a service and on what was fed into the model. None of those are recorded here.
4Values age, and the date is the mitigation
Repositories are edited, model cards are revised and licences are clarified. A value read on a given day is a fact about that day, which is why every row carries the date it was read and a link to the live page.
A register without dates would be a snapshot pretending to be a specification. With them it is a set of claims that can each be rechecked in a minute.
5Absences are recorded, not filled
Where a repository states nothing in a column, the cell says so. Filling it from a forum thread, a configuration file or arithmetic would make the register the source of a claim no vendor made.
The empty cells are also findings. A column that most vendors fill and a few leave blank says something about the few, and that is only legible if the blanks are honest.
6What the form is good for
Establishing which version has files, which terms travel with them, what the vendor claims about hardware and output, and where the claims stop. That is most of what a planning decision needs before anyone spends card time.
The rest belongs to a test run and to whoever is accountable for the decision. Naming the boundary is what makes the part inside it trustworthy.
7Where the repository figures are kept
The techniques above are general. Which vendors have published what, under which licence and on what hardware, is recorded on the model pages, each figure quoted from the repository it was read from with its date.
- How read — the rule for what enters a cell
- Empty cells — where the gaps fall
- The dataset — what is exported and what is not
Craft notes on reading releases. No row here is attributed to a vendor, and nothing on this page is a reading of anyone's licence obligations. The sourced material is on the requirements page. Related: Choosing a build, Recording a reading.