Scenario Status

A Scenario carries two independent status axes, never one:

• Lifecycle — is this a spec the team stands behind? Draft, Published, or Deprecated.
• Verification — has reality been checked against it, and what happened? Not attempted, Fit, or Gap.

Both are app-only overlays on the Scenario record. Neither is part of the Scenario’s content, and neither is evidence. And neither gates the other: a Draft Scenario can already be a fit, and a Published one can sit at not attempted indefinitely.

Lifecycle

• Draft — still being worked up. This is where every Scenario starts, human-written or AI-proposed alike. Draft is a status, not a separate staged object: a Draft Scenario is a real, immediately queryable row the moment it exists, with no confirmation step in front of it.
• Published — the team stands behind this Scenario as written. There is no gate and nothing to confirm; publishing says nothing about whether anyone has checked it.
• Deprecated — a retired fact. It stays queryable, and deliberately stays both editable and verifiable — retiring a Scenario doesn’t freeze it.

Retirement is asymmetric. A Draft can be deleted: it stops appearing everywhere, and can be restored from Deleted scenarios in Project settings — its path, evidence and verification history are kept, and it comes back as a draft. A Published Scenario can never be deleted — something may already cite it — so it is moved to Deprecated instead.

Verification

• Not attempted — never checked against reality. The default, and never a judgement about the Scenario.
• Fit — reality was checked and it matched the Scenario as written.
• Gap — reality was checked and it diverged. A Gap Scenario carries a drift note: a plain text field standing outside the Scenario’s own path and evidence, describing how reality currently differs.

There is no separate “bug” object — a gap is how a bug shows up, attached to the Scenario whose described behavior no longer holds. A gap states only the fact that the spec and reality diverged, in either direction — it doesn’t assert which one is at fault.

Verification passes

Evidence for a verification result does not live on the Scenario row. It belongs to a verification pass: one attempt at checking a Scenario against reality, recorded on the Scenario’s own Verify page.

• A pass walks the Scenario’s path, and each finding attaches to the step it is about, so what was found sits next to the claim it checked.
• Every part of a pass is optional — full evidence, partial evidence, or none at all. A step that was looked at but couldn’t be called is a real finding, distinct from a step that was never checked.
• A Scenario can have at most one open pass at a time, and accumulates passes over time as a history.
• Closing a pass with an outcome is what moves the Scenario’s verification status to Fit or Gap. Its lifecycle status is untouched. A pass can also be abandoned without ruling either way.

Fit and gap require the callees to be a fit

A Scenario’s verification can only be set to Fit or Gap once everything it structurally depends on — its nested children, its chain successors, and any cross-cutting Features it uses — is itself a fit. If a callee isn’t, the status change is blocked and the app lists which one is holding it up. Lifecycle changes have no such gate.

Verify all and rollups

Recording a fit can cascade: Verify all (mass verify) sets a Scenario and its nested descendants to a fit in one action, with chain successors as individual opt-ins. It only ever records a fit — it never records a gap and never publishes anything, and cross-cutting Features count toward the callee check without ever being cascade targets.

A Scenario that became a fit this way records which ancestor drove the rollup, so it reads as part of that action rather than as an independent check.

Who changed a status, and how

Every status change is recorded with a change_source, so it is always clear who or what made the call:

• Manual — a person changed the status directly.
• Mass verify — the Verify all cascade.
• Automation — an unattended, recurring CI or webhook integration.
• MCP agent — an AI agent connected over MCP, acting once, in-session.
• API — an API key acting on its own authority through the REST API.

These are deliberately kept distinct. Automation, an MCP agent and an API key are all non-human, but automation runs unattended and recurringly while an MCP agent acts once, in a session, with a person watching — a trust distinction worth preserving rather than collapsing.

For the practical steps of changing status day to day, see Managing Status.