Method

How this reference is built, in enough detail to follow the method or to disagree with it.

1. Enumerate, then exclude

The vendor's public model catalogue is listed in full, and anything whose name marks it as a converted copy of a model already present is dropped — gguf, fp8, mxfp4, nvfp4, int4, int8, awq, gptq, onnx, openvino, mlx. They are the same model in a different container, and counting them inflates every total. That leaves 172.

2. Read each model's own configuration

A published config.json is fetched directly for 139 of the 172; for the other 33 the absence is recorded rather than filled, and no geometry is inferred from a placeholder (see provenance). Nothing is inferred from a model card, a README or a name where a configuration has an answer — a card is prose someone wrote, and the configuration is what the code loads.

Geometry is not in a fixed place or a fixed spelling. Depth is num_hidden_layers, n_layer, num_layers or encoder_num_layers; width is hidden_size, n_embd, d_model or embedding_feature_dim; the context bound is max_position_embeddings or n_positions. It may sit at the top level, under text_config for a model with a language half, or under encoder_config for one without. All of them are read. Reading only the common spelling in the common place silently loses whole lineages — see findings.md.

3. Key on the declared class, not on names

Two checkpoints that declare the same architecture class go through the same code path, whatever their names suggest. The configuration still decides the layer mix, the activation, the rope base and so on — findings §1 shows how far one class can stretch — and a name is never used for geometry or code path, because there it adds nothing the class and configuration do not already say. Names are read in three places only, none of them about how a model is built: to drop converted copies (§1), for the role column in models.md, and in the third grouping rule of §5, where the class cannot tell a code model from a general one. 172 models reduce to a much smaller set of classes on that basis, and findings §6 shows how far it goes: a base and its instruction-tuned model, or two consecutive releases, can be byte-identical in configuration. Safety classifiers and adapter libraries that repeat their base's geometry are candidates for the same merge, not checked groups.

So nothing here picks "the" model for an architecture. Where a set of checkpoints is indistinguishable, the set is what gets shown.

4. A shape is class + depth + width + stack

The class alone is not a shape — most classes cover several. Neither is class-plus-size: granite-4.0-1b is 40 layers of attention and granite-4.0-h-micro is 36 state-space layers plus 4 attention, and they share a class, a depth and a width. Keyed without the stack they would merge, and the merged sheet would show one of the two layer maps and attribute it to both.

The stack signature — what the layer_types table actually contains — is therefore part of a shape's identity. That gives 55 shapes.

5. Group by what the model is, in a fixed precedence

Three rules, applied in this order, because the order is what makes them correct:

1. an adapter is an adapter, even though an adapter library ships its base model's configuration and would otherwise be filed as a dense language model;
2. the layer table beats the class name — a model declaring the hybrid class with no state-space layer is grouped by what its layers say, not by the label;
3. the class, then the name — and names are consulted only where the class genuinely does not distinguish the models, as it does not between a general language model and a code model that share a Llama-class configuration.

6. The pass structure is recorded, not derived

The order of operations for a shape is captured by running one forward pass in the author's unpublished implementation (see support.md) and recording the sequence of operations it performs — not by reading the configuration a second time and writing down what it implies. A structure re-derived from the configuration would be the same claim expressed twice, free to disagree with the thing it describes, and it would be right about models nobody had ever run.

The operation names in a recorded pass are that implementation's own labels, not names from transformers or from the checkpoint: delta_mix, for example, is its name for the token-mixing step of a state-space layer. Positions in the pass are numbered by their place in the structure, not by layer index: one position fires once per layer. Run-length form marks a repeated subtree with xN and deliberately does not record N, so two models differing only in depth have the same pass — depth is geometry, not structure.

31 of the 55 shapes carry a recorded pass, collected on one page, recorded passes. The rest are described from configuration and weight structure alone, and say so on their face. A pass nobody ran is not a pass anybody can write down.

A recording is matched to a shape by the same key the sheets are grouped by, stack included, and both come from one function. Otherwise granite-4.0-h-micro — 36 state-space layers and 4 attention — would be shown granite-4.0-1b's all-attention recording, because the two share a class, a depth and a width.

7. The implementation sketch is derived, and it is not the recorded pass

Each sheet also carries a forward pass written out as code. It exists because the sections around it answer a different question: the layer map and the geometry say what shape a model is, and the recorded pass says what ran and in what order, but neither says what to multiply by what.

Every number in it is the checkpoint's own, lifted out of its config.json into the catalogue and substituted at generation time, so the block is regenerated rather than maintained. Where a configuration does not carry a value the line says so instead of printing a default — a generated pass that quietly filled in an epsilon nobody published would be a made-up fact in a code block, which is the most believable place to put one.

It is deliberately not the recorded pass, and the two are shown separately. One is captured from a real forward pass and is evidence; the other is what the published configuration implies and is a reading. Where they disagree the sheet says so and names both sides — a model that declares no positional encoding and whose recorded pass enters a rotary step is not a contradiction, but a reader is owed the sentence that reconciles them.

8. What is checked automatically, and what that cannot catch

Every page is generated, and every build re-extracts the catalogue from stored copies of the configurations, regenerates every page, and fails if either differs from what is published; it also resolves every internal link and heading anchor, and checks that each published field of the catalogue changes the page it belongs on. Those checks run on the author's machine against unpublished copies and generators, so they are the author's claim, not something a reader can rerun. What you can check yourself is the input, by comparing a model's config.json with its digest as provenance describes.

What they cannot catch is an error in the reading itself. They prove the pages agree with the extraction, not that the extraction reads a field the way the modelling code does. A spelling the extractor does not know is the standing risk: rope_parameters, the newer transformers block that carries the rope base, appears in 11 configurations — granite-4.2-3b, -8b and -30b, the three granite-switch-4.1-*-preview models and granite-swash-3b-a600m at the top level, and granite-4.0-1b-speech, granite-speech-4.1-2b, -nar and -plus under text_config — and in 5 of them (the three switch models, granite-swash-3b-a600m and granite-speech-4.1-2b-nar) no rope_theta sits beside it, so a reader of rope_theta alone finds no rope base at all. Nor can any check see an equation or tell whether an operation is in the right order; the implementation sketches are readings, and the recorded passes are one run of one implementation.

9. What an evidence grade is computed from

support.md grades each row by the strongest evidence that exists for it in the unpublished implementation, computed from the stored checkpoints and recordings rather than maintained by hand. The distinction the grades are built around: a reference implementation existing is not the same as a comparison having been run. A grade whose name ends in "parity" must name a recording made against that checkpoint or shape; a recorded forward pass is the implementation running its own copy, which is weaker and different. A row that does not claim to run gets no implementation grade at all.

10. What is published, and what is not

These pages are published without the implementation they describe, so they leave out its source and storage paths, its name, and the tensor names its loader invents — a fused gate/up pair, a split projection — because a reader matching those against the published download would look for tensors it does not contain. Every claim those things supported is kept, stated as what was done.

What is published is the catalogue, the assessment with the names of converted checkpoint files removed, and a claims manifest, claims.json: one row per model with the evidence grade, what the grade means, and, where the model publishes a configuration, the sha256 of the exact file these pages read. It carries no result, metric, tolerance, run date or recording digest. The digest makes a claim traceable, not reproducible; what it does and does not identify is set out under provenance.

11. Keep catalogue facts separate from implementation evidence

The public catalogue says what IBM publishes; it cannot say what any implementation of it does. support.md is generated separately from the support assessment, and the build requires that assessment to cover exactly the same model ids as the public catalogue.

For ordinary model rows, a matching stored checkpoint (see support.md) is a configuration match, not checkpoint identity. Base, instruct and guardian releases can share a normalized configuration even though their weights and roles differ. For adapter rows, the stored checkpoints listed may instead be compatible bases, so classification follows the execution status first. The page reports both without turning either into a claim that the exact published checkpoint was converted or tested.

How to read an architecture sheet

Every sheet has the same sections in the same order. What those sections mean is the same on every sheet, so it is explained once here and each sheet keeps only what is specific to its shape. The index explains the file names.

The layer map

Present only where the configuration publishes a layer_types table: one character per layer, input on the left, with a count of each kind. A sheet without one is for a model whose configuration does not say, and nothing is inferred to fill it.

The pass

Recorded passes are kept together on recorded passes, one section per shape that has one, and each such sheet ends with a link to its section; nothing else on the sheet depends on it. Its italic lead-in says how much was recorded. Full forward is a nested trace of a whole forward; block level names the steps inside one repeating block and nothing above or below it; wrapper only is a single step, which says the model ran and nothing about order. 31 of the 55 shapes have one; a sheet without it says so (see §6).

It is recorded from one complete forward in the author's unpublished implementation: the structure is what that run emitted, not a reading of the configuration.

The tree. The root is the entry point the recording started from — forward for a decoder, encodeIds or encodeManyIds for a text encoder, encodeUnits or block for a speech encoder. It is a label, not a step. Each child is a step in the order it ran. ×N marks a position that fired once per layer; how many times is not part of the structure, so two models that differ only in depth have the same pass. Where the count was recorded, the sheet gives it on its own line (layer fired 40 times). In a stack that mixes layer kinds, the tree shows one layer node holding every step any kind of layer takes; the canonical form keeps the kinds apart.

The canonical form is the same pass as one string. Each number is a position in the pass, numbered by first appearance, not a layer index. Parentheses hold what nests inside a step, *N marks a run, and a number without *N fires once in that place. On a hybrid sheet, 2*N(3 4 5 …) 2(3 12 13 …) reads as a run of state-space layers followed by one attention layer. Two passes are the same structure exactly when their strings match.

The step names are generic. They are the implementation's own labels, the same across every class, and not names from transformers or from the checkpoint. The recorded names are never changed, because they are a record. Where a name misdescribes a model, the sheet annotates the step inline in the tree — rope (entered; no-op — this model uses no positions), or rmsnorm_attn (LayerNorm with bias in this model). A step is logged when it is entered, whether or not it does any work for that configuration, so an annotated step is not a contradiction between the pass and the configuration.

Implementing it

The forward written as code, one block per checkpoint whose arithmetic differs. A shape groups checkpoints by class, depth, width and layer stack, and none of those decides an activation, a rope base or a routing rule, so the members of one shape can disagree. Each block names the checkpoint it was generated from and the checkpoints it also covers. Where checkpoints differ only in constants, such as a multiplier, a rope base or a vocabulary size, the sheet lists those values in a table under one full block instead of repeating it.

It is what the published configuration says the arithmetic is, not the recorded pass (§7). Where the configuration does not carry a value, the line says so instead of printing a default; a value computed from others, such as head_dim from width over heads, is stated as computed.

Tensor names are the published checkpoint's where it publishes one, and canonical otherwise. A loader may store them differently, fusing a gate/up pair into one matrix or splitting one projection in two; those are the loader's names, not the model's.

The Granite multipliers. The Granite classes carry four floats that a Llama-class model does not: embedding_multiplier scales the embedding output, attention_multiplier is the attention score scale, residual_multiplier scales each sublayer's output before it is added back, and logits_scaling divides the logits (modeling_granite.py at transformers v4.57.1: attention, residual, embedding, logits). They are configuration values, not tensors, so a checkpoint loads the same whether or not a port applies them. They also change between releases: granite-4.1-8b publishes 12, 0.22 and 16 for the embedding, residual and logits values, and granite-4.2-8b publishes 1 for all three. The blocks print each one on the line where it acts.

How this was checked

Each checkpoint's implementation status and evidence grade, from support.md. What each grade means is in its grade table, and how grades are computed is in §9. In short: a grade ending in parity means an output comparison against a reference recording was made; own- means this checkpoint's own converted weights, shape- a converted checkpoint of the same shape that may not hold this checkpoint's weights, base- the base model an adapter applies to, and class only that the architecture class is implemented. The list under it names the parts of the unpublished implementation that exist for this shape. None of them is published. Where the implementation and the published configuration disagree, the sheet reports the configuration and says what the disagreement is.

Sources

Numbers on a sheet come from the model's config.json at the upstream commit pinned in claims.json, or from the tensor names in its published weights. Those tensor-level claims — names, counts, shapes — can be checked against tensors.json, an inventory of every published safetensors header at the same pinned commit. A claim that goes beyond those, about what a library does, how ties are broken, how an input is normalised or masked, or why a file is in a given format, links to the upstream source it was checked against, pinned to a release tag or commit. A claim that could not be checked against a public source is not made, or is reduced to what is known.

What this method cannot tell you

A configuration is a declaration, not a measurement. Where a field is absent the tables show a dash rather than a default; where a field is present but vestigial it is reported as published. findings.md collects the places where that distinction matters.

Parameter counts are totals. For a sparse model this includes every expert, most of them inactive for any given token. Comparing a sparse total against a dense total compares storage, not work.

Nothing here is a benchmark. No output quality was measured, and no claim is made about how any model performs. This is a description of what was built and how it is put together.

Provenance. These pages are generated from two kinds of public source — the catalogue, and the config.json files that exist; where a repository supplies none, nothing is inferred to stand in for it. Where a page shows a recorded pass, it comes additionally from a run of the author's unpublished implementation, which is not a public source and is described as such wherever it is used.

2026-09-18 is the latest upstream lastModified timestamp in this snapshot, and that is all it is. The hub distinguishes createdAt from lastModified, and this is the second: the repository carrying it was created earlier and touched on that date. It is not a publication date, not the date this reference was built, and not the date anything was retrieved. It dates the snapshot because it is the newest fact in it, and it does not move when these pages are regenerated — a date that changes when nothing else did makes every rebuild look like new information.

Each model is pinned to an upstream commit, and createdAt is not recorded. The pins, the configuration digests and the check made against the Hub are described once, under provenance.