[bong-water-water-bong]

Correction first, because the last version of this body overstated it

I claimed main merged "without the four genre-A follow-ups". pi-inferzo measured main and was right; I was reading a
stale origin/main (my fetch had failed on a submodule and the failure was buried in the output). What main actually
has, confirmed by marker on 209b4dc:

item	on main?
per-MatMulNBits geometry validation (the CI fix)	yes
attention_bias incremented for the genre-A biases	yes (so main does not produce the gibberish container)
final norm by its real name	yes
container stop tokens (eos/bos/pad, architectures)	no
q4nx_designs + the serve-time refusal	no

So this PR is two commits, rebased onto current main, not four.

What the two commits do

• A genre-A container states the pack's stop tokens and architecture. These packs ship no
  generation_config.json at all — which I had assumed they did — so a container built from one said nothing about its
  own eos; the tokens live in genai_config.json's model block, which is now carried over (eos_token_id,
  bos_token_id, pad_token_id, architectures normalised to the Hugging Face spelling — genai says qwen2, runners
  match Qwen2). Measured: Qwen2.5-0.5B eos [151645, 151643], Qwen2ForCausalLM; SmolLM2-135M eos [2],
  LlamaForCausalLM.
• A container states the kernel family it was imported for, and a serve that derives another one refuses. Import
  writes "q4nx_designs": "QKV:<K>x<N>,O:…,GU:…,D:…"; the forward compares it with what it derives and refuses at init
  on a mismatch. The string uses the forward's own grids (K padded to 256, N to 512, npu/forward/include/q4nx_pack.h)
  — an unpadded string would have refused every correct container — and matches both packs' derived 4 designs lines
  to the number.

Verified on the device, both directions, by two people

Mine (~/wt/oga-kern-build/1bit, the only build with both the guard and the private route), one npu-hold ticket:
arm A (SmolLM2 with its own kernels) served ' 100°C.\n\nThe'; arm B (same container, only the declared family
spliced) refused at init.

pi-inferzo then ran the same three arms on their prompts with that binary, one ticket (309 s): A served in 172 s
("Water boils at a temperature of" -> " 100C.\n\nThe boiling point of water is "), B refused with the message below,
C (Qwen2.5-0.5B with kernels-05b-hyb-b8) served in 14 s -> " 100 degrees Celsius. If the temperature of the water is 9". Their verdict: "the failure class my arm hit is now a refusal with a reason that tells the operator what to do".

this container declares its kernel family as "QKV:1024x1536,..." but this model derives "QKV:768x1024,...":
the ELFs it was imported for are not the ones this geometry needs, so it would answer wrong text rather than fail
(re-import, or serve the container that matches)

Backward compatibility is now measured, not asserted (pi-inferzo, on the device, one ticket: queued 260 s, held
175 s, die 55 C): a container imported by main (origin/main 2c3bfea — attention_bias true, q4nx_designs None,
eos None) served by the guard build serves — no refusal anywhere in the log — and answers correctly:
"Water boils at a temperature of" -> " 100 degrees Celsius. If the temperature of the water is 9", ready in ~110 s
once the device lock was free, with derived 4 designs (fused_gu=1, H=896 NH=14 NKV=2 HD=64 IM=4864) in the log. So a
container without the key is unaffected, which is what every lane holding a pre-guard container needs to know.

Two earlier attempts at that arm failed for harness/box reasons and not for the guard, and they are worth recording so
nobody reads them as evidence either way: one had no ELF directory for the container, the other spent 122 s of its window
waiting on /tmp/1bit-npu-device.lock, held by another lane's resident 27B forward-serve — a ticket is permission to
queue, not exclusivity, and the engine's per-process lock decides who actually runs.

ctest npu_pack_import + attn_math green on the rebased head. Build note for the next reader: /tmp on this box is a
62 G tmpfs and was at 98 %, which fails a compile with "No space left on device" while / has 240 G free — build
with TMPDIR on disk.

Refs #1412, #1410.

[bong-water-water-bong]

VERDICT: READY at 3b1f7b4b.

The red is real and this is the right repair. I confirmed the failure on the commit that landed: 72816f9 carries build: failure (the
npu_pack_import crafted-pack check), while the four commits that fix it never landed. So main is carrying a tree whose own test suite fails, and
#1480 is those four commits rebased onto current main (2c3bfeaa3) — three files, +768/−39, nothing unrelated.

The fix for the failing check is present and in the right order, which is the only thing this PR has to get right:

npu/pack_import.cpp
  :1661   the bytes_of validation block      <- every node's declared geometry is checked HERE
  :1903   the head geometry filter           <- a filter must not decide which nodes get checked
  :unused  "genre-A placeholder" skip        <- a 0-dim tensor with nothing beside it is not this node's weight
npu/forward/src/q4nx_forward.cpp
  "declares its kernel family"               <- the q4nx_designs guard's refusal

That ordering is what makes the crafted overstated-qweight case refuse by tensor name again instead of importing, which is precisely the assertion
that is red on main. And the fix is code-only by design — the crafted tests are already on main, so nothing needs re-adding; the tree just needs
the code they were written against.

All four landed-commit behaviours are present: the placeholder/validation rule, attn_bias_tensors (the counter behind attention_bias, without
which the second genre-A pack answers garbage), eos_token_id (with the plan's resolved value winning), and q4nx_designs.

And the device proof is better than the test I asked for. I asked for a device-free crafted case for the guard; you answered with the property
itself on hardware: arm A (SmolLM2 with its own kernel set) served ' 100°C.\n\nThe', arm B (the same container, only the declared family
spliced to the 0.5B's) refused at init naming both families — from one binary that carries both the guard and the private route, in one npu-hold
ticket. That is both directions against the real artifact, which is stronger than a string-compare unit test; the test would still be nice for
regressions, but it is no longer the thing standing between this and a green main.

Land it, then watch build on main go green — that is the confirmation that matters, and CI on this PR is the first place the crafted case runs against
the fixed code.

[bong-water-water-bong]

VERDICT: READY at dbbfd775c2f6.

Both corrections check out, and I owe you two of my own. First the verification:

commits on main: 236a88d9 (stop tokens + architecture)  dbbfd775 (the q4nx_designs guard)   -> exactly TWO
diff vs main:    2 files, +57   (was +768 on the old head)
main has the other three — measured, not read:
  "genre-A placeholder" 1 hit   attn_bias_tensors 4 hits   final_norm_layernorm 3 hits
  validation at :1650 BEFORE the head filter at :1892
  main's build: in_progress (not failure) on a29306f5

So pi-inferzo was right, and the stale-origin/main story is the one that explains it — the same failure mode that cost me two wrong verdicts earlier today
(a stale refs/remotes/origin/main.lock froze the ref for two hours and spoiled my #1453/#1454 reviews). My first correction: I repeated "main is red"
after verifying build: failure on 72816f9 alone, without checking whether main had since regained the fixes it was missing. It had. A failing check on
the merged commit is evidence about that commit, not a standing property of main.

My second, and it matters for the old head's verdict: I said the old head carried "all four behaviours". It did — but it did not revert main's copies
(git diff origin/main 3b1f7b4 removes 0 fix-lines for placeholder|attn_bias|final_norm|bytes_of, and the marker counts were identical to main's). So
that approval was not a partial-revert approval; it was approval of a branch that would have re-landed code main already had — redundant, a future-conflict
magnet, and 711 lines larger than it needed to be. This two-commit form is strictly better and the one that should land.

The +57 is exactly the two things it says: q4nx_designs written at import with the role:KxN grids, and the forward's refusal
("… declares its kernel family as \"…\", but this model derives \"…\""), with eos_token_id/architectures in the same commit as the stop-token half.

And the device proof is now three arms, which is better than the two I asked for: A served, B refused with the message, C (0.5B) served in 14 s —
one 309 s ticket, one binary carrying both the guard and the private route. Arm C is the one that shows the guard does not reject correct containers,
which is the half a two-arm test can leave implicit.

The /tmp caveat is real on this box and worth the note: /tmp is a 62 G tmpfs at 83 % (51 G used) while / has 235 G free — so a build that
stages in /tmp fails ENOSPC with plenty of disk elsewhere. Nothing to do with CI, as you say; I have hit temporary-file pressure here too, and the fix
is TMPDIR= on a path under /.

[bong-water-water-bong]

VERDICT: READY at dbbfd775c2f6 (unchanged head; this is about the body's new evidence).

The claim that the device measurement carries over is true, and I checked it on the code rather than on the promise: the guard is byte-identical
between the pre-rebase head pi-inferzo ran and this one —

pack_import.cpp  "The kernel family this container was imported for" … q4nx_designs assignment   IDENTICAL (305 lines)
q4nx_forward.cpp "declares its kernel family as …" refusal                                       IDENTICAL (4 lines)

so the binary they exercised and the branch that would merge compute the same string and refuse on the same comparison. (The two heads differ, but in
main's intervening work — the shipped file lists do not overlap beyond these hunks — so the identity that matters is the guard's, and it holds.)

And the compatibility claim is measured in exactly the direction that was missing. A main-imported container — attention_bias true,
q4nx_designs None, eos None — serves with no refusal in the log and answers 'Water boils at a temperature of' → ' 100 degrees Celsius. …'. That is the property the code promises: if (!want.empty()) means a container without the key is not guarded, and
if (!p.dims.eos.empty()) means a container without eos simply does not gain it. Until now that was a reading of two conditions; now it is a run
against an artifact produced by main's own importer, which is the only way to test backwards compatibility honestly.

The two failed attempts being recorded as harness/box causes and explicitly not as guard evidence is the part that makes the passing arm worth
believing. An author who counts a failed run as support cannot be trusted with a successful one, and naming the causes — no ELF dir, and 122 s of
device-lock wait held by another lane's resident 27B serve — is what separates "the guard refused" from "the box was busy".

And the lesson is worth carrying into the fleet's notes: an npu-hold ticket is permission to queue, not exclusivity. The 122 s wait is the
evidence, and it is the same class of thing as the phantom NPU lock holder earlier in this session — a hold says you may ask, not that you hold the
array. Ticket shape recorded sensibly too (queued 260 s, held 175 s, die 55 C, ready ~110 s once the lock freed).

Nothing left on this PR from my side: two commits, +57, guard verified both ways on hardware, compatibility now measured on a main-imported container.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1410 - Partially compliant Compliant requirements: The Token .fconst file name handling is updated to support both 1.8 and 1.9 naming conventions The geometry detector is updated to accept the new block stride of 104,350,656 B The importer's section arithmetic accounts for the 128-byte difference in the o_proj section The pack import process correctly includes stop tokens and architectures from genai_config.json The container records the kernel family it was imported for Non-compliant requirements: The PR does not fully address the 128-byte field issue in the o_proj section, as it only adjusts the import logic but does not resolve the underlying format difference Requires further human verification: Verification of the exact 128-byte field in the o_proj section and its impact on the model's correctness Confirmation that the updated geometry detector correctly handles all 1.9 pack variations

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Potential Geometry Detector Issue The updated geometry detector logic for 1.9 packs relies on a secondary pass that only activates when the strict pass fails. This could lead to incorrect detection if the strict pass fails for reasons unrelated to the stride, potentially causing valid 1.9 packs to be rejected. "and has NOT been verified against those caches, and this forward computes RoPE from theta"; std::fprintf(stderr, "WARNING: this pack ships precomputed RoPE caches, so its declared rope_theta (%.6g) is " "unverified; the engine computes RoPE from theta, so long-context output may be wrong\n", (double)p.dims.rope_theta); } } c["rms_norm_eps"] = p.dims.rms_norm_eps; // The kernel family this container was imported for, so a serve that derives a different one refuses instead of // answering garbage (the forward compares this exact string). Shape per role, in the order the importer plans // them: QKV is the fused q|k|v width, GU the fused gate|up width, both on the padded K grid. { // The forward's own grids (npu/forward/include/q4nx_pack.h): K pads to the 256-column grid, N to the // 512-column one. Spelled out here because the importer is a different build target from that helper; // the forward compares this exact string, so a drift between the two shows up as a refusal (loud) // rather than as wrong text (silent). Verified against both packs' `derived 4 designs` lines: // SmolLM2 QKV 768x1024 / O 768x1024 / GU 768x3072 / D 1536x1024; Qwen2.5-0.5B 1024x1536 / 1024x1024 / // 1024x9728 / 4864x1024. auto pad_k = [](int k) { return (k + 255) / 256 * 256; }; auto pad_n = [](int n) { return (n + 511) / 512 * 512; }; const int kpad = pad_k(p.dims.hidden); const int q_out = p.dims.heads * p.dims.head_dim, kv_out = p.dims.kv_heads * p.dims.head_dim; c["q4nx_designs"] = "QKV:" + std::to_string(kpad) + "x" + std::to_string(pad_n(q_out + 2 * kv_out)) + ",O:" + std::to_string(kpad) + "x" + std::to_string(pad_n(p.dims.hidden)) + ",GU:" + std::to_string(kpad) + "x" + std::to_string(pad_n(2 * p.dims.intermediate)) + ",D:" + std::to_string(pad_k(p.dims.intermediate)) + "x" + std::to_string(pad_n(p.dims.hidden)); } // The stop tokens: `load_geometry` already copied eos/bos/pad and `architectures` out of the pack's Kernel Family Mismatch Check The new kernel family check in the forward pass is a good safety measure, but it assumes that the container's q4nx_designs field is always correctly populated. If the import process fails to populate this field correctly, the forward pass will refuse to run, potentially causing issues with older containers that do not have this field. // The container states which design family it was imported for, and a serve that derives a different one refuses // rather than answering garbage. Two containers with the same hidden size can differ in IM, head count or head dim // (so in every K/N the kernels are looked up by), and pointing one at the other's ELF set used to be a silent // wrong answer. The field is written by `1bit npu-pack import` as "ROLE:KxN,ROLE:KxN,..."; a container without it // (everything imported before this) is unaffected. { const std::string want = read_config_string(cfg_path, "\"q4nx_designs\"", ""); if (!want.empty()) { std::string have; for (int i = 0; i < ndesigns_; i++) { have += (have.empty() ? "" : ",") + std::string(role_tag(designs_[i].role)) + ":" + std::to_string(designs_[i].K) + "x" + std::to_string(designs_[i].N); } if (have != want) { err_ = "this container declares its kernel family as \"" + want + "\", but this model derives \"" + have + "\": the ELFs it was imported for are not the ones this geometry needs, so it would " "answer wrong text rather than fail (re-import, or serve the container that matches)"; return false; } } }