pub const VERSION: u16 = 1;Expand description
Which canonicalization rule this build implements.
1 is RFC 8785: UTF-16 code-unit ordering of object keys (so a signed
Agent Card verifies against the standard rather than only against this
crate) and ECMAScript number formatting for doubles — 4.5 stays 4.5
but 1e30 becomes 1e+30 and 100.0 becomes 100 — completing JCS for
everything a Value can hold except integers beyond ±2⁵³, which stay
exact for the reason the module docs give.
§Why a digest is not enough on its own
A rule change moves every derived digest — effect keys, manifest digests, plan digests — and nothing on the record would say which rule produced them. The journal chain is never at risk, because it hashes the bytes it stored rather than re-canonicalizing them. The exposure is replay: a run recorded under one rule and replayed by a build implementing another recomputes different effect keys and is quarantined as non-determinism — a healthy run, reported as the most serious conclusion this runtime reaches, with nothing on the record to say the rule moved underneath it.
So the version is journaled at admission and replay compares it first. A run written under another rule is unverifiable by this build, which is a different sentence from this run diverged and the one the evidence supports. That distinction is the whole point: an audit must report unknown scope as prominently as corruption, and never as corruption.
§It names the digest algorithm too
This number governs the whole derivation — the canonicalization rule and the hash applied to it — because the two only ever move together: a reader that cannot reproduce a digest cannot check a chain, whichever half changed. So replacing SHA-256 is a bump here rather than a migration anywhere, and history written under the old pair stays verifiable under it, because nothing rehashes stored bytes. Signatures are agile on their own terms, not on this one.