validate

name	validate
description	Freshly judge exact subject content against bead or caller acceptance, optionally persist verdict.v2 for a declared consumer, and stop. Triggers: "validate", "independently validate", "vibe".
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 schemas/verdict.v2.schema.json persistence

Validate

Independently judge one exact subject against the acceptance in its existing bead or caller source, return one semantic result, and stop. Validate is the sole verdict.v2 writer when persistence is requested. It never asks the model to reconstruct Plan or Candidate packets.

Preconditions

• The subject is a nonempty implementation candidate: the manifest lists at least one entry, and store-verdict refuses an empty one. Plans, audits, reviews, and other control artifacts are not completion subjects unless the caller explicitly requested document review.
• The intent source is available as a caller-owned artifact or runtime-owned content-addressed snapshot; its acceptance digest is derived automatically.
• The subject manifest still matches the subject.
• Author and validator context IDs are explicit.
• Freshness is explicitly attested with source: runtime | caller and an attester identity.

Missing, colliding, or unattested identities produce NOT_PROVEN. This is a declared trust fact, not cryptographic proof that contexts were isolated.

Cross-model fresh validator (caller-elected)

A caller may request that the fresh validator run on a different model than the author. Dispatch via the controller-session recipe in the agent-native model-dispatch recipe (codex-exec and/or ntm, probed at runtime). Record author and validator model_identity in evidence refs and freshness attestation notes — do not change verdict.v2 schema. If the requested validator model has no live adapter, disclose the unsatisfied diversity request and proceed same-model; never invoke claude -p / claude --print. Single fresh validator remains the default shape.

Mutating-check quarantine

Before running any acceptance-listed command, classify it as read-only or subject-mutating. Regen scripts, sync scripts, formatters, and anything with --force are subject-mutating until proven otherwise. Never run a subject-mutating check against an uncommitted subject: on 2026-07-15, scripts/test-ci-deterministic-gates.sh regenerated skills-codex/ from HEAD mid-validation and destroyed the uncommitted subject, forcing NOT_PROVEN (verdict b6e759dd...cb6a); only restoring the subject and revalidating in a fresh context produced the PASS (e9b6cdb8...37b9). If a mutating check is genuinely required by acceptance, run it against a disposable copy or a committed subject, never the judged working tree.