Every completed build carries its verification record — the receipts behind the word "verified". Most people never need to open it. This chapter is for when you do: before publishing something serious, after a fix round, or when you're deciding how much to trust a build you made three weeks ago.
Where it lives
On the build's version card, alongside the preview and code actions. The record is per-version — version 4's record describes version 4, not the conversation's history.
The layers, and what each verdict means
| Layer | A pass means |
|---|---|
| Functional / in-browser | The build ran in a real browser; interactions were exercised (games get played) |
| Code review | A read-only reviewer found no defects it could substantiate with a file and behavior |
| Security | No injection surfaces, leaked secrets, or unsafe patterns surfaced |
| Links & SEO | No broken links; metadata, robots and sitemap in order |
| Accessibility | The automated axe pass found no violations |
| Conformance | The build contains what the approved plan promised |
Must-fix vs advisory
Findings split into two classes, and the split is the point. Must-fix findings block completion — they went back into the fix loop, and the record shows what was caught and repaired; you're reading history. Advisory findings are judgment calls the verifiers deliberately left to you: stylistic observations, optional hardening, "consider" items. Advisory is not a euphemism for "broken" — anything broken was must-fix.
What a record can't tell you
Whether the product is a good idea, whether the copy persuades, whether your users want the feature — verification proves the build works as promised, not that the promise was right. The half of the platform that addresses the second question is the measurement loop.