The Opinion You Have to Take Back
Eight months ago you signed a report concluding that the defendant 'never opened' Schedule_A.xlsx, based on the absence of a corresponding LNK file and no RecentDocs entry. The report was produced under a litigation hold, has been exchanged, and the defendant's expert has already cited it. You now learn two things: the LNK parsing library version you used silently discards LNK files whose target path exceeds 260 characters, and the file lived on a DFS share that, in this environment, users opened through a mapped drive inside a RemoteApp session. Depositions are in three weeks and opposing counsel has not yet asked you about your tooling.
1. What are your obligations, to whom, and in what order?
Read the worked answer
Obligation first, strategy second. The duty of candour is owed to the court or tribunal, and it is owed whether or not anyone asks. The report contains an assertion you can no longer support, and the other side is relying on it.
Order of operations:
- Tell your retaining counsel immediately and in writing, with a short factual note: what the conclusion was, what you have learned, why it matters, and what you propose to do. Do not wait for the three-week deadline to sharpen your story.
- Do not communicate with the opposing expert or opposing counsel directly - that runs through counsel.
- Preserve everything about the original analysis: the tool version, the hash of the tool, the input set, your notes. The original work product is now itself evidence of what you did.
- Re-run and verify before you say anything publicly about the corrected result, so that one correction does not become two.
- Agree a corrected report or an errata with counsel, and expect to be deposed on both versions.
What you must not do is quietly re-analyse, leave the original on file, and hope the gap is not noticed. Being the expert who disclosed their own error is recoverable; being the expert who was caught concealing one is not.
2. How do you re-test, and what would change your opinion?
Read the worked answer
Re-test the two failure modes separately.
- Parsing. Re-run with a current parser and with an independent tool or manual binary inspection, keeping the old version for comparison. Count how many LNKs the old library dropped across the whole image - if long paths were common in this environment, the defect touches more than this one file.
- RemoteApp. Within a RemoteApp session, the user's shell runs on the session host. The LNK, RecentDocs, jumplists, and MRU entries land in the session host's user profile, not on the laptop or the client. Check whether the RDS host's profile for this user was collected at all - if it was never produced, the absence is a collection gap, not evidence of non-access.
What would change the opinion: a recovered LNK, jumplist, or RecentDocs entry in the RDS host profile; server-side evidence of an open from the DFS share (share access auditing, file server 4663 events, Office MRU in the roaming profile); or a cloud/backup copy of the profile that shows the file.
Even if nothing is recovered, the opinion as worded is unsupportable: absence of an artefact that was never collected, or that the tool could not parse, cannot support 'never'.
3. Rewrite the opinion and describe how you handle the deposition.
Read the worked answer
Rewrite - from negative absolute to bounded statement.
Before: 'The defendant never opened Schedule_A.xlsx.'
After: 'No record of the defendant opening Schedule_A.xlsx was identified in the artefacts collected from the laptop. This conclusion is limited in three respects: the file was stored on a DFS share and, in this environment, was opened through a RemoteApp session, so the relevant LNK, RecentDocs and jumplist artefacts would have been created in the session host's user profile, which was not among the materials provided to me; the parsing tool version originally used discarded entries with paths exceeding 260 characters, which I have since corrected; and the absence of an artefact is not evidence that an event did not occur.'
Deposition:
- Disclose the error and the correction at the first question that touches it; do not wait to be cornered by a document request.
- Explain the mechanism plainly and take responsibility for the verification failure - do not blame the library as though it were someone else's problem.
- Reaffirm only what still holds, and be explicit about what you no longer assert.
- If asked whether your original opinion was wrong, answer directly: yes, as worded, it went further than the data supported.
A clean, early correction supported by a documented re-test is far more persuasive than a defence of a position you already know is shaky.