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 semantic author of verdict.v2 when persistence is requested.
ao provenance store-verdict supplies structural verification and atomic storage. Before the verdict,
read boundaries.md in the rpi skill's references directory for the state
Validate leaves to the caller.
Prompt
Validate bead ag-1234 in this fresh context. Intent: the bead text and digest.
Subject: manifest.json from:
ao provenance manifest --root . --include cli/internal/gates
Author context ctx-a1. Re-run `cd cli && go test ./internal/gates/...`.
Return PASS, FAIL, or NOT_PROVEN with evidence; stop.
Preconditions
- The subject is a nonempty implementation candidate: the manifest lists at
least one entry. Plans, audits, and reviews are subjects only when the
caller explicitly requested document review.
- The intent source is a caller-owned artifact or a runtime-owned
content-addressed snapshot; its acceptance digest is derived automatically.
- Author and validator context IDs are explicit, and freshness is attested
with
source: runtime | caller and an attester identity. Missing,
colliding, or unattested identities produce NOT_PROVEN: a declared trust
fact, not cryptographic proof of isolation.
Fresh validator and model selection
Default to one fresh, author-distinct validator from the author's model family:
Codex/OpenAI work uses a fresh Codex/OpenAI reviewer; Claude/Anthropic work uses
a fresh Claude/Anthropic reviewer. Use the runtime's configured capable model
unless the caller pins one. Fresh context is required even when model weights
are identical; a new role instruction in the author's session is not fresh.
Risk determines the depth of evidence inspection, not an automatic second family.
Acceptance, tests/gates, stopping, allowances, safety, disclosure, hooks and
executable controls warrant deeper checks, including policy written as prose.
Conservative risk cues include cli/internal/gates/**, scripts/check-*.sh,
tests/**, skills/*/scripts/**, skills/cc-hooks/policies/**, lib/**,
.github/workflows/** and scripts/security-gate.sh. Unknown risk receives
deeper inspection; it does not silently change the selected model families.
The caller can request --cross-model or say "cross-model review" to add one
fresh validator from a different family. --cross-model <model> pins that
additional reviewer, for example --cross-model claude-fable-5-1 from Codex
or --cross-model gpt-6-astra from Claude. These are skill prompt options,
not ao CLI flags. RPI forwards them unchanged. Without a pin, use an available,
authorized capable model from the other family; never silently substitute for
a pinned model or count two models in one family as cross-family diversity.
An explicit caller requirement remains required until the caller changes it;
changing the default cannot erase a finding or relabel a missing verdict as PASS.
Route selection and invocation through
agent-native model-dispatch;
references/mechanics.md owns evidence storage.
There is no fixed ten-minute review timeout. Use the caller's selected review
timeout or remaining native deadline, respecting any earlier host or goal limit.
A timeout is missing judgment, not FAIL; never restart to renew an allowance.
Each selected judge receives the exact subject, unchanged acceptance and
authorized evidence independently, without the author's desired verdict or peer
conclusions. Record actual model/context identities and runtime receipts.
Missing freshness, an unbound subject, incomplete acceptance evidence, or
nonempty not_checked prevents PASS regardless of model family.
With no authorized adapter for requested diversity, disclose
diversity_unsatisfied: the required combined result is NOT_PROVEN even if
the same-family judge passed. A delivered FAIL stands. Advisory diversity that
the caller explicitly made optional may accompany the same-family result with
that limitation; it cannot discard an acceptance-relevant finding.
When selected judges disagree, preserve both verdicts and their evidence.
Required diversity converges only when both pass; neither majority vote nor a
preferred judge settles a split. Repair addresses findings under the existing
convergence law. Report unresolved dissent and the caller's decision openly.
Same-family fresh judgment reduces anchoring, but does not prove independence
from shared training biases; cross-family agreement is corroboration, not truth.
Mutating-check quarantine
Classify every acceptance-listed command as read-only or subject-mutating
before running it: regen scripts, sync scripts, formatters, and anything with
--force are mutating until proven otherwise. Run a mutating check only
against a disposable copy or a committed subject, never the judged working
tree (the boundaries appendix records the regen that overwrote a subject).
Scope disclosure
not_checked has exactly one meaning: in-scope acceptance surface this
validation did not verify. PASS asserts the whole declared acceptance
surface was verified, so a PASS carries no not_checked entries; every other
scope limit has a home that survives inside a PASS: a bounded proof in
criteria[].reason, a declared non-goal in the intent source, residual risk
in the report (table in the mechanics reference). Emptying not_checked to
obtain PASS is a contract violation: unverified acceptance makes the honest
result NOT_PROVEN, and an entry that was never acceptance moves to its home
and stays visible. A finding necessary to acceptance cannot be relabeled as
optional, residual risk, or a non-goal to obtain PASS.
Workflow
- Derive
subject-manifest.v1 with the helper's manifest command (flags
in the mechanics reference) at the start and again at the end; any
mismatch is subject mutation and returns NOT_PROVEN.
- Confirm the intent-source digest is unchanged since implementation, every
cited evidence digest matches the artifact it names, and complete
changed-path coverage can be derived; otherwise
NOT_PROVEN.
- Adjudicate the actual diff: runtime-derived changed paths against the
intent's scope classes. A proven out-of-scope path is
FAIL; incomplete
scope evidence is NOT_PROVEN.
- Inspect the exact subject and evidence. Reported exit codes are claims:
re-execute the proofs that bear on acceptance. A changed test, gate,
fixture, golden, tolerance, suppression, or acceptance source must be
required by the original intent, with green coming from implemented
behavior; green obtained by weakening acceptance is
FAIL. Judge every
acceptance criterion against its own evidence reference; a criterion with
no evidence of its own is unverified, not passed.
- Choose exactly one semantic result:
PASS, FAIL, or NOT_PROVEN. Return
it with criterion-level results, findings, evidence references, checked,
not_checked, both identities, both context IDs, and the freshness
attestation. Name a class for each finding: one short stable name for the
kind of defect, one per finding, reused word for word when the same kind
recurs, so the orchestrator can see a closed kind come back. Explain in the
existing summary and evidence whether a newly exposed defect pre-existed the
change, was introduced by it, or has unknown cause. Use before/after proof or
equivalent causal evidence under unchanged acceptance; counts and timestamps
do not establish cause. Recurrence calls for causal examination and does not
by itself prove a design failure. Name the class or omit it; a class that is
present and blank is a finding against this validator,
and so is a class that does not describe its finding. PASS
requires distinct identities, explicit freshness, nonempty checked scope,
nonempty top-level evidence, evidence for every criterion, and an empty
not_checked. A documentation sentence claiming something is published,
pinned, or proven is an acceptance criterion like any other: it needs a
check this validator can run, or it is not_checked. The
docs.claims-tracked gate covers the tracked-file half of that and nothing
more.
- Only when the caller requests machine-readable evidence or a declared
downstream consumer requires it, persist canonical
verdict.v2 with the
helper's store-verdict (mechanics reference), then return the artifact
path and digest with the result. Stop.
Fresh validation is independent judgment over the exact subject, not a replay
of every author command: rerun the risk-critical, uncertain, or thinly
evidenced checks; a digest-bound deterministic receipt may prove routine
facts; replay an expensive full suite only when acceptance requires it. The
repository's full literal CI command set, as quoted in AGENTS.md, runs
once, on the final integrated subject.
It's working if
Observable in the trace, without reading the prose, and the rubric a fresh
independent judge scores this skill against:
- A criterion whose evidence is a justification rather than a proof is named,
and the result is
NOT_PROVEN rather than PASS.
- Green obtained by widening a tolerance, skipping a case, or re-baselining a
budget is reported as
FAIL, never as completion.
- Every scope limit is placed in one of the Scope-disclosure homes; none was
deleted to reach
PASS.
- The subject manifest is derived twice, at the start and at the end, and the
two are compared.
Boundary
Validate emits no next action, repair, retry, replan, or delivery state (full
list in the boundaries reference); ledger availability cannot change a
verdict's validity.
1---
2name: validate
3description: 'Freshly judge a finished change against its acceptance: PASS, FAIL, or NOT_PROVEN. Not for claim-vs-tree checks; that is reality-check. Triggers: "validate", "is this proven", "check this change", "cross-model review".'
4practices:
5- design-by-contract
6- llm-eval-harness
7- content-addressed-storage
8hexagonal_role: driving-adapter
9consumes:
10- subject-manifest.v1
11produces:
12- subject-manifest.v1
13- validation-result
14- verdict.v2
15context_rel:
16- kind: customer-of
17 with: plan
18- kind: customer-of
19 with: implement
20skill_api_version: 1
21user-invocable: true
22metadata:
23 graph_root: true
24 tier: judgment
25 dependencies: []
26 capabilities: [compute_subject_identity, judge_acceptance, return_validation_result, persist_verdict]
27 effects: [write_verdict_artifact]
28 canonical_status: canonical
29 disposition: keep
30output_contract: 'PASS | FAIL | NOT_PROVEN with criteria, evidence, checked/not_checked, identity, and freshness; optional schemas/verdict.v2.schema.json persistence'
31---
32
33# Validate
34
35Independently judge one exact subject against the acceptance in its existing
36bead or caller source, return one semantic result, and stop. Validate is the
37sole semantic author of `verdict.v2` when persistence is requested.
38`ao provenance store-verdict` supplies structural verification and atomic storage. Before the verdict,
39read `boundaries.md` in the rpi skill's `references` directory for the state
40Validate leaves to the caller.
41
42## Prompt
43
44```text
45Validate bead ag-1234 in this fresh context. Intent: the bead text and digest.
46Subject: manifest.json from:
47ao provenance manifest --root . --include cli/internal/gates
48Author context ctx-a1. Re-run `cd cli && go test ./internal/gates/...`.
49Return PASS, FAIL, or NOT_PROVEN with evidence; stop.
50```
51
52## Preconditions
53
54- The subject is a nonempty implementation candidate: the manifest lists at
55 least one entry. Plans, audits, and reviews are subjects only when the
56 caller explicitly requested document review.
57- The intent source is a caller-owned artifact or a runtime-owned
58 content-addressed snapshot; its acceptance digest is derived automatically.
59- Author and validator context IDs are explicit, and freshness is attested
60 with `source: runtime | caller` and an attester identity. Missing,
61 colliding, or unattested identities produce `NOT_PROVEN`: a declared trust
62 fact, not cryptographic proof of isolation.
63
64## Fresh validator and model selection
65
66Default to one fresh, author-distinct validator from the author's model family:
67Codex/OpenAI work uses a fresh Codex/OpenAI reviewer; Claude/Anthropic work uses
68a fresh Claude/Anthropic reviewer. Use the runtime's configured capable model
69unless the caller pins one. Fresh context is required even when model weights
70are identical; a new role instruction in the author's session is not fresh.
71Risk determines the depth of evidence inspection, not an automatic second family.
72
73Acceptance, tests/gates, stopping, allowances, safety, disclosure, hooks and
74executable controls warrant deeper checks, including policy written as prose.
75Conservative risk cues include `cli/internal/gates/**`, `scripts/check-*.sh`,
76`tests/**`, `skills/*/scripts/**`, `skills/cc-hooks/policies/**`, `lib/**`,
77`.github/workflows/**` and `scripts/security-gate.sh`. Unknown risk receives
78deeper inspection; it does not silently change the selected model families.
79
80The caller can request `--cross-model` or say "cross-model review" to add one
81fresh validator from a different family. `--cross-model <model>` pins that
82additional reviewer, for example `--cross-model claude-fable-5-1` from Codex
83or `--cross-model gpt-6-astra` from Claude. These are skill prompt options,
84not `ao` CLI flags. RPI forwards them unchanged. Without a pin, use an available,
85authorized capable model from the other family; never silently substitute for
86a pinned model or count two models in one family as cross-family diversity.
87An explicit caller requirement remains required until the caller changes it;
88changing the default cannot erase a finding or relabel a missing verdict as PASS.
89
90Route selection and invocation through
91[agent-native model-dispatch](../agent-native/references/model-dispatch.md);
92[references/mechanics.md](references/mechanics.md) owns evidence storage.
93There is no fixed ten-minute review timeout. Use the caller's selected review
94timeout or remaining native deadline, respecting any earlier host or goal limit.
95A timeout is missing judgment, not FAIL; never restart to renew an allowance.
96
97Each selected judge receives the exact subject, unchanged acceptance and
98authorized evidence independently, without the author's desired verdict or peer
99conclusions. Record actual model/context identities and runtime receipts.
100Missing freshness, an unbound subject, incomplete acceptance evidence, or
101nonempty `not_checked` prevents PASS regardless of model family.
102With no authorized adapter for requested diversity, disclose
103`diversity_unsatisfied`: the required combined result is `NOT_PROVEN` even if
104the same-family judge passed. A delivered FAIL stands. Advisory diversity that
105the caller explicitly made optional may accompany the same-family result with
106that limitation; it cannot discard an acceptance-relevant finding.
107
108When selected judges disagree, preserve both verdicts and their evidence.
109Required diversity converges only when both pass; neither majority vote nor a
110preferred judge settles a split. Repair addresses findings under the existing
111convergence law. Report unresolved dissent and the caller's decision openly.
112Same-family fresh judgment reduces anchoring, but does not prove independence
113from shared training biases; cross-family agreement is corroboration, not truth.
114
115## Mutating-check quarantine
116
117Classify every acceptance-listed command as read-only or subject-mutating
118before running it: regen scripts, sync scripts, formatters, and anything with
119`--force` are mutating until proven otherwise. Run a mutating check only
120against a disposable copy or a committed subject, never the judged working
121tree (the boundaries appendix records the regen that overwrote a subject).
122
123## Scope disclosure
124
125`not_checked` has exactly one meaning: **in-scope acceptance surface this
126validation did not verify**. PASS asserts the whole declared acceptance
127surface was verified, so a PASS carries no `not_checked` entries; every other
128scope limit has a home that survives inside a PASS: a bounded proof in
129`criteria[].reason`, a declared non-goal in the intent source, residual risk
130in the report (table in the mechanics reference). Emptying `not_checked` to
131obtain PASS is a contract violation: unverified acceptance makes the honest
132result `NOT_PROVEN`, and an entry that was never acceptance moves to its home
133and stays visible. A finding necessary to acceptance cannot be relabeled as
134optional, residual risk, or a non-goal to obtain PASS.
135
136## Workflow
137
1381. Derive `subject-manifest.v1` with the helper's `manifest` command (flags
139 in the mechanics reference) at the start and again at the end; any
140 mismatch is subject mutation and returns `NOT_PROVEN`.
1412. Confirm the intent-source digest is unchanged since implementation, every
142 cited evidence digest matches the artifact it names, and complete
143 changed-path coverage can be derived; otherwise `NOT_PROVEN`.
1443. Adjudicate the actual diff: runtime-derived changed paths against the
145 intent's scope classes. A proven out-of-scope path is `FAIL`; incomplete
146 scope evidence is `NOT_PROVEN`.
1474. Inspect the exact subject and evidence. Reported exit codes are claims:
148 re-execute the proofs that bear on acceptance. A changed test, gate,
149 fixture, golden, tolerance, suppression, or acceptance source must be
150 required by the original intent, with green coming from implemented
151 behavior; green obtained by weakening acceptance is `FAIL`. Judge every
152 acceptance criterion against its own evidence reference; a criterion with
153 no evidence of its own is unverified, not passed.
1545. Choose exactly one semantic result: `PASS`, `FAIL`, or `NOT_PROVEN`. Return
155 it with criterion-level results, findings, evidence references, `checked`,
156 `not_checked`, both identities, both context IDs, and the freshness
157 attestation. Name a `class` for each finding: one short stable name for the
158 kind of defect, one per finding, reused word for word when the same kind
159 recurs, so the orchestrator can see a closed kind come back. Explain in the
160 existing summary and evidence whether a newly exposed defect pre-existed the
161 change, was introduced by it, or has unknown cause. Use before/after proof or
162 equivalent causal evidence under unchanged acceptance; counts and timestamps
163 do not establish cause. Recurrence calls for causal examination and does not
164 by itself prove a design failure. Name the class or omit it; a `class` that is
165 present and blank is a finding against this validator,
166 and so is a class that does not describe its finding. PASS
167 requires distinct identities, explicit freshness, nonempty checked scope,
168 nonempty top-level evidence, evidence for every criterion, and an empty
169 `not_checked`. A documentation sentence claiming something is published,
170 pinned, or proven is an acceptance criterion like any other: it needs a
171 check this validator can run, or it is `not_checked`. The
172 `docs.claims-tracked` gate covers the tracked-file half of that and nothing
173 more.
1746. Only when the caller requests machine-readable evidence or a declared
175 downstream consumer requires it, persist canonical `verdict.v2` with the
176 helper's `store-verdict` (mechanics reference), then return the artifact
177 path and digest with the result. Stop.
178
179Fresh validation is independent judgment over the exact subject, not a replay
180of every author command: rerun the risk-critical, uncertain, or thinly
181evidenced checks; a digest-bound deterministic receipt may prove routine
182facts; replay an expensive full suite only when acceptance requires it. The
183repository's full literal CI command set, as quoted in `AGENTS.md`, runs
184once, on the final integrated subject.
185
186## It's working if
187
188Observable in the trace, without reading the prose, and the rubric a fresh
189independent judge scores this skill against:
190
191- A criterion whose evidence is a justification rather than a proof is named,
192 and the result is `NOT_PROVEN` rather than `PASS`.
193- Green obtained by widening a tolerance, skipping a case, or re-baselining a
194 budget is reported as `FAIL`, never as completion.
195- Every scope limit is placed in one of the Scope-disclosure homes; none was
196 deleted to reach `PASS`.
197- The subject manifest is derived twice, at the start and at the end, and the
198 two are compared.
199
200## Boundary
201
202Validate emits no next action, repair, retry, replan, or delivery state (full
203list in the boundaries reference); ledger availability cannot change a
204verdict's validity.