Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

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
pull from: jcp/erasure-tombstone
merge into: Transaction-Science:main
Conversation 0 Commits 1 Files changed 1 +189
dcharlot commented 2026-09-01 05:59:47 -04:00
Owner
Copy link

⛔ CLOSED — superseded by #77 (already merged)

This branch conflicted with main once the environment-binding change (#73) landed: both inserted tests at the same anchor in jcp-receipt. A keep-both textual resolution broke brace balance, because the conflict did not split at function boundaries, so the change was rebuilt on current main instead and landed as #77.

The content is identical in substance and is on main now — verified by content probe (TOMBSTONE_PROFILE present), not by merge status.

No receipt chain in open-standards had a redaction primitive. Chains are append-only by construction — exactly right for evidence, exactly wrong for a deployment that must honour a data-subject erasure request. The absence was a hard blocker, not a missing convenience.

Why erasure has to be forward-only

The chain links on envelope bytes: each entry's prev is the content id of the one before it. An entry 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.

So ReceiptLog::erase appends a jcp.tombstone/1 entry. The erased envelope stops being retained; 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.

That is 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.

Details

  • A tombstone carries its own profile, so no reader mistakes it for a decision that happened to have no payload.
  • The chain 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.

Provenance

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.

Verification

264 jcp-rs tests pass (4 new) · conformance passes all classes · no clippy warnings in jcp-receipt.

> ## ⛔ CLOSED — superseded by #77 (already merged) > > This branch conflicted with `main` once the environment-binding change (#73) landed: both inserted tests at the same anchor in `jcp-receipt`. A keep-both textual resolution broke brace balance, because the conflict did not split at function boundaries, so the change was **rebuilt on current `main`** instead and landed as **#77**. > > The content is identical in substance and is on `main` now — verified by content probe (`TOMBSTONE_PROFILE` present), not by merge status. --- No receipt chain in open-standards had a redaction primitive. Chains are append-only by construction — exactly right for evidence, exactly wrong for a deployment that must honour a data-subject erasure request. The absence was a hard blocker, not a missing convenience. ## Why erasure has to be forward-only The chain links on **envelope bytes**: each entry's `prev` is the content id of the one before it. An entry 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**. So `ReceiptLog::erase` **appends** a `jcp.tombstone/1` entry. The erased envelope stops being retained; 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.** That is 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. ## Details - A tombstone carries **its own profile**, so no reader mistakes it for a decision that happened to have no payload. - The chain 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. ## Provenance 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**. ## Verification 264 jcp-rs tests pass (4 new) · conformance passes all classes · no clippy warnings in `jcp-receipt`.
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
Details
standards workspaces build + test / joule-code-rs (pull_request) Successful in 46s
Details
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m49s
Details
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m13s
Details
standards workspaces build + test / proof-rs (pull_request) Successful in 1m12s
Details
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 4m10s
Details
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m1s
Details
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 50s
Details
standards workspaces build + test / map-rs (pull_request) Successful in 39s
Details
standards workspaces build + test / mesh-rs (pull_request) Successful in 31s
Details
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m35s
Details
standards workspaces build + test / openpay (pull_request) Successful in 1m27s
Details
standards workspaces build + test / arl-rs (pull_request) Successful in 10m13s
Details
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 10m1s
Details
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 9m59s
Details
standards workspaces build + test / joulehook-rs (pull_request) Successful in 9m43s
Details
standards workspaces build + test / sense-rs (pull_request) Successful in 8m26s
Details
8a1232b759 
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.
dcharlot closed this pull request 2026-09-03 15:28:45 -04:00
All checks were successful
standards workspaces build + test / aac-rs (pull_request) Successful in 49s
Details
standards workspaces build + test / joule-code-rs (pull_request) Successful in 46s
Details
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m49s
Details
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m13s
Details
standards workspaces build + test / proof-rs (pull_request) Successful in 1m12s
Details
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 4m10s
Details
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m1s
Details
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 50s
Details
standards workspaces build + test / map-rs (pull_request) Successful in 39s
Details
standards workspaces build + test / mesh-rs (pull_request) Successful in 31s
Details
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m35s
Details
standards workspaces build + test / openpay (pull_request) Successful in 1m27s
Details
standards workspaces build + test / arl-rs (pull_request) Successful in 10m13s
Details
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 10m1s
Details
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 9m59s
Details
standards workspaces build + test / joulehook-rs (pull_request) Successful in 9m43s
Details
standards workspaces build + test / sense-rs (pull_request) Successful in 8m26s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!74
No description provided.