The Validate tab

Validate is where you check what your agents built and decide. It's organised by what needs you, not by what was built most recently: failing criteria and stories awaiting review come first. It's also where releases are closed, and where the project goes live.

Choose the releases

A row of chips across the top picks what Validate shows: All, each release by name, and Go live. Each chip says how many things in it need you.

• Tap a chip to see that release's page.
• Tap All to see what needs you across every release, then a card for each release.
• Choose Several… to tick more than one, then Done. On desktop you can also Shift-, Cmd- or Ctrl-click.

The choice is the same release filter Spec and Plan use. When you haven't picked one, Validate starts from the current release: the one a person made current, or else the first open release with stories.

A release's page

From the top:

1. The release: its name, which anyone who can edit the map can rename in place, and when and by whom it was closed.
2. The verdict: one line, such as "31 of 36 stories approved · 2 launch checks open. Seven need you." When everything is approved, it ends "Ready to close."
3. The stories, in three groups.
4. The decision: close or reopen the release.

Needs you

Stories you have to act on:

• A criterion failing. The card names the criteria that don't pass and what the agent reported. Choose Send back for rework, Approve anyway, or open the story.
• Awaiting your review. Dev complete and waiting for you. Open the story and decide on its Review tab.
• Blocked, or sent back and waiting for the fix.

Worth a look

Stories the agent says are built, but where part of the spec was never verified against the build. Choose Flag for rework, or Not a problem to clear it.

Everything else

Approved, being built, and not started yet.

Trust

Each built story carries a word saying how far its "done" can be trusted:

Word	Means
verified	Every must criterion has a passing result.
evidenced	Some results are in, but not every must criterion passes.
asserted	Marked done with no reported evidence.

A warning mark beside the word means there's something to read before you trust it: the agent's summary says something wasn't fixed, or its evidence mentions fake or hardcoded data. See Verification.

Approve one story

Open the story and go to Review. Read the verdict, then what the agent built. Choose Approve, or Request changes with a note saying what to fix; the story goes back to the agent with it. See The story page.

Approve many at once

When some stories have been fully proven by machine, Needs you offers a button such as Approve 12 fully verified, with a line naming what's left.

A story qualifies only if every criterion passed a machine check, with no caveats, its tests are newer than its last commit, and its pull request is linked and merged. How a story qualifies spells this out.

1. Choose the button. A sheet lists the qualifying stories, all ticked.
2. Untick any you'd rather read first.
3. Confirm.

The same check runs again as you confirm. A story that stopped qualifying in between is left out and named, never approved. Afterwards you have a few seconds to Undo.

Every other story needs reading, and says why, for example "No pull request is linked."

Close a release

Closing a release says it's finished. Releases never close themselves.

1. On the release's page, choose Close release.
2. If some stories aren't approved yet, they're listed. Choose Move them to the next release, or Leave them in this one.
3. Confirm with Close and the release's name.

A closed release can be reopened with Reopen release. The page keeps a history of every close and reopen, and how many open stories moved on.

Make current marks the release the team is working on now. Validate, the release filter and the agent tools start from it. Closing the current release moves Current on to the next open one.

Closing, reopening and approving are for the people who approve plans: you on a personal project; in a workspace, its owners, its admins and the members an admin has made approvers. See Workspaces and teams.

Go live

Every project ends with Go live, a release that always comes last. It can hold stories about launching, such as checking that payment works end to end. Its page also holds the launch checks:

Passing your spec means the build does what you asked. It does not mean it is safe to charge people for. These checks cover what the spec cannot.

• Blocking: checks that must be resolved before going live, such as data isolation between customers, a tested restore from backup, failure alerts reaching you, and a published privacy policy.
• Before you hand off: questions your agent would otherwise guess the answer to. Your answers ship with the spec: an agent reading it with get_context, or the INTENT.md that npx intentdocs sync writes, sees them under Going live — operational constraints.
• Before you scale — not blocking: checks that get harder once real data exists.

Each check says who resolves it. Agent check: copy a brief for your agent with Copy this check for your agent. Watched: IntentDocs looks for evidence in the project and you decide. Manual: only you can do it. A check that doesn't apply to your stack is struck through, with the reason. To resolve a check, paste your evidence and choose Save evidence & confirm.

While any blocking check is open, or any acceptance criterion isn't passing, the page says Going live is blocked and lists why. When it's clear, choose Mark shipped. To close the Go live release itself, choose Mark as live.