Skip to main content
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, 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.

​
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 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 — every promise, its stamp, and the actual request transcript that earned it.
  • The Tests tab — the checks themselves, re-runnable whenever you want.
  • The publish ledger — the same record, at the moment it decides something.