Module ledger 

Append-only access ledger: which splits were touched, under which profile.

Implemented by plan 02-04. Append-only access ledger: which splits were touched, under which profile.

The ledger has a deterministic canonical byte form and a ledger_hash, and both the records and the hash are embedded in the selection manifest payload. A ledger that exists only in memory is not evidence — the downstream selection-lock gate needs an artifact it can read.

Phase 2 records; a later phase reads (D-16)

Nothing in this phase consumes the ledger to make a decision. The persistence surface (to_canonical_bytes / from_bytes / ledger_hash) exists now because a selection lock cannot be enforced against an in-memory value that died with the process that built it, and retrofitting a canonical byte form later would invalidate every manifest produced before the retrofit.

Determinism

The canonical form is compact JSON over structs only — no maps whose iteration order could vary, no timestamps, no build metadata. Two runs that touched the same splits in the same order produce byte-identical ledgers and therefore the same hash.

Structs

AccessLedger

An append-only log of split accesses.

AccessRecord

One recorded split access.