AI Legal Chronology From Documents: Page-Cited, for Paralegals

To build an AI legal chronology from documents you can trust, give the model the whole matter folder and a fixed list of columns. Make it read every page in batches and write one row per event: date, event, party, amount, file, PDF page, printed page or Bates number, and a short verbatim quote. Then check the rows against the pages before anyone relies on them. The quote column is what makes that check fast. You open the page, and the words are either there or they are not.

This guide is the workflow for a small firm or a solo paralegal. You have no Westlaw budget, just a folder of PDFs and a deadline. It covers scans and email threads, comparing two versions of an agreement, keeping the chronology current as documents arrive, a spot-check protocol, and where privileged files actually go. It ends with an honest comparison of the AI tools for paralegals that come up most, CoCounsel included.

Why does a case chronology eat a paralegal's week?#

Reading is not the slow part. The slow part is that a chronology is a join across documents that were never meant to be read together. The payment in the bank statement matches the invoice in the exhibit. The invoice matches the email that disputes it. The email quotes a clause that was renumbered in the second draft of the contract.

Every row needs a date, pinned down in the right time zone and in the right form: the date signed, sent, served or effective. Every row needs an amount, copied exactly. Every row needs a source someone else can find in thirty seconds. Do that 300 times across 400 pages. Then a supplemental production lands on Thursday and half the sheet needs re-sorting.

AI helps with the first read and the re-sorting. It does not help with deciding what the case is about, and it does not remove the check. Plan the work around that split.

What does "page-cited" have to mean before you trust a row?#

Legal AI tools describe their output as "cited" or "linked to the source". Before you trust one, be exact about which page number you mean. In a typical production there are three:

A model that writes "p. 37" could mean any of them. Anthropic's own PDF documentation tells developers to use "logical page numbers (from PDF viewer)" in prompts, which is the first kind. So ask for the columns separately and never let one stand in for another.

The other half of "page-cited" is evidence on the row. Make the model copy 10 to 25 words verbatim from the page that supports the date or amount. A citation alone can be wrong in a way that looks right. A quote either appears on the cited page or it does not, so checking a row takes seconds.

The column list that holds up:

date_type and confidence do a lot of work. Most bad chronologies fail on dates that were derived rather than read: "within ten business days of notice", "the following spring". Flagging those rows tells the checker where to look first.

How do you build an AI legal chronology from documents, 400 pages at a time?#

1. Put the matter in one folder, and keep the originals untouched#

One folder per matter, with subfolders if the production came that way (pleadings/, exhibits/, correspondence/). Work on copies. Give the AI tool that folder and nothing else. Add a short matter.md that names the parties, their aliases ("Kline", "KBI", "Kline Builders Inc."), and the date range that matters.

2. Don't paste 400 pages into one chat#

A single prompt is the wrong shape for this job, for two reasons. Every model has a request limit. Anthropic's API, for example, allows 600 PDF pages in a request, or 100 when the context window is under 1M tokens, and its documentation warns that dense pages can fill the context before that limit. And a model asked to summarise a mountain drops rows quietly. It gives you a confident chronology with the boring payments missing.

So read by document, or in batches of 20 to 30 pages for long files, and append every batch to one sheet. The prompt, used the same way every time:

Read [file], pages [x–y]. For every dated event and every amount, add one
row to chronology.csv with these columns: date, date_type, event, parties,
amount, file, pdf_page, printed_page_or_bates, quote, confidence, notes.
The quote must be copied exactly from that page. If a date is derived or
approximate, say so in date_type and explain in notes. If a page has no
dated event, add nothing. Do not summarise. Do not skip pages.

Then keep a coverage log: file, pages_read, rows_added. A file with 60 pages and zero rows is either genuinely empty of events or was skipped. The log lets you tell which.

3. Sort, merge duplicates, and group by lane#

When every file is read, have the model sort by date, then flag likely duplicates, meaning the same event captured from two documents. Keep both sources on the merged row rather than deleting one; two documents agreeing is worth knowing. A lane column (contract, payment, correspondence, court, meeting) is the useful addition Vaquill's chronology guide recommends. Filtered by lane, the sheet shows the story of the payments separately from the story of the notices.

4. Ask the questions the sheet makes possible#

With every date and amount in rows, these become one-line requests:

• "Total every amount invoiced and every amount paid, by party, and list the gaps."
• "Which notices were sent, and was each one inside the period the contract gives?"
• "What happened between the first missed payment and the termination letter?"

Each answer should cite the rows it used, and the rows cite the pages.

How do you handle scans, exhibits and email threads?#

Scans. Anthropic's documentation says Claude processes each PDF page as both extracted text and an image of the page. So a scanned page with no text layer is still readable, including stamps and handwritten dates. Readable is not the same as right, though. Fax-quality pages, handwriting and faint stamps are where transcription errors live, so tell the model to mark anything it read off an image as confidence: check.

Exhibits. Cite the exhibit label and the Bates number, not only the PDF page of a combined exhibit binder. If the exhibits were merged into one file, include a lookup in matter.md (Exhibit 12 = PDF pages 188–203) so the model can report both.

Email threads. One row per message, not per PDF. Three rules prevent most errors:

1. Date the message from its own Sent header, not from dates quoted in the replies below it.
2. Record the time zone when the header gives one. A 23:40 Pacific email is the next day in New York, and deadlines turn on that.
3. Ignore quoted history that already has its own row. A long thread quotes the first message eleven times, and you want it once.

How do you compare two versions of an agreement with AI?#

"Where do the two agreements disagree?" is a different job from a chronology, and it has a better tool for the easy half. If you have both versions as Word files, run Word's built-in document compare first. It compares the text mechanically, so it does not invent differences.

AI earns its place on the hard half: clauses that were renumbered, moved or reworded so that a character-level redline marks the whole section as new. Ask for a clause-by-clause table rather than a narrative:

Compare Agreement v1 (2024-11-02) and Agreement v2 (2025-01-17) clause by
clause. Match clauses by subject, not by number. For each: clause topic,
v1 number and page, v2 number and page, v1 wording (quoted), v2 wording
(quoted), what changed (amount, date, party, obligation, deletion), and
whether the change matters to payment, notice, termination or liability.
List clauses that exist in only one version at the end.

Every row carries two quotes and two page numbers, so it can be checked the same way as the chronology. Add the substantive changes to the chronology too ("2025-01-17: cure period shortened from 30 to 10 days, v2 §14.2 p. 9"). The date the terms changed is often the date the dispute started.

How do you keep the chronology current when new documents land?#

A chronology is rarely finished. Discovery trickles in, the client forwards another folder, a deposition transcript arrives. You have two options. Re-run the whole thing, which is wasteful and reorders rows you have already checked. Or run an incremental pass:

Check the matter folder for files not listed in coverage.csv. Read each new
file with the same rules, add its rows to chronology.csv with
added_on = today, re-sort by date, and list the new rows that fall inside a
period we have already reviewed.

That last line matters most. A new document that lands in a stretch of the timeline you thought was settled is the one to read first.

To make this happen without remembering it, put the prompt on a schedule, for example every weekday morning. Scheduling a recurring job that reads local files covers how that works in Claude, ChatGPT and a desktop agent, and where each one stops. Keep earlier versions of the sheet too, so you can see exactly what an incremental pass changed.

How should you verify an AI-built chronology?#

ABA Formal Opinion 512 says the independent review a lawyer owes depends on the tool and the task it performs. A chronology that feeds pleadings and deadlines sits at the careful end. A protocol a supervising attorney can sign off on:

1. Every high-significance row, every time. Open the page, find the quote, confirm the date and amount.
2. Every amount. Numbers are cheap to check and expensive to get wrong.
3. Every row with date_type derived or approximate, and every row marked check.
4. A random sample of the rest. Pick the size before you look, and write it down (for example, one row in ten).
5. One wrong row means re-reading that whole document, not fixing the one row. An error in a batch usually has siblings.
6. Check coverage, not just rows. Compare the coverage log against the folder's page counts.

What never gets delegated: whether an event is relevant, anything touching privilege, calculations of limitation periods and filing deadlines, and anything that goes into a filing. The model can surface a date. Deciding what the date means is the job.

Where do privileged files go when you use AI?#

Ask three separate questions about any tool, because the answers differ.

Where do the files sit? In a cloud legal platform, on the vendor's servers once uploaded. Clearbrief, for example, stores documents on its own SOC 2 Type 2 servers by default and offers a "bring your own storage" option. With a desktop agent, they stay in the folder on your computer.

Who processes the text? Any tool that uses a hosted model sends page content to that model's provider. That includes a desktop agent running on your Claude or ChatGPT account. The retention and training terms that apply are your account's. Read them for the plan you actually have. Only a model running on your own machine keeps the text entirely local.

What else syncs? Many apps back up your work, transcripts included, to their own cloud. Find out what, when, and who at the company can open it.

Opinion 512 turns these into obligations. Understand how the tool uses the data. Get informed client consent before confidential information goes into a tool that can learn from it, and boilerplate in an engagement letter is not adequate. And the supervision rules for lawyers and nonlawyer assistants (Rules 5.1 and 5.3) apply to how the firm uses the tool.

AI tools for paralegals, compared (as of September 2026)#

When a legal platform is the better choice: your firm already pays for Westlaw and wants research and document analysis in one place (CoCounsel). You write briefs in Word and want every factual sentence checked against the record (Clearbrief). Or you want a chronology product with vendor support and trial-prep features, and you are not on a Mac (NexLaw). Each of those is built for lawyers, and a general agent is not.

Where Universe fits#

Universe is not a legal product. It has no Westlaw content, no Bates stamping and no legal-specific chronology feature. What it gives a small firm or a solo paralegal is the workflow above, on the model account they already pay for:

• It is a Mac app that runs Claude Code or Codex on your computer, signed into your own Claude or ChatGPT plan. Both CLIs ship inside the app, so there is nothing else to install. If you are unsure what that setup is, see what an AI agent workspace is.
• It works in the folders you give it. The chronology is a CSV in the session's folder that you can sort and edit in the panel, PDFs in the session open in the panel too, and the clause comparison is a document you keep. When you cancel, the files are still yours.
• A session can run several agents at once, so a 400-page production can be split across workers that each read their share, with the rows merged into one sheet at the end.
• Schedules can run the incremental pass every morning. They run on a Mac, so the Mac has to be on.
• Version history keeps up to 24 earlier versions of the sheet on the Mac, with a diff, so you can see what a pass changed. Restoring an old version is itself a new version, so nothing is lost.

On privilege, precisely: the work happens on your Mac and the model runs on your own account. When you are signed in, Universe syncs artifacts, uploads and session transcripts to its cloud, because sharing, rooms and a second Mac need them. Universe staff can open a synced session transcript only with a stated reason, and the access is recorded in your team's audit log. The app works without an account, and sync needs you signed in. So a matter you want kept off Universe's cloud can be worked signed out, on a Mac that stays signed out, because signing in later can sync what is already there. Your model provider still receives the page text under your plan's terms. If even that is too much, Universe can run an open model on your own machine (for example through Ollama), and you should check its output even harder.

The trade page shows the asks for this kind of work: Universe for law and paralegal work. The full feature list is at /features. When you are ready to try it on a closed matter first, download it for Mac (Apple silicon or Intel, macOS 13 or later).