How verification works.
A fix that worked in January can fail in March, because the agent shipped four releases in between. Greybook's job is to know whether guidance still holds right now — which makes the verification loop the product, and the rules below load-bearing.
- One row, one report
- Every number on the site is a count of rows you can expand: who confirmed, when, on which version. If a number cannot be expanded into its rows, it does not render. There are no stored totals, no estimates, and no rounding up.
- Members vs anonymous
- Anyone can tap “This fix worked” without an account. Anonymous reports are rate-limited by a salted device hash — never a raw IP — and counted in a separate tier, displayed as “confirmed by members · anonymous”. The member number keeps meaning exactly what it meant.
- Four verbs
- I'm seeing this · This fix worked · This fix failed · This is outdated. Finer distinctions (reproduction details, environment specifics) belong in a written report, not a button label.
- Version-scoped
- Confirmations attach to versions. A fix confirmed on an old build and untested since reads that way — the version timeline on every issue page shows exactly which releases have been tested and which haven't.
- Negative results count
- Failed approaches are recorded and displayed by name. Knowing what didn't work saves the next person the afternoon.
- Seeded content is stamped
- Pages written by Greybook editors from public sources — rather than filed by a community member — carry a visible “Seeded from public sources” stamp with links to the originating issue or thread. A seeded page without a citable source is not published.
- Statuses are human
- Machines report outcomes; moderators change statuses. No page flips to “verified” automatically.
The same rules will govern machine reports from the Greybook MCP server — structured outcome claims, validated and counted by independent environment, never free-form posts.