Skip to main content
Machine verification proves the app does what the tests say. In practice tests are green when they reach you, because failures feed back to the agent during the build, so reviewing is about confirming the green means what you intended. For feature entries that comes down to three things:
  1. The entry’s language. The title and behavior text are the claim. Is this the requirement you meant?
  2. The video. The recording shows what the app actually does. Is it what you wanted?
  3. The acceptance criteria. Each is bound to a real assertion. Are these the right criteria, and is anything missing?
API and data-access entries need less. Their checks are derived from the contract and cross-checked against the code, so the review that remains is confirming intent: the needs-attention flags and the business rules. The PRD view is built to make all of this quick, and to route what you find back to the agent that builds the app.

​
Reading the header

The PRD header rolls every entry into four counts:
  • Current — passing, with up-to-date evidence.
  • Needs re-recording — the code changed since this evidence was captured, or the entry has never run. See Running and lifecycle.
  • Failing — the test is red. The entry’s drawer shows exactly where it stopped.
  • Need attention — a derived review flag on a non-failing entry (an over-permissive endpoint) waiting for your review. See Access verification.
A reviewed PRD is all current, nothing failing, and every attention flag reviewed.

​
Verifying a feature entry

Open the entry’s drawer and work through the evidence, cheapest first:
  1. Watch the hero video once. Does the flow do what you meant? Each step tells you who’s acting and with what permissions, and its label tells you what it claims to do.
  2. Read the timeline. Every assertion in plain language with its ✓. This is where you check the claims themselves: is “Ada does NOT see Ben’s task” actually asserted, or just implied?
  3. Skim Setup data and End state data. Did the flow start from meaningful data (both sides of any visibility boundary seeded, not an empty database), and did it end with the database in the expected state?
  4. Read Service calls (what the app sent). The exact payloads that would have left the app. For anything involving an LLM or messaging, confirm the right data, and only the right data, was sent.
For a feature with calculation children, the video covers the wiring and the children carry the cases: read each ✓ row as a claim (“five or more completions caps the score at 100”), then check the “App code calls” section, which shows for each check the real call it ran against (productivityScore(9) → 100). Ask whether those are the cases that matter, and whether any are missing. You don’t need every layer every time: watch the video once, then read only what the entry calls for. When something looks off, the layers narrow it down: a wrong number on the right screen points to Setup data and the calculation rows; a correct result with a questionable side-effect points to the service calls.

​
Verifying an access entry

Access entries have no video, because nothing visual happened. You read the generated Who can do this / How access is verified prose, then the scenario list: each boundary as a plain-language row with its transcript of real calls (“Ada lists her tasks” → her rows; “Someone who isn’t signed in is denied” → rejected). Resolve each need attention flag. The flag means the code permits something broad, such as any signed-in user reading every row. If that’s intended, confirm it and move on. If it isn’t, send it back to be locked down.

​
Feedback that reaches the agent

Anything you notice attaches to where you noticed it: leave a threaded comment on the item (“this should say overdue, not late”, “why does the summary include archived tasks?”), or use the drawer’s Ask Agent and Fix it shortcuts to hand the item straight to the appWriter agent. Either way the agent receives a pointer to the exact PRD item plus your feedback, makes the change (to the app, the PRD, or the tests, whichever is actually wrong), and reports back with a passing build and the evidence re-captured. This keeps review in the language of what the app should do: you review evidence rather than code, and point at the requirement rather than the file. The comment threads, agent shortcuts, and collaboration mechanics are covered in The PRD view in the desktop app.