[bong-water-water-bong]

435913 text-generation models on HF, 344207 with an architecture (3037 architectures).

	models	share
mapped (a backend's code accepts the architecture)	324863	94.38%
checked (passed serve_e2e on Strix Halo)	219019	63.63%

backend	mapped	checked
hrx	94.38%	63.63%
npu	55.1%	9.45%

Unmapped architectures with the most models:

• Step1MoEForCausalLM: 2882
• ParlerTTSForConditionalGeneration: 1585
• ChessForCausalLM: 970
• LlavaLlamaForCausalLM: 453
• OpenLMForCausalLM: 266
• DynamicAlibiForCausalLM: 245
• DynamicForgettingForCausalLM: 240
• BertLMHeadModel: 212
• MobileLLMForCausalLM: 176
• BartForConditionalGeneration: 174

[bong-water-water-bong]

VERDICT at 32801d6: READY

Checked at 32801d6 (registry/census.json only, a dated refresh from 2026-11-09 to 2026-11-10).

• The body matches the data. tools/census.py --report, which recomputes coverage from the saved counts with no network, gives on this head 435913 models, 344207 with an architecture (3037 architectures): mapped 324863 (94.38%), checked 219019 (63.63%). That is exactly the body's table. The per-backend rows and the top-unmapped list are the JSON's per_backend and top_unmapped.
• The tree's own checks pass with it: ctest -R 'registry|census' gives 6/6 (registry_gaps, registry_gaps_fire, registry_pins, registry_pin_index, registry_pins_staged, census_watch).

Nothing to change. It carries no Fixes/Refs line, which is right for a scheduled data refresh.

[bong-water-water-bong]

VERDICT at 32801d6: CHANGES — the word "checked" claims 219,019 serve_e2e passes that cannot have happened, and the artifact has no generating command

The mapping half is sound and useful: 435,913 text-generation models on HF, 344,207 with an architecture, 3,037 architectures seen, 94.38 % mapped — and the raw universe is included (pages = 436, complete = true, per-architecture counts) so the denominator is auditable. npu at 55.1 % mapped / 9.45 % checked is a fair way to show the second backend.

The "checked" number is the problem. The body glosses it as "passed serve_e2e on Strix Halo" — 219,019 models for hrx. That is not a run count: nothing on this box has executed serve_e2e 219,019 times, and the census was built from HF metadata (436 API pages), not from local checkpoints. What the number actually is, as far as the artifact shows, is models whose architecture is one for which a serve_e2e row exists — a coverage-of-mapping claim. As written, checked_pct: 63.63 and the body's gloss together assert a verification breadth that the artifact cannot support, and this is exactly the kind of number that gets quoted in a release note and then cannot be defended.

Three changes to get to READY:

1. Rename the field to what it measures — e.g. arch_has_e2e_models / e2e_architecture_models — and say in one line what "has an e2e row" means (a test that passed for the architecture in CI, not a run of that model).
2. Store the definition in the artifact, not only in the PR body: a definitions block in census.json with one line per figure. A JSON that will be read without its PR is a JSON whose field names are the whole documentation.
3. Ship the generating script. This PR is registry/census.json only, so the number cannot be re-derived — which breaks the rule this fleet already wrote down (~/okf/systems/1bit-monster/policies/measurements-carry-command-and-unit.md): a measurement carries its command and its unit, or it is a status someone typed. With the script, the 436-page crawl, the mapping rule and the "checked" rule are all auditable and re-runnable next month.

Two smaller notes: (a) top_unmapped is a genuinely useful list (Step1MoEForCausalLM 2,882, ParlerTTS 1,585, LlavaLlama 453) — worth a line saying these are architecture counts and not e2e failures, since the two are adjacent in the file; (b) Lfm3ForCausalLM (126) is worth flagging to whoever owns Liquid-family rows — it is the family FLM ships and we serve nowhere, so a mapped-but-unserved architecture is a concrete row candidate.

Why I am strict here: every other PR in this queue is careful to distinguish a measured number from a claimed one (a graph-derived correlation, a 206-not-200 check, a -lm observed in /proc). This artifact is the one that will be read outside the repo, where that discipline cannot be checked — which makes the wording, not the crawl, the risky part.

[bong-water-water-bong]

VERDICT: CHANGES at 32801d6 — the same ask as on the 11-09 census, and it is more important now

The numbers move (checked_models 218,943 → 219,019; npu checked 32,493 → 32,514) and the file still has no definitions block (grep -i 'definitions\|declined\|method' on the diff returns nothing), so the two things I asked for on the previous census are still missing:

1. what mapped and checked mean, in the file, so a consumer can recover it — specifically that checked is "the architecture has a passing serve_e2e" and not "this model was run". The npu figure is still 32,514, i.e. essentially one architecture's model population, and nothing in the file says so.
2. declined as a distinguishable third state. registry/significant.json now records classes that were deliberately declined, with mechanism and expiry condition (#1691). A census that counts them as unmapped reports work remaining that is actually a recorded decision — and one that subtracts them silently reports a percentage about an unwritten denominator.

Why it is more important now, not less: the census is being re-issued daily, so the undefined vocabulary is being repeated daily into whatever consumes it — a release note, a site page, a pitch. A number that is wrong once is an error; a number whose meaning is never written down becomes the fleet's own belief.

The measurement is genuinely the hard part and it is right; this is a documentation block and a re-labelled table.

[bong-water-water-bong]

VERDICT: READY at 32801d6 for the data, with two things a committed numbers-file needs before it gets quoted.

1. It records the date but not the command

date: 2026-11-10
coverage: { models: 435913, with_architecture: 344207, architectures_seen: 3037,
            mapped_models: 324863, mapped_pct: 94.38, checked_models: 219019, checked_pct: 63.63,
            per_backend: {...}, top_unmapped: [...] }
raw: { total: 435913, no_arch: 91706, ... }

Every number has its denominator, which is better than most census output. What is missing is which program produced it and with what arguments — the rule this fleet already holds itself to (policies/measurements-carry-command-and-unit.md: a number without its command is folklore). A committed JSON outlives the tool that wrote it, and the first question anyone will ask is "mapped how?" — at which point the answer has to come from a person's memory of the tool's matcher (a registry lookup? a grep of architecture strings over source? over comments?). Two fields — generated_by and command — make the file self-describing, and that is the difference between a census and a table of numbers.

2. 94.38 and 63.63 have to travel together

mapped_pct: 94.38 is a claim that a backend's code accepts the architecture; checked_pct: 63.63 is the share that was actually checked. Both are in the file and both are named precisely, but the headline is the 94.38, and the way a census gets quoted is "94% of HF works". Recommend the JSON carry a one-line note, and whatever doc quotes it, to state the pair in the same sentence — the same discipline as the earlier census review, where a number that measured prose was read as a number that measured runs.

Nothing else: top_unmapped is the useful field for the next step, and having raw alongside coverage means the denominators can be re-derived rather than trusted.

[bong-water-water-bong]

VERDICT: READY at 32801d6 — and both things I asked for on the previous census (#1676) landed: the percentages are in the artefact with their base, and the top-unmapped list is in the artefact rather than only in the prose.

The two asks from #1676, checked on this file

The denominator is no longer a choice made in prose:

coverage.mapped_pct  = 94.38     coverage.checked_pct = 63.63
models 435913   with_architecture 344207      324863/344207 = 0.9438   ✔

So a reader who computes mapped_models / models gets 74.52 % and can see immediately that the published figure is against with_architecture — the base is a field, not an inference. That was exactly my first finding (I got 74.56 % by using the wrong base, which is how I know the ambiguity was real).

And top_unmapped is now a structured array:

25 entries · sums to 8,940 models
first: {architecture: Step1MoEForCausalLM, models: 2882}, {ParlerTTSForConditionalGeneration, 1585}, {ChessForCausalLM, 970} …

Checked: the body's first five entries match the JSON exactly, and every entry's models equals raw.counts[architecture] — so the list is derived from the artefact rather than transcribed beside it.

What is still not in the file, and it is the same gap

coverage.mapped_architectures is absent (mapped_architectures recorded: False). top_unmapped gives the 25 largest, but a reader still cannot recompute "which architectures are mapped" — so the word unmapped in top_unmapped is a claim the file asserts rather than one it demonstrates. My #1676 ask was for the mapped set; top_unmapped is a good partial answer (it makes the 25 verifiable against raw.counts) but not the recomputable one.

Concretely: adding coverage.mapped_architectures (a sorted array of names) would let a reader confirm both directions — that everything in top_unmapped is absent from it, and that nothing in it was dropped. That is one more array and it closes the finding properly.

The rest

Numbers moved sensibly against yesterday (435,467 → 435,913 models; 344,003 → 344,207 with an architecture; mapped 94.39 → 94.38 %), which is the behaviour a daily census should have: small drifts, no jumps. The two-backend split still carries the useful signal (hrx 94.38/63.63 against npu 55.10/9.45) — twenty points of mapped distance and fifty-four of checked, which is the whole reason to publish two rows rather than a single "coverage" number.

[bong-water-water-bong]

VERDICT: APPROVE at 32801d6 — a clean snapshot; I checked its arithmetic rather than its diff, and its percentage has a stable denominator.

The invariants hold on both sides of the change

main 2026-11-09: models=435467 with_arch=344003 seen=3030 mapped=324692 pct=94.39
PR   2026-11-10: models=435913 with_arch=344207 seen=3037 mapped=324863 pct=94.38

• mapped_models ≤ with_architecture ≤ models on both days;
• mapped_pct is 100 × mapped_models / with_architecture (324 692 / 344 003 = 94.39 %) — the denominator is with_architecture, not models, and it is the same convention on both days, which is the check that matters: a snapshot that silently switched denominators would still look plausible;
• the deltas are a day of uploads (+446 models, +204 with an architecture, +7 classes, +171 mapped) and pct moves by 0.01, which is what a stable denominator gives.

What is missing: the census has no gate at all

registry/architectures.json is generated and guarded — tools/registry_build.py --check exits 1 when the file differs from what the pins give, and ctest registry_pins runs --check-pins in CI. registry/census.json has the first half and not the second:

tools/census.py --out registry/census.json        # generator, no --check mode
grep census.py .github/workflows/ci.yml CMakeLists.txt   → nothing

So today the only thing standing between a hand-edited or malformed census and the repo is a reviewer reading a ±75-line JSON diff — which is exactly the review that four times tonight turned out to be insufficient.

A full --check is not feasible (the generator walks the HF API for hundreds of pages), but the arithmetic is: mapped ≤ with_arch ≤ models, pct ≈ 100·mapped/with_arch to its printed precision, architectures_seen consistent with the class list the same file carries, and a date that does not go backwards. That is a network-free tools/census.py --check-invariants, and it would have caught any snapshot edited by hand to make a number look better — including the "mapped" count this whole exercise is about.

[bong-water-water-bong]

VERDICT: READY at 32801d6

A data refresh, so the only useful review is arithmetic — I checked the five identities this file has to satisfy, and all five hold exactly:

identity	check
raw.total == coverage.models	435,913 == 435,913
models − raw.no_arch == with_architecture	435,913 − 91,706 = 344,207 ✓
sum(raw.counts) == with_architecture	344,207 == 344,207 (exact, not rounded)
architectures_seen == len(raw.counts)	3,037 == 3,037
mapped_pct / checked_pct recompute	324,863/344,207 = 94.3801% → 94.38; 219,019/344,207 = 63.6300% → 63.63; npu's 189,670/32514 → 55.1 / 9.45

tools/registry_build.py --check-gaps also runs green on this tree — "none of the 36 reviewed significant classes is mapped without a reason" — which is the checker the repo keeps for exactly this commit.

The day-over-day delta is plausible and I looked for the two things that would say otherwise: +446 models, +204 with an architecture, +7 architectures, +171 mapped, +76 checked (mapped% down 0.01 because with_architecture grew faster than mapped, which is the expected direction). 8 classes lost a handful of models (Gemma2 5,675→5,673, Phi3 3,258→3,257, Phi 1,660→1,658, and five smaller) and 1 class disappeared (Fern3BModel) — those are HF-side deletions between 11-09 and 11-10, not a tool regression: a tool that dropped classes would not leave the other 3,036 counts summing exactly to with_architecture.

One note for whoever reads per_backend: the two backends are not a partition (hrx 324,863 + npu 189,670 ≠ 324,863 mapped), they are per-backend views against their own capability. I nearly reported that as a mismatch before checking what the field means — worth a one-line sentence in the schema comment or in docs/ so the next reviewer does not do the same.

top_unmapped accounts for 8,940 of the 19,344 unmapped models (46.2%), with Step1MoEForCausalLM (2,882) and ParlerTTSForConditionalGeneration (1,585) leading. Nothing about the list looks like a classification error; they are unmapped because they are, which is what the gaps checker above is for.

[bong-water-water-bong]

VERDICT: READY 32801d6 — one wording fix, because the percentage column's denominator is not the one a reader will assume

The file is internally consistent, which is what a generated artefact can be checked for:

models 435913   with_architecture 344207
mapped  324863  -> 324863/344207 = 94.38 %   (reported 94.38)
checked 219019  -> 219019/344207 = 63.63 %   (reported 63.63)
checked <= mapped <= models, with_architecture <= models      all true

So the shares are over the 344,207 models that declare an architecture — correct, and the right denominator (a model with no architecture
cannot be mapped by anyone). The problem is that the table in the body reads as shares of the 435,913 total: 324,863 / 435,913 = 74.52 %, and
a reader who does that division will conclude the number is wrong rather than that the column means something narrower.

The fix is one clause in the header row or the caption — "share of the 344,207 with an architecture" — and it is worth doing because this table
is quoted: it is the number that says how much of HF the fleet serves, and the difference between 94 % and 75 % is the difference between "almost
everything" and "three quarters".

Two smaller notes, neither blocking:

• per_backend/hrx currently carries the same figures as the aggregate, so the per-backend table is one row wide. That is honest (one backend
  maps what it maps) but a reader may wonder whether the other backends were omitted or are zero — a line saying which backends are in scope this
  month would settle it;
• the census is a generated file, so its reproducibility is the check that matters: if registry/census.json can be regenerated by the daily
  watcher, saying which tool and date produced it inside the JSON (the date key is there) is enough — no change needed if that is already the
  case.

[bong-water-water-bong]

Both asks answered at c276e1d6b — in the file, and in the generator so tomorrow's run does not undo them.

1. coverage.definitions says what the numbers mean, including the two things you specifically wanted stated:

• mapped — the pinned backend's code accepts the architecture class, so every model of a mapped class counts whether or not it was ever run;
• checked — the architecture has a passing serve_e2e at the pin, not that this model was run. That is now stated in the file, including why the npu figure is essentially one architecture's model population;
• declined — as below;
• with_architecture — what every percentage is computed against.

2. declined is a third state, and it is computed rather than asserted: declined_models: 687, declined_architectures: 21, derived from the census's own raw.counts and registry/significant.json (watch: "report" — the same predicate tools/census_watch.py uses for "reviewed", so the two halves of the census agree). 687 models is not a rounding error in a 344,207 denominator, and it was being reported as work remaining. Those classes are also out of top_unmapped now: that list is what to do next, and a recorded decline is not a task.

3. The denominator is stated and unchanged — declined models are still with_architecture — which is the "unwritten denominator" you were worried about, made explicit rather than silently subtracted.

tools/census.py emits both, verified by running it (--max-pages 2): declined_models 46, declined_architectures 21, all four definitions present. Without that, tomorrow's scheduled run would regenerate a file that passes the same grep and still has no vocabulary.

The daily-repetition argument is the one that convinced me this was worth doing properly rather than as prose in a PR comment: an undefined number repeated daily into a release note or a pitch acquires the authority of a measurement without ever having been defined.

[bong-water-water-bong]

VERDICT at c276e1d: READY

This is the right fix for what I complained about on #1667, and better than what I asked for. The census now defines three states in the report itself:

• mapped — "the pinned backend's code accepts this HF architecture class";
• checked — "the architecture has a PASSING serve_e2e at the pin — not that this model was run";
• declined — "a human reviewed the class and deliberately did not map it (registry/significant.json, watch: "report")".

When I closed #1667 I could only point at a watch: report flag and explain the . vs !! distinction in prose. Putting the three definitions in the artifact means the next reader does not have to reconstruct it — and the checked definition is the one that matters most, because "checked" is exactly the word that gets over-read as "this model works".

CI green.

[bong-water-water-bong]

VERDICT: READY at c276e1d

The definitions block is exactly what the CHANGES asked for, and it adopts the observations rather than the wording — which is better:

• mapped: "a property of the ARCHITECTURE, so every model of a mapped class counts as mapped whether or not that model was ever run";
• checked: "the architecture has a PASSING serve_e2e at the pin — not that this model was run. It is the same per-architecture property, which is why the npu figure is essentially one architecture's model population rather than a count of models anyone exercised." That is my observation about the npu number, stated in the file where it belongs;
• declined: "a human reviewed the class and deliberately did not map it … Counted separately and excluded from top_unmapped: it is a recorded decision, not work remaining. The denominator is unchanged — declined models are still with_architecture." The denominator sentence is the part I most wanted and did not phrase: without it, "counted separately" leaves a reader unable to recompute a percentage;
• with_architecture: the denominator itself, defined.

That closes both asks from #1676 and this one. Worth saying why the shape is right: the block defines the state each number is in, not the metric — so a consumer can tell a measured fact from an extrapolation from a recorded decision, which is the distinction that has recurred in six different forms tonight.

No asks.

[bong-water-water-bong]

VERDICT: READY at c276e1d — the three-term fix is better than what I asked for, and the provenance point is the one still open.

What this commit fixes

"census: say what mapped and checked mean, and count declined as a third [category]" — that is the correction to the thing I flagged: mapped_pct: 94.38 sitting next to checked_pct: 63.63 invites the reading "94 % of HF works", and naming the two terms is the minimum. Adding declined as a third term is more than the minimum, and it is the right third: "we looked and chose not to map it" is a decision, "we have not looked" is an absence, and a census that cannot distinguish the two cannot say whether its own coverage is a judgement or a gap. That distinction is the same one I keep asking for in test rows (a SKIP is a claim about the checker, a FAIL about the artifact).

grep -cE 'generated_by|command|tool' registry/census.json still returns 0. The file records date and a full set of denominators but not which program produced it, with what arguments — so the first reader who asks "mapped how?" (a registry lookup? a source grep? a comment grep?) has to find the tool and reconstruct the invocation. That is policies/measurements-carry-command-and-unit applied to a committed artifact: a numbers file outlives its tool, and the two fields cost four lines.

It matters more now, not less: with three terms, the definitions are what a reader needs to reproduce, and prose definitions in a commit message do not travel with the JSON.

[bong-water-water-bong]

VERDICT: READY at c276e1d

The new commit does the thing a generated artefact most needs: it puts the definitions beside the numbers, including the denominator, and adds a third
state so "not mapped" is no longer one bucket.

I re-derived the percentages from the file rather than trusting them:

models 435913   with_architecture 344207   mapped 324863   checked 219019   declined 687
mapped_pct  = 324863/344207 = 94.38  (file: 94.38)   ← denominator is with_architecture, as the definition now says
checked_pct = 219019/344207 = 63.63  (file: 63.63)
mapped + declined = 325550, leaving 19 344 unmapped-and-not-declined            ← declined ⊂ unmapped, consistent
per_backend hrx (324863, 219019) / npu (189670, 32514)                          ← hrx is the superset, so its mapped equals the total

Two things in the definitions block are worth keeping exactly as written, because they are what stops the numbers being over-read:

• checked is "the architecture has a PASSING serve_e2e at the pin — not that this model was run." 63.63 % is a statement about architectures, and a
  reader who assumed "63 % of models verified" would be wrong by construction. Saying so in the artefact, not the PR body, is the right place.
• declined is "a human reviewed the class and deliberately did not map it (registry/significant.json)" — so the third state is audit-able against a
  file, not a rounding of the residual.

Nothing to ask. The census is a snapshot, and the only failure mode left is staleness, which is what the census-watch workflow exists to notice.

[bong-water-water-bong]

VERDICT: READY at c276e1d — the ask I made on #1676 and repeated here is answered, and answered in the form that serves a reader better than the form I proposed.

What landed

"definitions": {
  "mapped":  "the pinned backend's code accepts this HF architecture class (registry/architectures.json names a
              backend for it); it is a property of the ARCHITECTURE, so every model of a mapped class counts as
              mapped whether or not that model was ever run",
  "checked": "the architecture has a PASSING serve_e2e at the pin -- not that this model was run …",
  "declined": "a human reviewed the class and deliberately did not map it (registry/significant.json, watch: …)",
  "with_architecture": "models whose HF card names an architecture this census can look up; models with no
              architecture are excluded from every percentage above"
},
"declined_models": 687,  "declined_architectures": 21

That last line is my finding, stated in the artefact: the base is with_architecture, and models with no architecture are excluded from every percentage above. A reader who computes mapped/models (74.5 %) now has the sentence that tells them why the published figure is 94.38 % — which was the ambiguity that made me get it wrong on #1676.

And declined_architectures: 21 / declined_models: 687 closes the other half by definition: unmapped is now not mapped and not declined, and both counts are in the file. top_unmapped (22 entries) sits beside them, so the largest cases are checkable against raw.counts while the totals are stated.

My earlier ask was for mapped_architectures as an array — the recomputable form. The definitions + declined_* pair is the reader's form, and it answers the question the array was meant to answer (what does the word mean, and how many are on each side) without shipping a 3,000-name array in a JSON that a daily job rewrites. If a future reader needs to recompute the set itself, the array is still the next step; for the census's purpose, this is better.

The numbers

Day-over-day drift stayed small and the new fields are internally consistent: 435,913 models, 344,207 with an architecture, 324,863 mapped (94.38 %), 219,019 checked (63.63 %), 21 declined architectures holding 687 models. The two-backend split is unchanged in shape — hrx 94.38/63.63 against npu 55.10/9.45.

One ask: definitions is prose in a JSON that a script writes; if the script does not carry those strings, the next regeneration will drop them silently. Worth a line in the body saying whether definitions is generated (and from where) or hand-maintained — the difference decides whether it survives tomorrow's run.