Cassette Build Report 049 — One Model, Several Hardware Plans

Scope note: This report covers S20’s certified hardware-plan catalog and the review of its production guard and fixture. It concerns plan selection and persistence metadata, not live qualification of a physical device or a claim that one plan is universally best.

S20 was the first step after the whole-system audit. Its question sounded practical: how should Cassette describe several possible machines for the same model without copying the model into each plan?

The answer had to stay smaller than a hardware benchmark. A plan could record measured memory, throughput, minimum bandwidth, and the limits that make a selection valid. It could not smuggle a second model into the catalog. The model remained one immutable authority. The plan described how that authority could be approached under a named profile.

Kimi K3 Max reviewed the machinery first. One-, two-, and three-plan roots shared one executable identity. Reversing specification order produced the same root. Three named latency profiles selected the expected plan. A plan one byte per second below its floor refused. A nonzero weight-payload field was structurally impossible, and a resealed nonzero payload still refused. The baseline was thirty-seven of thirty-seven tests with a clean ledger.

That result was strong, but Kimi’s first mutation report was too broad. Kimi removed the catalog-detachment comparison and built a forged catalog whose budget was changed to seventeen bytes. The fixture stayed green, so the first account called it a production admission. Sol traced the attack. The forged root had been derived from the source root and had discarded the repacked physical index. It failed on a layout mismatch before the catalog-binding guard ran.

The production guard existed. The fixture was wrong.

That distinction is not a footnote. A test can fail to prove the thing it was designed to prove while still catching an earlier failure. The red or green color is not enough. We need to know which refusal happened.

The S20 record now makes the plan a generated contract. The implementation keeps the persisted plan metadata explicit:

_HARDWARE_PLAN_FIELDS = (
    "plan_id", "profile", "memory_bytes", "bandwidth_bytes_per_second",
    "weight_payload_bytes",
)

plan = {
    "plan_id": plan_id,
    "weight_payload_bytes": 0,
}

The metadata-only plan record in compiler.py puts the prohibition in the record that crosses the persistence boundary. The zero is not a claim that all hardware has zero model bytes. It says this catalog does not own a second weight payload. The model remains elsewhere, with its own identity and verification.

Opus 5 Max found another problem in the review language: a plan had been described with an unverified superlative, as if it were the best or lowest-latency option. The evidence supported selection under measured profiles. It did not support “best” without a defined comparison set and a current measurement boundary. The wording was narrowed. A plan can be selected because it satisfies the requested profile and predicts the lowest latency among the plans in this catalog. That is a finite claim.

The generated schema mattered for the same reason. S20 introduced hardware_plan.json and hardware_plan_catalog.json instead of leaving their fields as handwritten sets inside compiler.py. The validator runs before semantic reconstruction. A malformed persisted plan does not become meaningful because the code can guess what it meant.

The repair to the fixture was surgical. The forged root now starts from the planned root, preserves the physical index, changes only the catalog value under test, and asserts that removing the catalog comparison makes the fixture fail. The second run passed thirty-seven of thirty-seven tests, and the ledger was clean.

There is a larger point here about “supporting hardware.” A product can say it supports three machines and still mean three different things: the same model can be planned for three profiles; the same weights can be loaded three ways; or three separate model artifacts can exist. S20 chose the first. The plan is a measured description around one model identity. It is not a new model and not a live device certification.

I liked the way the agents disagreed here. Kimi supplied the independent attack and then accepted the narrower diagnosis. Opus removed the superlative and kept the comparison finite. Sol repaired the contract and the fixture. My job was to keep “the guard works” separate from “the fixture proves the guard.” Those sentences are close. They are not interchangeable.

S20 closed with one model, several certified plan records, generated validation, and a selection rule that says what it knows. The useful hardware plan is not the one with the grandest label. It is the one whose identity, limits, and evidence can survive the next question.