Validate

Validate

Freshly judge one finished candidate against its original acceptance, return PASS, FAIL, or NOT_PROVEN with criterion-level evidence, and stop. Neighbours: advice or a second look is Review; whether a stated claim holds is Reality Check. This file carries every rule the judgment needs. Linked files, including RPI boundaries and mechanics, 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 cannot stand in for this judgment. 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.
• 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". Generic checking or readiness questions, even with criteria supplied, do not: ask once whether the caller wants advice or an acceptance judgment, and wait. Issue no verdict or readiness approval meanwhile; missing intent is not a NOT_PROVEN verdict. Shared routing: advice or acceptance.

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. After the author repairs findings, the affected checks confirm the repair; a second judgment happens only when the caller asks for one. 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 means FAIL on that subject; 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.
• 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, such as a pasted diff or a described change, is exactly what was supplied; anything it does not show is unverified.

A requested retrospective follows the code judgment and is not evidence for it. When intent bundles both, judge the code criteria separately and keep the overall request incomplete until the retrospective exists; issue no overall PASS early. An explicitly requested review of the retrospective judges that document on its own scope.

Identity and freshness

Author and validator identities must be explicit and distinct, and freshness must be attested by the runtime or the caller, naming the attester. An attestation is a declared trust fact, not cryptographic isolation. In ordinary use these count:

• Author: the identity the caller gives for whoever produced the candidate: a person, a session or agent ID, or the commit author.
• Validator: this context's runtime ID when the runtime exposes one, such as a subagent or session ID; otherwise the handle the dispatcher holds for it, such as the agent ID returned at launch, or "this conversation" when the caller opened it for the judgment.
• Freshness: a statement from the runtime, the dispatcher or the caller, naming who makes it, that this context did not produce the candidate and was given intent, subject and evidence rather than the author's working history. When the caller opened this conversation for the judgment and supplied the candidate, the caller is the attester.

A role name, a persona switch inside the author's conversation, or the validator vouching for itself does not count. Never invent an identity. An identity gap makes the result NOT_PROVEN; keep every finding in the report.