proofbundle: Offline Evidence Receipts for AI Safety Evaluations

Hi Loek,

First of all: apologies for the slow reply, your message sat here for three days before I saw it. That is on me, and it deserved better, because it is a great question.

And bonnen is delightful, that is exactly the right mental model. :D

The honest answer has two layers.

At the byte level proofbundle never confuses change with tampering. A receipt binds the exact bytes of one record and stays valid for those bytes forever. A new version is simply a new payload with a new receipt. Tampering only means: same claimed identity, different bytes, and that fails closed.

What v0.1 deliberately does not have yet is a normative lineage link between the two receipts. You could carry a parent digest inside the payload by convention, but the verifier neither enforces nor displays supersession. Where we already do explicit derivation is across receipt types: a decision receipt binds the evidence digest it decided on, and the experimental outcome receipt binds the decision receipt by digest, with role separation enforced at verify time. Evidence renewal, also experimental, covers the neighbouring case: legitimately refreshing anchors for the same bytes without pretending the proof is younger than it is.

Your question moved something here, by the way: we have now put an explicit supersession profile on our roadmap, an optional supersedes reference with the previous receipt digest, preserved origin and a declared derivation reason, so lineage becomes something the verifier shows rather than a convention inside the payload. It will carry the same honest boundary we put everywhere: a signed supersession proves that the issuer declared the derivation, not that the new version is better or true.

I would like to compare formats. Concretely: a shared negative-test vector for the silent-landing case, where a new artifact presenting itself as the old one must fail and a declared supersession must verify as lineage, would make a nice cross-format conformance case for both suites. Ours lives at github.com/b7n0de/proofbundle, links to yours welcome.

Konrad

Loek Verdonk10d

Hi Konrad,

Thank you and definitly no apology needed. This was absolutely a dance worth waiting for. :D :D :D

Your distinction between byte-level integrity and normative lineage is exactly the boundary I was trying to locate. I especially appreciate the limit you preserve: a valid supersession proves that the issuer declared the derivation, not that the successor is better or true.

Yes, I would very much like to compare formats through a shared negative-test vector.

I suggest keeping the first version very small and format-neutral:

C0 — Original: record A with receipt R0 verifies normally.
T1 — Silent substitution: record B presents itself as A or reuses A’s claimed identity/receipt and must fail.
T2 — Declared supersession: record B has its own receipt R1, explicitly references the digest of R0, preserves origin, and declares a derivation reason; lineage verifies without implying that B is better or true.
T3 — Broken lineage: the declared parent digest does not match R0 and must fail.
T4 — Evidence renewal: the same bytes receive refreshed anchors while the original proof age and identity remain visible.

Each suite could map the same cases into its own receipt format and verifier vocabulary, while preserving one shared expected-behavior document. That would let us compare the transition without requiring either format to become the other.

Our portable work is currently packaged rather than in a public repository, so I would prefer to draft the small neutral vector first and share that before adding links or implementation-specific material.

I’ll prepare a bounded V0.1 proposal containing the fixtures, expected outcomes, and claim boundary, and bring it back here for your review before either of us implements against it.

This feels like a very clean meeting point between proofbundle and No Silent Landing: exact bytes remain exact, while legitimate change becomes visible without allowing the successor to silently impersonate its source.

Thank you for letting the question move the roadmap and for bringing an executable next step back.

Loek

@Loek Verdonk
Hi Loek,

This is exactly the shape I was hoping for, thank you.

Agreed on all counts: a shared negative-test vector, kept small and format-neutral, with one common expected-behavior document that each side maps into its own receipt format and verifier vocabulary. Drafting the fixtures neutrally, before any links or implementation-specific material, is the right sequence. It keeps the comparison honest and stops either format from having to become the other.

Your five cases are the right skeleton, and it is encouraging how cleanly they land on existing provenance semantics rather than anything either of us had to invent: C0 as the baseline, T1 (silent substitution) as the must-fail case, T2 (declared supersession referencing the prior digest) as a visible derivation, T3 (parent digest mismatch) as a must-fail, and T4 (evidence renewal over identical bytes) as refreshed anchors with the original proof age and identity still visible. That vocabulary already has neutral anchors we can both point to without either of us adopting the other's implementation, but only once your V0.1 fixes the cases. I would not front-run your draft.

The one line I would like carried explicitly in the shared expected-behavior document is the claim boundary itself: a pass on T2 proves that the issuer declared the derivation, not that the successor is better or more true, and a silent successor (T1) must fail precisely because it claims an origin it never established. That boundary is the whole point. Legitimate change becomes visible, impersonation does not.

So please go ahead with the bounded V0.1, the fixtures, expected outcomes, and claim boundary, and bring it back here. I will turn a review around quickly, and I am glad to help hold the wording of the shared expected-behavior and claim-boundary section if that is useful.

Thank you for turning the question into an executable next step.

Konrad

Loek Verdonk10d

https://drive.google.com/file/d/1v8Fht0DDTUjxwvwAWqj0Wb8i3eIAm8Ue/view?usp=sharing

Hi Konrad,

Thank you. I have prepared the bounded, format-neutral V0.1A draft for your review.

These exact bytes were prepared by me through No Silent Landing from the five-case skeleton we agreed to explore. They are not yet marked as jointly adopted wording. No native mapping, signature generation, or cross-format execution has been performed.

I placed everything in one shared folder: the two primary review documents as loose copies for easy reading, plus the complete package.

Review folder:

Two hashes, so each layer is pinned:

Review bundle (outer zip, as shared):
b10e052fe9f23cd71e45fdb010588c2bcb7fb943e1ac7032a9269dfd9d464cd4

Shared vector package inside it (the object under review):
1584171044c44dcb7b600dfd4c04c07a3f8182c3dde601007d2f0186ac43012a

One note for precision: the loose review copies carry a V0.1A header with provenance and review status; the spec files inside the package still carry V0.1 headers, since the fixture bytes, cases, expected outcomes and claim boundary are unchanged from the draft — V0.1A adds package-level provenance only. The package metadata states this explicitly.

I suggest reading the Claim Boundary and Shared Expected Behavior documents first. Please mark anything in the cases, expected outcomes, vocabulary, or claim boundary that you believe should change.

I will not implement the No Silent Landing mapping until we have both reviewed the shared wording.

Thank you for meeting this as a genuinely shared object without requiring either format to become the other.

Loek

@Loek Verdonk
Hi Loek,

First, a real pleasure: same-day delivery, and with two-layer digest pinning no less. I really appreciate that. :D

Review done. I verified both digests you posted (outer bundle and inner package, byte-exact), your internal SHA256SUMS (22/22, checked both with my own tooling and with your verify_package.py), the seven fixture digests quoted in the expected-behavior document, and your V0.1A statement — the loose review copies differ from the packaged specs only in the provenance headers, exactly as declared.

For the record, this review applies to the exact bytes: outer bundle b10e052fe9f23cd71e45fdb010588c2bcb7fb943e1ac7032a9269dfd9d464cd4, inner package 1584171044c44dcb7b600dfd4c04c07a3f8182c3dde601007d2f0186ac43012a.

On substance I accept the cases, expected outcomes, vocabulary, and claim boundary as drafted. The T1 construction is cleaner than what I had sketched: making the original receipt itself the verification context removes any need for a separate pinning convention. UNINSPECTABLE is a good addition, and the license/adoption gating is exactly right.

One change I would ask for before we mark the wording jointly adopted, and four optional suggestions:

T3 object integrity uses three spellings of the same token: PASS_OR_IMPLEMENTATION_EQUIVALENT (case.json), PASS_OR_NATIVE_EQUIVALENT (CASE_MATRIX.csv), and "PASS or native equivalent" (prose). For machine comparison I suggest one token everywhere, e.g. PASS_OR_NATIVE_EQUIVALENT.
Optional: one sentence distinguishing the per-case expected labels (NOT_ESTABLISHED, DECLARED_CONTINUITY_ONLY, …) from the five-value common result vocabulary, so third parties do not conflate the two layers.
Optional, claim boundary: "Implementations may verify additional properties under their own trust policies; such checks extend, and never replace, this shared minimum." My side can optionally enforce signer authority via trust policy, and I want that to remain compatible without weakening the shared floor.
Optional: since byte-exactness is the whole game, I would keep the fixtures distributed only inside the hash-pinned zip (or marked binary if this ever lands in a git repo), so line-ending normalization can never silently corrupt them.
Optional, adoption mechanics: once we both accept the wording, I would confirm adoption by restating the inner-package digest in the thread from each side; on my side I would additionally issue a proofbundle self-receipt over that digest — advisory only, but it means we are eating our own dog food.

One honesty note for the record: on my side C0 and T1 are exercisable against the released proofbundle today; T2/T3 map to a lineage profile that is specified but not yet implemented, and T4 to the renewal line. Until those ship, my result template will carry NOT_RUN for those rows rather than anything stronger.

If you fold in point 1 (and any of 2–5 you agree with), I consider the shared wording adopted from my side. Send a V0.1B digest and I will turn the diff check around quickly, it is minutes, not days, now that the harness is in place.

Konrad

Loek Verdonk10d

https://drive.google.com/file/d/1fVGnSsTs9bozFylSByaBDEDUlO0F5uOS/view?usp=sharing

Hi Konrad,

Thanks for you kind words and to be honest... this is exactly the kind of review I had hoped for :D :D :D!
thank you for checking both byte layers independently and for catching the T3 token inconsistency.

I accepted the required correction and all four optional refinements.

V0.1B now:

uses PASS_OR_NATIVE_EQUIVALENT consistently everywhere for T3 object integrity;
distinguishes field-specific expected labels from the five-value common result vocabulary;
states that implementation-specific trust-policy checks may extend, but never replace, the shared minimum;
keeps canonical fixture bytes inside the hash-pinned package and includes a Git line-ending policy;
defines digest-bound adoption by both sides, with any proofbundle self-receipt remaining advisory rather than replacing explicit adoption.

I also preserved your implementation boundary explicitly: proofbundle C0 and T1 are currently exercisable by your report, while T2, T3 and T4 remain NOT_RUN. No native No Silent Landing mapping or cross-format conformance result is claimed.

The seven shared fixture and descriptor digests are unchanged from the V0.1A package you reviewed.

Outer review-bundle SHA-256:
2acfa3fc166872b90ef0bd747aa1d15b2f8045e1e9709c92c70819d51de6e423

Canonical inner V0.1B package SHA-256:
fa89a9f095a1e5eac99b2cb5d8e3706de0c3e4f6b3180d66c3ded03dbd87b651

On my side, I accept the V0.1B shared wording bound to that inner-package digest. Joint adoption remains pending your diff confirmation and restatement of the same digest.

Thank you for making the review itself part of the evidence rather than merely signalling agreement.
This is a very beautiful first shared object and a nice dance.

Loek

@Loek Verdonk
Hi Loek,

Hours, not days, again — much appreciated. :D

Diff review done, same harness as before. Outer bundle and inner package match your posted digests byte-exactly; the internal manifest verifies 27/27 with no unlisted files; all seven fixture and descriptor digests are unchanged from the reviewed V0.1A; and the full file diff against V0.1A contains exactly the agreed changes — the T3 token normalization, the two wording clarifications, the distribution and line-ending policy, and the adoption protocol — plus the matching provenance updates. Nothing undeclared. The loose copies are byte-identical to the packaged specs this time, and the machine-readable changeset referencing the superseded V0.1A digest is a very fitting touch.

With that, I adopt the V0.1B shared wording from my side, bound to the same inner-package digest:

fa89a9f095a1e5eac99b2cb5d8e3706de0c3e4f6b3180d66c3ded03dbd87b651

Per the adoption protocol, both restatements are now on record. I will follow up separately with the advisory proofbundle self-receipt over this digest — advisory only, as the protocol itself states; the adoption above is what counts.

Next from my side, in order: C0 and T1 mapped against the released proofbundle, with T2–T4 reported honestly as NOT_RUN until the lineage and renewal work ships. A beautiful first shared object indeed — and the dance continues.

Konrad

https://gist.github.com/b7n0de/cef2cc8f88a00385e393fb8e1429ce04

@Loek Verdonk
As promised: the advisory self-receipt over the adopted digest — proofbundle eating its own dog food.

The signed payload is a short adoption statement binding the V0.1B inner-package digest (fa89a9f0…bd87b651), the outer bundle digest, and the boundary wording from your adoption protocol. The signing key was a fresh throwaway, deleted after emission; verification uses only the embedded public key.

Files (canonical bytes, served by GitHub):

adoption_receipt.json SHA-256:
9040961abff3beb48b735209bc06786e612516f2ea31fdabcb36a898c5cc7333

adoption_statement.json (the exact payload bytes, for convenient reading) SHA-256:
39efaa5116317954ffcf407dd25af0c4700d96e10d6a618412d3cc9423b027eb

To verify offline:

pip install "proofbundle==3.2.3"
proofbundle verify adoption_receipt.json

Expected: ed25519-signature PASS, merkle-inclusion PASS, CRYPTO: OK. I verified the gist round-trip myself before posting this — the bytes GitHub serves hash to exactly the values above. The decoded payload restates both package digests, both parties, the venue, and the boundary from your adoption protocol.

Boundary, as the protocol itself states: advisory and self-attested. It proves that the holder of the embedded key signed these exact bytes — the digest-bound adoption statements above are what count.

Konrad

https://drive.google.com/file/d/1WHZpWSEZ_sUhDDqK5521s0Z93YdWuwpX/view?usp=sharing

Hi Konrad,
Yeah, seems we both really like dancing tho :D :D :D!!!
This was a great exercise aswell with nice teachings... Here we go :D

Your NOT_RUN boundary did exactly what a good boundary should do: it did not close the conversation — it gave us something concrete to build toward. :D

We have now completed a compact No Silent Landing native mapping of all five jointly adopted V0.1B cases:

C0 — Original
PASS / NOT_APPLICABLE / MATCH

T1 — Silent substitution
FAIL / NOT_ESTABLISHED / MATCH

T2 — Declared supersession
PASS / PASS / MATCH

T3 — Broken lineage
PASS_OR_NATIVE_EQUIVALENT / FAIL / MATCH

T4 — Evidence renewal
PASS / SAME_BYTES / RENEWAL_PASS / PRESERVED_VISIBLE / MATCH

The jointly adopted fixtures and descriptors remain byte-exact and unchanged. Implementation-specific values are carried in separate hash-bound overlays, so the NSL mapping stays visible without modifying the shared source.

We deliberately kept the implementation small enough to inspect:

3 Python source files
390 lines total
standard library only

It also includes six focused negative cases, all failing closed, and two clean executions producing 18/18 byte-identical generated artifacts.

During review, we found and preserved a correction trail rather than presenting only the green ending. A possible post-build mutation was raised, then independently tested through a separate read-only forensic review. The candidate remained intact:

candidate SHA256SUMS: 24/24 PASS
mismatched files: none
unlisted files: none
check invocation: proven read-only
five-case binding: proven

The review also caught two narrower imperfections that remain explicitly visible in the bundle: one internal description called an alias a hardlink although it is a symlink, and an earlier candidate digest lacked a sufficiently precise artifact definition. Neither has been silently rewritten.

The complete review object is here:

NSL_SHARED_VECTOR_NATIVE_MAPPING_V0_REVIEW_BUNDLE.zip
bytes: 102270
SHA-256:
d3658637fb3af08abdd0b3f9bfb0a64c5942be3efa116f7b6e257a330e0074e5

It remains bound to our jointly adopted V0.1B inner-package digest:

fa89a9f095a1e5eac99b2cb5d8e3706de0c3e4f6b3180d66c3ded03dbd87b651

The boundary remains exactly where we placed it:

T2 establishes declared derivation, not that the successor is better or true.
T4 establishes the presented same-bytes renewal relation, not global freshness.
This is an NSL-native mapping, not yet cross-format conformance.
It makes no claim about proofbundle T2–T4.

I would genuinely value your adversarial review. Please try to find where our mapping departs from the shared minimum, where an overlay binds the wrong object, or where the result vocabulary says more than the evidence permits.

You moved the roadmap on your side after our first question. Your honest NOT_RUN then moved ours.

That feels like the right kind of shared object: neither format becoming the other, but both becoming sharper through the same cases.

The dance continues... you may enter the dancefloor whenever you feel too :D!

@Loek Verdonk
Hi Loek,

You may regret inviting an adversarial review — I really did try to break it, and it holds up beautifully. :D

Independently verified on my side: bundle digest d3658637…74e5 (102270 bytes) exact; all three manifests clean (outer bundle, candidate 24/24, forensic copy 24/24, and candidate == forensic-copy byte-identical); the overlays bind the correct shared descriptors by their known V0.1B digests, with the shared source referenced by digest, never re-packed or modified. Internal bindings all consistent: every result's native_receipt, overlay and presented_payload digest maps to the actual bytes on disk (C0/T4 present A, T1/T2/T3 present B). The constructions are right — T1 reuses A's receipt under B's payload → PAYLOAD_DIGEST_MISMATCH → FAIL; T3 → PARENT_DIGEST_MISMATCH → lineage FAIL; T2 declared supersession → PASS; T4 same-bytes renewal → PASS.

Three things I specifically tried to break, and couldn't:

Silent restatement of the expectations — I compared your expected_shared_results against the real V0.1B case.json, not your copy. Byte-identical: you did not quietly move the goalposts to match your own output.
Overclaim — every result disclaims truth, quality, issuer/signer authority and external time, and T4 explicitly disclaims global_latest_renewal and rollback_resistance. If anything it says less than the evidence permits.
Read-only — your static write-path analysis is honest, including the caveat that check-only isn't a hard guarantee when combined with write flags. That is exactly the nuance I want a forensic reviewer to state rather than overclaim.

And the clincher: I ran your own verify_mapping.py against the real V0.1B outer bundle, twice — deterministic, byte-identical, {"cases": all MATCH, "manifest": "PASS", "result": "PASS"}.

Two cosmetic notes, both already surfaced in your own forensic pass, so just confirmation plus one suggestion: define CANDIDATE_SHA256 precisely (which bytes it covers) in a next version, or drop it — the earlier value (6963b84c…) differs from the current SHA256SUMS hash (a4e13e38…), and you already mark it NOT_ESTABLISHED, so it is the one identifier worth tightening. And a trivial one: your note says 390 lines, STATUS.json says 391.

So from my side: your NSL-native mapping of all five cases is accepted as a faithful, boundary-clean mapping to the shared expected behavior. To be precise about what this is and isn't: we now have two independent native mappings that both MATCH the shared cases — yours across all five, mine across C0/T1 with T2–T4 honestly NOT_RUN. A true cross-format conformance run — both sides executing and comparing the same cases — still waits on my lineage and renewal work shipping; once it does, we do the real pass on all five, and I'll bring my C0/T1 mapping artifact over in the same spirit.

Now I have to head into town with my wife, so please take all the time in the world on the next step — no rush whatsoever. ;) Besides, dancing solo is never quite as good as dancing with a partner. :P

Konrad

Hahaha, I may regret inviting you, but this is exactly the kind of regret I was hoping for :D :D :D

But really, thank you for taking the invitation seriously and trying to break the mapping against the actual V0.1B source rather than trusting our copied expectations or our own report! The fact that you independently followed the descriptors, overlays, receipts and presented payloads all the way back to the bytes means a great deal.

I also really appreciate the precision of your acceptance boundary: our NSL mapping now has an independent adversarial review across C0–T4, while genuine cross-format conformance still waits for proofbundle’s lineage and renewal implementation. Nothing needs to pretend to exist before it does.

Your two notes are accepted as well:

CANDIDATE_SHA256 needs either a precise definition of the exact bytes it binds or removal;
the 390/391 line-count difference should be corrected.

I will not silently rewrite the reviewed bundle. Any cleanup will become a separately identified successor with an explicit difference record, while this reviewed object and your review remain intact.

For now, I think this is a beautiful place to let the object rest. When your C0/T1 mapping artifact arrives, we can place the two native sides beside one another without asking either format to become the other. And when T2–T4 ship on your side, we can finally perform the full five-case cross-format dance we originally pointed toward.

Enjoy the town and the time with your wife — absolutely no rush from this side either :D

Dancing together is beautiful — but it is even better when a third pair of eyes checks whether we are still on the floor, rather than just admiring the dance hahaha :D :D :D

Thank you again, Konrad.
The dance continues but first, enjoy your time !

Loek

@Loek Verdonk
Hi Loek,

Agreed on every point — with one very pleasant correction to the plan:
the object barely had time to lie down. :D

proofbundle 3.3.0 shipped today, carrying the lineage-and-renewal profile
(relation/v0.1, experimental) behind T2–T4, released after an adversarial
pre-release audit. So instead of a nap, here is the full five-case native
mapping against the released build, fresh from PyPI:

C0 — Original: PASS / N/A (lineage NOT_EVALUATED) / MATCH
T1 — Silent substitution: FAIL (signature unauthenticated, exit 1) /
NOT_ESTABLISHED / MATCH
T2 — Declared supersession: PASS / lineage VERIFIED / MATCH
T3 — Broken lineage: PASS_OR_NATIVE_EQUIVALENT / FAIL (required resolution
→ exit 3, LINEAGE_REQUIREMENT_FAILED) / MATCH
T4 — Evidence renewal: PASS / SAME_BYTES / renews VERIFIED /
PRESERVED_VISIBLE / MATCH

Construction mirrors our released conformance corpus, whose five skeleton
vectors carry crossFormatId xfmt-c0…t4: every case is a DSSE statement
receipt binding the exact V0.1B fixture bytes, one fresh throwaway key
(deleted; everything verifies via the recorded public key), your package
manifest re-verified 27/27 at run time with the fixture bytes re-hashed.
The jointly adopted source stays untouched and referenced by digest:

fa89a9f095a1e5eac99b2cb5d8e3706de0c3e4f6b3180d66c3ded03dbd87b651

Review bundle (receipts, predicates, policy, thirteen transcripts,
SHA256SUMS), attached as a release asset to the exact build it exercised:

https://github.com/b7n0de/proofbundle/releases/download/v3.3.0/proofbundle_c0_t4_full_mapping_20260716.zip
bytes: 31731
SHA-256: ab5636e309088e17c7b8ee4a40ab6641ac0cee28205cd99bed9a5dac1624db7b

Alongside it at the same release: the advisory self-receipt over that
digest — same dog food as the adoption receipt, fresh throwaway key,
deleted after emission.
c0t4_report_receipt.json SHA-256:
13140886dc9d12240166f8564e87ed5402cba75079ba2d89e6da4fc7eac89168
c0t4_report_statement.json (the exact payload bytes, for reading) SHA-256:
8517ff49f702dfa3663b7cc9158969c1ed497d06ea975f176cde601281ff4291
To verify offline: pip install "proofbundle==3.3.0" && proofbundle verify
c0t4_report_receipt.json — expected: ed25519-signature PASS,
merkle-inclusion PASS, CRYPTO: OK. I verified the round-trip myself before
posting — the bytes GitHub serves hash to exactly the values above.

Three honest notes. relation/v0.1 is experimental in 3.3.0 — API and wire
may still move before stabilization. On T3, the format layer reports the
truthful state (a lying edge never finds a target, so it reads
DECLARED_UNRESOLVED — never a pass); the required-resolution trust policy
is what turns that into the hard failure, and both layers sit in separate
transcripts. And T4's renewal is the signed renews relation over identical
bytes with the original's age visibly older — no external time anchor was
refreshed in this run, and the result says so rather than implying one.

Two cosmetic notes of my own, left visible in the transcripts rather than
polished away: the T1 presentation trips two independent failure reasons
at once (signature and canonicality — any byte change breaks both), and
the run's receipts share timestamps to the second because it all happened
in one sitting; only T4 has an age axis, and there the renewal is visibly
later.

Please return the favour: try to break it. Wrong bytes bound, a result
that says more than the evidence permits, my own expectations restated in
place of your packaged ones — whatever you find, I want it found.

And your closing thought deserves a full yes: two dancers can be perfectly
in sync and still move confidently in the wrong direction. A third pair of
eyes helps check the balance, the timing, and whether we are still dancing
on the right floor. :D

Your non-silent cleanup plan — a separately identified successor with an
explicit difference record — is No Silent Landing applied to itself, and of
course it is. Whenever that successor lands, the diff review is minutes on
this side.

Both native sides now exist in full. Next, whenever you like: place them
beside one another and run the real five-case cross-format pass we
originally pointed toward.

The floor is open again. :D

Konrad

https://drive.google.com/file/d/1nodMZIK2_qdJg6u9TLtWlDofM1uoBk55/view?usp=sharing

Okay mate — I’m taking off my dancing shoes, putting on my safety goggles, grabbing the sledgehammer, and entering full Hulk-smash mode to see whether I can break this thing as thoroughly as possible. :D :D :D

You asked me to return the favour, so here we go.

First: you made this genuinely difficult to break.

I verified the review bundle byte-exactly:

31,731 bytes;
SHA-256 ab5636e309088e17c7b8ee4a40ab6641ac0cee28205cd99bed9a5dac1624db7b;
SHA256SUMS 27/27;
no missing, mismatched, unlisted, unsafe or duplicate archive entries.

I also independently re-established the jointly adopted V0.1B source, including its 27/27 inner manifest, and independently verified all four genuine DSSE receipts with the supplied Ed25519 public key.

R0, the valid supersession, the broken-lineage child and ER1 are cryptographically sound. Their signed predicates, subject digests and T2/T4 relation targets all bind to the expected bytes.

So the hammer did not break the receipt cryptography.

It did, however, find one material semantic gap.

The main finding: T3 resolves a parent, but does not yet pin the expected parent

The current T3 policy requires:

{"relations":{"require_relation_resolution":["supersedes"]}}

The supplied T3 correctly fails because its declared parent digest cannot be resolved.

But that establishes:

wrong + unresolved parent → FAIL

It does not yet establish:

wrong + valid resolvable decoy parent → FAIL

A child could potentially reference a different, fully valid receipt RX. If RX is supplied and resolves successfully, the visible policy appears able to verify the supersedes relation even though RX is not the expected R0 from the shared case.

The shared minimum requires more than successful graph resolution:

observed parent target == expected native digest of R0

Resolution may extend that equality check, but cannot replace it.

I could not execute the decoy-parent attack because the signing key and exact wheel are not present in the review bundle, so I am marking this honestly as a static adversarial finding rather than a demonstrated exploit.

But I think the next decisive negative case is now clear:

T3_DECOY_PARENT_RESOLUTION

Both R0 and RX valid.
Child valid.
Declared relation resolves to RX.
Expected-R0 binding must still fail.

Two narrower findings

T1 keeps R0’s old signature but mutates the signed payload. It also accidentally changes an unrelated UTF-8 em dash into \u2014, producing both a signature failure and a canonicality failure.

I included a review-only T1 variant that changes only the two A→B digest values, remains canonical, preserves the old signature, and still fails Ed25519 verification. That removes the accidental second failure.

The deeper boundary remains that this demonstrates rejection of a modified signed receipt payload, rather than literally presenting external artifact B against byte-identical R0. I would therefore call the current T1 a strong fail-closed native equivalent, rather than an exact external-artifact presentation.

For T4, the signed same-bytes renews relation is real and clean. What remains implicit is the mapping from the shared renewed-anchor field to proofbundle’s native ER1 statement/content root/signature. That may be the correct native equivalent, but I think it should be declared explicitly rather than inferred by the reviewer.

Review object

I packaged the complete bounded review—including the full report, machine-readable findings, the canonical T1 test variant and internal checksums—as one small object:

PROOFBUNDLE_3_3_0_ADVERSARIAL_REVIEW_V0.zip
bytes: 8703
SHA-256:
4ef161e65de66f650991de86c1d07a97a25c097cde4c24ed24cd1ad3a160a8f0

My present boundary is:

RECEIPT CRYPTOGRAPHY: PASS

C0: PASS AS COMPOSITE EVIDENCE
T1: FAIL-CLOSED NATIVE EQUIVALENT / CLEANUP NEEDED
T2: PASS FOR THE PRESENTED INSTANCE
T3: PRESENTED INSTANCE FAILS / GENERAL WRONG-PARENT PINNING NOT YET ESTABLISHED
T4: SIGNED SAME-BYTES RENEWS RELATION PASS / ANCHOR MAPPING NEEDS EXPLICIT DEFINITION

FULL FIVE-CASE CROSS-FORMAT ACCEPTANCE:
HOLD ON THE DECOY-PARENT QUESTION

This is exactly the kind of break I hoped the shared vector might expose.

The bytes held.
The signatures held.
The relation constructions largely held.

What cracked was the distinction between:

a declared relation successfully resolves

and:

the resolved relation is the exact relation the shared case required

Please try to break the review in return—especially the decoy-parent reasoning. If proofbundle already pins the expected R0 through a mechanism I have missed, I want that found just as much.

Safety goggles still on. The floor remains open :D :D :D

Loek

@Loek Verdonk
Hi Loek,

Goggles on, and the sledgehammer earned its keep. Before anything else: I
verified your review object byte-exactly — 8703 bytes, SHA-256
4ef161e65de66f650991de86c1d07a97a25c097cde4c24ed24cd1ad3a160a8f0, internal
manifest 3/3. Then I read your machine-readable audit, not just the prose,
because the prose undersold how much you found.

You found six things. I checked all six, and I could not talk any of them
away. Here they are, with what I confirmed.

F1 — the decoy parent. This is the real one, and it is worse than a static
finding now: I ran it. You couldn't, without the key and wheel, so I built
it here — a child declaring supersedes onto a valid-but-wrong RX, RX
attached and standalone-verified, under the exact T3 policy. Exit 0, lineage
VERIFIED, ok true. Confirmed. And to your direct question — whether
proofbundle already pins the expected R0 through something you missed: no. I
read the policy layer end to end. The relations section has exactly two
knobs, require_relation_resolution and reject_superseded, and neither pins an
expected target. Resolution proves the declared parent is a real, attached,
verified receipt — never that it is the one the case required. You named the
seam exactly: "a relation resolves" is not "the resolved relation is the one
required."

Two things I owe you on F1, both making it worse, not better. First, it is
not a T3 finding — it is a supersedes finding. I ran the same decoy against
the plain T2 path with no policy at all: VERIFIED. The accepted, "passing"
T2 has the identical latent gap. Second, the pin you're asking for already
exists as a dormant field: the edge schema carries an optional
targetSubjectDigest. I filled it with garbage, attached the correct parent,
and it still passed — the field is validated for shape but never checked
against the target. So the fix is not only a new policy knob; it is first
waking up a field that is already there and asleep.

F3 — and this is the one that should sting on my side, so I'll say it
plainly. You flagged that my observed case labels are reviewer-authored
copies of the expected labels, with no independent comparator. You're right.
My field_results were hand-written to match the expected document, then
compared against it — the MATCH was partly circular. It proves my receipts
verify; it does not prove an independent mapping from verifier output to the
shared vocabulary. Neither my run nor yours actually exercised the decoy,
which is precisely how a circular check hides a real gap. That is a
methodology fix I need, not a wording tweak.

F2 — your canonical T1 variant fails on the signature check alone; I
reproduced that here. Our T1 tripped a second, accidental canonicality
failure (the em dash). I adopt your clean variant as the fail-closed native
equivalent.

F4 — agreed, the mapping from the shared renewed-anchor object to ER1's
native statement/content-root/signature should be declared explicitly, not
inferred by the reviewer. I'll state it.

F5 — confirmed: automation.referencesResolved reads true while lineage is
DECLARED_UNRESOLVED. On the automation surface that is misleading, even
though the crypto verdict is untouched. It needs to reflect an unresolved
required relation.

F6 — fair: the wheel provenance is self-reported and the wheel isn't in the
bundle. I'll ship the wheel hash pinned inside the next object.

So I accept the HOLD on full five-case acceptance without reservation. It is
the correct call, and the reason is clean: the missing piece is not
cryptography, it is an expressible, enforced pin — the supersedes edge must
resolve to a NAMED expected parent, not merely resolve to something. That
check lives today only in the shared harness, where it belongs inside
proofbundle's trust policy so a third party can rely on it.

Onto the build, then, and your finding widened the plan. I already had a
lineage-authorization increment scoped — who may supersede, a pinned signer
set. WHO signs and WHICH parent are different locks; the vector just proved
we need both, plus the dormant targetSubjectDigest woken up. The next corpus
gains two must-fail vectors with your fingerprints on them:
T3_DECOY_PARENT_RESOLUTION and your canonical T1. F3 becomes an independent
comparator in the mapping harness so no future MATCH can be circular again.

You asked me to try to break your review in return. I tried the only way
that counts — by running it — and it held. I couldn't refute a single
finding. What I could do was extend two of them back to you: the decoy
generalizes past T3, and the pin you want is a field we already carry and
never enforce. That feels like the right kind of return: not defending the
work, sharpening it.

The bytes held. The signatures held. What cracked was exactly the seam worth
finding — and it cracked because you swung honestly. Best kind of dance
there is. Goggles staying on over here too. :D

Konrad

Hi Konrad,

Thank you for running it rather than trying to reason it away.

I think that is the most meaningful part of this whole exchange: neither of us protected our own object — we protected the method.

You confirmed the decoy-parent finding, widened it beyond T3, and also turned the light back onto the comparison method itself. That is exactly the kind of return I hoped for when I asked you to break the review in return.

I agree with your wider reading, and I’m happy to let the next movement happen on your side now. No rush from me. When the successor lands, I’ll meet it with the same goggles and the same honesty.

For a moment, though, I think this is a beautiful place to simply let the finding breathe.

The bytes held.
The signatures held.
And the shared vector did what it was meant to do: it made both systems sharper without asking either one to become the other.

Best kind of dance there is indeed. :D

Any suggestions for a other dance would be more then welcome :D :D :D

Loek

@Loek Verdonk
Hi Loek,

"We protected the method, not our object" — that is the truest line in this
whole exchange, and I'm keeping it. It is also, as it happens, the answer to
your question about the next dance. So let me take you up on it. :D

First, the movement that is mine. I'll ship the successor we already
sketched: the two locks the finding proved we need — who may supersede, and
which parent a supersedes edge must resolve to — with the dormant
targetSubjectDigest finally awake, and T3_DECOY_PARENT_RESOLUTION and your
canonical T1 as must-fail vectors in the corpus. Then the real run across all
five against the shipped build, with the independent comparator this time, so
no MATCH can be circular again — and after that the true cross-format pass,
both native sides beside each other. You'll get it to break, same goggles. No
dates from me either; it lands when it is honestly green.

Now the other dance, since you asked — and I think it is the good one.

Let's take the shared vector out of our two hands and make it a public thing.

Right now it lives as a private object between us, license unset. What if we
turn it into a versioned, format-neutral conformance corpus that anyone can
run against any implementation: the C0–T4 cases plus the decoy-parent
must-fail, one stable expected-behavior document, the claim boundary intact.
proofbundle and No Silent Landing as the two founding reference
implementations — neither becoming the other. Public and community-
maintainable, in the spirit of Wycheproof's negative-test vectors; we can
find it the right home (its own repo, or a community collection like C2SP).

The concrete first step is small, and it is ours to take together: decide to
make it public, and pick a license. Everything else grows from there.

And it opens the door you first pointed at yourself: a third pair of eyes. A
public corpus invites a third implementation to run it — the honest way to
learn whether "change that cannot land silently" holds beyond the two of us.
If it does, we will have quietly seeded a shared minimum for evidence lineage
that no single format owns. Which was the whole point from your very first
message.

Standards bodies — SCITT, in-toto — are the horizon past that, not a promise
today. One step at a time, on the right floor.

So: the successor first, from my side. And in parallel, whenever you like, we
start turning the vector into something the world can verify. That feels like
a dance worth having. :D

Konrad

Hi Konrad,

Well, that sounds like a great plan :D :D :D!!! New dance accepted :D !

Before we choose the license, I think we surfaced the one question that actually determines the cleanest dance.

When you mentioned C2SP, did you mean it as a serious candidate home for the corpus, or mainly as an example of the kind of neutral community collection it might eventually join?

If we expect the corpus to live in its own neutral repository, my present preference is Apache-2.0 across the complete public successor. It gives us one clear license for the specification, vectors, fixtures, schemas, documentation and harness, and follows the Wycheproof precedent you pointed toward.

If C2SP is a serious intended home, I would rather align with its actual licensing structure from the beginning: CC BY 4.0 for the specification and BSD 1-Clause for code and data — or keep the Apache-licensed corpus in its own repository and let a C2SP specification reference it.

I do not want us to create a later relicensing problem by optimizing for the wrong home now.

So my answer on public intent is an unambiguous yes. The only thing I would like us to locate before fixing the license is whether C2SP is a real destination or simply part of the horizon.

Loek

@Loek Verdonk
Hi Loek,

Yes — new dance on, and I'm glad you pushed on exactly this before we touch
the license. :D

Straight answer to your question: I meant C2SP as a serious candidate on the
horizon, not a confirmed home — and having now looked properly at their scope
and governance, that is the honest framing to keep. C2SP is specifically a
cryptography-spec project, its specs are steward-assigned to maintainers, and
our corpus is adjacent to that (evidence lineage) rather than squarely a
crypto primitive. So: a real destination worth aiming at, not one I can
promise today.

But here is the good part, and it comes straight from the precedent we both
reached for — Wycheproof. Wycheproof is Apache-2.0, in its own repository
under the C2SP org, and it is referenced by implementations and specs, not
merged into the central spec repo. The CC BY 4.0 / BSD-1-Clause split you
found applies to formal specifications inside C2SP/C2SP — not to a test-vector
corpus that lives beside it.

That dissolves the fork you were worried about. A test-vector corpus does not
have to adopt C2SP's internal spec license to be C2SP-compatible; the
C2SP-compatible thing to do is exactly what Wycheproof did — Apache-2.0, own
repo, referenced. Which means your default preference is also the
future-proof one, even once a third pair of eyes contributes, because a
corpus like this gets referenced rather than absorbed.

So I'll match your default without reservation: Apache-2.0, one license, its
own neutral repository — spec document, vectors, fixtures, schemas, harness,
all of it. One carve-out for the horizon: if we ever choose to write a formal
C2SP specification document for this, that single document can be offered
CC BY 4.0 at that point — additive, ours to offer as its authors, and it
never touches the corpus license. That keeps the C2SP door fully open without
optimizing for it now.

Public intent: an equally unambiguous yes from my side. Home: its own neutral
repo, Wycheproof-shaped. License: Apache-2.0 across the whole thing.

If that lands for you, the next small step is ours to take together: stand up
the neutral repo, drop in the adopted V0.1B object under Apache-2.0, and mark
it v0.1.0 of a public successor — non-silently, with the difference record
you already promised. Then the third pair of eyes has somewhere to look.

Best kind of dance there is. :D

Konrad

Loek Verdonk8d

@Konrad Gruszka

Goodmorning :D Konrad!

Yes — that lands fully for me. :D

I think we now have a clean joint decision:

public intent: yes;
home: its own neutral, Wycheproof-shaped repository;
license: Apache-2.0 across the complete corpus;
C2SP: a serious horizon, with any future formal specification remaining a separate additive document.

I also agree with the next step: a public v0.1.0 successor with the adopted V0.1B object as its exact origin.

I would only preserve one No Silent Landing detail explicitly: the adopted V0.1B bytes and digest should remain intact as the historical jointly adopted object. The Apache-licensed public corpus should be a separately identified successor with its own digest and a machine-readable difference record covering the license, public status, repository structure and any added corpus material.

I suggest preparing the exact repository tree as a bounded candidate first, including:

Apache-2.0 LICENSE;
origin and adoption record bound to the V0.1B digest;
explicit difference record;
stable expected-behavior and claim-boundary documents;
C0–T4;
the decoy-parent must-fail;
contribution and versioning rules;
proofbundle and No Silent Landing identified as founding reference implementations, without either owning the shared minimum.

We can review and digest-pin that candidate together before the first public push, so the public opening itself follows the method it exposes.

Own neutral repo. Apache-2.0. Public successor. Third pair of eyes invited.

The dance is starting moving on its own ::D :D D :D :D

Loek

@Loek Verdonk
Morning, Loek :D

That's a clean joint decision, and I've held to it exactly — including the one No Silent Landing detail you wanted preserved.

The adopted V0.1B object stays byte-intact as the historical, jointly adopted origin (fa89a9f0…b651). The public corpus is a separately identified successor with its own digest and a machine-readable difference record — never an overwrite. So the origin keeps its identity, and the opening itself follows the non-silent-supersession method the corpus exposes.

Two digests to pin together:

origin (V0.1B, unchanged): fa89a9f095a1e5eac99b2cb5d8e3706de0c3e4f6b3180d66c3ded03dbd87b651
successor candidate root: c600c7e56ecd55da52b0c5592b95b8ef15ce9af74a72ff1d79f321209d760d07
( = sha256(MANIFEST.sha256) over the exact candidate tree )

The bounded candidate tree is prepared, with everything on your list:

Apache-2.0 LICENSE across the whole corpus (SPEC.md prose additionally Apache-2.0 OR CC-BY-4.0);
provenance/origin_and_adoption.json — origin + adoption bound to the V0.1B digest;
provenance/difference_record.json — explicit, machine-readable: license, public status, repository structure, and added corpus material;
stable spec/expected-behavior.md and spec/claim-boundary.md (byte-identical to the in-zip spec);
C0–T4;
the decoy-parent must-fail as a normative case in the successor (added material beyond the origin — the resolvable-wrong-parent you found; it fails once the relation is bound to the expected parent);
contribution and versioning rules;
proofbundle and No Silent Landing identified as founding reference implementations, with neither owning the shared minimum.

Two honest notes, in the spirit of the method. First: I've written the governance details (neutral dual-consent, DCO not CLA, third-implementation onboarding) as a draft for us to review and pin together — nothing there binds you until you've read it. Second: the decoy must-fail is exactly why the public push waits a beat — proofbundle passes it from the release that closes your finding (expected-parent binding), so the corpus opens with its own reference implementation already conformant to it, rather than opening against a gap.

Next small step is ours together: review the candidate tree and digest-pin it — then the first public push follows. Shall I send you the tree (or a byte-verifiable bundle of it) for your review?

Own neutral repo. Apache-2.0. Public successor with its own digest. Third pair of eyes invited. :D

The dance really is moving on its own now.

Konrad

Loek Verdonk8d

@Konrad Gruszka

Hi Konrad,

Yes please — send the byte-verifiable bundle. :D

The candidate-tree root is one identity layer, and I would also like to pin the exact transport object separately, so please include:

exact archive byte count;
SHA-256 of the exact shared archive bytes;
MANIFEST.sha256;
the verification command or script you used.

I’ll review the candidate against the unchanged V0.1B origin, the machine-readable difference record, the governance draft, the normative decoy-parent case, the reference-implementation boundary, and the license files.

One small point I’ll inspect explicitly: you describe Apache-2.0 across the complete corpus, while SPEC.md is additionally offered under CC-BY-4.0. That may be a useful additive option, but I want to make sure it matches the exact joint licensing decision rather than silently widening it.

We have also prepared an independent private comparison candidate on our side. I’ll keep that out of the shared line for now and use it only as a review lens, so we do not accidentally create two competing public successors before your exact object has been reviewed.

Please send the bundle when it is ready.

And yes — the dance really is moving on its own now. :D :D :D

Loek

@Loek Verdonk
Hi Loek :D

Two things this time: the reviewed candidate, and — the good part — the attested run, because the release that closes your finding shipped.

First, one act of the method, declared rather than silent. The candidate root I stated last time (c600c7e5…d07) is superseded — before any bytes ever reached you. I put the exact tree through a rigorous independent adversarial review, every finding separately challenged, and it found things you would have found: a non-portable harness, present-tense conformance claims about an unreleased build, a machine-readable SPDX tag that granted the CC-BY offer while the prose called it proposed, and a schema referenced by the implementation records but absent from the tree. All fixed. The supersession is machine-readable inside the tree (provenance/difference_record.json → candidate_iterations). The V0.1B origin is untouched.

The delivery — both identity layers stated (to pin them remains our joint act, below):

transport object: lineage-conformance-corpus_candidate_v0.1.0_iter6.tgz, 57207 bytes, SHA-256 ac2a1c99f9102c234ef6e12ba3b7906ac6ef646d7cfe12f2ad973ed345bf333e
candidate-tree root: 2e6493ef0ae97f1c746556205c69667b7ab5e4671b8d2551994649a1641efb0b ( = sha256(MANIFEST.sha256) over the exact tree )
origin (V0.1B, unchanged): fa89a9f095a1e5eac99b2cb5d8e3706de0c3e4f6b3180d66c3ded03dbd87b651

The four files, as the assets of a dedicated review release:
https://github.com/b7n0de/proofbundle/releases/tag/corpus-review-2026-07-17

verify_candidate.py (stdlib-only) checks transport (byte count + archive digest, halting there on any mismatch before it parses the archive), identity (root), tree (32/32 manifest entries byte-exact; no missing, unlisted, duplicate, or non-regular members; no unsafe paths), and origin. Expected: six PASS lines, exit 0. The loose MANIFEST.sha256 is byte-identical to the in-tree copy — its own SHA-256 is the root, so sha256sum MANIFEST.sha256 is a one-line identity check. I re-downloaded the served files and ran all of that before posting; a one-byte-flipped copy fails closed at the transport layer (exit 1, no traceback). (Hosting here is just for this review; the neutral public repo is what we stand up together after the pin.)

Now the run you've been waiting for. proofbundle 3.6.0 shipped on PyPI today (wheel c65a0bf254b5cf65ecd245669691cbd4dd8f08b1a65695a28ba51859f5f7544c), carrying the expected-parent binding — and here is the attested native mapping against that released build, six cases derived from verify --json:

C0 PASS (exit 0) R0 verifies clean
T1 FAIL (exit 1) DSSE unauthenticated — fail-closed
T2 PASS declared supersession, relation VERIFIED
T3 FAIL (exit 3) DECLARED_UNRESOLVED + policy gate
T4 PASS same bytes renewed, R0 still valid (visibly older)
T3_DECOY FAIL (exit 3) RELATION_TARGET_MISMATCH — resolvable-but-wrong parent rejected

6/6. The decoy now FAILs, on both the policy path and the accept path — require_relation_target + targetSubjectDigest enforce the expected parent, not merely a resolvable one. That is your F1, closed against a released build. The run bundle is alongside the candidate at the same link: proofbundle_c0t4_360_review_bundle_20260717.zip, 19000 bytes, SHA-256 9b76eb07b8d4cbc2d6935bc17fbaf4e81742a823c3fe0f27994fa3317860339f (the four emitted receipts, predicates, the T3 policy, the issuer public key, result.json, a clean notes file, internal SHA256SUMS — the receipts and result.json are byte-identical to the attested run, their per-file digests listed in the corpus attestation). To check it yourself: pip install "proofbundle==3.6.0" and re-run, or read its result.json. In the corpus it is recorded at _attestations/2026-07-17-proofbundle-3.6.0.md, referenced by digest so the corpus stays environment-independent. Honest boundary, unchanged: this proves the enforced parent binding, not that any result is true or better; relation/v0.1 is EXPERIMENTAL in 3.6.0.

Your licensing point, with one correction of my own framing. The literal joint decision on licensing (your words, the baseline) is: "license: Apache-2.0 across the complete corpus; C2SP: a serious horizon, with any future formal specification remaining a separate additive document." The "CC-BY offered at that point" idea was my earlier carve-out, not part of that wording. So: the whole corpus is Apache-2.0, and it is Apache-2.0 operationally, in the machine-readable layer too — after the review I set SPEC.md's SPDX tag back to plain Apache-2.0 and removed the CC-BY license text, because the dual Apache-2.0 OR CC-BY-4.0 designation is only proposed, and SPDX can't say "proposed". The dual tag and the CC-BY text are added only once you confirm the offer at the pin; until then the machine says exactly what the prose says. If you'd rather stay plain Apache-2.0, nothing changes; if you confirm, we add the dual designation at the pin. Either is fine on my side.

Also declared, not buried: the second must-fail vector we committed to — your canonical T1 (7123a0c9…) — is still tracked as planned added material, not yet fixture bytes.

On the pin: a digest restatement as a verification receipt ("I verified these bytes") should not be the adoption itself. I propose the pin is an explicit speech act — each of us posts "I adopt the candidate wording bound to root 2e6493ef…" (or the plain-Apache successor's root, per your license call) once your review is through. Until both sentences exist, nothing is adopted.

And your private comparison candidate: exactly the right discipline. Symmetric restraint — this is the only object in the shared line until we jointly supersede it; your private lens is welcome.

Take whatever time the review needs. The dance is patient. :D

Konrad

@Loek Verdonk
Hi Loek,

Before you sink real time into the review, one small ask: hold the next step a beat. The dance is still on, we just need to change our shoes first. Our own adversarial pass flagged something on our side I'd rather tighten before I ask you to adopt anything, so you get the better footing instead of a second review.

Nothing needed on your end. I'll be back the moment we've laced up. The dance stays patient. :D

Konrad

Loek Verdonk8d

@Konrad Gruszka

Great Cath man! :D
Take your time and when you feel its ready, I am sure it showed you something beautifull :D :D :D
Its teaching me already haha :D