A Model File That Carries Its Own Kernels

A GGUF file is normally just weights and metadata. This project's bakes carry more than that: the exact source files the kernels were compiled from, the git commit those sources came from, and, for a class of them, the prompt tokens and reference output ids a verify tool needs to gate the rebuilt engine against. Point tools/gguf-verify.sh at one of these files and it rebuilds the engine from the file's own embedded sources, runs it against the file's own embedded reference tokens, and reports whether the two agree, without touching a git checkout, a fixture directory, or anything else on the machine that happens to be lying around.

That last clause, "anything else on the machine that happens to be lying around," is the entire point, and it is also exactly where one of these bakes quietly failed.

The pipeline, one step at a time

There is no single model-import script. A comment in tools/engine-pack.py used to reference one, model-import.sh, which does not exist anywhere in the tree; that stale comment was corrected in 3444a8d. What actually runs, driven by bench/dense-run.sh and tools/bake.sh, is a chain of small tools:

1. tools/gen-profile.mojo (spark family only) generates a profile.mojo from the source GGUF's own dimensions, rope settings, and activation function, because serve/spark.mojo is not architecture-specialized at compile time the way serve/engine.mojo is.
2. tools/engine-pack.py (dense and MoE models) or tools/spark-pack.py (the spark2_5 family, whose per-head attention gate engine-pack.py refuses to handle) builds the runtime weight pack: one flat binary plus a text index, with --q8, --q4, --q2b3, --tq1, or --tq2 quantization flags. tools/q8-check.py proves the --q8 path bit-equal to llama-quantize's own Q8_0.
3. tools/embed-files.py prints the exact source-file closure a bake must embed. It deliberately never embeds serve/engine.mojo or serve/spark.mojo themselves; those two files are instead pulled from git at the bake's own recorded commit by the verify and closure tools, so that a tampered or dirty-tree bake is detectable rather than trusted.
4. tools/gguf-embed.py writes a new GGUF (the source file is never touched in place) carrying baro.kernel.* metadata: architecture, commit, file list, and the full source text of every embedded file. For bakes meant to be self-verifying, it also writes baro.run.*: the harness path and its sha256, the prompt tokens used, the reference generated ids, the environment, and the pack tool and flags used to build the weight pack.
5. tools/bake.sh orchestrates steps 3 and 4, and refuses outright to bake from a dirty kernels/, serve/*.mojo, grammar/, uregex/, minja/, or latentos/ tree.
6. tools/gguf-closure.sh rebuilds the engine from a bake's own embedded sources and gates it on the bake's own embedded reference tokens.
7. tools/gguf-verify.sh runs that closure step, then prints the running card's GPU architecture, driver, ROCm version, and power cap next to the bake's own baro.hw.* expectations. Its own inline comment is explicit that the throughput comparison it prints "is a receipt, never a pass/fail."
8. tools/gguf-receipt.py is the only writer of the project's verified-receipt ledger, and only from tools/baro verify --append. A plain tools/baro run number is explicitly labelled self-reported and never becomes a ledger receipt.
9. tools/baro is the CLI wrapping all of the above: run (self-contained, builds an engine and pack from the file alone), verify (pulls the harness from git and byte-compares it against the file's embedded copy before trusting anything downstream), serve (adds a persistent engine and pack cache keyed by a structural model id plus the file's own sha256), and receipts (lists the ledger).

What "PROVEN self-contained" actually means here

Two bakes at commit 8184f7d, the Qwythos champion and the RegesCore MoE model, both pass tools/gguf-verify.sh at 64 of 64 tokens with a rebuilt throughput close to their own embedded 20-prompt median. Both carry baro.hw.* (card, driver, ROCm version, power cap, the 20-prompt median, the run configuration, and the protocol used), baro.kernel.model, and the vendored LatentOS package under baro.kernel.src.latentos/*, which means the closure rebuilds the entire harness with no path pointing outside the file at all. An earlier pair of bakes at commit aa3f147 needed files from ~/AMDHQ/src on the building machine to close; the 8184f7d pair vendors that dependency and is what supersedes them.

The single-prompt numbers attached to these two bakes are receipts, not claims about typical throughput: the Qwythos champion rebuilt to 118.9 tok/s_gen on one prompt (p09, speculation on), and RegesCore rebuilt to 93.7 tok/s_gen on the same prompt. Neither figure is a median over a prompt set, and neither is compared against a competitor measured in the same session; they exist to show that the number the rebuilt engine produces from a cold clone of the file's own sources lands in the neighborhood of what the file already claims for itself, which is what "the closure works" means in practice.

The bake that was wrong, and stayed on the record as wrong

A third bake of the same Qwythos champion model, built before the 8184f7d pair and later superseded, is on record in ~/Models/library/INDEX.md under the label "fixture-assisted." What that label means: its closure claimed a clean pass, but the closure tool had silently fallen back to a local .work/engine-pack-q4 fixture on the building machine instead of reading the prompt and reference tokens the file itself was supposed to carry. The file's own embedded evidence was never actually exercised. The claim that this bake had been verified from itself was false, and it was only caught during a later model-library audit that deliberately checked whether tools/gguf-closure.sh's branches were building their own pack from each file's embedded pack tool, rather than from whatever happened to sit in a fixture directory.

This was not an isolated slip. The same audit found the defect in two separate closure branches: the spark family's and the qwythos-style dense family's closure paths both silently depended on local .work/ fixtures rather than on the evidence embedded in the file under test. Both were fixed across a handful of tools/ commits, and nine bakes were rebuilt clean afterward: Spark-X2.5-4B-Q8_0, Llama-3.2-1B, lily-7B, Qwen2.5-7B, Qwen2.5-Coder-7B, Granite-4.2-3B, Ornith-1.5-9B, Qwythos-v2, and a fresh bake of the Qwythos champion source itself, replacing the fixture-assisted one. All nine pass. Two of the nine still carry a separate caveat that has nothing to do with the closure defect: Qwythos-v2 has no llama.cpp agreement receipt on file, and MiniCPM5-2B is blocked outright, because the teacher-forced check run during the same audit found that serve/tokenizer.mojo has no pre-tokenizer regex for that model's tokenizer family at all. Passing a closure check and being verified against a reference are different claims, and the model library records both separately rather than collapsing "the file rebuilds itself" into "the model is correct."

What a fixture-assisted failure looks like from the outside

The dangerous property of a fixture-assisted closure is that it looks identical to a genuine one from the verify tool's own printed output. Both report PASS. Both rebuild an engine. Both produce a throughput number that looks plausible. The only difference is which bytes actually got exercised, and that difference is invisible unless something specifically checks whether the closure tool's own file paths point inside the GGUF or outside it. A tampered bake and a merely lazy closure implementation fail the same way to a naive reading of the output: they both say PASS while resting on something the file itself does not carry.

The general shape of the risk here is the same one this project keeps running into under different names: an instrument that can silently substitute a convenient stand-in for the thing it claims to be checking will keep reporting success right up until someone deliberately breaks the stand-in and watches whether the check still passes. tools/embed-files.py printing the exact closure a bake must carry, and tools/gguf-closure.sh being fixed to build its own pack from each file's own embedded tool rather than from a hardcoded local path, is what turns "the file is self-describing" from a claim in a doc into something a stranger's machine can actually confirm.

What counts and what does not

What counts as a genuinely self-contained bake, on the evidence above:

• Rebuilds its engine and pack entirely from baro.kernel.* metadata embedded in the file, with serve/engine.mojo or serve/spark.mojo pulled from git at the file's own recorded commit, never from a local checkout that happens to be lying around.
• Carries its own reference tokens and generated ids under baro.run.*, so the closure gate has something to compare against that did not come from outside the file.
• Reports baro.hw.* hardware context (card, driver, ROCm, power cap) so a throughput receipt can be read next to the conditions it was measured under, rather than as a bare number.

What does not count, even if the tool prints PASS:

• A closure step that falls back to any path outside the file, silently, when the file's own embedded data is missing or unread. This is exactly what made the earlier Qwythos bake fixture-assisted.
• A model appearing in bench/quality-models.json as servable. Only two of the eleven listed configurations there have both a perplexity pass and a task pass; the rest are blocked by construction, void from a harness accident, or simply not run in a given round, and none of that is visible from the roster count alone.
• A rebuilt throughput number standing in for a quality claim. tools/gguf-verify.sh's own comment is explicit that its tok/s comparison is a receipt, never a pass or fail; agreement with a reference model is a separate gate entirely, run by bench/dense-run.sh and reported against a MIN_PCT floor.

What this cost

Fixing the two closure branches took a small number of tools/ commits and re-baking nine models, which is cheap compared to what it replaced: a superseded bake that had been sitting in the model library, cited elsewhere as proof that this project's self-verification claim worked, while its actual verify path had never touched the evidence it claimed to be checking. The audit that found this was not looking for it specifically; it was a routine pass through the model library checking that eleven listed GGUF entries actually built and closed, and it happened to check the closure tool's own file paths along the way. A self-describing file is only as trustworthy as the tool that reads what it describes, and that tool needs the same scrutiny as the file does.

How to prove this wrong

Take any bake this project ships and delete or rename the local .work/ directory the bake tool would normally write pack fixtures into, then run tools/gguf-verify.sh against the bake on a machine with a fresh git clone and nothing else. If the verify step still passes, it is either genuinely reading the file's own embedded evidence, which is the claim, or it has found some other path outside the file to fall back to, which would reproduce the fixture-assisted failure in a new form. Either way, the receipt from that run, including whichever file paths the closure tool actually opened, is worth reporting.

Provenance

AMD RX 7900 XTX (gfx1100, RDNA3), 24 GB, one card, for every rebuilt-engine throughput figure above; none of these numbers say anything about closure or rebuild behavior on a different card. Self-describing bake commit 8184f7d; superseded bakes at aa3f147; stale comment fix 3444a8d; model-library audit commits 9a9dc21, d84324f, 04867e2, f3bf2c8, plus two smaller fixes, recorded in the project whiteboard. Details in docs/CAPABILITIES.md ("Import and bake pipeline") and docs/BASELINE.md ("Self-describing bakes 2026-09-15"), in amarbaro/mojo-baro.