We've had to issue a correction on a fast-moving AI story before, and reviewing what actually went wrong in that process taught us more about our own vulnerabilities than any story we got right ever could. The specifics of that story matter less here than the process failure behind it, which is worth being honest about.
What actually went wrong
The failure wasn't a fabricated source or a made-up quote - it was treating a single, confident-sounding source as sufficiently authoritative without pushing for the independent confirmation our own standard is supposed to require, because the story was moving fast and the source had been reliable before. Past reliability isn't the same as verification on a specific claim, and we let the former substitute for the latter under time pressure.
Why time pressure is the real culprit
Nearly every process failure we've reviewed traces back to the same root cause: a reasonable standard applied inconsistently under deadline pressure, not a standard that was wrong in the first place. This is a more uncomfortable finding than a story of outright deception, because it means the fix isn't a new rule - it's better discipline under exactly the conditions that make discipline hardest.
What changed afterward
We built an explicit pause step into our breaking-news workflow: before publishing anything based on a single source, someone other than the reporter has to confirm the sourcing standard was actually met, not just that the reporter believes it was. This adds friction, deliberately, at the exact point where speed pressure previously overrode judgment.
Why we're describing this publicly
A correction explains what was wrong. It rarely explains why, which is the part that actually helps readers calibrate how much to trust future corrections - or the absence of them.