Implementation support

The rest of this reference describes what IBM publishes. This page records something else: how far one independent inference implementation gets through the same 172 catalogued models. That implementation was written by the author of this reference to run Granite checkpoints and is not published. It is neither IBM's code nor Hugging Face transformers.

It is here because trying to run every model is a practical test of the catalogue. It shows which architectures an outside implementation could cover from the published files, which adapters could be merged into their base models, and which releases need behaviour that it refuses on purpose.

This is not a benchmark. No output quality, accuracy or speed was measured. Because you cannot inspect the implementation, every row is a statement by the author about work you cannot re-run; the evidence grade says how strong that statement is. What you can check is the configuration side: each model that publishes a config.json has its sha256 in claims.json (see evidence).

Every one of the 172 catalogue ids appears exactly once below. The support assessment and the public catalogue cover the same ids, so no model can drop out of this page unclassified.

Terms

• checkpoint — one published set of model weights; one row of the catalogue.
• the implementation — the unpublished inference implementation assessed here.
• pack (in the tables, stored checkpoint) — a checkpoint's weights converted into the implementation's own file format. A pack is what the implementation actually loads.
• class — the architecture class a configuration declares, such as GraniteForCausalLM.
• normalized configuration — a published config.json with the fields that record provenance rather than behaviour set aside (see findings §6).
• shape — class plus depth, width and the stack of layer kinds; see method §4.
• forward pass — one run of the model over an input.
• reference recording — outputs (logits) saved from the model's own published reference implementation, so the independent implementation's outputs can be compared with them. Parity in a grade name means such a comparison was made; the tolerance used is not published here.
• LoRA adapter — a small set of weight changes published to modify a base model. aLoRA (activated LoRA) switches on at a particular token position partway through a sequence.
• fold — merge a LoRA adapter's weights into its base model's weights once, when the pack is built, so that the result loads like an ordinary checkpoint. The assessment status runs (adapter seam) means a model runs only in this folded form; the adapter seam is the implementation's folding step.
• fold manifest — the implementation's record of which adapters were folded into which packs.
• approval list — the digests of folded packs that the author has checked and accepted.
• covered base — a base model the implementation already runs.

Reading the tables

For ordinary model rows, packed means the assessment records one or more packs with the same normalized configuration. It does not establish that a pack holds the exact weights of the linked checkpoint. Base, instruct and guardian releases of one generation often share a configuration exactly, so one pack can match several catalogue rows, and the assessment cannot always say which of those rows it holds the weights of. Where it can, the grade begins own-; where it cannot, shape-. Both are true statements, and they are not the same statement.

Adapter rows add a second distinction: their pack list may name compatible base packs, while their status says whether anything was actually folded. Classification follows the status first, and the reason column keeps both facts visible.

runs is one word covering several strengths of claim, so each row also carries the strongest evidence that exists for it. The grade is computed from the packs, the recorded passes and the comparisons made, not written down by hand. Strongest first:

A row that does not claim runs gets no implementation grade, because a grade answers "how well does this run" and those rows do not ask it:

The packs, recorded passes and reference recordings behind these grades belong to the unpublished implementation and are not published here. The grade is the whole public statement.

Summary

Runnable paths with configuration-matched packs

The implementation runs this architecture, and at least one pack has the same normalized configuration. That is a match of configuration, not proof that the pack holds this checkpoint's published weights.

_{↑ summary}

Runnable shape, no matched pack

The implementation runs this architecture class, or the adapter has been folded into a covered base, but no pack with this exact configuration is recorded. For the adapter rows the evidence is the folded packs; for the others it is the class alone.

_{↑ summary}

Foldable adapter, not packed

A plain LoRA that could be folded into a covered base, but nothing has been folded for this release. A compatible base pack, where one is counted, says a suitable base is stored, not that this adapter was applied to it.

_{↑ summary}

Not implemented

None in scope. No catalogued model outside the out-of-scope rows (the GneissWeb and geospatial releases) needs an architecture the implementation lacks.

_{↑ summary}

Refused by design

The model needs behaviour at run time that folding weights once cannot express. The implementation refuses these by name when loading them, and its tests check the refusal.

_{↑ summary}

Out of scope

The release is in IBM's Granite catalogue but outside what the implementation sets out to run.

_{↑ summary}