Evidence

The three data files this reference cites, travelling with it.

• granite-public.json — the catalogue: each model's geometry and, where the model publishes a config.json, the impl block lifted from it. 33 of the 172 publish none; their rows carry what the catalogue knows and nothing inferred to fill the gap. Public data about public models, which is what every page here is computed from.
• granite-assess.json — the support assessment that support.md reads each row's status from. It describes an independent inference implementation written by the author, which is not published, and the names of that implementation's converted checkpoint files have been removed: the status is the fact, and those files are only how the author reached it.
• claims.json — one row per model: the evidence grade claimed for it, what that grade means (the grades are explained in support.md), and, where the model publishes a configuration, the sha256 of the exact file these pages read. Every row also pins the upstream commit it describes (upstream_revision), with that commit's upstream_last_modified date and the date the pin was checked (revision_checked).

What claims.json is, and is not

It gives traceability, not independent verification. A row says what grade a model's support claim carries and what that grade rests on, and its digest lets you establish that the config.json you have is the one analysed here.

It carries no comparison result, no metric, no tolerance, no run date and no recording digest — because none of those are recorded in a form this export can read, and a field filled by inference is worse than a field left out. Those are exactly what would make it a verification record, and they are named here so the gap is visible rather than implied.

config_sha256 is absent on the 33 rows that publish no configuration. Their stored file is an empty object, and a digest of that would be the same value on all 33 — identifying nothing, while sitting in a field that looks like it identifies something. Those rows carry config_published: false instead.

A configuration digest identifies a configuration. It is not a checkpoint identity and not a repository revision: two models can publish byte-identical configurations and different weights, and findings §6 is about exactly that.

upstream_revision is the commit, and it was checked, not inferred. On 2026-09-22 each of the 172 repositories was queried on the Hugging Face Hub, and for the 139 that publish a configuration the config.json at that commit was downloaded and hashed. All 139 matched config_sha256 byte for byte (config_matches_revision: true), and in every case the matching commit was the repository's head on that date. The 33 without a configuration are pinned to their head commit on the same date, with nothing to compare. A pin says which commit these pages describe; it does not hash the weights at that commit.

To use it, download a model's config.json from Hugging Face, compute its sha256 and compare it with that model's config_sha256. A match means these pages describe the file you hold; a mismatch means the upstream file has changed since this snapshot.

The implementation these pages were checked against is not here, and neither is its inventory. Where a page says a forward pass was recorded or a comparison was run, that is a statement about work done in an implementation you cannot inspect. The reference is to IBM's models; that implementation produced the execution evidence summarised here.