jcp: an erasure path that neither breaks the chain nor loses the joules #74

Closed
dcharlot wants to merge 1 commit from jcp/erasure-tombstone into main

2026-09-01

David Charlot
jcp: an erasure path that neither breaks the chain nor loses the joules
All checks were successful
standards workspaces build + test / aac-rs (pull_request) Successful in 49s
standards workspaces build + test / joule-code-rs (pull_request) Successful in 46s
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m49s
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m13s
standards workspaces build + test / proof-rs (pull_request) Successful in 1m12s
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 4m10s
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m1s
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 50s
standards workspaces build + test / map-rs (pull_request) Successful in 39s
standards workspaces build + test / mesh-rs (pull_request) Successful in 31s
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m35s
standards workspaces build + test / openpay (pull_request) Successful in 1m27s
standards workspaces build + test / arl-rs (pull_request) Successful in 10m13s
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 10m1s
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 9m59s
standards workspaces build + test / joulehook-rs (pull_request) Successful in 9m43s
standards workspaces build + test / sense-rs (pull_request) Successful in 8m26s
No receipt chain in open-standards had a redaction primitive. Chains are
append-only by construction, which is exactly right for evidence and exactly
wrong for a deployment that has to honour a data-subject erasure request — so
the absence was a hard blocker, not a missing convenience.

The chain links on envelope bytes: each entry's `prev` is the content id of the
one before it. An entry therefore cannot be edited or removed to satisfy a
request, because either breaks every link after it, and a chain that no longer
verifies is not evidence of anything — including of the erasure. Erasure has to
be forward-only.

`ReceiptLog::erase` appends a `jcp.tombstone/1` entry. The erased envelope stops
being retained by the operator; its content id is unchanged, so the links still
resolve; and the tombstone records that the erasure happened, where in the
order, and under what authority. What is lost is the ability to read what was
done. What survives is that something was done and what it cost.

**The joules stay, deliberately.** Every energy total, efficiency figure and
facility rollup over this log is a sum across its entries. An erasure that
dropped the cost would silently shrink all of them, and the shrinkage would be
indistinguishable from a genuine efficiency gain — a conservation break arriving
through the back door of a privacy feature, of exactly the kind the sibling
standards refuse elsewhere. The acquisition class rides along for the same
reason: a figure without one is not comparable to the others in the same sum.
Joules and a provenance label are not personal data; the payload hash, resource,
subject and action are, and a test asserts none of them appear.

The authority field is a request reference or policy id, never the requesting
party's identity — a tombstone that named the subject would re-introduce the
datum the erasure removed.

A tombstone carries its own profile so no reader mistakes it for a decision that
happened to have no payload, and the test compares the sealed payload
byte-for-byte against the expected chained wire rather than re-parsing it,
pinning the content as well as the signature.

Surfaced by the 2026-08-29 sweep, inside its refutation of the IETF agent
audit-trail draft: the draft proposes a tombstone with a content fingerprint,
and cannot retain the cost because it has no energy field at all.

Verified: 264 jcp-rs tests pass (4 new), conformance passes all classes, no
clippy warnings in jcp-receipt.
2026-09-01 05:58:53 -04:00