Build a chronology that survives checking

Start with the event, not the document

A document's date is not necessarily the event date. A 16 March email may report a conversation on 12 March, enclose an undated notice, and propose a meeting on 20 March. A table with one row per document cannot represent all three accurately.

For a first experiment, use the practice bundle linked below. It contains a short fictional record and an answer guide. The objective is a chronology you can verify, with uncertainty intact. Retrieval can supply relevant passages to a model; it does not itself decide whether the extracted event is established. [source]

Define the fields

Use: event ID; event date or range; date basis; neutral event description; person or entity; source ID; exact passage; source location; status; conflicting source; review note. Keep quoted evidence separate from your neutral description.

For an undated event reported later, the date basis might be “retrospective statement in A03.” For a proposed event, mark the status as “proposed.” Do not put a scheduled meeting in the table as an event that necessarily occurred.

Work the example

A03, dated 16 March, says: “I received your notice on Friday. I understand you posted it on Thursday.” A04 is a courier entry recording delivery on Thursday 12 March.

Record the reported Friday receipt and the courier's Thursday delivery separately. Ask whether they concern the same notice and delivery point. Do not resolve the conflict by choosing the source that sounds more official. The chronology's job at this stage is to expose the issue.

If “Friday” is normalized to 13 March 2026, preserve the original expression and explain that the date is calculated from the email's stated date. First verify the year and the email's actual timestamp; a quoted earlier message may have a different date.

Run a controlled extraction

Extract events from A01–A05 into the defined chronology fields. Use one row per distinct event or conflicting account. Preserve proposed events and retrospective descriptions as such. Quote the supporting passage. Keep date normalization separate from the original words. Do not infer that sending establishes receipt. List each input document after extraction, including documents yielding no event.

Review a first batch of five documents before scaling. Compare the rows with your own reading. Count both missing events and unsupported additions. A chronology that includes every extracted row but misses a material event is incomplete.

Reconcile the output

1. Match every source ID to the manifest.
2. Check the quotation and location against the original.
3. Check date normalization and chronology order.
4. Review whether each description is no stronger than its passage.
5. Read each source once more for events that never reached the table.
6. Keep unresolved issues in an exception list and assign a reviewer.