← Back to journal

Capture Is an Evidence Boundary, Not a Download Button

A useful software capture records which bytes, routes, requests, states, and policies produced the evidence—and which parts of the application remained unseen.

Evidence basisKodeCapture capture-ownership architecture and versioned workspace-contract history
DisclosureEarly-access engineering note; capture completeness depends on authorization, reachability, policy, and the states actually observed.
Published by Kalu KodeRequest KodeCapture access →

Downloading a page gives you files. Capturing a deployed application should give you evidence.

The difference is provenance.

A folder of HTML, JavaScript, and images does not necessarily tell you which route produced each asset, which responses were authenticated, which interactions revealed lazy code, whether network calls were recorded, or what remained outside the session.

KodeCapture treats capture as an evidence boundary with declared inputs and measurable output.

The target is not the whole application

A starting URL is one observation point. Modern applications can reveal new code and behavior through:

  • route navigation;
  • lazy imports;
  • authenticated state;
  • dialogs, menus, drawers, and tabs;
  • canvas or WebGL interactions;
  • API, GraphQL, and realtime messages;
  • service workers and workers;
  • storage and session state;
  • feature flags and environment-specific configuration.

A capture should not imply that reaching the landing page covered all of these surfaces.

Inputs need their own record

The capture environment affects the result. Useful provenance includes:

  • canonical target and any explicit origin override;
  • browser backend and viewport;
  • route and interaction policy;
  • page, depth, request, and time budgets;
  • robots and pacing policy;
  • authentication requirements without persisting secrets;
  • retry and timeout behavior;
  • source type, such as live navigation or an authorized archive.

Credentials should not be written into a portable workspace merely because they were needed during capture. The environment can record that protected input must be supplied again without retaining the value.

Bytes and observations have different roles

Captured response bytes are direct artifacts. A route graph, dependency fingerprint, or interaction summary is derived evidence.

Both are useful, but the distinction should remain visible. A report can be regenerated or reinterpreted. The captured body is the object the report describes.

This separation also supports integrity checks: the system can seal the donor bytes and bind later reports to that seal.

Optional failures should still be visible

Some capture activities are best effort. An exploratory click may fail. A candidate URL may be malformed. A route may require authority that was not supplied.

Best effort should not mean silent.

The capture can continue while recording:

  • which operation failed;
  • whether it affected required or optional coverage;
  • which candidate was skipped;
  • which budget was exhausted;
  • which evidence should be reacquired.

An operator can then distinguish a usable partial capture from an unexplained incomplete one.

Long-lived processes need bounded state

Capture systems often run through a CLI, server, or agent connection for many workspaces. Caches, browser pages, child processes, and temporary directories can outlive one command if ownership is vague.

A sound boundary creates command-scoped caches, caps retained entries, registers process cleanup, and closes only the browser resources it owns. Recoverable workspace transitions should not be deleted as if they were ordinary temporary files.

Operational discipline is part of evidence quality: an interrupted capture should not leave a half-published workspace that looks complete.

The output should explain itself

A portable capture workspace should answer:

  • What deployment and session did this represent?
  • Which bytes are sealed donor evidence?
  • Which routes and states were visited?
  • Which requests and interactions were observed?
  • Which policies and limits constrained exploration?
  • What failed, remained residual, or was intentionally excluded?
  • How can another tool replay or inspect the result?

KodeCapture’s objective is not to make a perfect copy of an unknowable whole. It is to preserve a declared, auditable slice of deployed truth so recovery, testing, analysis, and future comparison can begin from facts instead of recollection.