jcp: an erasure path that neither breaks the chain nor loses the joules (re-land) #77

Merged

dcharlot merged 1 commit from jcp/erasure-tombstone-v2 into main 2026-09-03 15:17:04 -04:00

Conversation 0 Commits 1 Files changed 1 +164

2026-09-03

David Charlot

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

No receipt chain in open-standards had a redaction primitive. Chains are
append-only by construction — right for evidence, wrong for a deployment that
has to honour a data-subject erasure request, so the absence was a hard blocker
rather than 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; 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. 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 chain test compares the sealed payload
byte-for-byte against the expected chained wire rather than re-parsing it.

Re-applied on current `main` after the environment-binding change landed;
the original branch conflicted at a shared test-insertion point, and rebuilding
was cleaner than resolving text that did not split at function boundaries.

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

Verified: full jcp-rs workspace green, conformance passes all classes.

Co-Authored-By: Claude Opus 5 <[email protected]>

dc84399ffd

• View at this point in history

2026-09-03 15:15:51 -04:00