SF
STS Forge

/validate

Self-validating loop that spawns parallel verification agents until pass criteria are met.

An autonomous validation loop. Given a task and pass criteria, it spawns parallel verification agents, collects findings, evaluates pass/fail, and iterates until converged.

Trigger phrases#

/validate, validate this, keep checking until done, loop until confident, self-validate, or when you want iterative verification of any artifact: a spec, implementation plan, code analysis, or integration design.

Do NOT use for: one-shot reviews (use /review) or simple questions.

What it does#

/validate [description of what to validate]

You provide:

  1. What to validate: an artifact, plan, analysis, or work product
  2. Pass criteria: explicit criteria, or "until you're confident"
  3. Source material: files to read and verify against

If you do not provide explicit pass criteria, /validate derives them from the task type:

  • Spec/analysis verification: zero new findings, zero disputes, zero line drift
  • Implementation plans: all steps feasible, no missing dependencies, no conflicts
  • Integration work: all behaviors accounted for, no regressions, no gaps
  • Code analysis: all claims verified against source, no contradictions

The validation loop#

Phase 0: Setup#

Creates a session directory at Docs/_working/sessions/validate-<topic>/ and initializes loop-state.json to track iteration history.

Phase 1: Agent allocation#

Decides how many agents to spawn (2–5 per iteration) and what each agent verifies:

Artifact type Agent strategy
Spec/analysis Split claims into groups, verify each in parallel
Integration plan One agent per system being integrated
Code analysis One agent per source file or function group
General Divide by aspect (correctness, completeness, consistency)

Phase 2: Spawn and collect#

All agents run in parallel. Each agent gets a specific verification scope, the source material to read, and a finding ID range to prevent collisions.

Phase 3: Evaluate#

Counts across agent results:

  • New findings: previously undiscovered issues or gaps
  • Disputes: contradictions of prior iteration's confirmed claims
  • Corrections: minor adjustments to prior claims
  • Drift: cited references that no longer match

If all pass criteria are met: loop terminates with PASS. If any criterion fails: another iteration begins with updated focus areas.

Phase 4: Iterate or terminate#

Each subsequent iteration prioritizes verifying the previous iteration's findings and uses fewer agents as scope narrows. The loop terminates when:

  • All pass criteria are satisfied (PASS)
  • 3+ consecutive iterations produce only marginal or out-of-scope findings (CONDITIONAL PASS)
  • 7 iterations complete without convergence (hard cap. CONDITIONAL PASS with explanation)

Typical convergence#

  • Iteration 1: High finding count (initial broad scan)
  • Iteration 2: Moderate (verification and new areas)
  • Iteration 3: Low (targeted verification)
  • Iteration 4+: Near-zero or out-of-scope only

If iteration 1 produces more than 20 findings, expect 3–5 iterations total. If iteration 1 produces fewer than 10, expect 2–3 iterations.

Final report#

## Validation Complete

**Status**: PASS | CONDITIONAL PASS
**Iterations**: N
**Total findings**: X
**Disputes raised/resolved**: Y/Y

### Iteration History
| Version | Findings | Disputes | Status |

### Coverage
[What was verified and to what depth]

### Remaining Gaps (if CONDITIONAL PASS)
[Out-of-scope or marginal items not resolved]

When to use /validate#

/validate is most useful for:

  • Verifying that an implementation plan covers all edge cases before starting code
  • Checking a spec against the actual source code for accuracy
  • Confirming an integration design accounts for all system interactions
  • Any situation where a single review pass might miss something and you want independent parallel perspectives

For a single pass code review before VCS submission, use /review instead.