LegalFree
Litigation Chronology and Key Documents
River builds the chronology from the production itself, with the source field and zone behind every date and a reason behind every hole in it.
River reads the production and its metadata together and returns a chronology of events rather than a list of documents. Each entry is the thing that happened, dated to when it happened, with the custodian, the Bates range and the document it rests on. Where several documents evidence one event they collapse into one row carrying all of them, and where one document evidences four events it produces four rows. The register is the artifact, and the narrative is built from it.
Every date also carries where it came from. A produced email has a sent date, a received date, a created date and a modified date, and they are four different answers to when. The row names the one it used and the zone it was normalised to, because a document's timestamp is not a property of the document. It is the output of a processing profile chosen by somebody on the other side, and it moves the same email across a calendar boundary.
Then the holes get classified, because a gap is not one finding. Some are absence: no record exists and none was ever kept, which is a fact about the case. Some are non-production: the record exists and did not arrive, which is the next request. Some are loss, which is a different conversation entirely. The chronology sits next to the digest of what the witness said about that week and the Bates ranges the load file actually contained.
The timestamp is somebody else's decision
Dates in a production are processed values. The engine discovers all natives in UTC and then applies the time zone's UTC offset to all date and time metadata fields, with a further daylight saving adjustment where one applies. That offset comes from a processing profile set by whoever handled the collection. An email whose UTC timestamp is just after midnight lands on one day or the previous one depending on that setting, and nothing on the face of the document tells you which was chosen.
Short message data makes the problem visible. Slack and Teams arrive as RSMF, and the same documentation states that RSMF extracted text preserves source-file timestamps regardless of the processing profile offset while only the metadata fields are adjusted. So one produced message carries two times in two zones, by design. A chronology built by reading the messages and a chronology built from the load file will disagree about the same conversation, and both of them are reading the production correctly.
A hole in the chronology is one of three findings. Where a record was regularly kept for a matter of that kind, evidence that the matter is not included in it is admissible to prove it did not occur, so the register records whether such records were kept. Where the record exists and did not arrive, that is a request. Where it existed and is gone, the rule on lost information turns on reasonable steps to preserve it and, for an adverse inference, on intent.
How it works
Hand over the production
The documents, the load file metadata, and whatever the team already believes happened and when.
Dates get resolved
Each event is placed on the day it happened, with the field and zone recorded.
The register fills
One row per event, collapsing duplicates and splitting documents that evidence more than one.
Holes get named
Every gap is classified and paired with the request, the argument or the motion it supports.
What you get
- One row per event, not one row per document, with every document behind it
- Each date names the metadata field it came from and the zone applied
- Bates range and custodian on every entry, with the hash where the load file carried one
- Gaps classified as absence, non-production or loss, because the three need different answers
- Contradictions between documents surfaced as paired entries rather than buried in a narrative
- A presentable timeline built from the register, so the exhibit and the evidence never drift apart
Common questions
What does it need to run?
The documents and the load file metadata that came with them. It runs on documents alone, but the date columns then read the face of each page rather than its metadata, which is the ambiguity the register exists to resolve. Hand over the .dat and the entries carry their provenance. Scanned records carry no load file at all, so a legibility pass runs in front of the dates.
How does it decide the date of an event?
By the day the event happened, not the day the document was made. A memo written on the fourteenth about a meeting on the third is an entry on the third, cited to the memo. Where the document is itself the event, a notice served or a contract signed, the two dates are the same and the row says so.
What if the two sides disagree about the sequence?
Then the disagreement is a row rather than a decision. Conflicting entries are paired, each keeping its own citation and its own date source, and the register records what would settle it. Most sequencing fights turn out to be metadata questions, which is cheaper to resolve than a credibility fight. Where testimony settles it, the page and line of the witness's own date joins the row.
Why record the hash on every entry?
Because it is what lets a copy stand on its own. Data copied from a file is self-authenticating where it is authenticated by a process of digital identification with a qualifying certification, and the MD5 in the load file is that process. Carrying it costs a column and saves a custodian witness.
How is this different from a key document index?
It produces both, from one read. The chronology is every dated event, and the key document index is the short list a partner reads first, ranked by what each document decides rather than by date. Both point at the same rows, so promoting a document to the index never means retyping it.
Does it produce something presentable?
Yes, a timeline built from the register rather than drawn separately, so the exhibit and the evidence cannot drift apart. Every marker traces back to its row and its Bates range, which means the version shown to a jury and the version defended in a deposition are the same document at two zoom levels.
Where does this sit in the case?
After the production is validated and reviewed, and before anybody drafts. It reads better alongside the log of what was withheld and why, because a chronology built only from what was produced has a shape carved into it by the privilege calls, and the two sheets read against each other.
Litigation Chronology and Key Documents
Fill in the form and your workspace opens with the work already underway.