Replay evidence should be bound to exact donor bytes, response inventories, generated source, and mutation plans so later tooling cannot silently change what was observed.

Once a capture becomes an input to recovery or verification, its identity must stop being informal.

If a JavaScript chunk is replaced, a response body is edited, or generated replay source changes after evidence was approved, downstream reports may still look valid while describing a different artifact.

Cryptographic fingerprints help turn capture state into explicit authority.

What should be bound

A replayable workspace can bind several related surfaces:

donor file inventory and byte digests;
sanctioned captured network material;
capture metadata and environment;
response targets and response-body digests;
MIME and content-type authority;
generated replay source inventory;
replay runtime bytes;
storage seed;
interaction flows and transitions;
any mutation plan used to rehydrate or normalize the workspace.

The binding does not have to collapse all of these into one opaque hash. A structured integrity document can preserve component roots and a combined root so tools know exactly which surface drifted.

Generated source needs authentication too

A replay system may generate inline modules, navigation guards, request shims, or rehydration code. Those files can execute with the same authority as captured JavaScript.

Treating them as disposable build output creates a blind spot. The workspace should expose when generated source is ready, list what can execute, and bind that inventory into the replay receipt.

An executable inventory should be complete for the declared sealed JavaScript closure. Missing, extra, duplicate, or changed entries are evidence failures—not minor packaging differences.

Mutation plans should have fingerprints

Rehydration may rewrite origins, URLs, imports, or runtime hooks so captured bytes can execute locally. The intended changes can be represented as a sealed plan.

Before applying it, the system verifies exact preimages. After applying it, the system records the postimage and plan digest. A stale or partially applied plan is rejected instead of being replayed against a new workspace generation.

This is especially important when publication is interrupted. Recovery can distinguish an untouched preimage, a fully authenticated postimage, and a partial state that must roll back.

Sealing does not mean freezing forever

Deployed software changes. Capture evidence sometimes needs to be refreshed.

The correct response is a new authenticated generation with a delta from the previous one. It is not editing the current donor tree and recalculating a seal without explaining why.

An update workflow can replace canonical capture state transactionally while Git or another history system retains the earlier generation.

Integrity does not prove completeness

A perfect digest can authenticate an incomplete capture.

It proves that the bytes being used now are the bytes represented by the seal. It does not prove that every route was visited, every lazy chunk was discovered, every response was recorded, or every interaction was safe to execute.

Coverage reports and residual evidence remain separate, necessary claims.

Why downstream tools care

Recovery, parity, exposure analysis, and agent handoff all need stable inputs. Binding evidence to exact capture roots lets them reject stale results automatically.

It also makes collaboration safer. One tool can say “I consumed capture root X and produced report Y” without assuming a directory remained unchanged.

KodeCapture uses sealed authority to preserve the chain between an observed deployment and every later interpretation. The seal is not proof that the capture saw everything. It is proof that we have not silently changed what it did see.

Sealed Bytes and Authenticated Capture Authority