Tools · PRD Studio · Guided replay
One real PRD, replayed one step at a time: four lenses, four real gaps, nothing invented for the demo.
Start the replayThe panel · ten lenses
Sundial is a fictional consumer marketplace for booking local appointments: hairdressers, physiotherapists, driving instructors.
Here is a slice of its PRD. It reads fine. Most PRDs do.
Four excerpts from the PRD’s actual text, provider discovery through to deposit collection. Scroll to read all of it before the grill starts.
G-1 Fewer confirmed bookings end as a no-show. Measured by: percentage of confirmed bookings marked no-show at the appointment time.
G-3 Consumers trust the deposit process. Measured by: repeat booking rate within 90 days of a first booking. “Consumers who trust the deposit process go on to book again within 90 days.”
G-4 Providers find Sundial worth paying for. Measured by: average score on the in-app satisfaction survey shown after a provider’s tenth completed booking.
Deposit requirements vary hugely by trade. Driving instructors typically take no deposit at all, since a missed lesson costs them relatively little. Hairdressers commonly take a small fixed fee to hold a first-time booking. Physiotherapists and similar allied-health providers often charge a percentage of the session price, since a missed hour is a meaningful loss to a one-person practice. Whatever we build has to live with that variety.
Deposit percentage Platform (fixed: every booking requires a 20% deposit of the service price).
FB-2 The consumer browses a calendar of upcoming availability for the selected provider and taps an open slot to select it.
FB-5 The system blocks a provider’s calendar from holding two bookings against the same slot. Once a slot is confirmed for one consumer, any further attempt to assign that slot, from any path, is rejected with a named error identifying the existing booking.
FB-8 Where a consumer’s saved card is declined at the point of automatic deposit capture, the provider dashboard shows the consumer’s card number and expiry date so the provider can take payment by phone before the appointment.
Payment: all deposit collection is handled through Sundial’s PCI DSS-compliant payment processor; card details are tokenised at the point of capture and Sundial never stores or displays raw card numbers.
QA
Can every behaviour be verified?
“Consumers who trust the deposit process go on to book again within 90 days.”
G-3's evidence statement just restates its measurement: consumers trust the process because they book again, and they book again because they trust the process. What observable signal, distinct from repeat booking itself, tells us trust caused the repeat rather than habit, convenience, or having no other provider nearby?
Platform Architect
Is the capability-versus-configuration boundary drawn right?
“Whatever we build has to live with that variety” against “every booking requires a 20% deposit”.
Section 2 says deposit requirements vary hugely by trade, some providers take none at all, and whatever we build has to live with that variety, but section 6 fixes a single 20% deposit at the platform layer for every booking. Is the deposit rule platform or configuration? As drawn, a driving instructor who wants to take no deposit cannot, which contradicts the market section 2 just described.
Engineer
Could I build this without guessing?
“Once a slot is confirmed for one consumer, any further attempt to assign that slot… is rejected.”
FB-5 only blocks a second booking once the first is already confirmed. Two consumers viewing the same provider’s calendar tap the same open slot within moments of each other, before either payment completes. Which one wins, and does the other find out before entering their card details, or only after their payment fails?
Security & Compliance
What is undefined about data sensitivity, audit and accountability?
“Never stores or displays raw card numbers” against “the provider dashboard shows the consumer’s card number”.
Section 7 promises card details are tokenised and never displayed, but FB-8's manual capture fallback has the provider dashboard show the consumer's card number and expiry. Which is true: does Sundial ever display a raw card number to a provider, and if FB-8 stands, has the tokenisation guarantee in section 7 just been quietly broken?
| ID | Gap class | Owner |
|---|---|---|
| D-1 | UNMEASURABLE | QA |
| D-4 | CONTRADICTS | Platform Architect |
| D-8 | EDGE-CASE | Engineer |
| D-5 | CONTRADICTS | Security & Compliance |
NOT CONVERGED
4 of 4 lenses opened a gap on first read.
Shortest path: fix G-3’s measurement, decide platform or configuration for the deposit, add a slot hold across checkout, and settle which of section 5 or section 7 is wrong.
This document looked done. Four lenses found the places it was not.
Open source
The method is open source: the personas, the prompts, the eval suite itself.
View the repository →Public evidence
The full evidence base behind these catch rates is public, not a claim to take on trust.
Read BASELINES.md →Working session
Digital Illumination runs this as a working session against your own PRD, not only a replay of someone else’s.
Talk to us →