How to build a case chronology from 900 emails

The order of events is usually the case. Getting it out of a disclosure set is a mechanical job, and it does not have to take a week.

A commercial dispute is usually an argument about what was agreed and when. The answer sits in correspondence written years ago by people who have since left both companies, and the side that can lay out the sequence cleanly is the side that looks credible.

Start from the documents, not from memory

The chronology most teams build first is a list of what everyone remembers, checked against documents afterwards. That order is backwards and it shows up under pressure. An entry you cannot trace to a document is an entry you cannot defend when the other side asks where it came from.

Work the other way. Take the documents you have, pull the dated assertions out of them, and let the sequence assemble itself. Gaps in the resulting timeline are findings in their own right: a month where nothing was written down is often the month worth asking about.

What belongs in one entry

Four things, and nothing else:

The date. From the document, not from context. If the document is undated, the entry says so rather than guessing.
What happened, in one sentence, in neutral language.
The source: which document, and where in it.
Who says so: the author of the document, because a claim by your own client and a claim by the other side carry different weight in the same list.

Anything else belongs in a note attached to the entry, not in the entry. A chronology that carries argument stops being usable as a reference and turns into a draft submission.

Three passes, in this order

Extract. Every dated assertion in every document, including the ones that look irrelevant. This is the pass to be generous on. Filtering during extraction means deciding what matters before you know what the sequence looks like.

Deduplicate. The same event will appear in twelve documents. Collapse them into one entry with twelve sources rather than twelve entries. This is where a hand-built chronology usually breaks, because merging by eye across hundreds of rows is not something a person does reliably at four in the afternoon.

Rank. Now filter. Which entries carry the dispute, which are context, which can be dropped. Do this last, in one sitting, with the whole sequence in front of you.

Where chronologies go stale

Disclosure arrives in tranches. A chronology finished in March is wrong by May, and the version circulating in counsel's inbox is a copy of a copy with two people's edits in it.

The fix is structural rather than disciplinary. Keep one chronology, keep it attached to the document set it was built from, and regenerate rather than patch. If rebuilding is expensive, people will patch, and the patched version is the one that goes to the hearing.

When two documents disagree

They will. An invoice dated March describes work a witness statement puts in June. Do not resolve it in the chronology. Record both entries, mark the pair, and deal with it as a contradiction rather than as a date problem.

A chronology that quietly picks the more convenient of two dates is worse than one that shows both, because the inconsistency is still in the file and the other side will find it.

What this looks like when it is automated

Legalnaut does the extract and deduplicate passes on import. Dates, parties and events come out of the text with a pointer back to the sentence they came from, near-identical entries are merged, and the ranking pass stays where it belongs, with the lawyer.

New disclosure folds into the same timeline instead of starting a new document. If two entries conflict, the pair is flagged rather than reconciled.

Legalnaut does this to your own case file: a chronology built from the documents, every finding showing the source it came from. See the plans.