Skip to content
Failure analysis

The cause-and-origin report, and what gets it taken apart

The format is not the hard part. The hard part is that every statement in it has to be traceable back to something in your file, months later, out loud, under questioning.

The format is the easy half

Ask ten forensic engineers what belongs in a cause-and-origin report and you will get ten answers that agree on the spine: scope, methodology, documentation, evidence examined, hypotheses considered, the opinion and its basis, the materials relied upon.

That part is settled. Firms have templates. Juniors are taught the headings in their first month. If format were the constraint, the problem would have been solved a decade ago.

The constraint is what sits underneath the format. Every sentence in the opinion section implies a chain back to something concrete, a measurement in the field notes, a specific photograph, a lab result, a clause in the edition of the code that governed on the date of loss. When the report is written, that chain is fresh in the author’s head. Eighteen months later, in a deposition, it has to be reconstructed from the file.

Where the traceability gap opens

Three habits produce most of the gaps, and none of them is carelessness.

The basis stays in your head. You know why you eliminated the electrical hypothesis. The report says the electrical hypothesis was eliminated. Those are not the same document. On review, the second one is what you have.

The code edition goes unstated. As one practitioner put it: the code in force on the date of loss is not the code sitting on the shelf today. A report that cites a standard without naming the edition invites a question with no good answer.

Ruled-out hypotheses never get written up. The investigation considered them. The file contains the evidence. Getting it into the report means re-reading everything, which is exactly the work that gets cut when the report is due in ten days.

Each of these is a documentation problem, not an engineering problem. The engineering was done. What is missing is the retrieval, pulling the supporting material back out of a file that has grown to a thousand pages across two years.

What “cited” has to mean

A citation that says see field notes is not a citation. It is a promise that someone else can find it. The useful form names the document and the page: Field notes, p.4. Someone reading the report, you, opposing counsel, a reviewer, can open that page and read the same sentence you read.

That is a low bar to state and a hard one to hold across a long file under a short deadline. It is also the bar that matters, because it is the one that gets tested.

Assembling from the file you already have

The material for a well-supported report is almost always already in the file. The work is finding it.

That is a retrieval problem, and it is the one thing this software is for. Load the case record, field notes, site photos, lab results, prior reports, the governing code edition and ask it what the file says. Every answer comes back naming the document and the page, so you can open the source and read it yourself. When the answer is not in the sources you loaded, it says so rather than producing something plausible.

What that changes in practice:

  • The ruled-out hypotheses get written up, because finding the supporting evidence takes minutes instead of an afternoon of re-reading.
  • The code edition is explicit, because the edition you loaded is the edition it cites.
  • Prior positions surface, so the report is consistent with what your firm has said about the same failure mode before.
  • The basis is checkable, because each line names its source.

It does not write the report. It shows you what your own record says, cited to the page. The opinion stays yours, which is the part a signature is actually for.

Questions

Common questions

What sections does a cause-and-origin report usually contain?

Most firms work from a consistent spine: assignment and scope, methodology, site and scene documentation, the artifacts and evidence examined, the analysis of candidate hypotheses including the ones ruled out, the opinion with its basis, and the qualifications and materials relied upon. The exact headings differ by firm and by retaining party. What does not differ is the expectation that each statement can be tied to something in the file.

Why do reports get challenged on format rather than on the engineering?

Because format is where the traceability gaps show. A conclusion with no stated basis, an untested hypothesis, a methodology section that does not match what the analysis actually did, a reference to a code edition without saying which one, those are visible from the outside without re-doing the work. Engineers account for roughly 24% of challenges to expert testimony, and amended Rule 702 put more weight on whether the stated basis actually supports the opinion.

Should the report say what you ruled out?

Generally yes, and this is where files most often come up short. An opinion is stronger when the record shows the alternatives were considered and why each was eliminated. That material usually exists in the field notes and in the sequence of the investigation. It just never made it into the document, because assembling it means re-reading the whole file.

Can software write the report?

No, and you should be wary of anything that claims to. What software can do is find and cite what is already in your file, the note that describes an exhibit, the prior report where you addressed the same failure mode, the code edition in force on the date of loss, and assemble that material for your review. The analysis and the opinion stay yours.

See it on one of your own case files.

Thirty minutes on a slice of your own records. See the citations before anyone signs anything.