Feature Deep Verify

Feature: Deep Verify

What it is. The final, deepest check on a surviving finding: one full agentic session per finding — no batching, no excerpt budget, full Read/Grep/Glob access to the actual repo — that independently re-derives the finding from the source, then reasons across the whole survivor set at once. It runs after Docs & History Corroboration, before optional runtime/live verification.

This is the tool encoding a specific manual discipline: read every cited line yourself, trace every sibling function, and don't trust an earlier verdict just because it survived two prior passes.

Why a separate stage from validation

Adversarial Validation is skeptical, but its prompt explicitly forbids one finding's verdict from influencing another's — so it can never notice that finding A and finding B are the same bug reached two different ways, or that finding C is quietly bundling two independently-triggerable bugs under one description. It's also batched and excerpt-budgeted for throughput across every raw candidate.

Deep-verify inverts both trade-offs on purpose: it runs on the much smaller surviving set (already thinned by validation and corroboration), one uncapped session per finding, and is handed a compact summary of every other surviving finding so it can reason across the set.

The verdict space

Validation's verdict is essentially binary (confirmed / refuted). Deep-verify adds a real middle ground:

Verdict	Meaning	Effect
reconfirmed	Independently re-derived; stands as written	kept
corrected	Mechanism is real, one stated fact was wrong (wrong line, wrong field, wrong precondition)	kept, correction noted
split	This one finding is actually ≥2 independently-triggerable bugs	replaced by N independent sub-findings, original kept in a split_originals appendix
merged	Duplicates another survivor by root cause (not just by dedup key)	folded into that finding, kept in a merged_findings appendix
refuted	Deep re-derivation shows validation and corroboration were both wrong	moved to the normal dropped list
inconclusive	A genuine, thorough attempt couldn't settle it from source alone	kept, flagged

Downgrade-don't-delete still applies: only refuted removes a finding outright. split and merged never delete — the original is always kept in a report appendix, never silently gone.

Every verdict — including reconfirmed — requires an independent_derivation field: the actual file:line trail walked, the sibling/caller/callee functions opened, the struct/ABI/precondition detail confirmed. This is the audit trail that makes the pass trustworthy rather than just trusted.

How it's gated

• Opt-in, off by default — --verify/--no-verify on pipeline, or argo verify --run RUN_ID standalone. Off by default because it's the most expensive annotation stage: one full session per finding, never batched.
• Offline, like validation — full read-only repo access (Read/Grep/Glob/Write), no network tools. See Guardrails & Safety.
• --verify-max-findings N caps how many survivors get a session (cost control on a large survivor set); findings past the cap are kept, un-deep-verified, never dropped.
• Best-effort — a session failure leaves a finding inconclusive with an infra-failure rationale prefix, distinguishable from a genuine "couldn't tell" — same pattern as validation and corroboration's unknown/needs_runtime_verification infra-failure split.

Related

• Adversarial Validation — the stage immediately before corroborate; the per-finding-isolated, batched pass this stage is not.
• Docs & History Corroboration — the networked cross-check that runs right before this one.
• Determinism & Anti-Hallucination — the downgrade-don't-delete philosophy this stage extends with split/merged appendices.