> ## Documentation Index > Fetch the complete documentation index at: https://synthetiq.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # PRD overview > Plain-language requirements where every claim is backed by a runnable test 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](/docs/platform-docs/app-framework/prd/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: | Entry type | What it verifies | How | | ---------------------------------------------------------------------- | ------------------------------- | ----------------------------------------------------------------------------- | | [Feature](/docs/platform-docs/app-framework/prd/feature-tests) | A user-visible flow, end to end | A browser test drives the real app and records a video | | [API access](/docs/platform-docs/app-framework/prd/access-verification) | A rule the backend enforces | Real requests against the running backend, asserting acceptance and rejection | | [Calculation](/docs/platform-docs/app-framework/prd/verifying-calculations) | A computed value is right | Known inputs through the app's real implementation, asserting exact outputs | 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](/docs/platform-docs/app-framework/prd/reviewing-results). ## In this section ### Reviewing and trusting a PRD Start here if you're reviewing an app. | Page | What it covers | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | [The trust model](/docs/platform-docs/app-framework/prd/trust-model) | The mechanisms that keep PRD claims honest | | [PRD structure](/docs/platform-docs/app-framework/prd/prd-structure) | `prd.json` anatomy: sections, entry types, and how they differ | | [What gets captured](/docs/platform-docs/app-framework/prd/capture-layers) | Videos, timelines, state snapshots, and service-call records | | [Reviewing results](/docs/platform-docs/app-framework/prd/reviewing-results) | How to verify an entry as a human, comments, and the Ask Agent flow | | [The PRD view in the desktop app](/docs/platform-docs/app-framework/prd/desktop-app) | Where PRDs live in Synthetiq, and how teams review and collaborate | | [Running and lifecycle](/docs/platform-docs/app-framework/prd/running-and-lifecycle) | How the suite runs, staleness, and what ships with the 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](/docs/platform-docs/app-framework/reference/prd). | Page | What it covers | | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | [Feature tests](/docs/platform-docs/app-framework/prd/feature-tests) | How hero tests work: steps, personas, seeding, multi-user scenarios | | [Verifying calculations](/docs/platform-docs/app-framework/prd/verifying-calculations) | Proving metrics, aggregations, and dashboard queries produce the right values | | [Services and workflows](/docs/platform-docs/app-framework/prd/services-and-workflows) | How service calls are stubbed, and how workflows execute in tests | | [Access verification](/docs/platform-docs/app-framework/prd/access-verification) | The access matrix, derived concerns, and needs-attention flags |