[alfredodeza]

Summary

• docs/specifications/PP-QUANT-001-MASTER.md — the plan for ARCH: quant-type dispatch is duplicated across ~30 files with no single source of truth — propose a dedicated consolidation release #3418 (0.69 placement per operator decision, §6), now with the concrete Rust design in §2.4: build the dispatch table on the existing GgmlQuantType (three partial registries already exist — a fourth is the two-lists defect), QuantTypeTraits as plain data + fn pointers indexed by ggml id (the actual shape of ggml_type_traits[], not dyn Trait — §2.1a explains why that cannot compile), a QuantCodebookFormat trait for the IQ/FP4 family with generated grid tables, hot kernels untouched, tensor_byte_size (CPU: Qwen3.5 / Qwen3.8 hybrid GGUFs are refused entirely — no fallback exists #3091's crash site) as the migration template.
• contracts/quant-dispatch-completeness-v1.yaml — Phase 0 done: all 35 live ggml tensor types with geometry transcribed from ggml-common.h static_asserts at llama.cpp 3173a5647, 8 removed ids, type_count 43, ten codebook grids, and the 30 dispatch sites. pv validate / pv lint green.
• crates/aprender-serve/src/quantize/dispatch_contract_tests.rs — five qdc_* tests binding the contract to the tree today: enumeration gapless, removed ids rejected by from_id, names agree, the five QuantBlockFormat impls match their rows, and the dispatch-site oracle equals the migrated: false set (so a 31st site, or a row falsely flipped, fails CI). Registered in scripts/tree_reader_tests.txt.
• §4 corrects ARCH: quant-type dispatch is duplicated across ~30 files with no single source of truth — propose a dedicated consolidation release #3418's "16 named types" to 13 (three were metadata value types).

RED→GREEN receipt (run in-session, all restored byte-identical)

Mutation (contract FALSIFY id)	Result
Q4K SUPERBLOCK_BYTES 144→145 (QDC-003)	FAILED — "SUPERBLOCK_BYTES 145 != contract bytes 144"
new file matching match qtype { GGUF_TYPE_Q4_K … + loader.rs flipped to migrated: true (QDC-005)	FAILED — names both zz_mutant_site.rs and gguf/loader.rs
from_id(4) → Some(Q4_0) (QDC-002)	FAILED — "must be None"
delete the Q3_K row	FAILED — gapless assertion
unmutated	5 passed; 0 failed

Test plan

• cargo test -p aprender-serve --lib qdc_ — 5/5
• pv validate + pv lint on the contract — PASS
• scripts/check_contract_test_binding.sh — PASS (0 dangling; the two obligations that need Phase 1 code carry no test: citation by design)
• scripts/check_tree_reader_tests.sh — registry equals derived set after --update
• scripts/check_no_claim_literals.sh — PASS
• cargo clippy -p aprender-serve --lib --tests -D warnings — RED on pre-existing findings in aprender-test-lib/pixel_coverage/* and forward_qwen35.rs (make raw seems to fail on a fresh mbp #2370 ceiling class), none in the files touched here

Refs #3418 · Epic #3421

keep-open: #3418 #3421 (epic/parent; not closed here)

🤖 Generated with Claude Code

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=3420 head=9b7fe4f7caadfaeeb3304ee81c54e24b130bfb19 verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.

[alfredodeza]

Ticket/epic consolidation (2026-09-17): #3422 (the shared-block forward-path finding) is now tracked as a sub-issue of #3418 rather than a sibling ticket — both are sub-problems of the same umbrella ("new architectures are too expensive to add"). Epic #3421 is rescoped to Phase 0/1 only (this PR's scope); Phase 2/3 now has a real home — milestone Inference dispatch & architecture consolidation, tracked by epic #3423 jointly with PP-ARCH-001, replacing the earlier vague "may slip forward under the train rule" language. Spec updated accordingly (§0 header, §6.1, §7).

[noahgift]

Review — measured against origin/main @ a672677f4 and this branch's head (2026-09-17). Comment only; your text and titles are untouched.

The direction is right and two calls in here are better than what I would have proposed: a data table instead of dyn (§2.1a), and the contract as the universe with a test that reads it. 35 live / 8 removed / 13 consts / 16 variants all reproduce [V]. Five findings, in order of how much they change the plan.

1. The oracle's universe is shrunk by its own pattern — 3 files are invisible to it [V]

oracle_hits_line fires on GGUF_TYPE_Q4_K, GGUF_TYPE_Q4_0, or match … qtype. A file that dispatches on any other id only is not a site. Reconciling dispatch_sites (30) against every non-test file in aprender-serve/src naming any GGUF_TYPE_* (27): 24 in both, union 33.

• in the tree, not in the contract: gguf/cuda/moe_ffn_forward_layer_cuda.rs (F32), gguf/inference/forward/forward_qwen35.rs (F32), gguf/loader_gguf_model_02.rs (Q3_K)
• in the contract, not in my const-keyed scan: api/model_source.rs, apr/cache.rs, convert/q4k_conversion_stats.rs, cuda/executor/layers/cublas_prefill/gemm.rs, cuda/executor/layers/gemv_dispatch.rs, cuda/types.rs

So both scans are invocation-shaped and each misses what the other finds. Since qdc_dispatch_sites_match_oracle is the ratchet for Phase 2, a site added with GGUF_TYPE_Q6_K today passes it. Suggest the oracle key on the enum/const namespace (GGUF_TYPE_[A-Z0-9_]+, GgmlQuantType::, WeightQuantType::) plus the match forms, and ship a must-match / must-not-match case table. Bare-integer arms (12 =>, qtype == 2) are a third form neither scan sees; upper bound 558 non-test lines across 10+ crates [U] — noisy, needs the case table before it is a baseline.

2. §2.4's registry table stops at the crate boundary — there are three ggml enums [V]

enum	ids
serve GgmlQuantType (gguf/types.rs)	16
core GgmlType (aprender-core/src/format/gguf/types.rs:55 — the import path)	12 — no Q5_0, Q5_1, Q2_K, Q3_K, Q5_K
compute GgmlType (aprender-compute/src/inference/gguf.rs:27)	15

Growing serve's enum to 35 leaves the importer at 12, so apr import and apr run will keep disagreeing about what a file contains. The enum + TRAITS want to live below all three (lowest common workspace dep, or a zero-dep leaf crate), with the three becoming re-exports → #3430. #3405 also added a fourth private name table (QTYPE_LABELS, 13 rows) that the same table replaces.

3. The defect history is two classes, and the larger one is not quant dispatch [V-diff]

Read from the five fix diffs, not the PR bodies:

issue	fix	what the diff does	class
#1749	#1751	routes apr bench to the MoE path	placeholder — re-route
#1789	#1790, #1806	validate_matmul_weight_shape rejects empty data; HTTP 501	placeholder — guard
#2535	#2541	validator skips dense FFN when arch is MoE	placeholder — guard
#3341	#3405	SUPPORTED_EXPERT_QTYPES + drift test	qtype list
#3091 (reopen)	open	tensor_byte_size: 11 arms	qtype list

Mechanism of the 3-of-5 class: from_gguf_for_moe fills a MoE layer's dense FFN slots with dense_ffn_placeholder — byte_size: 0, qtype: 0. 0 is F32, so the placeholder is a well-formed F32 tensor ref until something indexes it (hence #1789's qtype=0 in the panic, and #3368). All three fixes guard a consumer; none removes the placeholder — it is still built on main, and the tied-lm_head path has a second instance (#2309/#2441). 63 non-test files read .ffn_{up,gate,down}_weight; 14 carry no guard token, including all 4 gguf/cuda consumers and the wgpu adapter (file-level heuristic, [U] as a semantic claim). Neither this spec nor PP-ARCH-001 covers it. Proposed as a sibling epic, not a change to yours: #3428 PP-TENSOR-001 (absence as a type; #3433–#3435).

Correction to my own 09:20Z comment on #3418: I classed #3091 as "arch". Its reopen is a qtype-list defect, so the split is 3 placeholder / 2 qtype-list, not 4 / 1.

4. tensor_byte_size first is the right Phase 2 opener — and it is smaller than the spec says

It lacks not just IQ* but Q3_K and Q5_1, which the crate already defines; and there are three byte-size functions, not one (transformer.rs:435, convert/q4k_conversion_stats.rs:6, convert/q4k_converter_helpers.rs:20). Reproduced on the published v0.68.0 asset with a 338 MB public file (details on #3091). Because byte_size = n / blck_size * type_size needs only the two numbers your contract already carries for all 35 rows, this one site can close for every id without a single new kernel → #3432.

5. Placement — flagged, not decided here

The operator directive of 2026-09-17 makes a slice of this 0.69.0 must-carry: fixtures (#3429) → one enum + TRAITS (#3430) → reconciliation gate (#3431, builds on your dispatch_contract_tests.rs rather than duplicating it) → byte-size + single refusal (#3432), then PP-TENSOR T1–T2. That overlaps the Phase 1 → dedicated-milestone boundary in #3423. I have not moved or re-scoped anything of yours; the per-directory retype tickets I minted (#3436–#3440, in 0.70.0) restate your Phase 2 and should fold into whichever placement wins. CI on main is p50 31 min / p95 62 min, ~69 serial slots per 72 h, merge queue builds 3 wide — throughput is not what forces a dedicated cycle; the Qwen2.5-Coder parity risk you cite is the real argument, and a per-PR perf gate on the merge sha answers it on a train.

Not done: no independent quorum has reviewed any of this — these are one reviewer's measurements. #3444 (my graph-builder ticket) duplicates your #3422 and I am closing it in favour of yours.

Ask: the branch is behind main and gate, guard-cargo, guard-tree, present are red — gh pr update-branch 3420 first; I have not diagnosed the four reds against a current base.

[noahgift]

Triage from the release babysit session (aprender-ba): the guard-tree red here is the same one as on #3499 and is a PR-body rule, not the diff:

FAIL  no `ont-delta:` line. §11.1: a sweep PR closes with a delta,
FAILED: §11.1 — a sweep that ends in prose and nothing else is not finished.

gate is red only because guard-tree is. Fix = add an ont-delta: line to the PR body, then push (an empty commit is enough) or close/reopen — the guard reads the frozen pull_request event payload, so a body edit alone never re-runs it. GitHub reports the branch MERGEABLE against today's main, so nothing else is in the way. All three of your open PRs (#3499, #3420, #3424) are blocked by this same line; I have asked the ontology owner whether the §11.1 predicate is meant to reach spec PRs at all.

[noahgift]

Update: the §11.1 predicate was the reach-too-far, not this PR. #3536 (PMAT-3535) merged at 20:04Z: the spec now names only the release spec (docs/specifications/APR-RELEASE-001-*.md) as a sweep sink, a *-MASTER.md design spec is the finding's home and not a sink, and check_pr_ont_delta.sh got the predicate self-test it never had. No body change needed — a rebase/update onto main (ce343c7 or later) re-runs guard-tree with the fixed guard.

[noahgift]

Re-run on 9b7fe4f (main merged in): the §11.1 ont-delta red is gone as predicted. Two remaining reds, both this branch's, both small:

1. guard-tree, §6 R-2 body guard: FAIL: non-closing ref(s) with no keep-open reason: #3418 #3421. The body cites those two issues without closing them; add one line each, keep-open: #3418 <reason> and keep-open: #3421 <reason>, then push (body edits alone never re-run the guard).
2. guard-cargo, README claims: contracts/census.json .n_files=1799 but HEAD carries 1800 — this PR adds contracts/quant-dispatch-completeness-v1.yaml without regenerating the census. Run make contracts (pv census) and commit the updated contracts/census.json (and README count if make readme-sync moves it).

Everything else is green. #3424 has no such reds (no contract file added) and is running clean.

[noahgift]

One more after the main merge, and this one is code, not body: workspace-test-shard (1/3) fails quantize::dispatch_contract_tests::tests::qdc_dispatch_sites_match_oracle (crates/aprender-serve/src/quantize/dispatch_contract_tests.rs:216) — PO-QDC-005 FAILED — contracts/quant-dispatch-completeness-v1.yaml dispatch_sites and the tree disagree. Main moved since this contract was written (the CB-200 lifts in #3533 among others), so the contract's dispatch_sites list no longer matches the merged tree; re-derive it against main 338f1d4 or later and the test goes green. So the full list for this PR: keep-open lines (#3418, #3421), make contracts for the census, and the dispatch_sites re-derivation.

[noahgift]

Suggestion for the workspace-test-shard (1/3) red, from the neighbouring ticket (#3430 M1 / #3581) — not pushing anything to your branch, since this is an authoring judgement on your spec.

The failing assertion, verbatim from run 35469204174, job 105966962481:

PO-QDC-005 FAILED — contracts/quant-dispatch-completeness-v1.yaml `dispatch_sites` and the tree disagree.
Matching on a raw qtype but NOT listed (a new dispatch site — migrate it to quant_type_traits() or add a row): ["crates/aprender-serve/src/quantize/iq_dispatch.rs"]
Listed as open (migrated: false) but no longer matching (flip the row to migrated: true): []

One site, one direction: the tree has a raw-qtype match in crates/aprender-serve/src/quantize/iq_dispatch.rs that the contract's dispatch_sites does not list. The smallest honest change is the row with migrated: false — that records it as known and open, which is what it is, rather than claiming a migration that has not happened. Whether it should instead be migrated to quant_type_traits() in this PR is your call and not something I would decide for you.

Two other things on this PR, both measured, so you do not spend a CI round finding them:

1. guard-cargo is the census, not your spec. FAIL contracts/census.json .n_files=1799 but HEAD carries 1800 contract file(s). Adding contracts/quant-dispatch-completeness-v1.yaml makes three tracked derivatives stale, and your diff regenerates none of them. I hit the identical thing on PMAT-3430 M1: one ggml tensor-type table, extracted from upstream rather than typed #3581 an hour ago and they surface one per CI round, because each is masked by the one before it:

   derivative	regenerate with	shows up as
   contracts/census.json	make contracts (pv census contracts)	guard-cargo, and a false row-4 self-test red downstream of it
   contracts/contracts.nt	pv extract contracts	workspace-test-shard, the_tracked_repo_graph_is_fresh (R-18)
   README CONTRACT_COUNT block	make readme-sync	guard-cargo, FALSIFY-README-002 — invisible until the census one is fixed

   Running all three before the next push saves two rounds on a pool that has been at zero idle most of today.

2. guard-tree needs nothing from you. Its only FAIL row was non-closing ref(s) with no keep-open reason: #3418 #3421, and the body already carries the keep-open: line — I ran the guard against the live body and it returns rc=0 PASS. That red is a verdict on the body as it was 17 hours before the fix (run created 2026-09-19T21:02:26Z, body updated 2026-09-20T14:00:11Z); ci.yml reads the frozen event payload and has no edited trigger, so it clears itself on your next push and needs no separate re-trigger.

Also worth knowing: that shard reported 8576/21113 tests were not run due to test failure — fail-fast, so a single failing test hid the rest of the shard. Whatever is behind those 8,576 is still unmeasured on this branch; tracked as #3587.

Refs #3430, #3581

[noahgift]

slipped_from: 0.69.0. §4.1 freeze for the 0.69 cut today (operator 2026-09-21: "ensure this happens"). Not on the 0.69 platform (#3669 + bump). Rides 0.70. — aprender-04 (cop)

[noahgift]

closed by operator 1-day PR rule; reopen/rebase to resume.

No live owner session, red CI on the current head, not carried by main or any open integration PR. Linked issue: #3418 (open, milestone 0.74.0). Linked issues are not touched by this close.

Branch is NOT deleted: spec/pp-quant-001-dispatch-consolidation @ 9b7fe4f7c.