Validate Inference (before acting on it)
Overview
The failure mode this skill interrupts: an assistant infers a premise (most
commonly "nothing changed since the prior X, so skip / proceed"), acts on the
inference, and the action propagates a wrong premise into downstream work. By the
time a later check catches it, the cascade has touched multiple artefacts, and the
rework costs orders of magnitude more than the single tool call that would have
validated the premise at its source.
An inferred premise is a claim about state that the next action depends on and
that has not been directly observed in the current turn. The trigger surface is
textual and catchable in your own draft: clauses of the form "since / because /
given / per / based on X, [action]" where X has not been verified this turn. The
canonical rule (validate-inference-before-action)
states the discipline; this skill is its workflow wrapper for the moment the
trigger fires.
When to Use
- A draft or plan contains "since / because / given / per / based on / following /
according to" followed by a state claim not observed this turn.
- About to SKIP a step (a subagent, a test, a gate, a review) on the grounds that a
prior run covered it or that nothing relevant changed.
- About to declare a fix complete because the named occurrence is fixed (the
parallel-occurrence inference).
- About to reuse a prior approval, a prior file read, or a prior tool result as if
it were current state.
- NOT for ambiguity about what the requestor wants: that is decision doubt, and the
clarify-before-acting rule's
question protocol governs it instead.
Process
- Name the inference. Stop at the trigger clause and state X precisely, in one
sentence. If X cannot be named precisely, the premise is too vague to act on;
refine it before continuing.
- Pick the cheapest concrete validation. One or two tool calls almost always
suffice:
git status / git diff for "what changed"; a grep for "are there
parallel occurrences"; a file re-read for "what does it say now"; a status call
for "what is the current state"; a re-run for "does the check still pass".
- Run it and read the result. The validation must be an observation, not a
second inference ("I assume X because last time Y" does not validate anything).
- Act on the validated observation. If the validation confirms X, proceed,
and carry the evidence into any record the action produces. If it refutes X,
REPLAN from the observed state; do not partially adjust the planned action.
- Record the validation where the workflow keeps records. A structured cycle
(a sweep, an audit, a review) records what was validated alongside the action,
so a skipped step can never be reconstructed as an unexplained silence.
Red Flags
- "The prior run covered this scope" used to skip anything, without a diff or
status read taken this turn.
- "Only a comment changed, so the tests will pass" and its relatives: behaviour
claims inferred from change-size intuitions.
- Fixing the cited instance and declaring the class fixed without a project-wide
search for parallel occurrences.
- A validation that is itself an inference, or a validation run AFTER the action
it was supposed to gate.
- Treating a screenshot, quote, or tool result from an earlier turn as current
state.
- Skipping the validation because the action feels reversible: reversible actions
still propagate wrong premises into downstream work before anyone reverses them.
Verification
The skill's invocation is complete when:
- Every trigger clause in the draft or plan names a premise that is either
observed this turn (cite the observation) or validated by a tool call whose
result is read before the dependent action runs.
- A refuted premise led to a replan from the observed state, not a patch of the
original plan.
- Any structured record the workflow produces carries the validation beside the
action it gated.
Common Rationalizations
| Rationalization |
Reality |
| "The validation costs a tool call; I am confident." |
The cost is seconds and bounded; a wrong premise's cascade cost is unbounded. Confidence is not an observation. |
| "I checked this earlier in the session." |
State drifts between turns. The premise must be current-turn observed or re-validated. |
| "It is faster to just do the action and see." |
The rule's only carve-out is the collapse case: the action is fully reversible AND the validation would cost about as much as the action itself, so the action is its own observation. Anything broader ("it is safe", "it feels reversible") is the failure mode the rule names; the red flag above applies. |
| "The skip saves an expensive subagent." |
A skipped reviewer whose scope did change is the canonical cascade: the saved dispatch returns as multiple follow-up fixes. |
See Also
- Canonical rule
validate-inference-before-action:
the discipline, the cascade worked example, the anti-patterns, and the
exception protocol this skill wraps.
- Canonical rule
evidence-grounded-completion:
the assertion-side counterpart (claims need observations; this skill covers
actions needing validated premises).
- Sibling skill
validation-sweep: its dispatch
declarations are the recorded form of step 5 in a sweep context.
- Sibling skill
surface-instruction-concern:
the instruction-intake counterpart; its stale-state check is this discipline
applied to what an instruction assumes.
1---2name: validate-inference3description: Validates an inferred premise with a concrete observation before an action depends on it. Use when a draft or plan contains "since / because / given X, do Y" where X is a state claim not observed this turn, when about to skip a step because a prior run covered it, when declaring a fix complete because the named occurrence is fixed, or when acting on remembered rather than re-read state. Walks the discipline (name the inference, cost the validation, validate with a tool call, act on the observation) plus its recording step, so a wrong premise is caught by one cheap read instead of cascading into every downstream action built on it.4---56# Validate Inference (before acting on it)78## Overview910The failure mode this skill interrupts: an assistant infers a premise (most11commonly "nothing changed since the prior X, so skip / proceed"), acts on the12inference, and the action propagates a wrong premise into downstream work. By the13time a later check catches it, the cascade has touched multiple artefacts, and the14rework costs orders of magnitude more than the single tool call that would have15validated the premise at its source.1617An inferred premise is a claim about state that the next action depends on and18that has not been directly observed in the current turn. The trigger surface is19textual and catchable in your own draft: clauses of the form "since / because /20given / per / based on X, [action]" where X has not been verified this turn. The21canonical rule ([`validate-inference-before-action`](../../governance/validate-inference-before-action.md))22states the discipline; this skill is its workflow wrapper for the moment the23trigger fires.2425## When to Use2627- A draft or plan contains "since / because / given / per / based on / following /28 according to" followed by a state claim not observed this turn.29- About to SKIP a step (a subagent, a test, a gate, a review) on the grounds that a30 prior run covered it or that nothing relevant changed.31- About to declare a fix complete because the named occurrence is fixed (the32 parallel-occurrence inference).33- About to reuse a prior approval, a prior file read, or a prior tool result as if34 it were current state.35- NOT for ambiguity about what the requestor wants: that is decision doubt, and the36 [`clarify-before-acting`](../../governance/clarify-before-acting.md) rule's37 question protocol governs it instead.3839## Process40411. **Name the inference.** Stop at the trigger clause and state X precisely, in one42 sentence. If X cannot be named precisely, the premise is too vague to act on;43 refine it before continuing.442. **Pick the cheapest concrete validation.** One or two tool calls almost always45 suffice: `git status` / `git diff` for "what changed"; a grep for "are there46 parallel occurrences"; a file re-read for "what does it say now"; a status call47 for "what is the current state"; a re-run for "does the check still pass".483. **Run it and read the result.** The validation must be an observation, not a49 second inference ("I assume X because last time Y" does not validate anything).504. **Act on the validated observation.** If the validation confirms X, proceed,51 and carry the evidence into any record the action produces. If it refutes X,52 REPLAN from the observed state; do not partially adjust the planned action.535. **Record the validation where the workflow keeps records.** A structured cycle54 (a sweep, an audit, a review) records what was validated alongside the action,55 so a skipped step can never be reconstructed as an unexplained silence.5657## Red Flags5859- "The prior run covered this scope" used to skip anything, without a diff or60 status read taken this turn.61- "Only a comment changed, so the tests will pass" and its relatives: behaviour62 claims inferred from change-size intuitions.63- Fixing the cited instance and declaring the class fixed without a project-wide64 search for parallel occurrences.65- A validation that is itself an inference, or a validation run AFTER the action66 it was supposed to gate.67- Treating a screenshot, quote, or tool result from an earlier turn as current68 state.69- Skipping the validation because the action feels reversible: reversible actions70 still propagate wrong premises into downstream work before anyone reverses them.7172## Verification7374The skill's invocation is complete when:7576- Every trigger clause in the draft or plan names a premise that is either77 observed this turn (cite the observation) or validated by a tool call whose78 result is read before the dependent action runs.79- A refuted premise led to a replan from the observed state, not a patch of the80 original plan.81- Any structured record the workflow produces carries the validation beside the82 action it gated.8384## Common Rationalizations8586| Rationalization | Reality |87|---|---|88| "The validation costs a tool call; I am confident." | The cost is seconds and bounded; a wrong premise's cascade cost is unbounded. Confidence is not an observation. |89| "I checked this earlier in the session." | State drifts between turns. The premise must be current-turn observed or re-validated. |90| "It is faster to just do the action and see." | The rule's only carve-out is the collapse case: the action is fully reversible AND the validation would cost about as much as the action itself, so the action is its own observation. Anything broader ("it is safe", "it feels reversible") is the failure mode the rule names; the red flag above applies. |91| "The skip saves an expensive subagent." | A skipped reviewer whose scope did change is the canonical cascade: the saved dispatch returns as multiple follow-up fixes. |9293## See Also9495- Canonical rule [`validate-inference-before-action`](../../governance/validate-inference-before-action.md):96 the discipline, the cascade worked example, the anti-patterns, and the97 exception protocol this skill wraps.98- Canonical rule [`evidence-grounded-completion`](../../governance/evidence-grounded-completion.md):99 the assertion-side counterpart (claims need observations; this skill covers100 actions needing validated premises).101- Sibling skill [`validation-sweep`](../validation-sweep/SKILL.md): its dispatch102 declarations are the recorded form of step 5 in a sweep context.103- Sibling skill [`surface-instruction-concern`](../surface-instruction-concern/SKILL.md):104 the instruction-intake counterpart; its stale-state check is this discipline105 applied to what an instruction assumes.
jposluns