From captured evidence to a verified copy—and what inspection can actually tell us

Source boundary. The original capture implementation and its historical test records were reviewed privately; this chapter gives an owner-approved public-safe explanation, not a public reproduction of that code or private evidence. The linked Processor, Replication and inspector sources are separate pinned public implementations, with their own test limitations.

A successful command is an event. A complete evidence record is something more demanding: bytes that can be identified again, a durable account of where they came from, and an honest answer when an expected result is missing.

Edge Evidence explores that difference through several related engineering components. Capture establishes what the edge system preserved. Processing derives a new result without replacing its source. Replication copies eligible evidence to a bound destination and checks the bytes there. Inspection helps a person interpret a supplied record. None of those jobs, by itself, proves that every other job ran—or that the system has been deployed as one continuous service.

The sequence below is a map of responsibilities and interfaces, not a diagram of one currently running pipeline. The original edge platform, public standalone worker implementations, separate synthetic Showcase proof, and Visual Gateway have distinct execution boundaries. They should be read together without pretending they are the same runtime.

One evidence story, six responsibilities

Source / bounded recording
        │
        ▼
Finalized raw bytes + content-addressed manifest
        │
        ▼
Primary authority: SQLite artifact + capture occurrence
        │             └─ committed local outbox event
        ├───────────────► Read-only evidence verification
        │
        ▼
Deterministic processing: derived bytes + parent lineage
        │
        ▼
Replication: immutable create or exact adoption
        │
        ▼
Independent readback: verify destination size and digest
 
Separate presentation path:
Supplied synthetic artifact projection → deterministic inspection → explanation
                                     (no worker execution)

The final line is intentionally separate. A diagram that drew the Visual Gateway as the last automatically executed step would claim an integration that its public application does not perform.

1. Preserve something before calling it evidence

A recording begins as input, not yet as authoritative proof that an expected capture succeeded. The original platform uses a deterministic camera simulator so that the expected media and failure boundaries are repeatable. It also implements bounded recording-import and RTSP paths. The RTSP integration tests use a controlled loopback publisher and server, not a claim that a particular physical camera has been verified in the field.

For the deterministic capture profile, the finalizer validates the source description and media properties, then calculates a SHA-256 digest of the actual finalized media bytes. The raw artifact’s content identity has the form sha256:<digest>. It is not a number assigned by a user interface and does not establish the authenticity of the original scene; it identifies bytes that can be checked again.

The platform publishes those bytes under a content-addressed path. It creates an artifact-manifest.v1 describing the artifact, size, digest, source and finalization time. The manifest is deliberately narrower than the complete capture history: it does not carry session and sequence authority, which belongs in SQLite. The finalized media is published before the manifest, using guarded no-replacement publication and durable filesystem steps. This ordering prefers recoverable media without a public final manifest over a manifest that falsely points to missing final media.

The implementation includes a generated-manifest schema check, a real-media finalization test and refusal to overwrite an existing final object. That supports a bounded software behavior claim. It is not evidence that every possible disk, filesystem or camera behaves identically, or that a hash proves who or what originally produced the recording.

2. Distinguish the bytes from the occasion that produced them

Two recording attempts can legitimately produce identical bytes while still being different events. That is why the original platform separates artifact identity from capture-occurrence identity.

• An artifact records which immutable content exists. Its identity comes from the content digest.
• A capture occurrence records which source, session, sequence and expected interval the content belongs to. Its identity is derived deterministically from those occurrence facts.
• The local outbox records which terminal event was committed. It is not evidence that an external subscriber received that event.

The primary authority consists of the finalized filesystem evidence together with the corresponding SQLite facts. Registering a verified completion connects the artifact, capture occurrence and SegmentFinalized outbox event in a database transaction. The committed outbox row can later be distributed by a separate publisher; committing it is not the same as publishing to a message broker.

This division also explains why the system cannot use one file digest as a unique capture-occasion identifier. The same content may be referenced by multiple occurrences. Later occurrence-specific assertions can preserve their distinct context while pointing to the same content anchor.

3. Make interruption visible instead of inventing a success

The capture lifecycle has a durable expected-occurrence record. Its essential states are:

PREPARED ── verified completion ──► COMPLETE
    │
    └──── evidence unavailable ──► GAP
 
Contradictory evidence ──► stop and report; do not fabricate either terminal result

PREPARED means the system committed the expectation before attempting crash-sensitive work. COMPLETE requires the evidence and corresponding database facts to pass their checks. GAP records that the expected capture was not preserved under the allowed recovery policy. It is not a euphemism for “try again later.” Both terminal outcomes are protected from being casually rewritten.

A crash can occur after a media file is staged, after it is finalized but before its manifest is published, or between filesystem work and the final SQLite commit. These are different states of the world. Reconciliation inspects the surviving evidence and follows a defined policy: it may verify and finish a recoverable occurrence, quarantine permitted incomplete material, record a gap, or stop on corruption. In particular, a final manifest without its media is not treated as a success, and an unowned file pair is not silently turned into a recorded occurrence.

The implementation is more than an aspiration: committed tests exercise these states, including a subprocess killed at seven defined crash barriers, followed by reconciliation and an exact second-pass no-op check. A retained acceptance record reports the synthetic local crash, retry, gap and corruption scenarios passing at its recorded source revision. That is a meaningful test result—not a certification of arbitrary hardware durability or of a production camera fleet.

4. Verify, then derive; do not move the source of truth

An independent read-only verifier asks whether the canonical SQLite facts and stored bytes still agree. It checks such matters as missing content, mismatched digests, manifests, occurrence assertions and derived lineage. Its job is to report findings, not to repair the database, start workers or make a corrupted record look healthy.

The related Evidence verification note asks what a repeatable check can actually establish. It offers a research concept, not evidence that this particular verifier ran.

Processing is a separate, state-changing operation. Before deriving an output, the deterministic Processor checks the eligible input against its expected database, manifest and media evidence. It can create a derived metadata report, register its content and retain a parent relationship pointing to the original raw artifact. The raw input stays unchanged.

This worker has its own recovery story. A processing job can be durably PREPARED before its report and manifest are published, then resume or converge to COMPLETE when the correct bytes are in place. An exact completed job can be verified and adopted on rerun rather than duplicated. In the worker’s snapshot, MISSING means an eligible job has not been recorded; it is not a persisted processing-job state and certainly not the capture system’s GAP.

The existing Processor recovery chapter documents the detailed job identity, interrupted publication cases, replay and worked synthetic trace. The important cross-component rule here is simpler: a derived output is new evidence with traceable parentage, not a rewrite of raw evidence or an independent proof of its origin.

The historical Lineage and provenance note asks related questions about repository relationships, scoped provenance and whole-candidate lineage. Those frozen research categories are not the Processor’s derived_from database contract.

5. A copy is not verified merely because a write returned success

Replication begins with already-finalized, eligible evidence and a previously bound destination. It does not capture the media, run the Processor, provision a new target, or choose where evidence should go. Its worker checks target identity and uses a provider-neutral interface for immutable publication.

There are three destination outcomes worth distinguishing:

The relevant check is the destination’s observed size and SHA-256, not merely the source hash or a provider’s upload response. Only after verification can canonical replica state record the successful result. A replica is still a verified copy; it does not become the primary artifact or the primary SQLite authority. Failed target availability or a refused collision cannot retroactively erase locally preserved evidence.

The Replication and independent-readback chapter covers binding, retries, adoption and collision refusal in detail. Its documented public proof uses local synthetic objects and an ordinary target directory; the mounted-NFS probe is substituted in that demo. Optional provider adapters are implementation options, not proof that every provider was exercised.

6. Inspection explains a record; it does not create the evidence

A final category of work is explanation. The public Edge Evidence Visual Gateway displays three synthetic artifact projections. The browser fetches an example and submits that supplied JSON to a deterministic inspector, which returns a classification and an explanation.

The words matter. healthy-complete means the supplied synthetic record describes a completed state; it does not establish an independent readback of some external file. bounded-defer and prepared-awaiting-catch-up are inspection classifications for the supplied examples. An accompanying proposal is review information, not authorization to execute a command. The returned mutation_authorized=false field expresses the inspection contract; actual safety also depends on the routes and permissions enforced by the application.

Agent vs deterministic inspector explores the distinction between explaining a record, using a tool and having authority to act. The actual HTTP behavior above is supported by implementation and tests, not by the concept note.

The Visual Gateway does not call the Processor or Replication worker when someone presses Explain. Its evidence API supplies disposable demonstration records, not the primary database. The current HTTP route calls explicit deterministic rules rather than a language model. An optional ADK adapter exists but is disabled for this gateway; the separate local ADK/Ollama comparison remains a proposed experiment, with no completed model integration or measured outcome asserted here.

For the precise contract and limitations, read What the current Edge Agent actually does, API and data contracts and Boundaries and verification.

The same word can name different things

These labels cannot be joined into one state machine just because they sound similar. Each is meaningful only with its component, contract and evidence authority attached.

What has actually been demonstrated together?

A similar but historically separate distinction appears in Project 03’s Publication and runtime reality: a claim that something ran is not the same as independent observation that it ran. Those frozen projection findings are not current telemetry about the Showcase or Visual Gateway.

These demonstrations remain separately scoped. A successful test says what happened for its particular candidate, inputs and environment; it does not establish one continuously deployed pipeline.

How this relates to Project 03

Project 03 asked what retained evidence can really establish. Its frozen research distinguishes candidate verification from engineering acceptance, repository relationships from exact lineage, publication from runtime observation, and an unresolved state from a failed test. Those distinctions offer a useful way to read the engineering account above.

That is a methodological connection, not a claim that the frozen investigation historically caused any particular design decision. The original analytical comparison remains fixed; later source commits, demonstrations and runtime observations form a separate engineering record. Neither a new successful test nor a convincing screenshot changes the meaning of an older unestablished finding.

The practical question to carry forward is not merely, “Did the last step return success?” It is: Which authority changed, which bytes or records were checked, what remains unverified, and who is allowed to conclude more?

For detailed reading, continue with Processor recovery, Replication verification, and the deterministic inspector baseline. Each answers a different part of that question.