Three weeks ago I built a booking widget for a friend who runs a yoga studio — a chat, a plan I approved fast because I was in the middle of something else, a run, and then a version card with a green checkmark I glanced at and moved on from. Tuesday she texted asking if she could point a second studio's site at the same build. Before I said yes I went back to look at what "verified" had actually meant three weeks earlier, and that's when I actually read one of these records for the first time instead of just trusting the checkmark.
It lives right on the version card, next to the preview and the code actions — same place you'd go to redeploy or roll back. First thing I noticed: it's scoped to that one version, not to the whole conversation. I'd iterated on this build five times chasing a broken date picker, and I half expected the record to tell me the story of the whole back-and-forth. It doesn't. Version 4's record only describes version 4. It has no memory that version 2 shipped with a login form that silently failed, and it won't tell me version 5 quietly fixed something version 3 broke. Each record is a snapshot, not a diff and not a changelog — if I want the history of what changed release to release, that's a different view entirely. This one only answers "is this one okay."
Scrolling down, the record breaks into six rows:
| 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 |
All six were green, and my first instinct was the same wrong instinct I'd guess most people have: security passed, so it's secure; accessibility passed, so it's accessible. Neither of those readings survives contact with what the checks actually do. The security pass means the surface-level stuff — string concatenation into a query, an API key sitting exposed in the client bundle, an eval on something a user typed — didn't show up. It's not a day with a penetration tester. My friend's studio isn't taking payments through this widget, just names and time slots, so the floor was fine for her. If it had been a checkout flow I'd have wanted more than a floor.
Accessibility is the one that actually made me stop and look something up, because "axe pass" sounds exhaustive and isn't. Axe — the automated engine running under the hood — reliably catches something like a third to half of WCAG success criteria: missing alt text, bad contrast ratios, unlabeled form fields, obvious ARIA misuse. It can't tell you whether the custom date-picker dropdown I'd asked for is usable with a screen reader, whether tabbing through the multi-step booking flow lands focus somewhere sane, or whether the "confirmed" vs. "pending" status I'd colored green and yellow is a problem for someone with red-green color blindness. Those need a person going through the build with the tools disabled users actually rely on. Axe is real signal, not nothing — it's the spelling-checker layer of accessibility, not the editor.
Conformance was the row I almost skipped past, because it sounds bureaucratic — "contains what the plan promised" — until I remembered that the plan I'd approved was written while I was distracted, and I genuinely couldn't recall if I'd asked for email confirmations or just SMS. This is the layer that checks the build against the plan, not against my actual intent, and it passed, which told me the build matched what I'd said yes to, not necessarily what I'd meant. I've heard of builds that were functionally solid and secure and still failed this layer because a feature got quietly dropped under time pressure. It's the layer that keeps a build honest to the conversation that produced it, even when the conversation itself was a little sloppy.
Below the six rows was a longer list, split into two buckets, and this is where I spent the most time. Must-fix items aren't things currently wrong with the build — they're receipts. One line read that the review layer had flagged a case where a date string got interpolated straight into a query, and it had already been patched before this version was marked complete. I wasn't looking at an open wound; I was looking at a scar. That distinction matters, because if you read a must-fix entry as a live warning you'll spend time worrying about something that's already closed.
The advisory list was longer, and it was mostly things I'd have said myself if I were reviewing a colleague's code without wanting to block the merge: "consider extracting the repeated slot-rendering block into a shared component," "this endpoint has no rate limiting, which is fine for an internal booking tool but worth reconsidering if it goes public." Nothing in that list was a defect. It was judgment calls a verifier made with only the plan and the code to go on, and for a yoga studio's internal scheduler, every one of those calls landed on the reasonable side. If my friend's studio had been a franchise with the widget embedded on fifty location pages, I'd have wanted to push back on the rate-limiting one — the classification depends on context the verifier can only guess at, and when a guess looks wrong to you, the right move is saying so in chat, not assuming the label is final.
What struck me, looking at a decent-sized advisory list next to a clean must-fix column, is that I'd almost read the length of it as bad news. It isn't. A build with zero advisory notes either got a narrow pass or got lucky; a build with a stack of "consider" items and nothing outstanding in must-fix is one that's actually been looked at carefully. The advisory column is what's supposed to be left over once the real problems are gone.
The other thing I made myself do, since this record was three weeks stale, was check which layers actually ran before trusting the verdicts at all. All six were present here, but I've since seen a build where accessibility was simply absent from the list rather than marked pass or fail — that's not the same as being skipped as unimportant, it's a sign the check didn't run for that particular site type or flag configuration, and reading absence as a quiet pass is exactly the mistake this format invites if you're skimming.
None of it told me whether the yoga studio's booking flow actually converts, whether people abandon it at the time-slot step, or whether the whole idea of a custom widget instead of just linking out to Calendly was the right call in the first place. Verification proves a build works as promised, not that the promise was the right one to make — those are separate questions, and I've watched builds sail through every layer clean and still flop with real users because "works correctly" and "solves the right problem" don't overlap as much as you'd hope. The half of this that actually answers the second question is the measurement loop, and the two are meant to be read together. A clean verification record on a feature nobody books through is still a feature nobody books through.
