> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oktolabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Validation gates

> The Pulse gates that keep specs, sprints, tests, and cards evidence-based.

# Validation gates

You can use validation gates to keep AI-assisted work from advancing on confidence alone. Pulse separates writing, implementation, and validation so one agent does not silently mark its own work complete.

## Why gates exist

A gate makes a state transition depend on evidence. Gates are especially important with agents because a fluent answer is not proof of completeness, test coverage, or alignment with a spec.

## Gate 1: Spec evaluation

Spec evaluation is the qualitative review. It checks whether a spec is complete, assertive, low-ambiguity, and ready for a formal validation pass. The common threshold is score `>= 80`.

## Gate 2: Spec validation

Spec validation uses `okto_pulse_submit_spec_validation` to move an approved spec into `validated`. This is the content evidence gate. A passed validation locks the spec until a backward transition clears the active validation pointer.

## Gate 3: Task validation

Task validation uses `okto_pulse_submit_task_validation` while the card is in `validation`. It records reviewer confidence, completeness, drift, threshold violations, and justification. A recommendation to approve can still fail when thresholds are violated.

## Gate 4: Test evidence

Pulse treats test evidence as structured data. Test status updates should include a file path, test function, last run time, and output snippet or run ID. Sprint close checks passed scenarios rather than trusting labels.

## Bug-first gate

Bug cards should not enter implementation without a failing scenario that proves the defect. That scenario becomes the baseline for the fix and the future regression check.

## Sprint evaluation

Sprint evaluation is a qualitative closeout. It is useful for retrospectives and delivery quality, but it is not a substitute for spec validation or task validation.

## The Validator preset

Validator is the intended exclusive gate-holder. It can submit spec validation, sprint evaluation, and task validation, while Executor and Spec roles read validation records but cannot submit them.

## Backward transitions

Backward transitions keep recovery explicit:

* `spec.move.approved_to_draft` allows edits after approval.
* `spec.move.validated_to_draft` unlocks a validated spec and clears the active lock.
* `card.move.validation_to_not_started` sends failed work back for rework.

## Related pages

* [Spec](/concepts/spec)
* [Cards](/concepts/card)
* [Built-in presets](/permissions/presets)
* [Validation tools](/reference/mcp/validation)