| Filename | Latest commit message | Latest commit date |
|---|---|---|
e0e9fa7831
Applying the producer to a second standard found something about the `E3` mechanism rather than about that standard. `map/conformance/v1/joulespec.toml` maps every conformance item of the map standard's §8 to a named check with a counter-artifact, and all of them reach `E3`. Four did immediately. The fifth did not, and the reason is the point. That standard's `verify_envelope` enforces its steward twice: once as the envelope's key identifier, and again because the steward sits inside the signed core the envelope commits to, so a wrong steward also fails the payload comparison. Disabling either check alone leaves the other standing, and the test keeps passing. The harvester reported that the check could not see its subject — true, and misleading, because the check is strong and the mutation was well aimed. Neither of the two readings the producer's own documentation offers fits. It is a third case: the artifact state in which the check should fail is not one edit away from the state in which it passes. So a counter-artifact may now declare several edits. They are applied before anything runs and reverted together, in reverse order, including on a panic; if any fails to apply, those already applied revert as the partial vector drops, so the tree is never left half-mutated. The witness's report records how many were applied, because a state several edits away is a different claim from one edit away and a reader should not have to open the manifest to tell. The single-edit form is unchanged and the proof standard's manifest, which uses it throughout, still reaches `E3`. SPEC §2.5 states the rule: nothing in the rung says the failing state is one edit away, and a conforming producer must accept several and record the count. The schema refuses a counter-artifact that declares both forms, or part of the single-edit form, or no edit at all: the first is ambiguous about what the artifact state is, and the others claim to be a counter-artifact while describing nothing. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
| .. | ||
| v1 | ||
| README.md | ||
Map conformance
An implementation is conformant if it round-trips the published wire vectors
in v1/. The reference harness is map-conformance in
../map-rs/:
cargo run -p map-conformance --bin map-conformance # run the suites (exit 1 on any FAIL)
cargo run -p map-conformance --bin gen-vectors # regenerate v1/*.json
Suites (SPEC §8)
| Suite | Covers |
|---|---|
| C1 | Cell-key canonical CBOR + content id; the time axis distinguishes otherwise-equal cells. |
| C2 | Directory is Hilbert-sorted; the range planner coalesces a viewport; payload hashes verify. |
| C3 | Manifest signs/verifies; the revision chain validates back to a trusted root. |
| C4 | The cascade closes at the highest tier ≤ the request and falls back to the F1 floor. |
| C5 | JCR-1 receipts seal, verify, reject the wrong steward, and enforce the provenance coupling. |
| C-neg | Tampered manifest root, unendorsed revision, dishonest receipt, unsorted directory — all rejected. |
Vectors are deterministic (fixed Ed25519 test keys), so gen-vectors produces
byte-identical files and a third-party implementation in any language certifies
by reproducing them. Receipt vectors are byte-compatible with the family's
existing JCR-1 verifiers.