Seal what is running on a deployed asset — who built it, who signed it, what it contains, when it changed, and what key authorized it. Proven offline, with no vendor infrastructure in the loop.
Fleet turns a fleet sustainment record — node_record.json — into a shard compiled, signed, and sealed by the axm-genesis kernel. One record shard is a self-contained, offline-verifiable answer for one asset at one moment. The chain of shards is the asset's lifecycle.
Lifecycle is a supersedes chain. An update is not an edit — it is a new shard that supersedes the previous one. The kernel seals manifest.supersedes and ext/lineage@1.jsonl; axm-fleet history walks the chain from any shard back to first fielding.
Records are succeeded, never mutated. A record is sealed once and never touched again. Deploy, patch, rollback, recovery — each is its own shard, and the sequence over time is the sustainment history. Nothing in the past can be quietly rewritten.
Identity is derived, never stored. A shard's identity is sh1_ + BLAKE3 of the manifest bytes. There is no shard_id field. Same record + same key + fixed --created-at → byte-identical manifest and identical sh1_ id.
Genesis compiles and signs; everything else reads. The spoke owns only domain extraction (record_schema.py, record_compile.py) and its CLI. It never implements signing, hashing, Merkle construction, or resealing. Suite: axm-hybrid1 — Ed25519 ‖ ML-DSA-44.
Verification never trusts the publisher.pub embedded in the shard being verified. Trust is anchored to a public key supplied out of band — escrowed, published, sealed in an offline ceremony. Verification needs no transparency log, no network, and no reference implementation.
The record document itself becomes the sealed content/source.txt; every claim cites a byte span of it. The record's digests bind the external artifacts — the shard seals the record, and the record's hashes pin the image, SBOM, provenance statement, models, and firmware by sha256 content address.
Every claim in the shard carries a tier assigned at extraction time by which part of the record it comes from — a semantic distinction, not configuration.
| Tier | Source | Claims |
|---|---|---|
| Tier 0 | digests, key id | Integrity facts — content addresses of image / SBOM / provenance / components, and the signing key id. Facts, not choices. |
| Tier 1 | configuration | Build id, versions, platform, compute module — the surface a rehost changes. |
| Tier 2 | event | What happened, when, and authorized by whom. |
./demo.sh is the product. CI runs it on every push — every claim below is a runnable command with a real, observable result, not a promise. Throwaway keypairs are generated per run; a hardcoded key would be a regression.
axm-fleet record examples/node-0042.deploy.json pool/deploy --key publisher.key compiles the deploy record and prints the derived sh1_ identity. Then axm-verify shard pool/deploy --trusted-key publisher.pub verifies it offline against a key supplied out of band → PASS.
Compile a successor with --supersedes sh1_<deploy-id>. The kernel seals the lineage — it emits manifest.supersedes and ext/lineage@1.jsonl. axm-fleet history pool/ walks the chain from the patch back to the deploy.
Flip one sealed byte in content/source.txt → E_MERKLE_MISMATCH. Verify the untampered shard against the wrong trusted key → E_SIG_INVALID. There is no escape hatch; either failure halts the pipeline.
Verify the same shard with the independent Go verifier in axm-genesis (verifiers/go), built from the spec and vectors alone. axm-verify-go shard pool/patch --trusted-key publisher.pub → PASS. Remove the reference implementation and the record still proves out — the record layer passes its own substitution test.
Same kernel, three spokes, three record types. Genesis compiles and signs all of them; each spoke owns only its own domain extraction. Fleet is the one that seals lifecycle over time.
| Spoke | Seals | Record | Shape |
|---|---|---|---|
| axm-show | Mission authorization — what may fly, under which ceiling | show_spec.json | One-shot |
| axm-fleet | Lifecycle — what is running, and how it got there | node_record.json | Supersedes chain |
| axm-sfn | Hardware custody — what the machine attested it did | session journal | TPM-bound |
A natural next step — aspirational, not yet implemented — is a hardware-attestation capsule on fleet records, following the conventions axm-sfn already established rather than inventing new ones.
A capsule carrying the node's TPM quote at record time — self-fingerprinting key rows, algorithm-tagged signature rows, blobs indexed into content/, everything recomputable from the shard alone. The kernel would seal it in one pass via extra_content/extra_ext; the claim outlives the TPM's cryptography. This tpm-attestation@1 (what hardware attested) is distinct from RFC 0005's attestations@1 (when a shard existed).