Status is earned — the ladder, the guards, and the lock.

The bracket walkthrough showed one job climbing from draft to executable and getting knocked back a step by a change to the shipping terms. That post was the story. This one is the rulebook behind it: the exact conditions for each level, the guards that refuse a bad quote or a bad award, and the one state a traveler can't leave.

The through-line is a single design choice from the idea post: where a job stands is computed, not declared. There is no status field for a person to set. A traveler is at a given level because its contents satisfy that level, and both reference implementations — reading the same file — report the same level. The register's C6 row pins this with shared vectors for real travelers at L0, L1, and L2.

The ladder, with its ingredients

Three things to notice.

L0 is about the seller's question, not the buyer's intent. A buyer can be certain a job is ready; if the material is missing, it's a draft. The test is whether someone else could price it without a phone call.

L1 depends on a word — bound. A quote carries the fingerprint of the job it priced (traveler_hash_quoted). It's bound when that fingerprint equals the traveler's current fingerprint. A quote against an earlier revision isn't wrong, exactly; it's about a different job, and it's marked stale. A traveler with three stale quotes and no bound ones is at L0, not L1.

L3's contents are deliberately unspecified in 0.1. Both implementations compute the level — is there a non-empty as_built object on an executed traveler? — but what goes inside it isn't defined by the spec yet and isn't covered by conformance vectors. The spec says this plainly rather than pretending the as-built record is finished.

What a quote has to be

For a quote to count at all, the spec requires:

quote_id, seller, traveler_hash_quoted, created_at,
valid_until, lead_time_days, pricing

with pricing carrying a currency and one or more lines, each line a quantity of at least one and a unit price as an integer number of minor units (cents), between 0 and 10¹². No decimals, no unbounded numbers — Part 2 explained why.

The binding fingerprint is the field that matters most, and in the reference tools it isn't typed in. It's computed from the traveler in hand at the moment the quote is attached. Over the MCP surface — the tools an AI agent on either side would use — the quote tool has no input for it at all; the register's M2 row is the test that a binding cannot be asserted, only earned. You can't claim your quote covers a job it didn't see.

The four guards

A conforming desk checks these when a quote is attached or awarded. In the reference code, the per-seller check runs when a quote is attached, expiry and the priced line are checked at award, and ITAR is checked at both. Expiry and the priced line are tests in the register (L3) and ITAR is L4; the one-quote-per-seller rule is enforced in the reference code but doesn't have its own register row yet.

1. Expiry. A quote past its valid_until can't be awarded. It still counts as bound — it priced this revision — and an expired quote can still be attached, but the award is refused. The strict, shared datetime rule from Part 2 is what makes both sides agree on when that moment is.
2. One quote per seller per revision. A seller doesn't get to stack three prices on the same version of a job. Re-quoting is for a new revision. (The reference code — the desk and the MCP tools share it — is stricter than the spec here today: it also counts a seller's stale quote from an earlier revision, so that seller can't re-quote after an amendment. That's a bug, and we're fixing it.)
3. A priced line at the target quantity. The traveler asks for 250. A quote whose lines cover 100 and 500 but not 250 doesn't price the job that was asked, however reasonable the interpolation looks, so it can't be awarded.
4. ITAR consistency. A traveler that declares ITAR-controlled data can't take a quote from a seller who doesn't declare ITAR. The spec is careful about what this is: a consistency check, not compliance. There are two layers to it. The lifecycle guard — the one the reference desk runs at bind and award — checks the seller's self-declared itar bit (L4). The signature layer in the reference libraries goes further: an ITAR traveler's seller must hold the ITAR capability attested in the signed key directory, not merely claim it (PQ6), which part 5 covers. Neither is ITAR registration with the State Department's DDTC, a technology control plan, or an export classification (an ECCN), and the spec says so in the same sentence.

What an amendment does

Change anything in the quoteable body — a quantity, a rev, the Incoterms — and three things happen at once (L1):

• the traveler's revision increments;
• the fingerprint changes, because the body changed;
• every existing quote is marked stale, because none of them are bound to the new fingerprint.

If the traveler was at L1, it drops to L0. The sellers see their quotes marked stale the moment they open the amended file; nothing has to be explained over the phone. And a stale quote can't be awarded (L3) — there's no path to accept a price for a job as it used to be.

This is the rule that generates the most pushback, and the walkthrough post took it head on. The format doesn't adjudicate which changes are material. Every change to the priced body is a new revision, and the seller decides whether their price stands by quoting again.

The lock

Awarding a bound quote — with an operations list and a ship-to present — takes the traveler to L2, and at L2 it locks. An amendment on a locked traveler doesn't take: the reference store either ignores it or raises "Executable traveler is locked," depending on the path, and either way the revision doesn't move and the quoteable body can't change. The register's L2 row is the test.

Two consequences follow from how the hash was drawn in Part 1:

• The award doesn't change the fingerprint. Award, ops, and ship-to live outside the quoteable body, so the seller's quote stays bound to exactly what they priced, all the way to delivery.
• A change after award is a new conversation. Not a quiet edit to a file someone has already scheduled material and machine time against. If the buyer needs rev D after awarding rev C, that's a new traveler, and both shops know it.

The MCP tools enforce the same thing from the other direction: the amend tool can't inject an operations list, a ship-to, or an as-built record to walk a traveler up the ladder without an award (M1). A level is earned through the same path on every surface.

The audit trail underneath

Every compose, quote, amend, award, and import is appended to the desk's local audit log with a timestamp, in order (L5). On the reference desk it's capped at a hundred events and contains no personal data; it's there so a shop can see the sequence of what happened to a job, not as a compliance artifact. The trust page in the repo is explicit that a central, immutable log with alerting and retention is the operator's to provide — this is the local record, not the enterprise one.

What a level is not

The spec includes a section it calls export control and commercial reality, and it's worth repeating here because the ladder can look like more than it is:

• An award is not a purchase order, and a bound quote is a structured price, not a contract. In 0.1 an award may carry optional commercial terms — governing law, warranty, payment — but carrying them doesn't make it a contract by itself. There's no battle-of-the-forms logic in a file format, and there shouldn't be.
• Incoterms is a free-form string. Incoterms are the standard shipping-term codes, like FOB and EXW. The spec even notes the common mismatch: Incoterms 2020 FOB means sea or inland waterway with a named port, while a US domestic shop writing FOB usually means F.O.B. origin or destination under the UCC (the US commercial code). The field records what the parties wrote; it doesn't interpret it.
• Buyer and Seller on the desk are a view switch, not login, not tenancy, not least-privilege. The reference desk demonstrates the format. Identity is the signature layer; access control is the operator's.
• The lifecycle fields aren't signed yet. The award, ops, and ship-to are protected against corruption and naive tampering in transit by the full-file digest from Part 1 — it's unkeyed, so someone rebuilding the archive can recompute it — but authorship signatures in 0.1 cover the quoteable body only (G7). Signing the award is a named candidate for a later revision, not a thing the spec claims today.

What to take from this

For a shop: a job's status is something your software and your partner's software compute from the same file, and they'll agree. Nobody's "ready" checkbox is in the loop. For an implementer: the levels are a pure function of the document; the four guards run when a quote is attached or awarded; an amendment marks every quote stale; L2 is terminal for the body. Build those and the public vectors will tell you if you got them right.

Next: the archive the traveler travels in, and why a zip from a stranger is designed to be something you can open without getting hurt.