independent-verification

Independent Verification

Use this skill to obtain evidence-backed review from a verifier that did not implement the change. This is a risk-control workflow, not a simulated panel and not a substitute for accountable human approval.

The mandatory trigger and release gate are owned by the workflow rule (${HANDBOOK_ROOT}/rules/010-workflow.mdc). This skill owns the verification procedure and artifact contract.

Non-Negotiable Principles

1. Deterministic evidence comes first. Run applicable tests, lint, type checks, builds, policy checks, security scans, plans, and schema validation before asking a model to interpret the result.
2. Freeze the review target. Bind the request to an exact commit SHA and SHA-256 digest of the reviewed diff or patch. Moving branches and mutable working trees are not approval targets.
3. Separate implementer and verifier. Prefer a different tool and model provider. At minimum, use a fresh session with no implementer reasoning or hidden chain-of-thought.
4. Keep the verifier read-only. It reports findings and a verdict. It does not edit files, run deployments, write Git state, dismiss findings, or approve its own output.
5. Use a trusted controller. A small deterministic wrapper creates worktrees, runs commands, enforces limits, checks hashes, and writes artifacts. The model never receives broad credentials or arbitrary write authority.
6. Invalidate stale verdicts. Any reviewed-file, commit, diff-hash, requirement, policy, or deterministic-evidence change requires another verification.
7. AI verdicts are advisory. A model cannot satisfy a mandatory human approval, CODEOWNERS review, protected-environment approval, or regulated sign-off.

When Independent Verification Is Required

Require this workflow for:

• authentication, authorization, IAM, PKI, secrets, cryptography, or tenant boundaries;
• production infrastructure, deployment controls, destructive data/schema migrations, or rollback-sensitive changes;
• privacy, regulated data, financial calculations, safety-critical behavior, or irreversible external actions;
• broad architecture decisions, trust-boundary changes, or changes with difficult rollback;
• explicit user, policy, CODEOWNERS, compliance, or release-process requirements.