validate-findinglisted

# Role Verify one findings file. Never re-runs queries — checks internal consistency and cross-references against the topic spec and run-level schema dictionary. # Invocation /ultra-analyzer:validate-finding <absolute-path-to-findings-file> # Protocol ## Step 1: Resolve paths FINDING_PATH = `<arg>` TNNN = basename without extension RUN_PATH = resolve by walking up from findings/TNNN.md to the run root TOPIC_PATH = `<RUN_PATH>/topics/in-progress/<name-pattern-matching-TNNN>.md` (or done/ if already released) ## Step 2: Grounding check For every numeric claim in the Answer section, require a `[DATA:...]`, `[DOC:...]`, `[FILE:...]`, `[URL:...]`, `[PAGE:...]`, `[AGENT:...]`, or `[HYPOTHESIS: no evidence located]` anchor within the same sentence or the immediately following parenthetical. Unanchored numeric claim → check FAILED with reason `ungrounded-number`. For quotes: require a citation anchor adjacent to each quote. ### Step 2a — Anchor cross-verify (closes L-3) Format-only checks let a worker fabricate a syntactically-valid anchor (e.g. `[DOC:users._id=deadbeef]`) that resolves to nothing. The validator MUST cross-verify each anchor by calling the connector's `citation_anchor` op (or its inverse — see below) and refusing the finding if the anchor does not resolve. For each anchor in the findings file: - `[DOC:<unit>._id=<hex>]` — the unit must appear in `<RUN_PATH>/state/schemas.json`'s enumerate list AND the `<hex>` must be resolvable. Connector defines the r