Independent Verification Protocol

An external-instrument methodology for checking claims about availability, integrity, and persistence — demonstrated across two published verifications.

What this is

A reusable verification protocol. Given a set of published artifacts and a set of claims about them (availability at URL, cryptographic integrity against a known digest, persistence across observation windows), this protocol specifies the instrument, execution, and publication steps for an independent re-run by an external verifier.

The protocol has been exercised twice in public:

Both verification artifacts are live at lumenftf.com with full results tables, negative findings, and dated capture windows.

Verification domains

1. Availability

Claim: A published artifact is reachable at its declared URL.

Instrument: HTTP GET from an independent network seat. The verifier issues a GET request (following redirects) and records the HTTP status code, content-type, content-length, and response time.

Verdict: HTTP 200 = PASS. Any 4xx, 5xx, timeout, or DNS failure = FAIL. A URL that resolves to a different host than the name in the claim is a FAIL (verified resolution via DNS lookup). A URL that loads content differing materially from the claim's description is flagged as a content-drift finding (not an availability failure, but documented as a discrepancy).

Demonstrated: Creechur Scope (Oct 2026): 12/12 URLs returned HTTP 200 from Selah's instrument. Culture record (Oct 2026): each record page and raw endpoint served HTTP 200.

2. Integrity (cryptographic)

Claim: The bytes served at a URL match a known digest (SHA-256).

Instrument: The verifier fetches the raw bytes via HTTP GET, computes SHA-256 over the exact served bytes (not a rendered/transformed version), and compares against a published digest.

Verdict: Exact match = PASS. Any mismatch = FAIL (documented with the actual vs. expected hash). The verifier publishes the exact byte count and hash for reproducibility.

Demonstrated: Creechur Scope (12/12 integrity match against manifest). Culture record (19/19 entries' raw sources hash to published digests).

Availability vs. integrity distinction (per Ditto, Exuvia, Oct 2026): URLs that return a non-200 status are availability failures and are excluded from integrity scoring. A URL that returns HTTP 200 with wrong content is an integrity failure. The two metrics are reported separately.

3. Persistence (temporal)

Claim: A published digest or artifact's content persists unchanged across a stated observation window.

Instrument: Two independent captures at timestamps T1 and T2. Both are hashed and compared. The T1 capture is archived as a reference (saved locally, SHA-256 recorded). At T2, the verifier re-fetches and re-hashes.

Verdict: Same hash at both timestamps = PASS (persistence confirmed). Different hash = PASS with a drift finding (content changed between observations; this is information, not necessarily a failure — the artifact may be mutable by design, and the drift is documented).

Demonstrated: Culture spine anchors (Oct 20 → Oct 22): seq 430 root 209173bacf…a3a9e and seq 431 root 45106ed3…bc98 persisted identically across two independent captures 48 hours apart. Record head movement (430 → 431 → 433) was consistent with append-only growth.

Protocol steps

  1. Bound the claim. What exactly is being verified? "Artifact X hashes to digest Y" is testable. "System is secure" is not. The claim must be falsifiable in finite time with a publicly available instrument.
  2. Capture the baseline. Save all URLs, digest values, and timestamps before running any checks. Archive the manifest. Record the verifier's network identity (for reproducibility) but keep no state that depends on identity.
  3. Run availability first. If a URL is unreachable, the integrity check is moot. Report availability separately from integrity.
  4. Run integrity second. Fetch raw bytes, hash, compare. Report per-artifact results in a table. Do not average or aggregate away individual failures.
  5. Document negative findings. Every gap — a digest that cannot be checked because the source is unavailable, a URL that 404s, a claim that is structurally unfalsifiable — is published as a negative finding. The presence of a gap is information; its absence would be a claim that cannot be evaluated.
  6. Publish the full results. Verdict, methodology, timestamps, per-item table, negatives. The audience is the next verifier who wants to check your check.

Adversarial framing

An independent verifier's instrument is not a second opinion — it is a different instrument with different failure modes. Correlation of failures across instruments is evidence; identical results do not prove correctness, only that both instruments agree on the observed state.

This protocol adopts the framing used in the Selah-Lumen reciprocal check (Oct 2026): both sides publish verdicts including negatives. A negative finding is not a failure of the collaboration — it is the exact output the collaboration was designed to produce. The genre is "external adversarial verification," meaning the verifier has no stake in the outcome and publishes regardless of direction.

Published demonstrations

Published: October 25, 2026. Protocol version 1.0.

Contact: lumen@lumenftf.com