Audit-grade Provenance by Construction

Kendall Clark · Pentad Labs · 2 June 2026 · PLRN-006

Abstract

Audit-grade provenance is a byproduct of substrate evaluation, not an instrumentation layer pasted on after the fact. In WunderOS every derivation seals into a tamper-evident chain that an auditor verifies offline, independent of the system that produced it. The differentiating property is the verifier, not the log. The log is a sequence of bytes anyone can produce and anyone can forge. The verifier is a procedure the customer runs against their copy of the data, recomputing every cryptographic commitment from scratch, and reaching a verdict without trusting the operator that generated the records. This is the claim: the customer can prove for themselves whether the records were altered.

1. Provenance is produced, not observed

The conventional pattern instruments a running system from the outside. An observer process watches execution, writes a log, and the log becomes the audit artifact. The log is downstream of the work, separated from it by an interface that can drop events, reorder them, or be silenced. Provenance recorded this way is only as trustworthy as the observer, and the observer is a second system with its own modes of failure.

WunderOS produces provenance from inside the evaluator. Every Gleamalog derivation emits a content-addressed trace record, a derivation trace, into a Trace WAL as the derivation happens. The record is not a description of the work written by a watcher. It is the work, addressed by the hash of its own content. There is no instrumentation interface to silence, because the evaluator that derives the fact is the same evaluator that emits its trace. Provenance is a byproduct of evaluation, in the same sense that the heat of (an irreversible) computation is the unavoidable, Landauerian byproduct of the computation rather than a measurement taken alongside it.

This is the first and central commitment, and it bears the load for everything that follows. Because the trace is content-addressed at the point of derivation, the bytes are fixed before any chain is built over them; and, further, the chain is a commitment to bytes that already exist rather than a promise about bytes the operator might later supply.

2. The seal chain

A per-tenant batcher accumulates the hashes of audit-bearing events. On batch close it builds a seal record (wire tag TSEL). The seal carries a Merkle root, computed with 16-bytes truncated BLAKE3, over the batch’s event-hash leaves; a prev_seal_hash link to the previous seal; a timestamp; and an event count. The seal body is signed with tenant’s Ed25519 key. The seal is stored content-addressed, and the per-tenant chain head advances monotonically as each new seal links to the one before it.

The chain is per tenant. Each tenant’s seals form a single hash-linked sequence, so the question an auditor asks is always scoped to one tenant’s history. There is no shared structure across tenants that one tenant could use to reason about the data of another.

What a seal proves is narrow and exact. It proves that the event was emitted by the tenant’s instance at or before the seal timestamp, and that no event was inserted, deleted, or modified since. The Merkle root commits to the set and order of leaves, so any change to a leaf changes the root. The prev_seal_hash link commits to the entire prior history, so any change to an earlier seal breaks every link after it. The signature commits the tenant’s key to the whole structure; hence, the seal cannot be reattributed undetected.

3. Key rotation inside the chain

Keys rotate. A naive design keeps the key history in an out-of-band registry the auditor must trust, which reintroduces exactly the trusted third party the chain was built to eliminate. WunderOS keeps rotation inside the chain.

A key rotation record, wire tag TROT, lives in the same per-tenant chain as the seals. A rotation carries both the old public key and the new public key and is signed by the old key. The signature is the proof of authority: only the holder of the old key could have authorized transition to the new. An auditor who holds nothing but the genesis public key can walk forward through the chain, verify each rotation against the key that was active when the rotation was made, and learn the complete active-key history. The auditor never consults a registry, because the key history is carried by the same records the auditor means to verify.

4. The verifier is independent of live state

The verifier shares no state with the batcher that produced the seals. It does not query the running system; it does not ask the operator which key is active; and it does not take the operator’s word for the chain head. It pulls seal records by hash, walks the chain backward via prev_seal_hash, checks the bytes of each record against the content hash they are claimed to have using BLAKE3, Ed25519-verifies each seal against the public key active at that point in the chain (switching keys at each rotation boundary), and recomputes every Merkle root from the leaves. Auditors run this procedure offline against their own replicated copy of Trace WAL.

The verifier returns a verdict. The taxonomy is small and each verdict is a claim the auditor can act on. Four symbols in a tight verification alphabet.

  1. Verified. Every link holds, every signature checks against the key active at that point, every content hash matches, and every Merkle root recomputes.
  2. Tampered, with a reason. One of the cryptographic checks failed, and the verdict names which: ChainLinkBroken, MerkleRootMismatch, SignatureInvalid, PrevSealNotFound, DecodeFailed, or ContentHashMismatch. The reason localizes the failure rather than reporting a bare boolean, so the auditor knows whether a signature, a hash, a link, or a decode is faulty.
  3. ChainTruncated. A prev_seal_hash points at a record that is absent from the store. Deletion of history therefore shows up as a gap, not as a clean shorter chain, because the link to the deleted record survives in the record that pointed at it. An operator cannot quietly drop the oldest seals; the dangling link is the evidence.
  4. Empty. There is nothing to verify.

A separate inclusion verdict answers a different question: whether a specific event is included under a given seal. It returns a per-event Merkle inclusion proof, so tenant auditr can prove that one particular event sits under one particular root without replaying the whole chain.

5. Determinism makes the chain a test oracle

Ed25519 is deterministic by RFC 8032. The same seed yields the same key, the same key over the same message yields the same signature, and the same sequence of events therefore yields the same chain, byte for byte. This is a property the construction inherits for free, and it matters for the auditor and for testing.

For the auditor, two parties verifying the same Trace WAL compute identical roots and identical chain heads, so any disagreement is a disagreement about the bytes rather than procedure.

For testing, the deterministic-simulation harness described in PLRN-002 (/PLRN/002/) replays a workload under controlled scheduling and uses Merkle roots and chain heads as invariant oracles: the same simulated history must seal to the same root every time, and a divergence is a bug. The provenance chain is not only an audit artifact. It is also a fingerprint of execution precise enough to test against.

BLAKE3 truncated to 16 bytes gives 64-bit collision resistance. Under per-tenant scoping this is adequate, because there is no cross-tenant key collision to engineer against and the attacker’s target is a single tenant’s chain rather than a global namespace.

6. The boundaries are the substance

The construction proves something exact and proves nothing beyond it. The boundaries below are not caveats appended for safety. They are the specification of what a seal does and does not mean, and stating them is the same work as stating the guarantee.

  1. The sealing window. Events emitted between the last seal close and the pending close are not yet in any sealed batch. An attacker who holds both disk access and the signing key during that window can alter pre-seal events without detection, because the bytes those events would have committed to have not yet been committed to anything. Shorter windows narrow the exposure, and per-event signatures close it entirely, both at a throughput cost. The window is real and the mitigation is a throughput trade, not a claim that the window does not exist.
  2. A seal proves emission, not truth. The chain proves that an event was emitted by the tenant’s instance and not altered since. It says nothing about whether the event was correct. A tenant that emits a false statement and seals it has a tamper-evident record of a false statement. Input correctness is the customer’s responsibility, and the seal neither borrows nor claims authority it does not have.
  3. Tamper-evidence is not erasure. The chain is append-only, which is the opposite of forgettable. Logical retraction, the case where a fact must stop being asserted while the record of its assertion remains, is handled by append-only-with-retraction, described in PLRN-007 (/PLRN/007/). Regulatory erasure under regimes such as GDPR is a different requirement, met by a destructive force-purge that is a separate operator escape hatch outside the tamper-evident model. The chain does not pretend that logical tamper-evidence satisfies a legal right to be forgotten.
  4. Key compromise. Signatures made by a leaked key during the compromise window are cryptographically valid, because validity is exactly what a signature with the right key asserts. Rotation marks the boundary at which the key changed, and an auditor walking the chain can see precisely when the active key switched. What the chain cannot do is decide on the auditor’s behalf whether the interval before rotation is trustworthy. It marks the boundary; the auditor decides what to do with a questionable interval.

One commitment on the roadmap tightens the model further. HSM- or TPM-bound keys would mean that even the operator cannot forge a seal without the customer’s hardware, removing the operator from the trust boundary entirely. This is un-shipped roadmap work to be done.

Sound trace recording. RIARC supplies the soundness invariant for the trace algorithm: Aceto, Attard, Francalanza, Ingólfsdóttir, “A Decentralized Instrumentation Algorithm for Synchronous Outline Runtime Verification,” 2024, arXiv:2406.19904.

Cryptographic construction. Standard Merkle-DAG and signed-chain constructions; Ed25519 per RFC 8032; BLAKE3 per the BLAKE3 specification.

Contrast. Durable-execution frameworks (Temporal, Cadence) record activity histories so that a workflow can be replayed after failure. That is a different problem. They record for replay, not for tamper-evident attestation, and an operator who controls the history controls the replay; the verifier described here exists precisely so that the customer need not trust the operator that holds the records.

A note on method

Drafted in conversation with Claude Opus 4.8 (Anthropic) as structured interlocutor and prose editor. The framework, claims, and architectural commitments are mine.

Kendall Clark · k@pentad.ai
—Great Falls, Virginia
June 2026