which carrier, and why

	corpus → context	constitution → weights
holds	facts, versions, API surfaces	rules applied on every token
gated	per query, by similarity	per request, by naming the adapter
models	any	one base checkpoint
updates	re-seal the pack	recompile the adapter
cost per turn	tokens	none

The rule of thumb that survived measurement: ask whether the thing is consulted or exercised. A fact a model looks up belongs in the corpus. A rule that must hold on every line of output belongs in the constitution and gets compiled.

what the measurements said

Frozen Qwen3.5-4B, sealed briefs, deterministic checkers frozen before any arm ran. Full raw results and the code that produced them are in the engine repository.

arm	wordpress-theme	motion-craft
base model, nothing	3.4/14	8.7/15
rules pasted into context	4.9/14	10.2/15
capability mounted	14.0/14	14.2/15
frontier model, nothing	8.4/14	5.9/15
frontier, rules in context	6.8/14	5.2/15

Read the last two rows. On both domains, giving a frontier model the rulebook made it score below its own unaided arm — parse failures rose from 4 to 6 on motion at a 6000-token budget, so it is not truncation. Carrying rules in context costs attention and output budget; artifacts grow more ambitious and a share of them never finish. Rules in weights cost nothing per turn and cannot be skipped.

the asymmetry that decides the carrier

Compiling 213 arbitrary protocol facts moved a model from 11/53 to 37/53 — but cost 7 of 31 unrelated control questions to domain intrusion. It began answering a TCP question with "the stdio transport provides guaranteed ordered delivery." Retrieval scores 52/53 on the same facts with no damage at all.

Compiling craft rules costs nothing measurable: both craft capabilities score 30/31 on the same control set, identical to the untouched base.

The mechanism is the gate. Retrieval is filtered per query by a similarity floor, so a mounted corpus contributes nothing to an unrelated question. An adapter has no floor — while it applies, it applies to every token. So facts go where the gate is, and rules go where always-on is the point.

using one

yantrik cap verify  pack-0.1.0.ycap
yantrik cap install pack-0.1.0.ycap --db mem.db

Capabilities install beside the database, the way packs do, so a database plus its knowledge plus its capabilities copy and back up as one unit.

Then name the adapter per request:

{"model": "motion-craft", ...}   applied
{"model": "base", ...}           not applied

Naming it per request is not a style preference. Mount state on a shared server is global, so a request that does not name its adapter gets answered by whatever the previous one left mounted — with nothing in the output looking wrong. We lost a measurement to exactly that before making per-request naming the interface.

what a listing must show

Every capability page carries four things, and a missing one is information:

• The arm table — including the unaided baseline, not only the number being sold.
• The control column — what it costs on questions outside its subject. This is a gate, not a footnote: a capability that wins its category by damaging everything else is a bad capability. "Not measured" is displayed distinctly from "passed."
• The base revision — a snapshot hash, not a model name. A LoRA is a delta against one checkpoint; applied to different weights it is noise wearing a capability's name, so a runtime refuses on mismatch.
• The grader digest — efficacy figures are bound to the exact checker that produced them. Re-author a check and the claim no longer applies.

building one

A constitution of rules, a deterministic checker, and briefs. The checker is the product: it admits the training data and grades the exam, so a cheap fast teacher is safe because its mistakes are discarded rather than learned.

Cost on our runs: about $0.15 of teacher calls and half an hour of one consumer GPU per capability. The expensive part is writing the checker, which is a day of human work and the reason this is not simply a matter of renting more hardware.

The full authoring guide, every grader we have written, the raw results and the sealed briefs that produced them:

Authoring guide →

Check the claim without a GPU →

what we do not claim

Twelve sealed briefs per domain is a small n. Every figure above is a single base model. The checkers measure mechanical discipline rather than beauty — the frontier model attempts more elaborate artifacts and loses more of them to parse failures, which flatters us. And a capability trained on checker-passing artifacts is graded by that checker, so the sealed briefs are doing the work of showing it generalises.

Uploading a capability proves its bytes match its manifest and its signature verifies. It does not prove the weights are safe to run. Nothing short of running them would, which is why this page shows you a base pin, a publisher key and a control column instead of a green tick.