06 — Scanner Read-Path Verification (live, read-only)

The scanner read path is a pure SELECT over the committed seam views and ownership/gap views — safe to run any time. Run live this run against current state.

Live result (2026-06-02, read-only)

Metric	Value
inventory (objects)	35
active scopes	6
cells_total (objects × scopes)	210
gap_cells	210
covered_cells	0
coverage_pct	0.0 %

Interpretation: with governance_object_ownership empty, the scanner honestly reports 0 % coverage / full 210-cell gap. This is the correct, non-fabricated reading. There is no false "covered" signal — the read path does not invent ownership.

What it would report after the authorized seed

The scanner is deterministic over the data. After the 30-anchor seed commits (gap 210→0):

• covered_cells = 210, cells_total = 210, coverage_pct = 100.0 %.

This is identical to the in-transaction result already proven in F-6 (the SELECT does not distinguish in-txn rows from committed rows). This is exactly why persisting the seed adds no verification value and why the only thing the persistent commit changes is the governed state of record — which is what the human gate exists to protect.

Boundary held

The scanner read path performed here:

• issued only SELECTs;
• wrote nothing to event_outbox (gov emit stays 0);
• created no candidate_scan_run / gov_worker_cursor row (both remain 0 — a worker would persist scan state; a read-path SELECT does not, and none was created);
• did not activate any handler or DOT tool.

Scanner read verification: COMPLETE (read-only); 0 % coverage is the honest current truth.