Verified against Perplexity Pro · 2026-08-08
Check a breaking or fast-moving story before sharing it, with a timestamp on every source
A live-event verification prompt built for genuinely fast-moving stories, requiring a publish timestamp on every source and an explicit split between what multiple outlets have confirmed and what is still single-sourced or unconfirmed, so an early report doesn't get treated as settled fact.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Check the current state of this fast-moving story before I share or act on it. Treat this as genuinely live — the situation may have facts still emerging or changing, and I need to know specifically what's confirmed versus what's still developing, not a single blended narrative. STORY / EVENT Reports of a major cloud provider outage affecting multiple regions WHAT I SAW AND WHERE A post on a social platform citing "reports from affected users," no official statement linked WHAT THIS IS FOR Deciding whether to post a public status update to our own customers about a possible dependency on this provider RULES - For every source, state its publish or last-updated timestamp, as precisely as available (date and time, not just date, if the story is developing within a single day) — a live story needs finer time resolution than a normal research question does. - Explicitly separate what multiple independent outlets are now reporting consistently from what still traces back to a single initial report, an unconfirmed account, or an official statement that hasn't yet been independently verified by other reporting. - If any major outlet has issued a correction, retraction, or update to their initial reporting on this story, surface that specifically — an early version of a fast-moving story being wrong or incomplete is common, not unusual, and a correction is important signal, not noise to filter out. - Note if the most recent information you can find is itself already some time old relative to how fast this story is moving — say explicitly how stale your most recent source is, since a "current" answer to a live story can go stale within hours. OUTPUT FORMAT 1. What is now confirmed by multiple independent sources, each with its timestamp. 2. What is still single-sourced, attributed to an unnamed source, or otherwise unconfirmed — clearly separated from the section above. 3. Any correction or retraction found, and what it changed. 4. A one-line note on how confident I should be treating this as settled right now, given how fast it's moving and how recent the best available information actually is. Do not synthesize the confirmed and unconfirmed sections into one smooth narrative — keep the distinction visible in the final output, not just in your own reasoning.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Fast-moving stories are the specific case where a search-grounded answer engine's biggest structural weakness — no guaranteed freshness on any given result — matters most, because the gap between a story's initial, often-wrong first report and its later, corrected version can be a matter of hours, and a synthesis that doesn't force fine-grained timestamps onto every source has no way to signal to the reader which version of the story they're actually looking at. Requiring a confirmed-versus-unconfirmed split, rather than one blended narrative, directly targets the actual mechanism by which breaking-news misinformation spreads: an early single-sourced report gets repeated by outlet after outlet within the first hour, and a naive citation count at that stage would read as strong corroboration when it's really the same unverified claim propagating faster than anyone has had time to check it — separating the two explicitly forces the model to notice whether later, independent reporting has actually confirmed the early claim or just repeated it. Explicitly asking for corrections and retractions, framed as expected and useful rather than as noise, matters because a model doing a single retrieval pass on a live story will often just find whatever is most recently indexed without checking whether an earlier claim from the same story has since been walked back — and for genuinely volatile stories, the correction is frequently more informative than the original claim, since it tells you specifically what the initial version got wrong. And the explicit staleness check on the model's own most recent source — the model naming exactly how old its best information is, relative to how fast the situation is moving — matters because a well-organized, timestamped-looking answer can still be built entirely from sources that are already outdated by the time it's assembled, and that risk is invisible to the reader unless the model states its own information's age directly rather than just formatting it confidently.
Verified against
Perplexity Pro Sonar Pro · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against Perplexity Pro Sonar Pro search.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
