/validate

name: validate
description: 'Freshly judge whether a finished change and its claims meet original acceptance: PASS, FAIL or NOT_PROVEN. Use when: asked for a go/no-go, sign-off or independent verdict.'
practices:
- design-by-contract
- llm-eval-harness
- content-addressed-storage
hexagonal_role: driving-adapter
consumes:
- subject-manifest.v1
produces:
- subject-manifest.v1
- validation-result
- verdict.v2
context_rel:
- kind: customer-of
  with: plan
- kind: customer-of
  with: implement
skill_api_version: 1
user-invocable: true
metadata:
  graph_root: true
  tier: judgment
  dependencies: []
  capabilities: [compute_subject_identity, judge_acceptance, return_validation_result, persist_verdict]
  effects: [write_verdict_artifact]
  canonical_status: canonical
  disposition: keep
output_contract: 'PASS | FAIL | NOT_PROVEN with criteria, evidence, checked/not_checked, identity, and freshness; optional verdict.v2 persistence (draft shape in references/mechanics.md)'

Validate

From a context that did not author it, judge one finished candidate against its original acceptance and return `PASS`, `FAIL`, or `NOT_PROVEN` with evidence for each criterion. The author's word is a claim, every criterion needs its own evidence, and green obtained by weakening a check is FAIL.

| Use instead | When | |---|---| | [Review](../review/SKILL.md) | advice or a second look | | [Research](../research/SKILL.md#claimed-state-audit) | whether a stated claim holds |

This file carries every rule the judgment needs. Linked files, including [RPI boundaries](../rpi/references/boundaries.md) and [mechanics](references/mechanics.md), add depth only: if one cannot be read, judge from this file and say which was unavailable.

Rules that decide the verdict

• The author cannot issue a binding PASS, and advisory findings, such as a

Review or Council report, cannot stand in for this judgment: test them as claims. An author's summary, confidence or assurance is a claim to check, not evidence; explanation alone is not proof.

• Each criterion needs its own evidence on the exact candidate. A criterion

nobody demonstrated goes in `not_checked` and never counts toward PASS.

• A changed test, tolerance, golden, suppression or acceptance text must still

satisfy the original intent. Green obtained by weakening the oracle is FAIL for the criterion it was meant to prove, and that green is not evidence. The same holds for green obtained by changing what the check runs against: product code that behaves differently when it detects a test or CI environment, a failure path newly silenced by an empty handler or discarded error, or a check made non-blocking, skipped or bypassed. Each needs a reason visible in the change that still serves the original intent.

• A receipt is check output tied to this subject: command, result, and commit

SHA or digest; a summary such as "suite is green" is a claim. Read receipts; do not re-run checks the author ran on this exact subject or that CI will run. Re-execute only a risk-critical claim that has no receipt.

• A necessary finding never becomes an optional caveat or non-goal.

Decide in this order:

1. The subject changed during judgment, changed-path coverage is incomplete, or author and validator identity or freshness is missing, colliding or unattested: NOT_PROVEN. 2. A criterion is proven failed, or a change is proven out of scope: FAIL, even when other criteria are unverified. 3. Any in-scope criterion lacks evidence: NOT_PROVEN. 4. Every criterion is verified with evidence, checked scope is nonempty and `not_checked` is empty: PASS.

Establish intent first

An explicit request for Validate, an acceptance verdict or independent proof that original acceptance is met selects this skill, even when phrased as "review this"; a request for a look or opinion goes to Review, and when the purpose is open, ask once and issue no verdict meanwhile, since missing intent is not a `NOT_PROVEN` verdict ([advice or acceptance](../review/references/advice-or-acceptance.md#ambiguous-requests)).

When a fresh judgment is worth it

Spend validation where a mistake is costly. For an ordinary change the author's checks and CI are the gate, and no fresh judgment is owed. Use Validate when:

• the caller asks for an acceptance verdict or independent proof;
• a mistake cannot be cheaply undone after it lands: a published release or

instructions users will follow, a security boundary, destroying data or tracker state, deleting a check that protects the product; or

• no deterministic check covers the behavior that changed.

Judge once. Report NOT_PROVEN with its gaps and stop; do not request or wait for another round. The author repairs findings and the checks that cover each repair confirm it; a repair does not start a second judgment. Keep the judgment's cost a fraction of the cost of the work: when it approaches that cost, stop and return what is unchecked.

Subject

The subject is a nonempty implementation candidate, held unchanged after required checks and known repairs; plans, audits and reviews are subjects only when the caller requested document review. Supplied failed-acceptance evidence proves a failure on that subject: FAIL, unless a step 1 gap makes it NOT_PROVEN; do not review a moving repair. Bind its identity at the start and again at the end of judgment:

• With AgentOps installed: `ao provenance manifest --root "$REPO_ROOT" --include "$CHANGED_PATH"`,

one `--include` per changed path ([helper commands](references/mechanics.md#helper-commands)). A deleted path is bound only with `--base-manifest <base-manifest>`; without a base manifest, use the Git fallback below.

• In any Git repository: the commit SHA (`git rev-parse HEAD`) and the changed

paths (`git diff --name-only <base>...HEAD`); for uncommitted work, the `git status --porcelain` listing and a `shasum -a 256` of each changed file.

• A subject supplied only in the conversation