A forensic report is not a summary of finished work. It’s a claim that has to survive someone trying to take it apart, and most reports aren’t built for that. A lot of what gets filed today is automated tool output with a cover letter attached: the examiner runs a parser, exports a spreadsheet, writes three sentences of narrative, and calls it analysis. That holds up fine until an opposing expert asks how the software actually reached its conclusion.

Three real cases show what happens when nobody asks that question early enough.

Case one: what happens when nobody checks the tool’s output

In the 2011 murder trial of Casey Anthony, a central piece of the state’s case was that the family’s computer had visited a website about chloroform 84 times. The number came from CacheBack, a browser-history parsing tool that the Orange County Sheriff’s Office used to analyze the Firefox history on the Anthony family computer.

It was wrong. The website, sci-spot.com, had been visited once. Firefox 2 stored its history in a database format nicknamed “Mork,” known for storing an inconsistent visit-count value across records, and eDiscovery Journal’s technical breakdown of the case concluded CacheBack pulled the count from the wrong adjacent record and returned 84 instead of 1. John Bradley, the developer who built CacheBack and testified for the prosecution, found the bug himself after his own testimony but before the jury reached a verdict, and told prosecutors right away, KSL.com reported. The jury was never told. Under cross-examination, Bradley had already conceded that the computer had two active user accounts and that there was, in his own words, no way to know who was at the keyboard: “there are limited things you can tell from this,” according to Fox News’s trial coverage. Defense attorney Cheney Mason later told ABA Journal that the failure to correct the record was “more than shame on them. It is outrageous.”

Anthony was acquitted of murder; jurors later said the digital evidence hadn’t convinced them either way. That’s arguably the more useful lesson here: even a dramatic, unverified number didn’t survive contact with a jury that wasn’t told to trust it blindly. The report should never have needed a jury’s skepticism to catch what the analyst’s own manual verification should have caught first.

The thing is, if your report states a tool’s output as fact without independently checking the underlying database, you’re not testifying about evidence. You’re testifying about someone else’s code, and you have no way to know if it’s right.

Case two: what happens when nobody rules out the machine itself

In October 2004, a classroom computer at Kelly Middle School in Norwich, Connecticut, displayed a stream of pornographic pop-up ads while substitute teacher Julie Amero was in the room. She was charged with risk of injury to a minor and convicted in January 2007, facing up to 40 years, per the Wikipedia case record.

The state’s forensic witness concluded that the images meant the user had “accessed” the sites, not that a background process had delivered them. That distinction mattered: The Register reported the classroom PC was running Windows 98 with an expired antivirus subscription, no anti-spyware software, no pop-up blocker, and a content filter that hadn’t been updated in months. Two of the domains involved, addynamics.com and adrevolver.com, were known adware and pop-up-ad networks, not sites anyone would deliberately browse to in a classroom, The Register’s follow-up analysis found. None of that made it into the original analysis.

In June 2007, Judge Hillary Strackbein set aside the conviction and ordered a new trial after the state itself acknowledged the original testimony about the computer had been “erroneous,” NBC News reported. There was no second trial; Amero pleaded guilty to a single misdemeanor of disorderly conduct in November 2008 and paid a $100 fine. Researchers Aaron Alva and Barbara Endicott-Popovsky later used the case as their central example in a paper arguing that law schools need to teach basic digital forensics, writing that the courtroom’s computer literacy had been “at the very low end of the spectrum”.

A file sitting in a browser cache tells you the machine did something. It doesn’t tell you a person chose to do it. Ruling out adware, malware, and background processes is part of the analysis, not an afterthought for the defense to raise.

Case three: what happens when everyone assumes the system is right

Between 1999 and 2015, the UK Post Office prosecuted more than 700 sub-postmasters for theft and false accounting based on shortfalls reported by Horizon, its in-branch accounting system built by Fujitsu; roughly 280 more were prosecuted by other bodies using the same data, bringing the total past 980, according to the House of Lords Library’s briefing on the scandal. For years, courts treated Horizon’s output the way UK law at the time presumed all computer evidence should be treated: as correct unless proven otherwise. Nobody with prosecutorial authority audited Fujitsu’s internal error logs.

That presumption collapsed when 555 sub-postmasters brought group litigation against the Post Office. In his 2019 Horizon Issues judgment, Mr Justice Fraser found that the system contained, in the judgment’s own words, “bugs, errors and defects” capable of producing exactly the discrepancies the Post Office had been prosecuting people over. The Criminal Cases Review Commission later called it “the most widespread miscarriage of justice” it had ever reviewed. As of the CCRC’s most recent figures, dozens of convictions have been referred back to the courts and the majority overturned, and the number is still growing.

A system being widely deployed, expensive, or backed by a large vendor is not evidence that it’s reliable. If nobody in the chain has audited the system’s error history, “the computer says so” is an assumption wearing the costume of a fact.

The four mistakes these cases share

Here are the common mistakes that contaminated these cases.

What actually holds up in court

None of this requires more tools. It requires treating verification as part of the job instead of something the other side does to you.

1. Verify anything load-bearing by hand. If a chat log, search entry, or timestamp is central to the case, open the raw database, registry hive, or log file and confirm the tool read it correctly, the way NetAnalysis and CacheBack disagreed with each other in the Anthony case before anyone checked which one was right.
2. Write down the mechanism, not just the conclusion. Instead of “the user accessed file X,” name the specific registry key, shellbag, or event ID that shows it, and explain why that artifact indicates a human action rather than a background process.
3. Go looking for the alternative explanation before the defense does. Check for malware, adware, cloud sync, and multi-user access during analysis, and put the negative findings in the report even when they don’t support your theory.
4. Match your language to what the data actually shows. There’s a real difference between “the system logged this event” and “this person did this thing,” and a report that blurs the two is a report an opposing expert can pull apart in one question.

I’d add one more thing: assume the report will be read by someone whose entire job is finding the weakest sentence in it. Write the sentence you’d want to defend, not the one that’s fastest to produce.