Why blueprints
Recipes are for home.
Blueprints are for work.
A recipe tells an engine what to try. A blueprint states what runs: every kernel, every precision boundary, the hardware and the evidence, in one content-addressed file that is signed and verified before anything in it is used.
Where this stands. The format is specified; the catalogue's blueprints are previews generated from the engine's circuit planner. Signing, the kernel registry and hot-swap are being built, so nothing in this store is signed yet, and every preview says so.
Recipe or blueprint
Community recipes got a great deal of inference running on new hardware. They are the right tool for a first serve. They are not a specification.
| Aspect | Recipe | Blueprint |
|---|---|---|
| What runs | Flags and environment variables. What they select depends on the engine version that reads them. | Every kernel by module::func, family and numerics (and, once signing is built, the SHA-256 of its compiled bytes); how each is wired into the model's circuit; the precision at every node and boundary, re-quantization included. |
| Reproducibility Not built yet | Works on the box it was written on. | Canonical encoding and a BlueprintId hash over the body. Every plan arm carries its digest, and every performance number carries the fingerprint of the record it comes from. |
| Trust Not built yet | A script, copied and pasted. | Signed with ML-DSA-65 (FIPS 204) and Ed25519; both must verify. Each kernel artifact is signed too, and the signature is checked before a single byte of the body is parsed. |
| Portability Not built yet | Assumes the engine build on the machine already has the right kernels. | Each kernel names a source: inline, internal, disk or remote. A lite blueprint and a full one with every kernel inline share one identity. |
| Operations Not built yet | Change a kernel: rebuild, restart, hope. | Kernels come from a signed registry. Hot-swap is opt-in and drains first: hold new requests, finish in-flight ones, swap, release. |
| Inspectability | Read the YAML and the source it points at. | The whole circuit, browsable: every layer, node, fused group and kernel, in the 3D view on each blueprint page. |
Drift, from our own history
Our GLM-5.3-Flash TP=3 recipe is kept equal to the environment of the serve that was measured. Its env block was written from the measured run on 14 October and re-copied three more times by 16 October as the engine gained levers, each time checked by hand.
A blueprint makes that check the loader's job: settings are typed and complete, and a lever the blueprint does not state is refused rather than silently read.
- 56env levers
beaa439fe - 59env levers
6b7847ca1 - 60env levers
0569ac44a - 69env levers
beff65e7b
What the format guarantees
As specified. What is marked not built yet is designed but not running; what is unmarked you can see on every preview page today.
The circuit is the contract
The model is stated as a circuit graph: nodes, the tensors between them, blocks and state. The planner fuses it into kernel groups per mode and row count, and each plan arm records a digest a loader must reproduce.
Kernels by content, not by name Not built yet
A kernel is
module::funcplus the SHA-256 of its compiled module. An old artifact under a new blueprint, or one built for another architecture, fails the hash or the architecture check.Precision at every boundary
Weight and activation formats are resolved per linear node, every edge carries its format, and the inserted quantize steps are nodes of the graph rather than side effects of a flag.
Verified before it is read Not built yet
Header bounds, body hash, certificate chain, expiry and revocation, then both signatures. Only after that is the body decoded. A lower revision of the same lineage is refused unless the operator allows it, and that is reported, so an old blueprint cannot be replayed silently.
Numbers with a fingerprint
A blueprint holds references to evidence, never bare numbers. In this store a figure appears only beside the record it came from: the record's hash, the engine commit and binary, and the argv and env hashes.
Change without a restart Not built yet
With hot-swap enabled, a new revision of the same architecture can replace remote kernels. Each rank validates the new kernels against the old on a probe step before all ranks commit together.
Anatomy of a .kbp
One file, five sections. The signature covers what the blueprint means; the sections that only say where kernel bytes live sit outside it, because every byte is checked against the hash the signed body pins.
- Headersigned in part
72 bytes: magic
MKBP, format version, flags, section lengths and the body's SHA-256. The format, body length and body hash are signed; bounds are checked before any allocation. - Signed bodysigned
The blueprint itself, in canonical postcard: checkpoint pin, hardware, circuit, precision, plan arms, kernel set, typed serve settings, evidence references.
- Locator tableunsigned
Where each kernel's bytes can be found: inline, internal, disk or remote. Unsigned on purpose: whatever the source, the bytes must hash to the value the body pins.
- Inline payloadsunsigned
The compiled kernels themselves, when the blueprint is shipped in full. Converting full to lite rewrites only this section and the locators.
- Signature blockML-DSA-65 + Ed25519
ML-DSA-65 and Ed25519 signatures over the header fields and body, with the certificate chain back to an offline root.
Swapping a kernel in a running serve Not built yet
Off unless enabled, and only for kernels sourced from the registry. Any failure keeps the old kernels.
- 1OfferNew kernels fetched, verified and loaded beside the old ones.
- 2HoldNew requests wait; nothing is dropped.
- 3DrainIn-flight requests finish on the old kernels.
- 4CommitEvery rank validates, then all swap at the same step.
- 5ReleaseHeld requests run on the new kernels.
See the whole circuit
Every blueprint page draws its model as a 3D graph you can orbit, filter and colour by layer kind, precision or kernel family.