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

# What "verified" means

> Promises made at plan time, checked against the running app, with receipts you can read — and the honest limits of what was checked.

When Creator says something is verified, it means something specific: **a promise
was written down before the code existed, and a check ran against your live app
to see whether the promise holds.** Not "the agent says it's done" — the agent
saying a story is done is exactly the claim verification exists to replace.

## Promises come first

At plan time, the build writes its promises — concrete, checkable sentences
about what the finished app will do ("visitors can submit the form and the
entry persists", "signing in with a wrong password is rejected"). You see them
during [plan review](/building/plan-review), before anything is built. Those
same sentences follow the build all the way to publish: what you approved is
what gets checked, in your words, not reworded afterward.

## What runs

As each story finishes, checks run against the real, running app — not against
the code in the abstract:

* **A production build.** The app must actually compile and build for
  production. A build failure stops the agent and gets fixed before anything
  else is claimed.
* **Behavioral checks.** Real requests against the live preview: every
  capability a story uses — its database, its sign-in, its webhooks — is
  actually exercised before the story can close. A story that never touched
  the thing it claims to use doesn't pass.
* **Wiring checks.** A capability the code imports but never actually calls is
  flagged — "it's in the code" isn't "it works."

Some promises can't be judged by a machine — "the dashboard looks right on a
phone" is a human call. Those are routed to you instead of being quietly marked
green; see [Your verdicts](/verification/your-verdicts).

## A grade, not a gate

Two different moments, two different rules:

* **While building**, a story can't be closed as done until its checks have
  run. If checks keep failing, the story is flagged as stuck rather than waved
  through.
* **At publish time**, verification is a **grade, not a gate**. The
  [publish screen](/shipping/publish) shows you exactly what held, what did not,
  and what was never checked — and then the decision is yours. Shipping with a
  known gap is a legitimate choice; the product's job is to make sure it's
  never an accident.

## Reading the numbers honestly

Verification reports are deliberately conservative:

* **"Confirmed N of M"** counts promises, and the list and the count come from
  the same record — they can't disagree.
* **"Couldn't confirm" is not "didn't work."** One means a check tried and came
  back unclear; the other means the check ran and the promise failed. They are
  always shown separately.
* A confirmed promise can still carry **clause gaps** — parts of the sentence
  no check actually exercised. When that's true, it's said, right there.
* If a run couldn't finish at all, the report says *the checks could not
  finish* — it never presents a broken run as a verdict about your app.

## Where to look

* The **[Proof tab](/verification/proof-tab)** — every promise, its stamp, and
  the actual request transcript that earned it.
* The **[Tests tab](/verification/tests-tab)** — the checks themselves, re-runnable
  whenever you want.
* The **[publish ledger](/shipping/publish)** — the same record, at the moment
  it decides something.