ba1212361f
Commit the previously-untracked standard directories and catalog them in the
root README alongside proof:
- aac/ — communication cargo class: portable boards + a ten-level
offline-first cascade (Apache-2.0 code / CC-BY-4.0 spec).
- map/ — geospatial cargo class: range-requestable signed tilesets +
an F0–F4 fidelity cascade (Apache-2.0 code / CC-BY-4.0 spec).
- sandbox/— isolated, metered, attested execution across the heterogeneous
compute fabric (Apache-2.0 code / CC-BY-4.0 spec).
- jouleclaw-otel-authz, jouleclaw-trust — new jouleclaw reference crates.
Root README now lists aac, map, sandbox, and proof in the catalog, the tree,
and the contribution guide.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
2.1 KiB
Map sub-spec — Manifest and the revision chain
Normative refinement of SPEC §5. Reference: map-schema::{Manifest, ManifestBody, Revision, RevisionBody, verify_chain}.
This is the "works forever" guarantee made normative: a published tileset is a signed, dated file whose validity does not depend on any service staying online.
1. Manifest
ManifestBody = {
spec_version, datum, alt_schedule,
dir_root: ContentId, // BLAKE3 Merkle root over the sorted directory
bounds: Option<(CellKey, CellKey)>,
disclaimer: Option<String>, // required, non-empty, for air-nav tilesets (SPEC §9)
publisher: VerifyingKey, // Ed25519
}
Manifest = { body: ManifestBody, signature } // Ed25519 over canonical_cbor(body)
A reader verifies the signature against body.publisher, recomputes the
directory root from the directory it fetched, and checks it equals
body.dir_root. A tampered directory root fails verification (conformance
C-neg). The manifest's own content id, ContentId::of(&body), is the
root a revision chains onto.
2. Revision
RevisionBody = { prev_root: ContentId, new_root: ContentId, timestamp_tai_ms, publisher }
Revision = { body, signature }
A revision is a signed, dated transition. Revisions are append-only: a new
weather forecast hour, a new AIRAC navigation cycle, a re-flight of a corridor,
or a correction is a new revision, never an in-place edit. verify_chain
walks a chain from a trusted root: each revision MUST verify and MUST chain onto
the prior root, returning the head root. A break (a revision whose prev_root
does not match, or signed by an unendorsed key) is rejected.
3. Pinning and offline verification
A reader MAY pin any historical root (an archived election map, a flight plan as
filed) and MUST be able to verify a revision chain back to a trusted root
without contacting the publisher — verification needs only the bytes and the
publisher's public key. Conformance suite C3 pins manifest signing and chain
validation in ../conformance/v1/tileset_vectors.json.