Enumerated conformance table: derive (qtype × op × backend) proof obligations from the dispatch registry — the test half of #3418 #3945

Downstream of #3421 Phase 1, and the other half of #3418. Alfredo's concept ticket asks for the data table (llama.cpp's ggml_type_traits[]); this asks for the test matrix derived from it, so that admitting a quant type automatically creates its proof obligations instead of an author remembering N sites.

#3418 already states the problem in exactly these terms:

"'does architecture X work' is not actually one question — it's architectures × quant_types × backends × call_sites, and today most of that matrix is untested."

That sentence is the specification. What is missing is the thing that enumerates it.

Why now: the 0.69.1 release paid for its absence, measured

Every item below is from the night of 2026-09-23 on release/0.69.1-batch-2.

1. The GPU-eligibility whitelist is recorded in NINE places. b9435c6b6 is titled "the whitelist is recorded in SIX places and I updated one" — and undercounted: it missed crates/apr-cli/contracts/apr-model-capability-v1.yaml, the include_str!'d packaged mirror, which held the release branch red for hours. dtype.rs itself is the eighth. The ninth is crates/aprender-serve/src/infer/tests_11.rs:357.
2. The ninth was invisible to three separate audits, and the reason generalises: it asserts is_legacy_gguf_quant(30) (BF16), and no BF16 change had happened — so a whitelist record stays latent until the type it names changes, and a sweep that looks for breakage cannot find it. It will now redden the in-flight BF16 work at the worst moment.
3. dtype.rs calls itself "Single source of truth for the GPU-eligibility whitelist" and contradicted itself — prose listed ten types and explicitly said Q5_1(7) … gated to CPU; the expression permitted thirteen, including 7, 20 and 21. Wrong in both directions: a reader concluded IQ3_S still needed work (it did not) and that Q5_1 was unsupported (it was permitted). That comment is what produced a wrong type number in a kernel assignment.
4. A capability string conflates two crates. "IQ also fails the CPU dequant path" is true of aprender-core (which is why tensor_contract cannot inspect those tensors) and false of aprender-serve (which decodes all four). One string, two crates, and an estimate was wrong until someone checked per-crate.
5. Six-plus bespoke per-type contracts already exist — q2k-dequant-parity-v1, q3k-dequant-correctness-v1, q5k-dequant-correctness-v1, bf16-dequant-v1, quant-roundtrip-fidelity-v1, … — each hand-written for one type. That is the duplication ARCH: quant-type dispatch is duplicated across ~30 files with no single source of truth — propose a dedicated consolidation release #3418 describes, in the contract layer rather than the code layer.

What competitors do, since #3418 already reaches for llama.cpp

test-backend-ops walks every type the backend claims and tests each. Structurally, findings 1–3 above cannot happen in that design.

Where we are already ahead, and must not lose it

Our kernel bar is planted faults proven RED first (gemv_entry_name_tests_3477.rs:116; the contract's "never moved on a kernel's existence alone"). test-backend-ops has no fault-injection step, and neither does vLLM's kernel suite. Our CRUX judge (crux_inference_judge.py, #3739) also refuses to pass vacuously — no comparator answered, control ALL_WRONG, no control declared — which most differential harnesses cannot do.

So this is not "adopt llama.cpp's testing". It is: keep the discrimination bar, replace the hand-picked matrix with an enumerated one.

Proposal

Once #3421 Phase 1 lands quant_type_traits(), derive a conformance table from it:

• Enumerate (qtype × op × backend × shape) from the registry, not from a hand-written list. A type admitted to the whitelist without its conformance rows is a build failure.
• Per-format tolerance, declared in the registry. This is a correction to our own current standard: we are claiming EXACT (0 ULP / 0.000e0). That is achievable for BF16, where widening is a pure 16-bit shift, and not generally achievable for GEMV, whose reduction order differs from the CPU's — which is precisely why llama.cpp uses NMSE thresholds. Each type should declare its bar, or we will eventually assert bit-exactness where it is physically unavailable and then either weaken the gate or block a correct kernel.
• Generate, do not maintain, the support table. Docs: publish a GPU-vs-CPU model architecture support table (no user-facing doc exists today) #3077 (Alfredo: publish a GPU-vs-CPU model architecture support table) becomes a rendering of the enumeration rather than a hand-kept document — and Docs: publish a GPU-vs-CPU model architecture support table (no user-facing doc exists today) #3077 stops being able to drift.
• Subsume the per-type contracts in finding 5 as rows, rather than leaving six hand-written siblings.
• Keep the mutation requirement per row, so an enumerated matrix cannot become a large vacuous one. An enumerated table that has never gone red is a bigger lie than a small one.

Precondition, and a correction to #3421

#3421 marks Phase 0 [x] complete and it is not. PR #3420 is OPEN, contracts/quant-dispatch-completeness-v1.yaml is not on main (it exists only on that branch, commit 1d7dcc5e9), and there are zero qdc_ tests in the tree. Verified on release/0.69.1-batch-2.

That is worth stating plainly because the five findings above are what #3418 predicted would keep happening, and its own foundation is sitting in an unmerged PR. Landing #3420 is the cheapest available step toward all of this.

Scope: 0.70.0 or the Inference dispatch & architecture consolidation milestone alongside #3423 — not the 0.69.1 train.