The /dr-verify Command — Tri-Layer Artifact Verification
How /dr-verify runs three independent verification layers — a deterministic shell check, a cross-model peer review, and parallel subagents — to surface findings before compliance.
A PRD that looks complete may have acceptance criteria that cannot be falsified. A plan that appears thorough may have steps that cover no acceptance criterion. An implementation report may assert completeness while leaving one AC item unaddressed. /dr-verify checks all of these without modifying a single file.
It is the standalone verification command in Datarim — invocable at any point in the pipeline, findings-only by design. Nothing gets fixed automatically. Everything gets flagged for operator triage.
Three layers, fastest first
The architecture runs cheapest to most expensive. Layer 1 is a deterministic shell pipeline: dr-verify-floor.sh runs with no LLM involvement, producing structured JSONL findings at near-zero cost. If --floor-only is passed, the command stops here — useful for pre-merge sanity checks where speed matters more than depth.
Layer 2 is cross-model peer review. A provider resolution chain selects the cheapest available external model — by default, this resolves to DeepSeek via the coworker abstraction, which costs roughly 14 times less than running Sonnet. The peer reviewer reads the artifacts and returns structured findings tagged with the provider and resolution chain step that selected it.
Layer 3 dispatches three parallel subagents on the Claude runtime: a reviewer, a tester, and a security specialist. Each receives a self-contained context package and returns findings tagged with its role. All three run simultaneously, not sequentially.
What gets verified
The --stage flag controls scope. Stage prd checks the PRD and task description for AC coverage completeness and falsifiability. Stage plan checks that every AC maps to at least one plan step and that a rollback path is explicit. Stage do checks the QA report for uncovered AC items. Stage all runs all of the above plus a cross-artifact drift check that looks for scope creep, spec decay, execution skew, and orphaned requirements.
Three verdicts and their routes
Findings are deduplicated across all three layers using a tuple of artifact reference, AC criteria, and category — the first-source layer wins. Then the command applies verdict logic: PASS means only low-severity findings or none; CONDITIONAL means at least one medium-severity finding with no high-severity ones; BLOCKED means at least one non-discarded high-severity finding.
BLOCKED routes back based on the highest-severity finding's category. A safety finding routes to /dr-design — security gaps require redesign. A correctness finding routes to /dr-do. A completeness finding routes to /dr-plan or /dr-prd. The route targets the earliest pipeline stage that can actually address the problem.
The audit log
Every run produces an append-only audit log at datarim/qa/verify-{task-id}-{stage}-{iter}.md. After writing, the file receives chmod a-w — it cannot be modified after the fact. Re-runs after fixes get a -v2, -v3 suffix. The prior logs stay intact for the audit trail.
For the full pipeline context, see what Datarim is. To see what happens after verification passes, read about /dr-compliance.