Evidence Chronology Builder
Turn a pile of 50+ emails, contracts, invoices and file notes into a dated, source-linked chronology your lawyer can actually rely on — in an afternoon, not a fortnight.
It reads every document in the matter, extracts each dated event, links it back to the exact source page, and drafts a chronology and a list of evidentiary gaps for a practitioner to check and sign off.
Where this works well
The slow, invisible problem this makes visible is reconstruction: in a document-heavy dispute the facts are real but scattered — an email here, an unsigned variation there, a progress claim, a file note of a site meeting — and assembling them into one reliable order of events is hours of careful, low-judgment transcription that someone bills at the wrong rate. This pattern reads the whole pile at once, dates each event, attributes it to a party, and lines it up on a single timeline with a link back to the source page for every entry.
It earns its keep on document-heavy matters above roughly 30–50 sources: construction and Security of Payment disputes, contractual and commercial litigation, insurance and employment claims. The person who benefits most is the solicitor or paralegal who would otherwise spend a day or two opening files, reading dates off letterheads, and typing a chronology into a table — that time moves to the part only they can do, which is deciding what the sequence *means*.
It is at its best when the gaps matter as much as the events. Surfacing that there is no written approval for a variation, that a party proceeded "under protest", or that a progress claim sat 342 days overdue is precisely the kind of pattern that's obvious once laid out and easy to miss inside a 53-document bundle.
Where it works badly
It works badly when the documents can't be dated from their own four corners. An undated draft, a forwarded email thread three replies deep, a meeting note with no date in the body — the tool will place these where the text implies and flag the uncertainty, but it cannot conjure a date that isn't there, and a chronology built mostly on inferred dates is a liability, not an asset.
It also works badly as a substitute for judgment about materiality. It will faithfully extract every dated event, including the trivial ones, and it does not know which three of fifty entries actually decide the matter. If you read the draft as "the answer" rather than "the raw sequence to interrogate", it will mislead you — confidently, because it looks finished.
The honest test: if a junior solicitor couldn't reliably date and attribute a document by reading it, this tool can't either. And if your matter is small enough that one person can hold the whole story in their head, the setup isn't worth it.
What it doesn't do — and shouldn't
It surfaces events and gaps; it does not form a view. It will flag that written variation approval is "NOT FOUND" — it will not tell you whether that sinks the claim, because that turns on the contract, the conduct, and the law, and is a legal judgment that belongs to a practitioner. It drafts a chronology; a solicitor decides what goes into a brief, an affidavit, or advice.
The human-in-the-loop boundary here is deliberate and load-bearing. A chronology can become evidence, and a solicitor carries a duty to the court for the accuracy of what they put forward. So the tool never asserts a fact without a source link, and nothing leaves review as a "finding" until a person has checked each entry against its document and approved it. The point is not caution for its own sake — it's that an unverified, machine-built timeline has no standing, and pretending otherwise would be the worst thing this could do.
What your data has to look like for this to work
Concretely, this needs the actual matter documents — not a summary of them. It reads emails (with their headers intact, so the send date survives), contracts and variation documents, progress claims and invoices, formal letters, meeting and file notes, and texts. Dates need to live *in* the documents: an email export keeps its timestamp, but a screenshot of an email may not, and a scanned letter relies on the date printed on the page. Scans and photos go through OCR, so legibility matters — a clean PDF reads far better than a skewed phone photo.
The honest part most firms haven't thought about: the documents must be the real, current set for the matter, organised so the tool isn't fed three versions of the same letter or missing the one variation email that matters. Most firms have the documents but not the discipline — files live across inboxes, a shared drive, and someone's desktop, and the "complete set" is assembled by memory. Getting that capture right — where matter documents live, how they're named, how completeness is assured — is usually the real first job, and it's a matter of how information is filed, not a tool you buy. That groundwork is the work we help with, and it's typically larger and more valuable than the AI layer sitting on top of it.
Could it build a chronology that's confidently wrong and send my advice off in the wrong direction?
It can mis-date an event, mis-attribute a party, or read an undated draft as if it were executed — that is exactly why every entry carries a clickable link to its source document and nothing is asserted without one. The safeguard is structural: the tool drafts and cites, a solicitor checks each entry against its source and approves it. Treat an unreviewed chronology as a research note, never as a finding of fact.
Our matter files are a mess — scanned PDFs, photographed letters, email threads three replies deep, half of it undated. Does that break it?
Scans and photos run through OCR first, so a faint fax or a phone snap of a letter is readable but lower-confidence, and it says so. Undated documents and ambiguous email threads are the genuine hard cases: it will place them where the text implies and flag the uncertainty rather than inventing a date. The honest test — if a junior solicitor couldn't reliably date a document from its four corners, neither can this.
Does this replace the solicitor or paralegal who'd normally build the chronology?
No. It removes the hours of opening, dating and transcribing 50-plus documents into a table; it does not form the view about what the chronology means. Deciding which events are material, what a 'proceeding under protest' email is worth, and how the gaps bear on the claim stays with the practitioner. The recaptured time goes into that judgment, not off the payroll.
How current does the document set have to be?
The chronology is only as complete as the documents you give it — it reads what's in the matter folder at the time it runs. Discovery is a continuing obligation in Australian litigation, so a late email or a freshly produced variation can shift the picture. Re-run it when the document set changes; don't treat last week's chronology as covering documents that arrived since.
Where does our matter data go, and is privilege protected?
It runs against your documents in an environment you control; the material is not used to train any third-party model. Because these are privileged and often commercially sensitive files, the data boundary and retention are set up as part of the engagement, not assumed. We scope where the documents live and who can see them before any matter touches the system.
What kinds of matters does this actually suit?
Document-heavy disputes where the facts are spread across many sources and the order of events matters — construction and Security of Payment disputes, contractual and commercial litigation, insurance and employment matters. It earns its keep above roughly 30–50 documents; below that a paralegal with a notepad is faster.
Estimated build: 3–5 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.