# Evidence Verification

> Use at every workflow checkpoint of a flattened delivery run, in-session by the orchestrating delivery-lead — never as an Agent-tool dispatch: mechanically confirming a stretch's required outputs exist, factually reading whether that evidence satisfies the accepted acceptance criteria or user story, and routing the run per the checkpoint's own routing table. This replaces the retired Blind Re-Score practice for flattened commands: the orchestrator directed the work, so a blind re-score makes no sense — independence comes from the distinct reviewer roles already in the flow, and this check verifies evidence instead. Trigger at every checkpoint position of the currently running command.

- Skill: `bhangeef16/evidence-verification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bhangeef16/evidence-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bhangeef16/evidence-verification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: BhangeeF16 (https://skillmd.com/u/bhangeef16)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bhangeef16/evidence-verification

---


# Evidence Verification

The delivery-lead's in-session gate check, run at each checkpoint position with no subagent dispatch. It has exactly two parts, in order:

1. **Mechanical check** — do the stretch's required outputs exist as real files/content, per each action's own reported locations? This part is scriptable and involves no judgment: an output is present or it is not. A missing output ends the check — route on missing evidence; do not proceed to part 2 to argue the gap away.
2. **Factual read** — does that evidence, read plainly, actually satisfy the accepted acceptance criteria or user story? This is a judgment call, but a factual one: "criterion X asks for a denied-path test; the evidence contains one / does not." It is NOT a quality re-score — quality independence is already provided by the distinct reviewer roles in the flow (the code reviewer is not the implementer; the security reviewer implemented nothing; QA judges evidence it did not produce).

Two rules apply to every checkpoint: a claim with no evidence entry behind it is not passing-shaped, regardless of the result field attached to it; and residual risks are recorded explicitly even when the list is empty.

## Where the contract and routing live

There is exactly one copy of this data, and it is already in your context: the current command's own `commands/<name>.process.yaml`, live-injected at the start of every run. Each `- checkpoint:` entry in its `sequence:` carries its own `required_inputs`, `required_outputs`, and `routing` map (`on_pass`, `on_pass_with_risks`, `on_score_below_minimum`, `on_failure`, `on_missing_evidence`, `on_security_gap` — each value a real action id in that same file, or `null` when the run simply completes, or `ask_user_required_question` when no in-process target exists). Read the checkpoint you are currently at directly off that file. Do not transcribe or memorize a copy of it here — if this file and the process definition ever disagree, the process definition wins, because it is the one thing re-read fresh on every single run.

A routing destination naming an action id means re-dispatch that action. A routing destination of `null` means the run completes at this checkpoint (only `discover`'s `design_review` does this today). `on_blocked` and `on_material_unknown` (not present as explicit routing fields, since they never vary by checkpoint) always mean: ask the human one focused, specific question and stop — `continue_without_answer: false` — never continue on an assumption.

## Gate defaults

Every command declares its own gate once, at the top of its process definition (`orchestrator.checkpoint_gate` — currently `minimum_score: 80`, `preferred_score: 90`, `blocking_unknown_action: ask_user_required_question`, identical across all three commands). A result at or above minimum but below preferred advances as `pass_with_risks` with the risks named. No checkpoint in any current process definition overrides this gate — if one ever does, that override lives on the checkpoint's own entry, not here.

## Escalation to the human

Ask the human only when part 2 is genuinely ambiguous after reading the artifacts — and ask a specific factual question ("can you confirm criterion X is met by Y", "does the recorded approval at Z cover this scope"), never a generic "confirm this score". Bounded by materiality: escalate when the call would materially change scope, ownership, a security boundary, or the acceptance outcome — not for every assumption.

## Journal duty

Each checkpoint's decision is appended to the run journal as it is made (checkpoint name, decision, route taken, one-phrase reason) — the `debrief` persona (the `process_retrospective` action) at the end of the run reads exactly this.