Skip to main content
Every app can include a PRD: a product requirements document that describes what the app does in plain language, where every entry is bound to a real, runnable test. It’s a living document, not a write-once spec: each feature plays back as a recorded video of the real app, each API rule shows the requests that proved it, and each calculation shows the exact values it was checked against, all of it re-verified as the app changes. The PRD exists to answer the question every app owner eventually asks: how do I know it does what I want it to do? Instead of trusting a description, you watch the feature run, read the data it produced, and see every service call it made. When the code changes, results go stale until the tests re-run, so the document can’t drift from the app. These are not simply tests the AI writes and grades itself on. Much of the verification is derived from the code itself: access rules are read from the backend’s declared guards and cross-checked at build time, calculation tests are statically checked to compute their assertions from the app’s real implementation, and the plain-language descriptions of access are generated from what was verified, never written by hand. The trust model covers the full set of guarantees. The PRD also makes it safe to keep changing the app. The whole suite re-runs on every build, so the agent making a change finds out immediately when it breaks or alters a feature you already verified, and fixes it before the change reaches you. When you review your changes, the PRD shows a diff against your base version: which features are new, and which existing ones your changes touched, each with its evidence re-captured against the new code.

​
What’s in a PRD

The PRD lives in prd/prd.json and is organized into sections, one per functional area. Each section contains entries of three kinds: Every feature has exactly one hero test: the end-to-end story a reviewer can watch. Value permutations that would be tedious on video (boundary cases, rounding, empty states) nest under the feature as calculation children, one level deep.

​
The PRD view

Opening an app’s PRD shows every section and entry with its current status. Click into an entry and you get the full evidence for that requirement:
  • Video — the flow recorded in both light and dark themes, with a step timeline synced to playback
  • Steps — every action and assertion, green when it passed, red where it failed, gray if it never ran
  • Before and after data — snapshots of the database state the test started from and ended with
  • Service calls — everything the app sent across the service boundary, including calls made by workflows
The intent is watch once, read the rest: watch the hero video to see the feature work, then skim the assertions, data, and calls to confirm the details.

​
Reviewing in plain language

A PRD is presented in plain language, not in code. A reviewer sees “Rae can only see her own tasks” with a video of exactly that: Rae seeing only her own tasks and Bob seeing only his. Multi-user stories like this are ordinary in a PRD: a test seeds several users with different permissions and data, acts as each in turn, and the one recording proves what every one of them can and can’t see. For more depth, every video is backed by a synced timeline of each step, acceptance check, data snapshot, and service call. This is what enables a non-engineer to build an app with the agent and confirm it does what they intend: they review the PRD, and request any change through comments or the Ask Agent shortcut. See Reviewing results.

​
In this section

​
Reviewing and trusting a PRD

Start here if you’re reviewing an app.

​
How the tests are written and enforced

Reference for how entries are authored and gated. Tests are written by the agent; these pages are for anyone who wants to see what’s underneath. The exhaustive schema and harness reference is the PRD reference.