Encevra Research Round 20

What Must the Log Reveal? Minimal-Disclosure Receipts for Verifiable Evidence Delivery

11 October 2026 | Research paper | Version 1.0

Evidence status: Primary-source and authoritative-standards review; continuity inspection of the Encevra Research archive at commit 2998fad7543bb2adb1def50e3cd1cef1eddbc9dd; and an executed deterministic development harness over constructed event histories. Fourteen external sources were directly inspected at the depths recorded in Section 18. The supplied standard-library program passed 76 of 76 named checks across 96 constructed episodes, eight synthetic task families, twelve corruption families, and 6,912 mutated episode-arm evaluations. It also verified 480 valid reveals and rejected 480 altered reveals. These are protocol and engineering-diagnostic results, not language-model performance or production-security results. No new Encevra language-model benchmark, model call, human annotation study, production database inspection, collector deployment, or Noetis reasoning change was performed. H20-1 through H20-4 and E20-B remain proposed and untested.

Abstract

Round 19 established a measurement gate: before Encevra can credit a reasoning protocol for using evidence, the collector must bind exact provider-bound inputs, source versions, order, truncation, retries, responses, and terminal output. The same round also identified a conflict. Retaining raw prompts and source text makes reconstruction easier, but expands sensitive-data exposure, storage, access, and deletion obligations. Hashes appear to offer an easy compromise, yet an unsalted digest of a low-entropy policy record can be guessed offline, a self-generated chain can be rewritten by the same compromised operator, and a receipt cannot prove an event that was never emitted.

Round 20 asks a narrower, falsifiable question: Can Encevra bind the application-observable evidence lifecycle strongly enough for an authorized audit while keeping raw prompt and source content out of routine telemetry, within explicit leakage, overhead, and post-compromise limits? The question extends Round 19's Evidence Lifecycle Observation Contract without repeating it. Round 19 defined what must be observed. Round 20 tests what can be committed publicly, what must remain in a protected reveal store, and when an independent witness is necessary.

We propose the Minimal-Disclosure Invocation Receipt (MDIR), a research profile with four separations: canonical content versus its commitment; routine public receipt versus protected reveal material; operator-held event chain versus independently witnessed checkpoint; and observable delivery versus causal use. Each event is canonically encoded, bound with a fresh secret salt, linked into an ordered chain, and associated with explicit parent events. The provider-bound request carries an ordered evidence manifest with source version, position, byte slice, truncation, and content commitment. Raw content and salts remain outside routine telemetry. A production design would checkpoint the chain with an asymmetric COSE receipt or transparency service; the development harness uses a separately keyed witness MAC only to test the trust-separation logic.

The executed harness compares six arms: endpoint-only, generic operational trace, raw inline log, unkeyed digest receipt, secret-salted receipt, and witnessed MDIR. Against ordinary artifact changes while the original receipt remained available, endpoint-only detected two of twelve corruption families, the generic trace detected four, and all content-bound arms detected twelve. Against a stronger simulated operator that rewrote both artifacts and every operator-held record after the checkpoint, the first five arms detected none; witnessed MDIR detected all twelve under the stipulated uncompromised-witness assumption. In a 128-candidate low-entropy probe, both an unsalted digest and a digest with a public salt uniquely disclosed the target; the secret-salt view offered no confirmable candidate without the salt. This is a view-based diagnostic, not a proof of secrecy.

The result is deliberately bounded. Minimal-disclosure receipts can separate routine observability from authorized reconstruction and can expose certain post-checkpoint rewrites under explicit trust separation. They do not prove source truth, completeness before the logging boundary, internal model processing, or causal evidence use. The current Encevra product collector still has not been shown to emit MDIR correctly. The next gate is a held-out collector study with independently authored traces and asymmetric receipts, not a claim that the reasoning system improved.

1. Numbering, archive inspection, and continuity

The live Lovable project contains completed research through Round 19, so the next sequential paper is Round 20. This corrects the automation request's older Round 11 designation. The archive was inspected at commit 2998fad7543bb2adb1def50e3cd1cef1eddbc9dd: Research overview, rounds index, publications registry, the full Round 19 and Round 18 manuscripts, the Round 17 manuscript, the Round 10 and Round 9 routes, the research registry, and the implementation status carried forward by Round 19.

Round 19, Did the Evidence Reach the Agent? Reconstructable Evidence Lifecycles for Reliable Experiments, reported that only 4 of 18 collector requirements were present at the required granularity, 3 were partial, and 11 were absent. Missing items included versioned source identity, content digests, exact per-call delivery manifests, immutable input-output binding, event sequence, revision lineage, terminal content identity, retry history, privacy and redaction binding, and exact receiver exposure. Its 44 checks over 15 development fixtures validated an event-schema concept, not the live collector.

Round 19's handoff was conditional. If an exposure-level ledger passed held-out validation, Round 20 could resume the smallest Round 18 versioned-repair pilot. If invocation binding or privacy failed, Round 20 should remain an instrumentation and governance round. The archive has no intervening collector implementation or held-out E19-B result. The project commit is the Round 19 publication commit, not evidence that the Noetis collector now binds provider inputs. Round 20 therefore follows the failed-gate branch.

Round 20 is distinct from Round 19 in both object and falsifier. ELOC asked what events must exist. MDIR asks which event properties can be proven to an authorized reviewer without routine raw-content capture, and which attacks still succeed. MDIR should be rejected or simplified if raw inline logs or a strong generic trace provide the required reconstruction with acceptable privacy, if independent witnessing adds no post-compromise value, or if protected reveal makes audits too costly or unreliable.

2. Research question, novelty rationale, scope, and exclusions

Research question: Can salted, ordered, independently witnessed invocation receipts preserve exact application-observable evidence delivery for authorized audit while keeping raw prompts and source text out of routine telemetry, with acceptable leakage, false-alarm, storage, latency, and reconstruction costs?

The topic was selected after archive and literature inspection for five reasons.

1. Round 19 explicitly left privacy and invocation binding as failed gates.
2. OpenTelemetry's current GenAI conventions treat instructions, messages, and outputs as sensitive and recommend not capturing them by default. [S11]
3. Mature standards now exist for canonicalization, authenticated statements, verifiable data structures, receipts, and transparency, but they do not specify an AI evidence-delivery contract. [S1-S5, S7-S8]
4. A new Internet-Draft published on 8 October 2026 proposes salted digest-only evidence logs, completeness chains, selective disclosure, and spot checks. It is unusually close to Encevra's problem, but it is work in progress and does not establish provider-bound AI exposure. [S6]
5. The question can be tested initially with frozen constructed histories and zero model generation, separating collector claims from reasoning claims.

The novelty claim is narrow. MDIR does not invent canonical JSON, HMAC, commitments, Merkle trees, transparency logs, secure audit logs, attestations, or selective disclosure. Its proposed contribution is an Encevra-specific composition and evaluation boundary:

• exact ordered evidence manifests at the provider invocation boundary;
• fresh secret-salted commitments rather than raw content or guessable public digests;
• explicit separation between routine receipt, protected reveal material, and independent checkpoint;
• event parents, retries, model identity, usage, and terminal binding in the same chain;
• assurance levels that stop before internal processing and causal use; and
• an adversarial harness that tests both ordinary corruption and privileged rewrite.

This round excludes:

1. A claim that commitments encrypt content. They do not.
2. A claim that a salt is safe merely because it is called secret. Generation, storage, access, rotation, backup, and deletion all matter.
3. A claim that a hash, signature, or receipt establishes source truth, authorization, completeness, or semantic support.
4. A claim that application-observable provider-bound bytes equal internal tokenization, attention, or causal use.
5. Full chain-of-thought capture.
6. A production cryptographic implementation, formal proof, penetration test, or third-party security review.
7. Legal advice or a conclusion that a design satisfies privacy, records, discovery, or sector-specific law.
8. A live Encevra collector change, production database audit, or model benchmark.
9. Literal brain copying. Section 15 uses a memory-index theory only to derive one ablatable storage arrangement.

3. The properties must be separated

The phrase "verifiable log" compresses several different properties. A design can have one and lack the others.

This separation prevents two dangerous promotions. First, integrity is not confidentiality. RFC 9334 explicitly treats sensitive evidence as requiring both integrity and, where needed, confidentiality protections. [S8] Second, inclusion is not completeness. RFC 9942 can prove that a statement is in a verifiable data structure; it cannot prove that an omitted event was ever submitted. [S4]

4. Threat model and trust boundaries

MDIR has no meaningful security claim without a named adversary and trusted components. Round 20 uses four views.

T0 - accidental or unprivileged mutation. An artifact or event changes, but the original receipt remains available. Content-bound logs should detect the mismatch.

T1 - routine telemetry reader. The reader can see public receipts, event counts, coarse types, times or sequences allowed by policy, and stable or rotating identifiers. The reader cannot access raw artifacts, salts, reveal keys, or witness keys. The privacy objective is no raw prompt or source text in this view, while acknowledging metadata leakage.

T2 - privileged application operator after checkpoint. The operator can rewrite the artifact store and all operator-held logs and can recompute unkeyed digests or any tags whose secrets it controls. The operator cannot alter a checkpoint already held by an independent witness and cannot use the witness signing key. This is the threat under which external witnessing has incremental value.

T3 - witness or reveal-store compromise. The adversary obtains the witness key, secret salts, protected artifacts, or all of them. The development mechanism does not promise privacy or non-equivocation under total compromise. Production must specify key isolation, quorum, rotation, revocation, audit, and recovery rather than hiding this failure mode.

The trusted computing base remains material. A perfect receipt over the wrong request is perfectly misleading. Prompt construction, the provider-bound hook, canonicalizer, salt generator, receipt emitter, and witness client must be version-bound and tested. A provider may also transform requests after the application boundary. MDIR labels this as an application-observable boundary, not an attestation of provider internals.

5. Literature map and competing positions

The focused review was performed on 11 October 2026. Publication dates, working links, inspection depth, and claim boundaries are preserved in Section 18 and source_ledger.json.

5.1 Established or standards-grounded

• Deterministic canonicalization is necessary when signatures or hashes must survive equivalent serializations. [S1, S7]
• A MAC authenticates data under a shared secret; it is not encryption. [S2]
• Merkle inclusion and consistency proofs can make a registered sequence efficiently auditable. [S3-S5]
• Sensitive evidence and GenAI content require a privacy design beyond integrity protection. [S8, S11-S12]
• Signed or authenticated metadata can bind stages, inputs, and outputs in multi-stage pipelines. [S9]
• An operator-held current checksum alone does not provide a meaningful post-compromise history. [S10]

5.2 Mixed, conditional, or context-dependent

• Public transparency improves auditability but can create metadata and content exposure. CT, SCITT, CONIKS, and Sigstore-like systems make different choices because their subjects and threat models differ.
• Secret salts reduce offline confirmation only while they remain secret and sufficiently random. They add key-like lifecycle obligations and do not encrypt the protected artifact.
• Independent witnesses improve post-checkpoint tamper evidence, but add availability, governance, latency, and correlation risks.
• Raw inline logs maximize immediate reconstruction but may be unacceptable for sensitive production data. Protected external artifacts preserve an audit path only while authorization, retention, and locator integrity hold.
• Completeness chains can expose gaps inside the declared chain, but cannot prove that every real-world event entered the chain.

5.3 Open questions

• Can a real Encevra collector bind the final provider-bound request reliably across SDK transformations, retries, streaming, fallbacks, and truncation?
• Does authorized selective reveal let independent reviewers reconstruct exposure as accurately and quickly as raw inline logs?
• Can event counts, timing, coarse types, identifiers, and access patterns be minimized enough for the relevant privacy context?
• Does an external witness add useful protection beyond routinely exporting receipts to an independently controlled store?
• What retention and deletion policy preserves scientific reproducibility without turning research telemetry into an indefinite content archive?

6. Claim and evidence register

7. Proposed mechanism: Minimal-Disclosure Invocation Receipt

MDIR has three stores and one non-store boundary.

1. Routine receipt stream. Compact event headers, commitments, chain heads, coarse policy-approved metadata, collector version, and external receipt references.
2. Protected reveal store. Canonical event bytes, fresh salts, exact manifests, provider-bound request or authorized locator, response, terminal artifact, and access receipts.
3. Independent checkpoint holder. An entity or service outside the application operator's rewrite authority that signs or otherwise preserves chain heads and sequence information.
4. Provider internal boundary. Explicitly outside the claim. MDIR observes the last application-controlled request representation, not model internals.

7.1 Canonical event

Every event uses a frozen schema and canonicalization profile. The harness restricts values to strings, booleans, null, arrays, objects, and integers in an exact JSON range. It uses sorted-key compact JSON as a deterministic development subset. This is not a complete RFC 8785 implementation. Production must use a conforming JCS library, test cross-language vectors, reject duplicate keys and non-conforming numbers, preserve Unicode as the profile requires, and version the canonicalizer.

For event e with fresh 128-bit or stronger secret salt s:

commitment = SHA-256("encevra-mdir-v0|commit|" || s || canonical(e))

Domain separation prevents the same bytes used in another context from being silently accepted as an MDIR event. The salt is stored with the protected opening, not the routine receipt.

7.2 Ordered event chain

The public header contains schema version, run pseudonym, event ID, monotonic sequence, parent IDs, coarse event type, commitment, prior head, current head, redaction mode, and collector version. The next head binds the previous head and current public header. Explicit parents supplement the sequence for parallel branches.

A local chain detects accidental modification relative to a saved head. It does not stop the operator from recomputing the whole chain. That stronger claim begins only when a head and length are checkpointed outside the operator's unilateral control.

7.3 Provider-bound evidence manifest

The provider_boundary event opens to an ordered manifest for every delivered evidence item:

• stable source identifier and immutable source version;
• position in the serialized request;
• byte or token slice under a declared measurement unit;
• truncation, transformation, and redaction flags;
• commitment to the exact delivered content;
• parent transformation receipt where content was summarized or compressed;
• requested and actual model, provider, retry attempt, and fallback lineage; and
• request artifact identity after the final application-controlled serialization step.

The manifest must distinguish dispatch intent from observed provider-bound payload. A mismatch is an event, not a silently corrected statistic.

7.4 Controlled reveal

An authorized reviewer requests only the events or fields needed for a prespecified audit. The reveal bundle supplies canonical bytes, salt, commitment context, and the inclusion/checkpoint proof. Verification establishes that the opened bytes match the earlier commitment and chain. Authorization, purpose, reviewer, time, and scope are themselves logged.

Field-level disclosure can be added where the schema and threat model justify its complexity. The default research profile commits per event, because field names, count, and correlated openings can create leakage and because fine-grained commitments increase implementation risk. If field disclosure is needed, freeze the exact field tree and independently test hiding and binding behavior.

7.5 Checkpoint

The development harness computes a witness HMAC over domain, run ID, event count, and chain head with a key unavailable to the simulated application operator. This is not a production recommendation and is not publicly verifiable. It isolates one question: does trust separation change post-compromise detection?

A production candidate should use an asymmetric COSE receipt over a standards-based verifiable data structure, with an explicitly governed transparency service or witness. [S4-S5] Saved checkpoints must be retrievable independently of the application database. Quorum or witness gossip may be needed if one witness can equivocate or disappear.

7.6 Assurance ladder

8. Worked example

An agent answers whether a $60 purchase needs approval. Storage contains two policy records:

• P17: threshold $50, superseded;
• P18: threshold $75, current.

The intended prompt uses P18 before P17 so the model sees the current rule first. A middleware limit truncates P18 to the phrase "Current approval..." but preserves all of P17. The final answer says no approval is required because the threshold is $75.

Four records tell different stories.

Endpoint-only: terminal answer and aggregate usage. It cannot show which policy version arrived.

Generic trace: model, status, latency, usage, and call ID. It can show that a call occurred, not the evidence order or truncation.

Raw inline log: exact prompt and response. It supports immediate reconstruction but copies both policy texts and possibly user material into routine telemetry.

MDIR: routine telemetry contains five event commitments, order, parents, chain head, redaction mode, and a witness receipt reference. An authorized opening of the provider-bound event reveals that P18 was truncated and P17 was complete. The receipt verifies that this opening matches the previously checkpointed event. The reviewer can classify a delivery fault without exposing unrelated events to every telemetry reader.

Even MDIR cannot justify the sentence "P18 caused the answer." The answer may come from prior knowledge or another prompt feature. To test causal use, rerun a frozen branch with P18 withheld or replaced, control the remaining request and generation policy, and measure the claim change. The receipt's job is to verify that the intervention was delivered as designed.

9. Executed diagnostic E20-A

9.1 Design

E20-A generated 96 deterministic episodes across eight synthetic policy families. Each episode contained three versioned evidence items, an admission event, dispatch intent, provider-bound request, model-response placeholder, usage, terminal release, event sequence, parents, and a redaction locator. No external or personal data was used.

Each episode was transformed into six arms:

Twelve mutations were applied independently to every episode: source-text edit, source-version substitution, evidence-order swap, silent truncation, actual-model change, inserted failed retry, response edit, terminal edit, parent relink, duplicate sequence, usage edit, and redaction-locator edit.

The ordinary-corruption test compared each changed episode with the original arm record. The privileged-rewrite test let the simulated application operator rewrite the artifact and recompute every representation under its control. For B2 only, the original external checkpoint was retained and the witness key was unavailable to the operator.

9.2 Controlled resources

• Episodes: 96
• Synthetic task families: 8
• Mutation families: 12
• Arms: 6
• Clean episode-arm evaluations: 576
• Mutated episode-arm evaluations: 6,912
• Reveal verifications: 480 valid plus 480 tampered
• Language-model calls: 0 in every arm
• Human annotations: 0
• Generation compute: exactly 0 in every arm
• Hardware-dependent local timing: reported as descriptive microbenchmarks only

The fixtures, mutations, projectors, and validators were written by the same author. E20-A is therefore a development diagnostic and executable specification, not a blinded or independent security evaluation.

10. Results

All 76 named checks passed. No clean arm produced a mismatch across the 96 episodes.

10.1 Mutation-family coverage

The post-compromise result should not be misread. B2 did not win because HMAC is magical. It won because the checkpoint key and saved checkpoint were outside the simulated operator's rewrite authority. If A2 or B1 exported an immutable checkpoint to the same independent witness, it would inherit that property and would no longer be the same baseline.

10.2 Controlled reveal

The harness created five event openings for each of 96 episodes. All 480 valid openings verified, and all 480 openings with an altered event type were rejected. This establishes consistency of the harness's commitment and opening functions on the test domain. It does not establish resistance to cryptanalysis, side channels, key compromise, implementation bugs, or ambiguous canonicalization outside the restricted profile.

10.3 Low-entropy disclosure probe

The attacker enumerated 128 possible records formed from two decisions, sixteen thresholds, and four regions.

A public salt prevents reuse of one precomputed table across records but does not stop a per-record dictionary attack when the candidate space is small. A secret, unpredictable salt blocks this particular offline confirmation only while it remains unavailable. The zero is not an estimated probability of compromise and not a proof of confidentiality.

10.4 Routine content footprint

On the representative five-event episode, the raw-inline arm contained five occurrences of the selected sensitive-content markers in its routine record. The routine views of A0, A1, B0, B1, and B2 contained zero. B1 and B2 placed five markers in the protected reveal bundle instead.

The protected bytes still exist. MDIR changes access and routine exposure; it does not make retention disappear. A fair privacy assessment must count protected stores, backups, locators, access logs, correlation metadata, and retention duration.

10.5 Local projection time

On this execution environment, median projection time was approximately 0.14 microseconds for A0, 0.98 for A1, 31.2 for B0, 52.2 for B1, and 53.9 for B2. The B2 p95 was about 66.9 microseconds. These values are single-process Python microbenchmarks over small synthetic episodes. They are not production latency estimates, do not include network or durable-storage cost, and should not be compared with model latency as if they were stable performance claims.

11. Interpretation: what the diagnostics establish

E20-A establishes five narrow points.

1. Projection determines detectability. If a representation omits source version, order, truncation, response content, parents, or redaction locator, changes to those fields cannot be reconstructed from that representation.
2. Content binding need not require routine raw content. Secret-salted commitments plus protected openings matched the raw-inline arm's mutation coverage in the constructed test while keeping raw markers out of the routine view.
3. A public digest can leak a guessable record. Calling a digest "anonymous" or "redacted" is unsafe when the candidate space is enumerable.
4. A chain is only as independent as its checkpoint. An operator capable of rewriting all operator-held state can recompute an unkeyed or operator-keyed chain. The security claim must name an external witness, immutable export, or other trust separation.
5. Public receipts do not reconstruct semantics alone. B1 and B2 could verify exact delivery only for an authorized reviewer with the protected opening. The public view proves a commitment exists, not what it says.

The result does not establish that MDIR is the best production design. A raw inline log with strong encryption, tight access, short retention, and independent checkpoints may be simpler for approved synthetic research. A standards-compliant SCITT service may make the custom chain unnecessary. A protected generic object store with immutable versioning may provide equivalent evidence at lower engineering cost. E20-B must compare those competitors rather than treating MDIR as the default winner.

12. Proposed held-out experiment E20-B

Objective: Determine whether minimal-disclosure receipts let independent reviewers reconstruct exact provider-bound evidence and locate injected faults as accurately as raw inline logs, while reducing routine raw-content exposure and preserving post-checkpoint tamper evidence.

12.1 Materials

• 48 frozen base trajectories across eight families: direct model call, retry then success, provider fallback, prompt compression, tool result insertion, parallel specialist merge, streaming interruption, and terminal revision.
• Six independently authored variants per base trajectory: clean, wrong source version, reorder, silent truncation, omitted failed attempt, and post-checkpoint rewrite.
• Total: 288 trajectory packets.
• Synthetic or share-authorized content only.
• Separate teams for generator, instrumentation, reference labeling, and review where feasible.

12.2 Arms

• A1: frozen OpenTelemetry-compatible operational trace with content capture off.
• A2: raw inline ELOC with independent checkpoint and least-privilege access.
• B1: secret-salted MDIR without an independent transparency receipt, but exported to a separately administered immutable store.
• B2: secret-salted MDIR with an asymmetric RFC 9942-compatible receipt or equivalent independently verified checkpoint.

The comparison deliberately strengthens A2 and B1. B2 should not receive a unique independent-storage advantage and then claim the schema caused the gain.

12.3 Assignment and compute control

• Freeze the underlying trajectories before producing any arm.
• Every arm derives from the same trajectory bytes; language-model generation compute is identical and can remain zero for the replay study.
• Match reviewer access time with a hard ceiling and log every reveal request.
• Randomize packet order and blind reviewers to arm labels and injected-fault family.
• Report all packets, including unavailable openings, invalid receipts, reviewer timeouts, and collector failures.

12.4 Primary endpoints

1. Exact exposure reconstruction: source ID, version, order, slice, truncation, requested/actual model, and attempt.
2. First-divergence localization at event or prespecified equivalence class.
3. False exposure attribution.
4. False integrity assurance: reviewer says verified when proof or opening is missing.
5. Routine raw sensitive bytes and protected raw bytes.
6. Number of principals able to read raw content.
7. Reviewer time, reveal count, and agreement.
8. Receipt generation, durable-write, verification, and storage overhead.
9. Availability under witness or reveal-store outage.

12.5 Secondary live-boundary check

Only after replay validation, instrument a small development wrapper around the real provider client. Use synthetic prompts, no customer data, and at least one test for SDK mutation, retry, fallback, streaming partial response, and request cancellation. Compare the wrapper's recorded canonical request with bytes captured at the last application-controlled network boundary. If these differ without an explicit transformation event, the collector gate fails.

13. Falsifiable hypotheses and decision rules

H20-1 - reconstruction with reduced routine exposure. Under authorized reveal, B2 will reach at least 0.95 exact exposure reconstruction with no more than a 0.03 absolute deficit from A2, while routine raw sensitive bytes remain zero.

• Support only if both accuracy and exposure criteria pass.
• Reject if openings are unavailable often enough to miss the accuracy margin, or if routine telemetry contains raw content.

H20-2 - independent checkpoint value. Under post-checkpoint operator rewrite, B2 will detect at least 0.99 of seeded alterations with false-alarm rate at most 0.01 and outperform B1 by at least 0.20 absolute detection.

• If B1's independently administered immutable export performs equivalently, adopt the simpler mechanism and do not claim B2's receipt format caused the benefit.
• If witness outage creates more than 0.01 unclassifiable packets, report the availability cost and reconsider synchronous gating.

H20-3 - reviewer burden. Median review time for B2 will be no more than 25 percent above A2, and false integrity assurance will not exceed A2 by more than 0.01.

• Reject if compact public receipts make reviewers overconfident without opening decisive events.
• Reject if selective disclosure creates material delay or disagreement.

H20-4 - operational overhead. At the synthetic live boundary, p95 receipt creation plus durable checkpoint enqueue time will remain under the stricter of 5 ms or 5 percent of non-model orchestration latency, and median public receipt size will remain under 2 KiB for the frozen five-event profile.

• Treat asynchronous checkpoint delay separately from synchronous request latency.
• Any dropped required event makes the episode incomplete; it cannot be counted as a fast success.

These thresholds are design decisions for a development gate, not literature-derived universal constants. Freeze them before E20-B and publish sensitivity analyses.

14. Metrics that detect regressions and harmful changes

15. Brain-inspired analogy as an ablatable storage idea

Teyler and DiScenna's hippocampal memory indexing theory proposes, at a high level, that an index can help reinstate distributed cortical representations rather than storing the entire experience in the index itself. [S14] The analogy is limited but useful: a routine receipt may act as a compact index to protected distributed artifacts, while an authorized audit reactivates only the required material.

This yields a concrete ablation:

• Inline condition: raw events are stored with every routine trace.
• Index condition: routine trace stores commitments and authorized locators; the reviewer retrieves the needed event.
• Digest-only condition: routine trace stores commitments but no guaranteed retrievable opening.

Measure reconstruction accuracy, retrieval latency, missing-opening rate, routine and protected bytes, and unauthorized exposure. If the index condition does not preserve reconstruction near the inline condition, or if retrieval failures dominate, discard the analogy and the design. The neuroscience source supplies no cryptographic guarantee, no software-efficacy evidence, and no reason to copy a biological architecture literally.

16. Alternative explanations

1. The witness, not MDIR, caused the post-compromise gain. Correct. E20-B gives strong baselines the same independent storage where possible.
2. More retained structure caused the mutation gain. Correct. A length-matched generic structured trace should be included in sensitivity analysis.
3. The mutations mirror the schema. They do. Independent authors and mutation fuzzing are required before a confirmatory claim.
4. Zero raw markers is a weak privacy metric. Correct. E20-B must add semantic scanning, linkability, authorized-principal counts, retention, access-pattern leakage, and red-team dictionaries.
5. Secret salts are merely hidden keys. They create similar lifecycle risk. Random per-record salts reduce cross-record correlation but still require secure protected storage and deletion handling.
6. A2 could be safe enough. A raw inline design with encryption, minimal retention, synthetic-only data, and independent checkpoint may be preferable for a research harness.
7. Standards could replace the custom profile. If RFC 9942 and RFC 9943 profiles express every needed field and threat boundary, MDIR should shrink to an application schema over those standards.
8. Application-bound bytes are not provider-bound bytes. SDK, network, or provider transformations may occur later. The claim must stop at the measured boundary unless stronger attestation exists.
9. The new digest-only Internet-Draft already solves this. It offers important prior art, but it is three days old, work in progress, and not specific to ordered model inputs, retries, or evidence-use claims. [S6]
10. A correct answer makes the collector unnecessary. Endpoint correctness cannot distinguish correct delivery, lucky guessing, prior knowledge, or an unsupported path. The collector is for scientific attribution, not merely answer scoring.

17. Expected failure modes and safeguards

17.1 Canonicalization and schema

• Different language runtimes serialize numbers or Unicode differently.
• Duplicate keys are accepted by one parser and rejected by another.
• An out-of-profile value is coerced rather than rejected.
• Schema version changes without changing the commitment domain.
• Field order is normalized where order is semantically meaningful.

Safeguards: conforming library, frozen test vectors, cross-language verification, reject-not-coerce policy, versioned domains, and explicit ordered arrays.

17.2 Salt, key, and commitment

• Salt generated with insufficient entropy or reused across records.
• Salt copied into routine logs, backups, error messages, or URLs.
• Low-entropy content inferred from size, type, time, or correlated fields despite secret salt.
• Witness key available to the application operator.
• Key rotation makes historical verification impossible.
• Commitment opens to a technically identical byte string that lacks authorization or truth.

Safeguards: cryptographic random generation, secret scanning, domain separation, key-isolation review, rotation and archival verification plan, and explicit separation of integrity from truth.

17.3 Event completeness and ordering

• The failing call occurs before the logging hook.
• The operator omits an event before the witness checkpoint.
• Parallel events are forced into a misleading total order.
• Retry overwrites the failed attempt.
• Stream ends without a recorded partial state.
• Terminal answer changes after its digest is committed.

Safeguards: shared boundary instrumentation, monotonic per-run sequence plus parents, append-only attempts, explicit partial/unknown terminal states, and completeness policies that fail closed.

17.4 Privacy and governance

• Stable run IDs permit cross-dataset linkage.
• Event counts and timing reveal workflow or user behavior.
• Authorized reviewers request far more content than necessary.
• Reveal-store backups outlive deletion policy.
• A tombstone is misread as successful semantic replay.
• Public research packages include salts, locators, prompts, or personal data.

Safeguards: rotating pseudonyms, time coarsening or batching where justified, purpose-bound access, audited reveal scopes, retention enforcement across replicas, reconstructability downgrades, and automated packaging checks.

17.5 Scientific use

• Researchers exclude invalid receipts and analyze only clean successes.
• A verification failure is labeled a model failure.
• A verified opening is treated as verified semantic support.
• Receipt complexity causes reviewer errors that are hidden by consensus discussion.
• Overhead is reported against slow model time instead of non-model orchestration.

Safeguards: intent-to-measure analysis, separate collector and model outcomes, independent blinded labels, pre-discussion judgments, and full overhead accounting.

18. Source inspection ledger and full references

All external sources below were directly inspected on 11 October 2026. The machine-readable ledger records the same inspection scope and limitations.

Full references

[S1] Rundgren, A., Jordan, B., and Erdtman, S. "JSON Canonicalization Scheme (JCS)." RFC 8785, June 2020. https://www.rfc-editor.org/rfc/rfc8785.html

[S2] Krawczyk, H., Bellare, M., and Canetti, R. "HMAC: Keyed-Hashing for Message Authentication." RFC 2104, February 1997. https://www.rfc-editor.org/rfc/rfc2104.html

[S3] Laurie, B., Messeri, E., and Stradling, R. "Certificate Transparency Version 2.0." RFC 9162, December 2021. https://www.rfc-editor.org/rfc/rfc9162.html

[S4] Steele, O., Birkholz, H., Delignat-Lavaud, A., and Fournet, C. "CBOR Object Signing and Encryption (COSE) Receipts." RFC 9942, June 2026. https://www.rfc-editor.org/rfc/rfc9942.html

[S5] Birkholz, H., Steele, O., Delignat-Lavaud, A., and Fournet, C. "An Architecture for Trustworthy and Transparent Digital Supply Chains." RFC 9943, June 2026. https://www.rfc-editor.org/rfc/rfc9943.html

[S6] Jangra, A. "Digest-Only Evidence Logs: Completeness, Disclosure and Sampling over RFC 9162 Transparency Logs." Internet-Draft draft-jangra-scitt-digest-evidence-00, 8 October 2026; expires 11 April 2027. Work in progress. https://datatracker.ietf.org/doc/html/draft-jangra-scitt-digest-evidence-00

[S7] Sporny, M., Longley, D., Sabadello, M., Reed, D., and colleagues. "Verifiable Credential Data Integrity 1.0." W3C Recommendation, 15 May 2025. https://www.w3.org/TR/vc-data-integrity/

[S8] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Pan, W. "Remote ATtestation procedureS (RATS) Architecture." RFC 9334, January 2023. https://www.rfc-editor.org/rfc/rfc9334.html

[S9] Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, R., and Cappos, J. "in-toto: Providing farm-to-table guarantees for bits and bytes." 28th USENIX Security Symposium, August 2019, pp. 1393-1410. https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias

[S10] Schneier, B., and Kelsey, J. "Secure Audit Logs to Support Computer Forensics." ACM Transactions on Information and System Security 2(2), May 1999, pp. 159-176. https://doi.org/10.1145/317087.317089

[S11] OpenTelemetry. "Semantic conventions for generative client AI spans." Development status; inspected 11 October 2026. https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md

[S12] Brooks, S., Garcia, M., Lefkovitz, N., Lightman, S., and Nadeau, E. "An Introduction to Privacy Engineering and Risk Management in Federal Systems." NISTIR 8062, January 2017. https://doi.org/10.6028/NIST.IR.8062

[S13] Melara, M. S., Blankstein, A., Bonneau, J., Felten, E. W., and Freedman, M. J. "CONIKS: Bringing Key Transparency to End Users." 24th USENIX Security Symposium, August 2015, pp. 383-398. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/melara

[S14] Teyler, T. J., and DiScenna, P. "The hippocampal memory indexing theory." Behavioral Neuroscience 100(2), April 1986, pp. 147-154. https://pubmed.ncbi.nlm.nih.gov/3008780/

Internal continuity. [I1] Encevra Research Round 9, 30 September 2026, procedural learning from verified experience. [I2] Round 10, 1 October 2026, evidence exchange, selective revision, and H10. [I3] Rounds 13-14, 4-5 October 2026, transition records and fallible evaluation. [I4] Rounds 15-17, 6-8 October 2026, receiver-enabled action, missing conditions, and changed questions. [I5] Round 18, 9 October 2026, versioned support and bounded belief repair. [I6] Round 19, 10 October 2026, ELOC, collector audit, and conditional handoff. Repository source was inspected because preview commits may precede production deployment.

19. Noetis implications and next-round handoff

The immediate Noetis implication is a constraint, not a product claim: do not solve Round 19's privacy problem by copying every prompt into routine traces, and do not solve it with bare public hashes that reveal low-entropy records or with a chain the same operator can rewrite.

Recommended implementation order:

1. Freeze an MDIR schema over the smallest ELOC subset required for the Round 18 pilot.
2. Adopt a conforming, versioned canonicalization library and cross-language vectors.
3. Add the provider-bound ordered evidence manifest and bind response, usage, attempts, and terminal release.
4. Store content and fresh salts in a protected research artifact store; keep routine operational spans content-free by default.
5. Export chain checkpoints to a separately administered store or standards-based receipt service.
6. Run E20-A plus independent mutation fuzzing against the implementation.
7. Run E20-B on frozen synthetic trajectories, including unavailable openings and failed checkpoints.
8. Only after R2 exposure reconstruction and the privacy gate pass, run a small live-boundary collector check.
9. Only after that collector gate passes, resume the smallest Round 18 versioned-repair development slice.

Next-round handoff: Round 21 should implement and validate the smallest real MDIR collector slice, not yet claim improved reasoning. If a strong generic trace plus independent immutable export matches MDIR on exposure reconstruction, false assurance, reviewer time, and privacy, adopt the simpler design. If secret-salt handling, protected retrieval, or witness availability fails, remain in instrumentation and governance. If E20-B and the live-boundary check pass, the following round may resume the smallest Round 18 versioned-repair pilot with exposure-level receipts. Claim/revision semantic lineage remains secondary until it earns value beyond the delivery ledger.

20. Limitations

1. Constructed and co-authored diagnostics. Episodes, mutations, projectors, and validators were designed together. The 76 checks demonstrate internal consistency, not independent robustness.
2. Restricted canonicalizer. The harness is deterministic for its fixture profile but is not a complete RFC 8785 implementation.
3. Symmetric witness placeholder. The witness HMAC tests role separation but cannot provide independent public verification. Production requires asymmetric receipts or an equivalent governed mechanism.
4. No cryptographic proof. Standard-library primitives were used correctly for the harness's narrow functions, but no formal proof, audit, side-channel review, or adversarial implementation test was performed.
5. No production collector. The current Encevra code was not modified, deployed, or shown to capture provider-bound requests.
6. No privacy guarantee. Marker counts and dictionary probes are diagnostics. Metadata, traffic analysis, correlation, backup, and insider risks remain.
7. No completeness before emission. A receipt cannot prove an event that the instrumentation never observed or emitted.
8. No provider-internal observation. The strongest claim is the last application-controlled request representation.
9. No truth or semantic-support guarantee. A valid opening can contain false, irrelevant, unauthorized, or misleading evidence.
10. No causal-use claim. Delivery remains distinct from internal use and behavior-changing influence.
11. Environment-specific performance. Microsecond timings and byte counts are descriptive for small synthetic events only.
12. Recent work is provisional. The 8 October 2026 digest-only log source is an Internet-Draft that can change, expire, or be replaced.
13. Brain analogy is optional. The indexing analogy is an ablation prompt, not evidence of architectural equivalence.
14. No model/runtime claim. The scheduler did not expose a control that could verify GPT-6 Astra Max for this run; the paper makes no such claim.

Conclusion

A research log should reveal enough to test a claim, but no more than its purpose and threat model justify. Round 19 showed that Encevra's current records cannot reconstruct the full evidence lifecycle. Round 20 narrows the repair: commit to exact provider-bound events, keep raw content out of routine telemetry, preserve controlled openings, and place the history's checkpoint outside the operator's unilateral rewrite authority.

The executed evidence is useful but modest. Across 96 constructed episodes, content-bound arms detected every seeded ordinary mutation while endpoint and generic traces missed evidence-specific changes. A witnessed checkpoint exposed every simulated post-checkpoint rewrite under its stated trust separation. Unsalted and publicly salted digests disclosed a low-entropy target; a secret-salt attacker view did not permit confirmation. The protected content still existed, and every strong claim depended on assumptions that must be tested in the real collector.

MDIR is therefore a candidate measurement mechanism, not a security conclusion and not an intelligence result. The next scientific step is a held-out, independently authored collector study with standards-based receipts and explicit privacy metrics. Only after that gate passes should Encevra interpret a versioned-repair pilot as evidence about reasoning rather than evidence about its logger.

Reproducibility note

The companion package contains this manuscript, the rendered PDF, diagnostics.py, diagnostic_results.json, fixtures.json, source_ledger.json, proposed_protocol.json, delivery status, and a SHA-256 manifest. Running python3 diagnostics.py rewrites the diagnostic results and fixtures. Expected invariant summary:

{
  "episodes": 96,
  "failed_checks": [],
  "language_model_calls": 0,
  "mutated_episode_arm_evaluations": 6912,
  "mutation_families": 12,
  "named_checks_passed": 76,
  "named_checks_total": 76
}

Local timing fields will vary by machine and run. They are descriptive and are not part of the invariant check count.