Verification

Verification is the mechanism that proves a task is actually done — not “I think it works,” but “these commands exited 0.” Jig enforces a strict separation between the executor (the agent doing the work) and the verifier (the automated checks that confirm it).

The principle: no self-assessment

An AI agent that writes code cannot reliably assess whether that code is correct. Jig solves this by making verification external and mechanical:

1. The task defines verification commands and structured acceptance criteria before work begins.
2. The agent implements the changes.
3. A separate verification pass runs the commands and evaluates the criteria.
4. The task only reaches passed status if every gate succeeds.

The agent cannot skip, modify, or override verification. This is what makes autonomous execution trustworthy.

Verification gates

Each task includes a verification array of commands that must exit with code 0:

verification:
  - command: "bun run typecheck"
    proves: "No TypeScript errors introduced"
  - command: "bun test src/auth"
    proves: "Auth client behaves correctly"

At least one command should prove behavioral correctness, not just compilation. A task with only bun run typecheck is weakly verified — add a test or integration check.

Verification commands must be idempotent: running them twice produces the same result.

Structured acceptance criteria

Beyond verification commands, tasks can have structured acceptance criteria that are mechanically graded. Each criterion specifies a subject, property, expected value, and method for checking. See Acceptance Criteria for the full format.

Run jig test <task> to execute all structured criteria for a task.

The jig verify command

After a task’s work is complete, run verification:

jig verify <spec> <task>

This runs all verification commands defined on the task. If every command exits 0, the task moves toward local-verified status.

Environment-specific verification

Criteria can be scoped to different environments:

Environment	When it runs	What it checks
local	During development	Typecheck, unit tests, file existence, build
staging	After staging deploy	Playwright browser tests, API integration, E2E
production	After production deploy	Health checks, smoke tests, migration verification

Run environment-specific checks with flags:

# Local criteria only (default)
jig test <task>

# Staging criteria only
jig test <task> --staging

# Production criteria only
jig test <task> --production

# All environments
jig test <task> --all

# Batch all eligible tasks' staging criteria
jig test --staging --wave

A task is local-verified when local criteria pass. It reaches passed only when production criteria also pass (if any are defined).

The deployment pipeline

Verification integrates with the deployment pipeline:

1. Local — develop and verify locally (jig test <task>)
2. Staging — deploy to staging, run staging criteria (jig test --staging --wave)
3. Production — promote to production, run production criteria (jig promote)

Never deploy directly to production. All changes go through staging first.

CLI commands

See CLI Reference for full details on verify, test, deploy, and promote.