A successful code inspection does not raise the evidence class of the hypothesis it supports

[krapcys1-maker]

Code inspection can reach CODE_VERIFIED — locating a mechanism in a named file, line and symbol — and the hypothesis it was checking still ends the run at REPO_CLAIM.

Observed in a live run: inspection reported CODE_VERIFIED for two repositories, one of them matching a spreading-activation traversal module by name and content. The coverage counter verifiedArtifacts stayed at 0 and the final verdict was EVIDENCE_NOT_VERIFIED.

The verdict is not wrong — no evidence row carries a code-level class, so the report honestly says nothing was verified. But the inspection's finding never becomes evidence for anything, which makes the whole capability decorative.

What is missing: a path from CodeInspectionResult to an Evidence row carrying CODE_VERIFIED, bound to the specific hypothesis claim the inspection was checking.

The hard part, and why this is not a five-line fix: an inspection verifies that a mechanism appears in a repository. A hypothesis claims that this mechanism addresses this failure mode. Those are different propositions, and letting the first silently satisfy the second would reintroduce exactly the inflation this project exists to prevent. The binding needs to be explicit about which claim the file evidences.

[krapcys1-maker]

Still open, and now measured on both sides.

Two runs give the clearest evidence yet that the inspection itself is fine and the gap is in propagation:

• Run cmtb4podw (V10): ten verification tasks ran code inspection, reaching depth CODE_INSPECTED on clawdbrunner/openclaw-graphiti-memory, BENCHMARK_FOUND on artemMprokhorov/hippograph-pro, README_READ on AGAMPANDEYY/sage-mem. The final verdict was still EVIDENCE_NOT_VERIFIED, with verifiedArtifacts at 0.
• I re-read the verdict logic in src/lib/sources/code-inspection.ts line by line while auditing this. It is correct and stricter than I had assumed: comment matches are excluded from codePhrases, there is a separate path for a comment corroborated by code in the same file, and a prose-only phrase is explicitly graded as a repo claim rather than code evidence. I had previously written that it was matching words like temporal in comments and inflating the verdict — that was wrong, and I retract it. It matches those words, and correctly refuses to count them.

So the ladder works right up to the point where the result has to reach the hypothesis, and there it does not.

Two other findings from the same audit that bear on reproducing this:

• Every GitHub call in runs cmtf8woru and cmtfahu4h returned HTTP 401 from an expired token, and all 74 were recorded with error = NULL — the adapter caught its own transport error and returned an empty document list, so the audit column stayed clean. Both runs therefore had zero repositories to inspect, which looks identical to this bug but is not. Fixed in d089e81; if you are reproducing, confirm github coverage is completed rather than failed first.
• assessSourceCoverage and the per-target gate (04a0174) now distinguish "we could not look" from "there is nothing there", which matters here: a run with no inspectable repositories should not be read as evidence about this issue either way.

[krapcys1-maker]

Fixed.

maxEvidenceClassForSource(source, inspectedDepth?) in src/lib/agents/core/source-coverage.ts now takes the depth an inspection actually reached, and inspectionDepthByRepo() in claim-ledger.ts supplies it.

Verified against real stored run data rather than by reading the code — scripts/audit-replay-past-runs.ts re-runs the evidence logic over past runs' rows and reports what changes. Run cmtfoj5cy, which had reported that no code was read, promotes three repositories to CODE_VERIFIED under the current build: inite-brain-service, microsoft/SeCom and hippograph-pro, each at depth BENCHMARK_FOUND.

Two guards were added alongside, because the first version of this fix over-promoted:

• a per-claim promotion caps at CODE_VERIFIED even when the inspection reached BENCHMARK_FOUND. A benchmark existing in a repository is not a measurement tied to a particular claim. An earlier build promoted eighteen architectural descriptions to EXTERNAL_MEASURED on that path.
• promotion is gated on the matched terms appearing in the claim's own text. Keying by repository alone promoted every claim citing that repo, including claims the inspected code said nothing about.