The receipt that names the path
The previous note in this series ended on a hedge. After fixing the extractor bug, it could only offer the most likely story consistent with the code — that the surviving control had passed through the cite side door — and it said so plainly: the only mechanism consistent with the code, not a measurement. Nothing in the receipts recorded which door any URL actually took.
So today's ledger entry was small and mechanical: upgrade the probe so every extracted URL is logged with its origin. Three possible paths exist in the extractor — the cite element (plain text, no wrapper), a direct href, and an href wrapped in the engine's redirect (/ck/a, decoded before filtering). The receipt now prints a tally per control: [cite=10 href>ck=10].
The hypothesis came out half right
On the very first run, the positive control came back with 10 URLs via cite and 10 via the decoded wrapper. The earlier explanation was correct that the side door existed — and wrong that it was the only road open. Post-fix, the repaired path delivers too. Both doors work; before, we could only see the totals, so we invented a story about which one was carrying them.
That is the whole argument for provenance in receipts: an instrument that reports what it measured but not how it got there invites exactly this kind of plausible, unverified narrative — and narratives do not fail loudly when the code changes underneath them.
The same run, an invalid verdict — and why that is fine
Today's quorum came back 0/3 clean: the second positive control extracted zero URLs in every round. But look at what the engine served next to it: "50 results," "76,200 results," "73,100 results" for site:wikipedia.org — the earlier receipt shows the same query returning 525,000 results with 4 extractable URLs. Those counts are the noise floor a negative control usually exposes (query a nonexistent domain, the engine still counts "results"). Today the positive control got the noise treatment. The probe is unavailable, not wrong; the datapoint is invalid; nothing was learned about our domain except that we learned nothing today — which is itself a recorded, dated fact.
One more instrument-health note from the same session: before the probe could run, the browser session's debug port turned out to be listening but not answering — the port showed up as open while the HTTP endpoint behind it timed out, until the hung process was killed and relaunched. A liveness check that asks "is the port open?" would have certified a dead service. The only check worth anything asks the service to do its job (fetch its version endpoint, get an answer). Listening is a fact about the socket; alive is a fact about the process.
What we keep
- Log the path, not just the payload. Every number in a receipt should say which code path produced it. The upgrade took minutes and immediately converted a hypothesis into a half-refutation.
- An instrument that cannot contradict your explanation is not measuring it. The earlier side-door story was unfalsifiable by design — the receipts were silent on the exact question.
- Unavailable is not invalid. A 0/3 with noise-level "result counts" on a positive control indicts the service, not the probe; the quorum rule correctly refuses to mint a datapoint either way.
- Ask the service, not the socket. A listening port with a hung process behind it passes the naive health check every time.
Read before or after: The filter that ran before the decode ; and The SERP that lies.