How it was checked, and what’s open

Edge Evidence · Overview · 1 One record · 2 Copy and verify · 3 Lab runs · 4 The model · 5 Checks and gaps

Every claim on these pages rests on one of a few kinds of evidence, and they aren’t equally strong. This page lists them side by side, so you can see what stands behind each result and what you could check yourself.

What kind of evidence stands behind each claim

Claim	Kind of evidence	Can you check it?
An interrupted job resumes under the same ID; a locked spool defers with no writes	Synthetic demonstration with frozen expected values	Yes: public Processor fixture and demo
A copy is created, adopted or refused by destination state; `verify` is separate	Synthetic demonstration and integration test	Yes: public Replication demo and tests
A Processor report hands off to Replication and replays with no new writes	One retained synthetic result, cached, execution time unknown	Yes: retained snapshot in the public reference platform
Capture and processing conflicted over the spool (OPBD-1)	Lab run with two real sources	No: retained summary; the raw ledger isn’t public
222 captures accounted for, 445/445 read back, 75 gaps kept (OPBD-2)	Lab run with two real sources	No: retained summary
A missing Replication worker caught up, 12/12 (OPBD-3)	Lab drill	No: retained summary, sanitised
An exact object in a real bucket was adopted, not overwritten	One approved real-provider run	No: no public receipt
The model’s explanations stay inside their fences	Mocked test suite, plus eight real questions	Partly: public workbench source and tests; the sessions are described, not recorded
The hosted demo serves its public source, unchanged	Daily automated observation	Yes: public observation records

Tests per component

Component	Tests	What they are
Inspector	18 focused local tests	Rules, HTTP handler and gateway routes at the pinned baseline
Processor	15 worker and contract tests	Includes mocked media probing; not a container, filesystem-durability or cloud test
Replication	32 integration, target-contract and configuration tests	One cloud-storage case deliberately left out, because the optional provider SDK wasn’t installed; no cloud access
Local workbench	109 Python checks (4 optional skipped), 5 JavaScript tests	Mocked model transport; no model calls

These counts come from scoped local reviews of the public sources at their pinned commits. They aren’t a CI history of the workers.

Seen running, and traced to its source

Project 03 ended with two zeros. No published candidate could be traced as a whole to its exact source, and no published surface had been independently seen running. Afterwards, I asked both questions of this project’s hosted demo.

Seen running: closed, by the study’s own definition.

Once a day, a scheduled GitHub Actions workflow fetches the three files the demo serves (the page, its script and its stylesheet) and compares each one byte for byte with the same file at a pinned public commit, 78136e8.
It also asks the Proof endpoint what it is, and expects recorded playback that executes nothing.
It appends a dated record to a public branch, and fails publicly if anything differs.
The first run, at 17:09 UTC on 26 October 2026, passed.

Three limits:

I wrote the observer.
It sees only what is served, not the server code behind it.
Once a day is a sample, not monitoring.

Traced to source: narrowed to the build. Every source file in the deployed image now has a public, byte-identical counterpart. Comparing them turned up drift nobody had looked for: the public tests had been installing newer FastAPI and Starlette versions than the image pins. They now install the exact versions.

What’s left is the build itself:

The image was built on my machine and pushed with Docker’s provenance attestation switched off (--provenance=false), because the host rejected the default format.
The source spans two public commits, 773d8b8 for the inspector and 78136e8 for the interface.

Until the image is built in public CI from one commit with its attestation kept, the honest description is “file-for-file public, build unattested”. One gap closed, one narrowed has the detail.

What isn’t established

No raw lab ledgers are public. The OPBD numbers are retained summaries. In particular, the 75 source gaps can’t be shown as a timeline.
The create path hasn’t run against a real provider. Neither have bucket policies or continuous replication.
No fleet, no rate. Two sources in a lab, not a supported throughput or a camera certification.
No continuous pipeline. The hosted demo is a single process over synthetic records. It runs no workers, and the Proof is a replay.
No drone video end to end. The project’s origin in the drone work is my recollection, and no detector has run through it.
The model sessions aren’t recorded. Only their outcomes, timings and two raw texts are reported.
The build is unattested, as above.

What would come next

These are planned, not built:

An eight-hour endurance run. The two-hour result didn’t authorise it, so it would need its own approval.
The create path against a real provider, with its own approval, as the adoption run had.
A public CI image build from one commit, keeping the provenance attestation.
A wider denial-phrasing list for the workbench guard, with its own tests, then more fixed questions.
Publishing sanitised run ledgers, so the lab results can be checked rather than only read.

The public roadmap tracks which of these is next.

Basis: the test counts and scopes as recorded in the technical chapters (inspector baseline, Processor recovery, Replication readback, local workbench); the daily observation and build comparison as recorded in the note; and Development and operations for the lab runs. No new runs were made for this page.

Previous: A model that explains, never decides · Back to the overview