SuperBizAgent-java/devflow/projects/2026-07-08-verifier-evidence-reference-fidelity/evidence.md

Evidence

Existing Context

• Existing chat-verifier-agent spec still used source_invocation_ids and tool_trace_summary as the main verifier evidence context.
• Existing evidence-trace-hardening spec already established tool_invocation.retrieval_details as the right place for structured tool-specific facts.
• Prior devflow projects established that runbook/skill content is guidance, not incident evidence.

Code Findings

• VerifierInputHook previously backfilled plural source_invocation_ids from tool_trace_summary by tool name.
• ExecutorGatekeeperService previously validated invocation existence and tool name, but not raw_path or excerpt authenticity.
• ToolInvocationRecorder persisted retrieval details but did not generate claim-addressable evidence_refs.
• QueryLogsTools could fall back to generic-service placeholder logs on no-hit.

Implementation Evidence

• ToolInvocationRecorder now extracts:
  • $.alerts[i] for query_metrics
  • $.logs[i] for query_logs
  • $.evidence_blocks[i] for lookup_knowledge
• ExecutorGatekeeperService now validates:
  • invocation existence
  • tool name
  • raw path presence
  • retrieval_details.evidence_refs
  • excerpt similarity/support
• VerifierInputHook only auto-fills a singular source_invocation_id when exactly one candidate exists and never invents raw_path.
• QueryLogsTools returns HikariCP mock logs for order-service and returns empty no-hit results for unrelated services.

Residual Finding

The HikariCP negative E2E no longer has generic-service pollution, but the model still issued an extra broad HikariCP query without the service filter and used order-service as context. This is a remaining narrow-scope behavior issue, not a mock evidence pollution issue.