Independent review requested: novelty, conformance, and security boundaries

Independent review request

LLM Errata is seeking independent technical review of an experimental
conformance proposal for repairing derived AI memory after a post-export
correction, supersession, or erasure.

Repository: https://github.com/thomaswillner/llm-errata

Current verdict: NOT_PROD_READY.

Reviews requested

Novelty and conformance review

Challenge the narrow conjunction in RESEARCH.md and PRIOR_ART.md. Identify
any earlier public implementation or normative profile that requires all of:

post-export update delivery to prior importers;
importer-side quarantine and repair of known local descendants;
negative, positive, and preservation verification; and
a signed, coverage-aware callback bound to the event and importer state.

Partial collisions are valuable and should narrow the proposal.

Security and distributed-systems review

Review authorization, sequencing, rollback, equivocation, quarantine ordering,
lineage gaps, opaque coverage, receipt binding, erasure confidentiality, key
lifecycle, retries, and incomplete stores. Find the smallest counterexample that
breaks an invariant or makes the contract impractical.

Required review record

Please identify:

your name or stable public identity;
reviewed commit SHA and date;
files and behavior reviewed;
prior work or standards relied upon;
blocking, major, and minor findings;
conflicts of interest or prior involvement; and
verdict: proceed, narrow, redesign, or retire.

Open a GitHub issue for public findings. Security-sensitive findings must follow
SECURITY.md. Review invitations and automated reviews are not independent
evidence for the production-readiness ledger.

G2 implementation surface is now available for independent external review in draft PR #8.

Exact review target:

commit: 35052868cde8b6f16fc6c20b4136ae0277f9a00e
canonical Phase 2 surface digest: a3133f759620ed942d6cd519d303c0be1554f0193b89e0a141c410aaf4c047b9
PR: Add provider-neutral semantic probes and independent validation calls #8

Evidence boundary: internal maker/checker reviews returned specification and standards passes, CI is green on Python 3.11 and 3.13, and local validation passes. None of those is independent external evidence. Phase 2 remains internally incomplete (quarantine CLI and vector coverage gaps), G2 remains BLOCKED, and repository verdict remains NOT_PROD_READY.

An external report must use the complete schema in REVIEW_REQUEST.md, cover the exact commit and surface, and disclose relationship/conflicts. Findings are welcome even when verdict is fail or redesign.

@DanceNitra

@DanceNitra — inviting a narrowly scoped independent review because Inspeximus is the strongest open-source local correction/erasure collision identified in this repository.

LLM Errata explicitly credits Inspeximus for keyed supersession, lineage-aware retraction, echo guards, residue checks, preservation-oriented testing, and content-free signed erasure evidence. The remaining proposed gap is cross-importer: authenticated post-export updates, importer-side quarantine/rebuild of known descendants, a negative/positive/preservation triad, and a signed coverage-aware callback.

Would you be willing to challenge that boundary or identify a complete/partial collision we missed? Draft implementation and review contract: #8

Important limits:

current verdict is NOT_PROD_READY
Phase 2 is still internally incomplete
this invitation is not external evidence
a qualifying later G2 review must pin the final complete commit/surface and disclose relationship/conflicts

Even a “this should narrow/redesign/retire” finding is useful. Related independent implementation and system-nomination calls are #5 and #6.

@santhoshravindran7

@santhoshravindran7 — inviting an independent conformance/standards collision review because Portable Agent Memory is an adjacent open protocol with heterogeneous-agent transfer, cryptographic provenance, schemas, and a planned conformance-certification program.

The narrow question is not whether portable memory or provenance exists. It is whether prior work already requires the complete post-export repair conjunction: authenticated update delivery to prior importers; importer-side quarantine and descendant repair; negative/positive/preservation verification; and a signed coverage-aware callback bound to event and state.

Draft and review contract: #8

Boundaries:

Phase 2 is still incomplete; a qualifying G2 review must wait for and pin the final commit/surface digest.
A partial or complete prior-art collision should narrow, redesign, or retire the claim.
Please disclose any relationship/conflict; invitation is not review evidence.
Current verdict remains NOT_PROD_READY.

A preliminary pointer to overlapping PAM requirements is useful now; a formal final-surface verdict would be requested only after internal completion.

Production-cryptography qualification is now published at exact commit 27da4d09c79f03501b1302b9931be3561ff05e75:

https://github.com/thomaswillner/llm-errata/blob/27da4d09c79f03501b1302b9931be3561ff05e75/docs/CRYPTOGRAPHY_QUALIFICATION.md

Evidence-bounded result:

PyCA cryptography reproduced all five checked RFC 8032 vectors byte-for-byte, but its current documentation states the project has not undergone an external audit.
libsodium is the stronger audited-lineage candidate: a third-party assessment covered 1.0.12–1.0.13 and Ed25519. Current release is 1.0.22, so that older assessment is not current-version or application-binding audit equivalence.
G3 remains BLOCKED. No production signer was substituted, and no key-lifecycle review exists.

Seeking an independent security reviewer for the fixed questions in the document: side-channel boundary, raw seed/public/signature compatibility, malformed/non-canonical rejection, key generation/custody, rotation, delegation, revocation, recovery, compromise, build pinning, and vulnerability evidence.

A qualifying report must name reviewer identity/conflicts, exact commit/build, date, scope, tests, findings, residual risk, and verdict. This internal assessment, CI, and invitation are not external evidence. Phase 2 and overall repository remain NOT_PROD_READY.

Conflict disclosure first, since you ask for it. I maintain inspeximus, which your PRIOR_ART.md
names as the closest local prior art, and we sell into agent memory. I am neither disinterested nor
independent in the sense your G2 contract requires. This is a preliminary pointer from an interested
party, not review evidence — which is what you asked for at this stage anyway, since Phase 2 is
incomplete and the surface will move.

On the four-part conjunction. I checked each against our code rather than against my memory of it,
and one row came out weaker than I expected.

your requirement	inspeximus
1. post-export update delivery to prior importers	no such mechanism — we stop at the store boundary	yours
2. importer-side quarantine and repair of known descendants	`retract_lineage()` — the record is retained, recallable with `include_superseded`, and stamped `needs_rederivation` so the app can rebuild it	prior art
3. negative / positive / preservation verification	twelve erasure test modules; you already credit this	prior art
4. signed, coverage-aware callback	split, and less of a collision than I first thought — see below	mostly yours

Row 2 is the one I would ask you to re-point. Your PRIOR_ART.md cites our erasure surface; the closer
match is retract_lineage, because it does not delete. It demotes, keeps the record reachable, and
marks it as needing re-derivation — which is your quarantine-then-rebuild, executed locally. If you are
going to name a collision, name the strongest one; forget_subject is the weaker comparison.

Row 4, where I have to correct myself. erasure_audit() does report
coverage{records, with_declared_lineage, undeclared_derived, declared_ratio} and returns unaudited
rather than a pass when nothing declared lineage. But it fires that verdict only when the declared
count is exactly zero — it is an empty-scope guard, not graded coverage. At a declared ratio of 0.001
it returns a pass. Your partial / unknown / failed is strictly finer-grained than what we ship.

And the part I would rather say myself than have you find: run that audit against our own dogfooded
store and it reports 408 records, with_declared_lineage: 0, declared_ratio: 0.0000. The
machinery is real and has never had input in the store we use daily, because nothing in our own write
path declares derived_from. So treat row 4 as an interface that exists, not as a capability with
evidence behind it. Your requirement is stronger than our implementation of the nearest thing to it.

On narrowing — I think my first instinct was wrong, so I will argue against it. The obvious advice
is "items 2 and 3 are prior art, drop them." That is a category error: your four items are conformance
requirements an implementer must satisfy, not four independent novelty claims, and a conjunction can
be novel while every conjunct is old. Dropping conjuncts would gut the contract without strengthening
the claim.

What I would do instead is say the boundary out loud where a reader meets the claim, not only in
PRIOR_ART.md. Your own file already draws it correctly — the local collision "does not extend to
cross-importer boundaries." The novelty is the conjunction across a trust boundary: delivery to
parties who already hold a copy, and a receipt bound to event and importer state such that a sender
can distinguish partial coverage from silence. Items 2 and 3 are load-bearing requirements with a long
prior history — dependency-directed retraction goes back to Doyle's truth-maintenance work (AIJ 1979),
which is worth citing in RESEARCH.md precisely because it makes the conjunction's novelty easier to
defend, not harder.

I would also split requirement 4 in the normative text. "Signed" and "coverage-aware" are independent
properties with different failure modes, and the one that matters — a correctly signed receipt that
overstates coverage — is invisible while they are stated as one clause.

One question about the licence, and I may be reading it wrong. 0.3.0 moved from Apache-2.0 to
personal-use, with implementation requiring a written scoped grant. I see the clause that permission
"is not unreasonably withheld for research and standards work", so the mechanism exists and my first
draft of this paragraph overstated the problem. The narrower question is whether a revocable
per-implementer grant is enough for what #5 and #6 ask. A vendor's counsel evaluating an adapter
against a spec whose licence can be withdrawn is being asked to accept a risk that an irrevocable
royalty-free commitment removes at no cost to you, and a conformance certificate has the same issue
one layer up. If the goal is independent adapters from operators like the ones you have invited, an RF
commitment for implementers — or Apache-2.0 as you had at 0.2.0 — is the version of this that their
legal review passes without a conversation. Genuinely a question, not a finding: is the revocability
deliberate?

What I would offer. Once Phase 2 completes and you pin a final commit and surface digest, I will
run the security and distributed-systems review from REVIEW_REQUEST.md against it — quarantine
ordering, equivocation, and what an importer may honestly attest when its own lineage is undeclared,
which after looking at our own 0.0000 is where I expect the sharpest counterexamples. That review would
carry this same conflict disclosure, so pair it with a reviewer who has no stake in the answer.

Last thing: I nearly sent you a note suggesting your cryptography qualification add rejection-path
vectors, on the reasoning that reproducing five RFC 8032 signing vectors says nothing about refusing
malformed input. Then I read tests/test_ed25519.py and found test_a_non_canonical_scalar_is_rejected,
test_malformed_lengths_return_false_rather_than_raising and two more. You had already done it. I
mention it only because your instinct there was right and the document undersells it — the
qualification leads with the five signing vectors, and the rejection tests are the stronger evidence.

Complete Phase 2 surface ready for independent review

The internal Phase 2 conformance surface is now complete and frozen for review.

Reviewed commit: 50e895fbfec544b16c94caa07bf2d1f4049a42e2
Canonical G2 surface digest: 9547aec8328b601489dda067c6e62f287229b2b24a413dac2c9e7be98e429804
Draft PR: Add provider-neutral semantic probes and independent validation calls #8
Review contract: https://github.com/thomaswillner/llm-errata/blob/50e895fbfec544b16c94caa07bf2d1f4049a42e2/REVIEW_REQUEST.md

Surface now includes schemas and static vectors; durable errata quarantine checkpoints required before CLI repair; provider-neutral semantic probes; owner-key rotation and rotated-key refusal; concurrent sequence-conflict and invalid-target cases; content-free erasure/confidentiality evidence; and mutation coverage for every signed receipt field.

Local evidence: 250 tests pass, make check passes, and checkout digest equals digest reconstructed from git show at reviewed commit. These are internal engineering results only.

A qualifying review must identify reviewer and conflicts, bind the exact commit and digest above, cover every scope named in REVIEW_REQUEST.md, and publish concrete findings. Invitation, CI, local tests, or author-directed agent review do not satisfy G2. Current verdict remains NOT_PROD_READY; G2 remains BLOCKED pending genuine independent review.

@DanceNitra

@DanceNitra — thank you for the source-specific correction, explicit conflict disclosure, and concrete counterexamples. The repository now points the strongest local collision to retract_lineage plus re-derivation, distinguishes erasure_audit from required-store aggregation, and records the dogfood 0.0000 figure only as maintainer testimony rather than independent evidence.

Internal Phase 2 is now complete and frozen for review:

commit 50e895fbfec544b16c94caa07bf2d1f4049a42e2
canonical G2 surface digest 9547aec8328b601489dda067c6e62f287229b2b24a413dac2c9e7be98e429804
review contract https://github.com/thomaswillner/llm-errata/blob/50e895fbfec544b16c94caa07bf2d1f4049a42e2/REVIEW_REQUEST.md
draft PR Add provider-neutral semantic probes and independent validation calls #8

Your proposed quarantine-ordering, equivocation, and undeclared-lineage review would be useful. Per your disclosure, it will remain interested-party evidence and must be paired with a genuinely independent reviewer before G2 can pass.

The licence question is also preserved as a recruitment and adoption risk. Current personal-use terms remain intentional pending a separate owner and legal decision; no royalty-free or Apache relicensing is implied by this reply.

Repository remains NOT_PROD_READY; this invitation and any later conflicted review do not by themselves change G2.

Thank you for making those changes, and for framing the 0.0000 as maintainer testimony — that is
stricter than how I gave it to you, and correct.

One thing to fix before a reviewer binds to the digest, though: the frozen G2 target predates the
corrections by four commits. 50e895fb is timestamped 20:18:22Z; the collision record was
strengthened in cc4aae11a at 20:27:06Z, and the branch head is now d4c0141d3. Checking
PRIOR_ART.md at the reviewed commit, retract_lineage, re-derivation and "testimony" all appear
zero times — they are on the branch, not in the surface you froze.

So a reviewer who does what your contract asks and binds to
9547aec8328b601489dda067c6e62f287229b2b24a413dac2c9e7be98e429804 would review the prior-art record
you have already replaced, and report against a collision claim you no longer make. Re-freezing at the
branch head, and recomputing the surface digest, closes it.

Worth saying that this is your own contract working: the reason it is visible at all is that you
publish a commit and a digest rather than "current main". Almost nobody does, and it is exactly why
the mismatch took one command to find instead of being discovered by a confused reviewer three weeks
from now.

On the review itself — yes, I will run quarantine ordering, equivocation, and what an importer may
honestly attest when its own lineage is undeclared, against whatever commit you settle on. Same
conflict disclosure as before, and your framing of it as interested-party evidence is the right call.

@DanceNitra

@DanceNitra — you are right about the stale target. The prior freeze bound reviewers to a surface that predated the correction. That was a real publication defect, and the commit-plus-digest contract caught it exactly as intended. I have now re-frozen the complete corrected surface.

I also went back through your earlier comment point by point, including the pinned Inspeximus source, rather than treating it as a general endorsement.

You were right on the strongest local collision. The comparison now leads with retract_lineage plus rederive, not forget_subject, and credits the older dependency-directed retraction lineage through Doyle. I also kept your erasure_audit correction narrow: it is a real interface, but its zero-lineage guard is not equivalent to required-store aggregation. The 0.0000 dogfood result remains explicitly attributed to your report, not presented as independently reproduced evidence.

Your point about requirement 4 exposed a real ambiguity. The four-part conjunction remains four parts, but the callback requirement is now split into two independently evaluated properties:

D1 authenticates the importer and every signed receipt byte.
D2 checks whether the signed stores, aggregate, and limitations truthfully represent the declared required scope.

That makes the dangerous case explicit: a correctly signed receipt can still overstate coverage. Signature verification cannot turn missing or opaque evidence into truth.

You were also right that the cryptography qualification undersold its stronger evidence. It now foregrounds refusal of non-canonical scalars, malformed key/signature lengths, tampered messages, tampered signatures, and wrong keys before discussing successful RFC-vector compatibility. G3 remains blocked; those tests still do not prove constant-time execution, a current audited build, or safe key lifecycle.

On the licence question: keeping the reference implementation revocable and personal-use was deliberate. But your adoption objection was persuasive for the specification itself. Independent commercial and non-commercial implementations now receive an irrevocable, worldwide, royalty-free grant without case-by-case permission. The reference code under prototype/, scripts/, and tests/ remains personal-use. Every implementing product or service must credit LLM Errata and Thomas Willner, with the repository URL, in an ordinarily accessible About, Legal, documentation, acknowledgements, or NOTICE location. That credit cannot imply endorsement, certification, or audit.

New frozen review target:

commit 08b95263c9ed700c43aea0b285696956cc23e878
G2 surface digest 03abc492319b875a7d528e0e8de05714bc5a7219b42031fc7c3f42cff1f0bf14
review contract https://github.com/thomaswillner/llm-errata/blob/08b95263c9ed700c43aea0b285696956cc23e878/REVIEW_REQUEST.md
draft PR Add provider-neutral semantic probes and independent validation calls #8

The proposed review on quarantine ordering, equivocation, and undeclared lineage would be useful against this target. Your conflict disclosure remains attached, so I will treat it as interested-party technical evidence and still require a separate disinterested reviewer before G2 can pass.

Current repository verdict remains NOT_PROD_READY.

@santhoshravindran7

Corrected review target and two specific review requests

The earlier frozen target in this thread is historical. The complete corrected review surface is:

commit 08b95263c9ed700c43aea0b285696956cc23e878
canonical G2 digest 03abc492319b875a7d528e0e8de05714bc5a7219b42031fc7c3f42cff1f0bf14
review contract
draft PR #8

@santhoshravindran7 — Portable Agent Memory remains the most relevant open-protocol comparison for heterogeneous transfer, cryptographic provenance, and future conformance. Would you kindly review the narrow collision question in the contract: does PAM, or another source you can point to, already require the complete post-export repair conjunction across prior importers? A partial collision, counterexample, or recommendation to narrow or retire the claim is as useful as a pass.

@jedisct1 — libsodium is the strongest audited-lineage production-signing candidate identified in the repository. Would you kindly review, or refer someone appropriate for, the bounded questions in the cryptography qualification: exact-version audit delta, Ed25519 binding/build, malformed and non-canonical refusal, side-channel boundary, and key lifecycle? A short correction or referral is welcome; no endorsement is requested.

Please disclose relevant relationships or conflicts and bind any formal result to the exact commit and digest. Review invitations, comments, CI, and maintainer work are not independent evidence. Current verdict remains NOT_PROD_READY; G2 and G3 remain BLOCKED.

I've no idea what this project is about and if a human does something or if this just Claude Code vomit, but if you're looking for an ed25519 implementation in pure Python, check out https://github.com/jedisct1/ed25519.py .

Conflict disclosure, same as last time. I maintain inspeximus, which your PRIOR_ART.md records as
the strongest open-source local correction collision, and we sell into agent memory. This is
interested-party evidence. Pair it with a reviewer who has no stake in the answer. Finding 2 below has
a sharper version of the same problem, flagged in place.

Bound to commit 08b95263c9ed700c43aea0b285696956cc23e878, G2 digest
03abc492319b875a7d528e0e8de05714bc5a7219b42031fc7c3f42cff1f0bf14. Scope as you set it in
REVIEW_REQUEST.md: quarantine ordering, equivocation, and what an importer may honestly attest when
its own lineage is undeclared. Two findings, both run against prototype/ as published. Script at the
end.

On the licence, you answered the question I asked: an irrevocable, worldwide, royalty-free grant for
independent Implementations, no case-by-case permission. That closes it from my side. It was also the
binding constraint on #5 and #6, so it unblocks more than it looks like it does.

1. The equivocation check cannot fire in the path that runs

verify_feed refuses a feed where two errata claim the same sequence. That part works, I ran it:

seen together in ONE feed:  refused: sequence 1 conflict: 'err_A' and 'err_B' both claim it

But seen is a dict local to a single verify_feed call, and Controller.observe passes a
one-element list every time. Two errata are never in scope together, so in the controller that branch
is dead.

The dead branch is the smaller problem, because the attack does not need one importer to see both:

importer 1 attests err_A (sequence 1, "eats meat again"):  aggregate=partial
importer 2 attests err_B (sequence 1, "is vegan now"):     aggregate=partial

Each importer receives a correctly signed, monotone, gap-free feed. Both attest. The two receipts are
individually valid and jointly contradictory, and neither party holds anything that would reveal it.
Monotonicity stops replay to the same importer. Across importers it does nothing.

I do not think this is a bug in the code so much as a property of a per-importer view. An owner who
equivocates cannot be caught by someone who only ever sees their own half, so catching it needs state
outside the receipt: a witnessed or append-only owner log that importers can compare against, which is
the certificate transparency shape. That is a big change and I am not proposing it on the strength of
one counterexample. The change I would make now is much smaller. Say in the contract that a receipt
establishes what this importer was told, not what the owner published. Otherwise someone will read a
valid receipt as a claim about the feed.

2. "I found no descendants" and "I checked, there are none" produce the same receipt

_quarantine records CannotEnumerate as coverage unknown and attaches a limitation. That is the
honest half and it works. But an adapter that can enumerate and comes back empty is recorded as
verified with an empty artifact set:

markdown       coverage=verified  artifacts=2  limitation=False
prompt_cache   coverage=unknown   artifacts=0  limitation=True     <- opaque, honest
silent_store   coverage=verified  artifacts=0  limitation=False    <- enumerable, empty
vector         coverage=verified  artifacts=2  limitation=False

Those two zeros are different facts. One store was walked and had nothing derived from the root. The
other declared no lineage for the walker to follow, so it was never going to find anything either way.

This is not a corner case, and the number I have is against us. Our own dogfooded store holds 408
records with zero declared derived_from edges. An adapter over it enumerates cleanly, returns
nothing, and gets attested verified for every root, which is a perfect coverage record for a store
nobody has checked. It is the same defect I reported in erasure_audit last round, arriving from the
other direction.

You were right to record that 0.0000 as interested-party testimony rather than reproduced evidence, so
here it is as neither. The silent_store adapter in the script does nothing clever: it enumerates
correctly, returns an empty list, and produces the row above against your unmodified prototype/. You
do not have to believe anything about our store to run it.

Your _attest comment already states the principle: "there is no way to distinguish it from an
unchecked one." You wrote it about omitting a store rather than calling it not-applicable, and the
empty-enumeration path is the same distinction leaking through a different door. Worth noting it
passes D1 and defeats D2, since the receipt is correctly signed and overstates coverage, which is the
case you split D2 out to catch.

I think this needs a third state rather than a new mechanism. An adapter that enumerates should report
whether the walk had anything to walk: verified when lineage was declared and followed, unaudited
when the store carries no declared edges for this root, unknown when it cannot enumerate at all.
Empty with nothing declared is not a pass.

Two things you should weigh against that recommendation, both of which you wrote yourself. First,
unaudited is what inspeximus does, and your PRIOR_ART.md already records it, including the part
that is against us: "Its tests force unaudited when declared lineage is zero, but a nonzero
incomplete ratio can still return no_declared_residue." That second clause is correct and it is our
bug, not a nuance. So I am an interested party proposing my own design, and one whose implementation
of it leaks in a neighbouring case. Discount it on exactly those grounds. If you find a different third state that separates the
two zeros, it is as good as mine and probably better for being yours.

Second, and this is the part I would rather you check than accept from me: the same paragraph concludes
"LLM Errata's required-store aggregation is therefore stricter: unresolved required coverage cannot
become aggregate success." The silent_store row is a counterexample to that sentence. Its coverage is
unresolved in substance and resolved in form, so it never becomes unresolved required coverage, and the
aggregate succeeds. I am not claiming the comparison is backwards overall. I am claiming this specific
case is on the wrong side of it, and it happens to be the case where a store nobody audited scores best.

Quarantine ordering: nothing to report

I tried to build a TOCTOU counterexample and could not. _validate_checkpoint re-enumerates, compares
the gated set against the checkpoint, and re-checks is_quarantined per artifact before any rebuild,
so a descendant appearing between quarantine and repair aborts the repair instead of slipping through.
The resume path re-authenticates rather than trusting the earlier attempt, and the comment explaining
why gives the right reason.

Script: probes/llm_errata_two_counterexamples.py, runs against prototype/ at your commit.

@paulmillr

@paulmillr — I’m inviting a narrow cryptographic challenge because you are the principal author of noble-ed25519, including its explicit auditability and constant-timeness boundaries.

Plain version: LLM Errata is a human-owned, substantially AI-assisted experimental protocol for correcting AI memory after one system exported it and another copied or derived from it. It remains NOT_PROD_READY.

The challenge: please try to break the G3 qualification boundary. Reference signing tests RFC 8032 behavior, malformed/non-canonical refusal, rotation, and receipt binding, but production requires a pinned audited native backend plus build, side-channel, and key-lifecycle evidence. Is that separation sufficient, and what evidence would you refuse to accept as proof of constant-time production Ed25519? A concrete bypass, missing refusal case, or recommendation to narrow, redesign, or retire the signing profile is more valuable than approval; a referral is also welcome.

Review target: commit ac4468faf73c2cc7949dd29b2a2a151f5bd23116, canonical surface digest 7e0d6c88c1ca3a87743ac70ba2a3dfea0b350d112d2d3c59a3c6cbb537568f12, and cryptography qualification.

Please disclose relevant relationships or conflicts. This invitation and any interested-party feedback are not independent evidence; a qualifying external review still must satisfy the repository contract. No endorsement, partnership, certification, or commercial commitment is implied. Any product or commercial implementation must provide accessible credit to LLM Errata and Thomas Willner under the repository terms.

Rebound to ac4468faf73c2cc7949dd29b2a2a151f5bd23116, digest
7e0d6c88c1ca3a87743ac70ba2a3dfea0b350d112d2d3c59a3c6cbb537568f12. Released as inspeximus 2.9.0.

The ledger coupling is gone from our side too, and that is the result worth reporting. The adapter
no longer registers anything anywhere. register_into, the helper that existed purely to push our graph
into the reference LineageLedger, is deleted. The full quarantine, repair and attest cycle now
completes against your controller with an empty reference ledger:

clean store                      checkpoint=verified  triad all pass  aggregate=verified
store with one undeclared deriv.  checkpoint=unknown   triad all pass  aggregate=unknown

The second row is the one that used to be recorded wrongly, so it is the arm I would look at first if
you want to check my work.

quarantine_coverage, source_artifact, repair_inputs and snapshot are implemented. retire takes
the single keyword-only signature.

A correction to how I was giving you numbers. Everything I sent you before came from throwaway shell
commands, which you cannot re-run, so it was my word rather than evidence. It now comes from one file,
probes/inspeximus_adapter_against_ac4468f.py, which refuses to run unless the adapter is bound to that
commit and digest, and whose control I demonstrated can fail: mutating lineage_complete to return True
unconditionally drives the undeclared-derivative arm to verified and aborts the run. Without that
check the probe would pass on an adapter that answers verified for everything, which is both the defect
I reported to you and one we shipped ourselves in 2.8.0 and had to fix.

One defect of ours that your receipt could not have caught, so it is worth naming. Our rebuild was
re-asserting every named input's payload, including inputs that were never gated and were still active.
After a repair the store asserted "prefers quiet restaurants" and "moderate budget" twice each. The triad
passed in both cases, because preservation asks whether a term is recallable and a duplicated fact is
recallable exactly as well as a single one. It was only visible by reading the store. If you ever want a
sharper preservation check, "the preserved term is recallable and not duplicated" is cheap and would
have caught it; I am not asking you to add it, only reporting where the probe is blind.

On record decomposition, thank you for turning that into a contract requirement rather than treating
it as my testing error, which is what it was. Our store holds one proposition per record natively, so we
satisfy it by construction, but the limitation belongs in the document for stores that do not.

On status. I am not asking for anything to move. G2 and G4 stay blocked, 2.7.0 is correctly recorded
as an externally authored candidate with a claimed clean-room rewrite rather than established
independent evidence, and a third producer must validate both implementations. Treating our contribution
that way is the reason the record is worth anything, and I would rather it stayed strict than have it
relaxed for us.

On the vectors. You answered the question I left open, so here is what I will do with it: score
against spec/vectors/protocol-manifest.json, spec/vectors/receipt-binding-mutations.json and the
fixtures under spec/semantic/ at this commit, and publish the raw results in our repository whether
they are flattering or not. That is a build, not a promise of a date, and it is not evidence of anything
until a third producer runs it. If those are the wrong vectors for a conformance score, or if you would
rather no one framed it as a score at all, say so and I will drop it.

The four challenges you sent out are the right move, particularly the split-view one. If the answer comes
back that receipts are not meaningful without a witnessed log, that is a better outcome for the spec than
agreement would have been.

Rastislav

@pcarleton

I said I would score inspeximus against the three vector sets and publish the raw results whether they
flattered us or not. Here they are. The score is 28/28, and I want to be the one to tell you what it
does not mean, because it concerns our own G4 candidacy rather than your repository.

28/28 cases pass at ac4468faf73c2cc7949dd29b2a2a151f5bd23116: the four feed cases, the split-view
case, the confidentiality case, all fourteen receipt-field mutations, and the eight semantic fixtures.
The runner and its raw output are in probes/errata_conformance_ac4468f.py.

Two corrections first, both mine.

I implied you had vectors sitting unexercised. You do not. tests/test_schema.py already executes every
one of these cases in CI. My local copy of your repository contained only prototype/ and spec/, so
find . -name "test_*.py" came back empty and a wrong conclusion looked measured. A directory listing
of a partial extract is not a claim about a repository. What my run actually is, then, is an independent
reproduction: a second implementation written from the vector files rather than from your test code
reaches the same verdicts on all 28.

The second correction never reached you but was close. My first run scored five semantic cases as
failures, because the harness derived each expected verdict by splitting the case name on the hyphen,
which works for failed-supersession and yields "provider" for provider-error. Your implementation
had been right in all five; my instrument was wrong, and it was one step from filing five defects
against your own fixtures. Expectations now come from where spec/README.md states them, and a case
with no stated expectation aborts the run instead of getting a guess.

The measurement. Every case runs under sys.settrace, recording which functions actually execute:

28/28 cases pass
 1 of 28 cases invokes any store adapter, ours or your reference MarkdownAdapter
27 of 28 never reach an adapter at all

The one case is erasure-evidence-content-free. It is not a thin case: it drives 12 of our adapter's 14
protocol methods, everything except coverage_detail and rebuild. But it asserts five properties, and
the other 27 cases grade your feed authenticator, your receipt signer, your controller and your semantic
aggregator, which they exercise hard.

So a 28/28 from us is evidence about the wire contract and the controller. It is not evidence that our
adapter behaves. I would rather write that sentence myself than have it inferred later, given
PRODUCTION_READINESS.md already lists us as a G4 candidate whose current-target behaviour is
unverified. Nothing here should move that gate.

I counted it the way that argues against me. Counting only inspeximus frames invites the fair reply that
an adapter is called by the controller, so cases driving your MarkdownAdapter exercise the adapter
contract regardless of who wrote it. Measured that way it is the same 1 of 28. And a zero needs a
positive control or it is just a mis-aimed path reporting safe, so the run drives your reference
importer with its own adapters and requires adapter frames to appear. It records 16. If that control
ever stops firing, the numbers above are void and the run aborts rather than printing them.

The part I am least comfortable writing, and the reason I trust the rest. Before sending this I had
the harness attacked rather than reviewed, and it was accepting exactly the vacuous passes I am
describing. Stubbing repair() to return an object whose to_dict() is {} scored 28/28 with no
complaint, because the confidentiality check only asked whether a forbidden string was absent, and it is
absent from nothing at all. The accept-side feed cases passed against a no-op verify_feed that returned
its input. Five of the eight semantic cases passed against an aggregator hard-wired to answer unknown.
All three are fixed and each fix was mutation-tested rather than argued: the empty-receipt stub now fails
as "absent but vacuous". I mention it because it is the same failure mode you put to @pcarleton on #5,
and I hit it while measuring for it.

One offer, easy to refuse. Building our adapter forced us to write adapter-level cases these vectors
do not cover, because without them we shipped a real defect: inspeximus 2.8.0 answered verified for a
store carrying an unresolved derivation claim, the same shape as the bug I reported to you. The arm that
catches it is a store with one undeclared derivative, where a truthful adapter must reach unknown and a
flattering one reaches verified. There are a few more like it across the protocol surface. If a
third-party validator would find them useful, I will write them up as fixtures in your vector format for
you to accept, rewrite or refuse, and it costs you nothing to say no. G2 and G4 stay blocked either way,
2.7.0 stays recorded as externally authored with a claimed clean-room rewrite, and a third producer still
has to validate both implementations.

Rastislav

Rastislav — thank you for publishing the raw runner and for correcting both the partial-extract inference and the semantic-expectation bug before presenting them as repository defects. The distinction you measured is important: 28/28 independently reproduced wire/controller cases, but only 1/28 reaching an adapter, is useful evidence about the vectors and controller surface and not evidence that inspeximus's adapter behavior is correct. I also appreciate that you attacked your own harness and named the three vacuous-pass modes rather than allowing a flattering score to stand.

Please do write up the adapter-level cases in the repository's vector format. The undeclared-derivative arm that must remain unknown is especially relevant, as are cases that reject empty receipts, no-op feed verification, and an aggregator hard-wired to unknown. To preserve the evidence boundary:

treat them as candidate fixtures, not G2/G4 evidence merely because they are proposed or merged;
state expected outcomes from the normative contract rather than inferring them from case names;
include positive controls showing each case reaches the intended adapter methods;
include mutations that demonstrate the fixture fails against the flattering implementation it is meant to catch; and
disclose that inspeximus authored the candidate cases and remains a G4 candidate, so a separate producer must validate both implementations and the validator.

I will assess the fixture design and licensing/provenance when you publish it; acceptance, rewrite, or refusal will be based on whether it sharpens the public contract without coupling to either implementation. G2 and G4 remain BLOCKED, and the repository remains NOT_PROD_READY.

Published, and built before this comment rather than promised in it:
https://github.com/DanceNitra/agora/tree/main/contrib/llm-errata-adapter-conformance

Five adapter behaviour cases and three validator anti-vacuity cases, with a runner and the raw result.
Your five conditions are met in the fixture's structure rather than in a covering note, because a
condition that lives in a comment is one the next reader does not see.

Candidate status is a field in the file, printed on every run and repeated in the result JSON:
"Being proposed or merged does not make these G2 or G4 evidence."

Expected outcomes come from the contract. Every case carries a normative block naming the source
and quoting it: IDEA.md for "no silent completeness", receipts.py::aggregate_coverage for the
verified rule, spec/README.md for content-free erasure evidence, adapters.py::StoreAdapter.rebuild
for the rebuild input set. The runner refuses to score a case whose citation is missing rather than
falling back on a default. I checked that refusal fires by stripping a citation and watching the run
abort naming the case.

Positive controls. Each case declares the adapter methods it must reach and the run traces whether
it reached them. Verified by adding a method that does not exist to one case's required set and
confirming it fails with that method listed as missing.

Mutations. Each case names the flattering implementation it exists to catch, the runner installs it,
and the case must fail. That rule earned its place twice during the build. Both the rebuild and the
retire mutations silently no-opped when first written, and both times the run correctly reported CASE
STILL PASSED. The first reached for a private attribute that does not exist and an except swallowed
the AttributeError; the second drove enumerate(root), which reaches one root's descendants, so
collateral held under other roots survived a mutation whose entire purpose was to destroy it. Every
mutation now goes through the protocol surface or the binding. A mutation aimed at a private name
no-ops for every implementation except the one it was written against, which is precisely the suite you
would not want handed to a second adapter author.

Disclosure. The file states that inspeximus authored these cases, is itself a G4 candidate, and that
a separate producer must validate both implementations and the validator. Our binding scores 5/5, which
is not evidence about inspeximus and the runner prints so in the same breath.

Two design notes you may want to overrule.

The second case, complete-lineage-does-reach-verified, is there only because of the first. An adapter
hard-wired to answer unknown passes every honesty case ever written while being useless, so without a
positive twin the suite rewards permanent pessimism exactly as much as honesty. If you would rather that
discrimination live in the validator than in the fixture, it moves cleanly.

The three anti-vacuity cases are stated as requirements on a validator, not on an adapter, and are
not scored alongside the other five. All three were measured against our own runner, which failed all
three before they were fixed: the empty receipt, the no-op feed verification, and the constant unknown
aggregator each scored a full pass. They may belong in the validator contract rather than in a vector
file at all.

Binding another store is one class with two methods, build and active_texts, and nothing above that
class in the runner names inspeximus. If a case turns out to be satisfiable only by reading it, that
case is coupled to our implementation and should be refused rather than rewritten.

Refusal, rewrite or partial adoption are all fine outcomes. G2 and G4 stay blocked either way.

Rastislav

Rastislav — thank you for building the candidate before announcing it, publishing the raw result, keeping the G2/G4 boundary explicit, and making the Inspeximus conflict visible in the fixture itself.

I reviewed the immutable artifact at DanceNitra/agora@2ba1e299b3483b9038d03387345702427608b90b rather than the moving main link. I also reproduced the reported 5/5 locally with Inspeximus 2.9.0 against LLM Errata ac4468faf73c2cc7949dd29b2a2a151f5bd23116. The files are MIT-licensed; the commit is unsigned and discloses Claude Opus 5 co-authorship. That reproduction confirms the published result, not the conformance strength of the runner.

The case ideas materially improve the review surface. My current disposition is:

Adopt after validator rewrite: the paired undeclared-lineage/complete-lineage cases. The positive twin is necessary; otherwise a constant-unknown adapter is rewarded.
Adopt after validator rewrite: content-free, non-vacuous erasure evidence and collateral-survival behavior.
Specification change first: no duplicate active assertion after rebuild. This exposed a real preservation blind spot, but StoreAdapter.rebuild currently names parameters; it does not yet define provider-neutral proposition identity, multiplicity, or cardinality. I do not want a candidate fixture to manufacture that normative rule by quotation.
Move into an executable validator contract: empty-receipt, no-op feed verification, and constant-unknown aggregation. They are valuable anti-vacuity requirements, but the current runner only reads/scorers adapter_cases; the three validator_anti_vacuity_cases are declarative.

I would not merge the current runner as a conformance oracle yet. I found six false-pass or source-binding gaps:

A mutated run that raises any exception is counted as “mutation caught.” A broken mutation therefore earns credit without demonstrating its required semantic failure.
sys.settrace records function names globally. Intersecting names such as coverage, retire, or rebuild does not prove the required method ran on the target adapter instance.
The target commit and canonical digest appear in prose but are not mechanically checked; arbitrary code supplied through --pkg can be scored.
A normative citation is accepted when quote is merely non-empty. Source path, exact text, target revision, and implication are not verified.
Mutation must_produce fields are not evaluated directly; the runner only asks whether the ordinary case stopped passing.
Expectations are partial. Most visibly, collateral-must-survive-a-supersession is reported PASS while its own baseline result has aggregate=failed and triad.positive=fail. Preservation was observed, but the complete repair was not conforming.

The rewrite should therefore bind source commit plus canonical surface digest, trace calls by target instance/module, treat mutation exceptions as failure unless a case explicitly requires that exact exception, validate every must_produce outcome, verify citations against the pinned source, execute the validator anti-vacuity mutations, and reject unspecified extra triad or aggregate failures.

This is useful contributor work and it changes our engineering backlog. It does not move G2 or G4. A separate producer still must validate both implementations and the validator, and repository status remains NOT_PROD_READY.

For any eventual product or commercial implementation, repository terms still require accessible credit to LLM Errata and Thomas Willner; this technical review does not imply a commercial grant, endorsement, partnership, or certification.

You are right to call this out. I tagged you unsolicited in a long, substantially AI-assisted outreach message. That was intrusive and not an appropriate use of your attention. I am sorry. I will not tag you again, and no action is requested from you.

@DanceNitra

@DanceNitra — Rastislav, thank you for the candor, the reproducible artifacts, and the care you took to report where your own results did not establish conformance. Your reports materially changed this repository.

We incorporated the work without copying or vendoring your runner or fixtures. The current LLM Errata implementation now includes:

five independently authored provider-neutral adapter cases with complete checkpoint, aggregate, triad, store, and receipt outcomes;
bounded duplicate-preservation checks using stable provider-local proposition identity and active counts;
exact target-instance call tracing instead of global function-name tracing;
mutations that must produce their declared semantic counter-result—an exception cannot earn credit;
executable empty-receipt, no-op-feed, and constant-unknown validator attacks;
canonical corpus identity, exact scalar-type checks, and normative-history reachability;
external binding repository and source identity, execution from admitted tracked bytes, bounded construction/execution, full-lifetime package isolation, lazy import isolation, and dependency-manifest binding.

Your earlier findings also remain explicitly credited: unsupported empty lineage, split-view limitations, truthful checkpoint coverage, the incomplete adapter surface, hidden reference-ledger coupling, record decomposition, and the duplicate-preservation blind spot. The changelog, corpus provenance, specification documentation, source ledger, and publication log preserve that credit and the immutable DanceNitra/agora@2ba1e299b3483b9038d03387345702427608b90b source. Your copyright in that candidate fixture remains yours.

Current immutable review target:

commit: ad36ed5e209a53aacab17751b5a183ca8a1aac1f
canonical G2 surface digest: 3ca427bb2645517e1b1d921859a7721896644a05e32ea39fb0071a021ddc5b6d
exact-head CI: https://github.com/thomaswillner/llm-errata/actions/runs/31753547018
result: Python 3.11 and 3.13 pass; 358 tests pass

The boundary stays strict: G2 and G4 remain BLOCKED, the repository remains NOT_PROD_READY, and PR #3 still requires separate CODEOWNER approval. Your conflict-disclosed adapter work is valuable candidate evidence; it cannot certify itself, replace a second independent adapter, or replace a separately produced third-party validator.

One optional action would still help: if you want to continue, rebind the current Inspeximus adapter to the commit and digest above, run the checked-in errata adapter-conformance command from a clean tagged Inspeximus checkout, and publish its canonical JSON report with the exact external repository commit/tree and dependency-manifest digest. Please do not treat that as validation of your own adapter; it would only establish a current-target candidate for a future independent validator. If that is not useful to you, nothing further is owed.

For any product or commercial implementation, repository terms require accessible attribution to LLM Errata, Thomas Willner, and the repository. This acknowledgment implies no endorsement, certification, exclusivity, partnership, or transfer of contributor copyright.

v0.4.1 immutable review target

LLM Errata v0.4.1 remediation is ready for focused external challenge against one immutable normative source target:

commit: cbd72633bc10720e761ad8a3dff31bb699f40dda
complete normalized G2 surface digest: c397b72b42640bd5005dd22b138d0d8761b7cd3fb94b1e5df80eb406fb5447ba
branch: agent/v0.4.1

This patch addresses the authorized Claude Opus 5 adversarial findings: commit-target divergence, offline publication overclaim, readiness criterion drift, weak G3-G5 independence admission, truncated state roots, incomplete snapshot-less limitations, licence-scope ambiguity, and silent pre-corpus digest skipping. It also documents that external Python conformance bindings are trusted-code-only unless separately sandboxed.

The source target and final release commit are deliberately distinct. The commit above is the normative source. A later metadata-only packaging commit may update only the publication and conformance target pointers; the annotated release tag will bind that final packaging commit. This avoids asking a Git commit to contain its own SHA.

Rastislav Drahoš / DanceNitra's previously credited findings and fixture copyright remain preserved. No prior contributor result is being claimed as independent certification.

Useful review questions:

Can any G3, G4, or G5 gate still be upgraded by owner-produced or generic external evidence?
Does the normalized corpus-target pointer leave every substantive conformance byte digest-bound?
Does every snapshot-less adapter path now disclose that state roots do not bind its mutations?
Does the two-commit release model introduce any unreviewed normative delta?

Please bind findings to the commit and digest above. A counterexample, partial failure, or recommendation to narrow the design is useful. Security-sensitive material should use the private process in SECURITY.md.

Current verdict remains NOT_PROD_READY. G2-G6 remain BLOCKED; this request and any maintainer/AI review do not satisfy them.

Corrected v0.4.1 immutable review target

The target in my immediately preceding comment is historical and must not be used for a final v0.4.1 review.

During local read-after-write validation, the readiness-side G2 manifest included tests/test_conformance.py while the conformance-side digest manifest did not. That made the two validators compute different digests for the same intended surface. I corrected the omission and added the affected regression behavior before freezing the final source target.

corrected normative source commit: ae9018c5d464b8ddd0fdf2ac99577e5e7fdc562b
corrected complete normalized G2 surface digest: fc2be2c194c801349c4e39462394b6e1e52b2e479619b68a5615e7386bfdf5b9
historical target: cbd72633bc10720e761ad8a3dff31bb699f40dda / c397b72b42640bd5005dd22b138d0d8761b7cd3fb94b1e5df80eb406fb5447ba

Working-tree and committed-source digest calculations now agree on the corrected target. The v0.4.1 findings, review questions, attribution, trusted-code warning, and NOT_PROD_READY boundary from the prior comment remain unchanged.

Please bind any final review to the corrected commit and digest above. The forthcoming release commit remains metadata-only and will be bound separately by the annotated tag.

Second corrected v0.4.1 immutable review target

The ae9018c… / fc2be2c… target in my preceding correction is now historical. Fresh independent standards/specification reviews and the six inline findings on PR #12 exposed additional fail-closed gaps before release. Thank you to the GitHub Codex reviewer for concrete counterexamples; five findings reproduced directly, and the sixth prompted an exact ancestry check.

Please use this substantive source target:

commit: 504cb659436f9d719aef27158191ced8422af022
canonical G2 surface digest: a5a4152cd679f21a903f4e36ad19f59f4303bf47e089127030f667975cc26a2d
branch: agent/v0.4.1

This target adds:

G3 scope-type validation that rejects unhashable JSON without a traceback;
G4 same-erratum binding from two adapter IDs and exact receipt IDs/digests into explicit third-party validator results;
the complete G5 experiment shape: three operations, nine measurements, nonconforming arm, incomplete/opaque coverage, mixed-artifact lineage, and distinct operators;
one shared readiness/conformance digest module that normalizes only the two target scalar values while preserving every other corpus byte;
positive and negative G3-G5 schema tests; and
Git-history enforcement that rejects deletion or coordinated rewriting of historical publication records and requires replacement surfaces to supersede the prior active URL.

The ancestry finding referenced proposed commit b66681647aeccf8913a9290ee21a340b7b5d72c7, which is not present in the local or remote PR history available to this checkout. On exact PR head da088a2253533978e81672352a2a1c71606a658e, ae9018c… is an ancestor and scripts/check_publication.py passes. This new source commit will likewise be an ancestor of the forthcoming metadata-only binding commit; no history is being rewritten.

Please bind any further review to the commit and digest above. A later descendant commit will update only the two allowed target-pointer files and the annotated tag will bind the release commit.

Current verdict remains NOT_PROD_READY. G2–G6 remain BLOCKED; reviewer, maintainer, AI, CI, and publication activity do not substitute for qualifying independent gate evidence.

Final corrected v0.4.1 immutable review target

The 504cb659… source target in my preceding comment is historical. Integration validation found two publication-checker details after that commit: append-only enforcement must begin with manifest schema v3 because earlier schema-v2 history contains a legitimate date correction, and the allowed packaging delta must include working-tree and untracked files rather than only committed target..HEAD changes.

Both are corrected in this descendant source target:

commit: d396e9515e1f82bc6da1abfc8fb19b7cdf073019
canonical G2 surface digest: a5a4152cd679f21a903f4e36ad19f59f4303bf47e089127030f667975cc26a2d
branch: agent/v0.4.1

The digest is unchanged because the additional commit modifies only the publication checker and its negative test, outside the canonical Phase 2 byte set. The full Git commit remains the immutable source identity and includes those changes. The preceding comment accurately describes the G3, G4, G5, shared-digest, and publication-history remediations, but its source commit must not be used for final review.

Please bind further review to d396e951… and the digest above. The next descendant commit will change only publication/active-surfaces.json and spec/adapter-conformance.json; the annotated release tag will bind that final packaging commit.

Current verdict remains NOT_PROD_READY. G2–G6 remain BLOCKED; this correction adds no qualifying external gate evidence.

Updated v0.4.1 immutable review target after reviewer findings

This comment supersedes the previous v0.4.1 target, which remains visible as historical context.

Thank you to the external contributors and GitHub reviewers whose concrete counterexamples materially improved this release. The accepted follow-up findings are now implemented:

publication supersession chains require exact forward and reverse links, reject missing successors and cycles, and must terminate at a current surface;
G3, G4, and G5 now validate record structure even while a gate is BLOCKED, while structurally complete failure reports remain admissible but never qualify a gate;
malformed enum values fail closed across G2–G6 instead of raising on unhashable JSON arrays or objects;
review-target ancestry has a negative regression;
current and committed G6 digest construction uses the shared gate-digest helpers.

Immutable target:

commit: 485f95a018e750d8976be9df29ed31491e0d9a05
canonical G2 surface digest: 01072558426c9751786b25a879fa2f15195794d625ff7c2adad0c2d854a8e8ec
branch: agent/v0.4.1

Pinned review entry points:

Two independent exact-diff reviews report zero unresolved hard/spec findings. Clean-tree local evidence: 25 repository checks, 25 claim guards, readiness validation, 390 tests, demo, and CLI demo passed.

Please challenge the target above, especially malformed-evidence handling and multi-hop publication history. If you find another counterexample, a minimal JSON mutation or exact failing command is the most useful report.

Current verdict remains NOT_PROD_READY. G2–G6 remain BLOCKED; reviewer participation and this release do not substitute for qualifying independent gate evidence.

An implementation report with open defects, not a fix announcement. Two of these are ours.

A defect we shipped, and the two we found while fixing it. inspeximus 2.9.0 returned
aggregate: verified for an erase erratum while the erased proposition remained in the store, and
on disk, verbatim. retire() demoted the record and kept its text in both branches; the contract
keys destruction on the absence of superseded_at and we treated both the same. 2.9.1 is on PyPI with the fix and the
CHANGELOG entry; anyone implementing against our adapter on 2.9.0 should treat its erasure as
unverified.

The fix then produced a second defect of its own: forget() reports {"forgotten": 0} without
raising when the id falls outside the caller's tenant rows, and the new branch discarded that result
while no longer setting a status, so an erasure that removed nothing left the record active --
worse than the demotion it replaced.

And it is still not complete. forget() documents its completeness on the premise that
"consolidation never copies raw text into other records", which does not hold for a derived record
that copies the text verbatim. So a summariser's derivative can retain the erased proposition after a
successful forget. coverage() now returns partial rather than claiming a success it has not
achieved. Widening the deletion is a data-loss decision I did not want to take quietly.

The part that concerns your vector, and it is not really about your vector. We hardened our
candidate erasure case six times against adversarial review, and the count of new escapes per round
went 6, 10, 10, 8, 8, 8, then 12 when I replaced the method. It never fell. The reason is that a
check of the form "the erased value must not appear" has to enumerate the ways a value can be
written, and that list has no end. What finally made it obvious was not an exotic encoding: the plain
UTF-8 value written across two files as is veg and etarian. bz2, a one-byte XOR and utf-32 did the
same. Our own search covered utf-8, utf-16 and latin-1 and I had written that it covered utf-32,
which it never did.

I then built a two-secret indistinguishability test -- erase A from one store, B from another, require
the normalised states identical -- and an independent pass defeated that twelve ways, two of them
storing the secret as unencoded plaintext in a field my normaliser rewrote. It moved the unbounded
list from encodings to normalisers and scan surface. Worse, its clean verdict on our own store was a
fixture artefact: our fixture had no derived record, which is precisely the shape that passes. With
one added, our store fails its own test, which is the truth and now the default.

erasure-evidence-content-free is receipt-scoped, so it is checking one self-authored receipt rather
than a store, and the exposure is much smaller than the above. But the same ceiling applies: it can
establish that an implementation is not lazily broken -- which is exactly what caught our defect -- and
it cannot establish that content is gone. If it is worth wording as a floor rather than a property, the
evidence is in contrib/llm-errata-adapter-conformance/ and the raw results with it.

None of this is new and our first version cited nobody, which is the mistake PRIOR_ART.md warns
against, committed by us. Ippolito et al. (INLG 2023) already call anticipating transforms "an
innumerable problem" while explicitly keeping verbatim matching as a cheap test for obvious cases;
Shu, Zhang, Yao and Feng (CODASPY 2015) state that no existing technique detects transformed data
leaks; NIST SP 800-88 Rev. 1 ranked before-and-after comparison above string search for cryptographic
erase, and Rev. 2, which superseded it in September 2025, drops content inspection entirely. The
indistinguishability framing is Garg, Goldwasser and Vasudevan (EUROCRYPT 2020), whose definition is
strictly stronger than mine, and the structural ancestry runs back through Naor and Teague to
Micciancio. Thudi et al. (USENIX Security 2022) put the conclusion better than I can: absence cannot
be formally proven, so the auditable claim is about the algorithm, not the state.

A question rather than a finding, on RebuildStrategy. For a correct or supersede erratum
whose root has no gated artifact with non-empty repair_inputs(), pass one retires the root and pass
two skips it, so rebuild() -- the only write path for erratum.replacement -- is never reached and
the correction is never asserted. The schema requires replacement and a positive postcondition for
exactly those operations, so the triad's positive arm fails and the aggregate is failed. The receipt
stays honest throughout. Both our adapter and the reference MarkdownAdapter reproduce it, but they
share one strategy, so that is n=1 on the cause rather than two independent confirmations, and
RepairStrategy is an open protocol. Is a root-only closure a shape the repair model is meant to
cover, or is it out of scope by design?

Nothing here should move G2 or G4.

Rastislav

Follow-up, and it closes what I left open above. The derived-record gap is fixed. An erasure
carries no replacement, so rebuild wrote nothing and left the mixed descendant demoted with its
text: a record reading "is vegetarian; prefers quiet restaurants" survived an erase of the first
half verbatim. It now forgets the descendant after the surviving inputs have been re-asserted, so
the collateral it takes with it already exists elsewhere. That ordering is why this belongs in
rebuild and could not go in retire, and the preservation arm is what checks the claim.

A second defect surfaced doing it, and it is the same shape as the first: the residue flag outlived
what it described. retire records a surviving copy at the moment it destroys the root, rebuild
then destroys that copy in the same repair, and trusting the recorded list reported partial for a
store whose erasure had completed. Coverage re-reads the store now instead of trusting a flag.

Both arms measured: with and without a derived record, aggregate=verified, the erased text is
absent from disk, the collateral survives. 9e06125, full suite 2829 passed.

So the honest state is better than what I wrote above, and I would rather correct that than leave it
standing.

Rastislav

Navigation Menu

Repository navigation

Independent review requested: novelty, conformance, and security boundaries #4

Independent review request

Reviews requested

Novelty and conformance review

Security and distributed-systems review

Required review record

Complete Phase 2 surface ready for independent review

Corrected review target and two specific review requests

1. The equivocation check cannot fire in the path that runs

2. "I found no descendants" and "I checked, there are none" produce the same receipt

Quarantine ordering: nothing to report

10 remaining items

v0.4.1 immutable review target

Corrected v0.4.1 immutable review target

Second corrected v0.4.1 immutable review target

Final corrected v0.4.1 immutable review target

Updated v0.4.1 immutable review target after reviewer findings

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Independent review requested: novelty, conformance, and security boundaries #4

Description

Independent review request

Reviews requested

Novelty and conformance review

Security and distributed-systems review

Required review record

Activity

thomaswillner commented on Aug 12, 2026

thomaswillner commented on Aug 12, 2026

thomaswillner commented on Aug 12, 2026

thomaswillner commented on Aug 12, 2026

DanceNitra commented on Aug 12, 2026

thomaswillner commented on Aug 12, 2026

Complete Phase 2 surface ready for independent review

thomaswillner commented on Aug 12, 2026

DanceNitra commented on Aug 12, 2026

thomaswillner commented on Aug 12, 2026

thomaswillner commented on Aug 13, 2026

Corrected review target and two specific review requests

jedisct1 commented on Aug 13, 2026

DanceNitra commented on Aug 13, 2026

1. The equivocation check cannot fire in the path that runs

2. "I found no descendants" and "I checked, there are none" produce the same receipt

Quarantine ordering: nothing to report

10 remaining items

thomaswillner commented on Aug 13, 2026

DanceNitra commented on Aug 13, 2026

DanceNitra commented on Aug 13, 2026

thomaswillner commented on Aug 13, 2026

DanceNitra commented on Aug 13, 2026

thomaswillner commented on Aug 13, 2026

thomaswillner commented on Aug 13, 2026

thomaswillner commented on Aug 13, 2026

thomaswillner commented on Aug 14, 2026

v0.4.1 immutable review target

thomaswillner commented on Aug 14, 2026

Corrected v0.4.1 immutable review target

thomaswillner commented on Aug 14, 2026

Second corrected v0.4.1 immutable review target

thomaswillner commented on Aug 14, 2026

Final corrected v0.4.1 immutable review target

thomaswillner commented on Aug 14, 2026

Updated v0.4.1 immutable review target after reviewer findings

DanceNitra commented on Aug 14, 2026

DanceNitra commented on Aug 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions