AI Adoption GuideConstructionClose
Delay Claim Chronology Assembly
LLM assembles a delay event chronology from site diaries, correspondence, and programme updates for dispute or claim support.
Construction processBidAwardPlanMobilizeBuildInspectHandoverClose
By Don, DoneThat’s AI coach · updated
What a usable chronology contains
A delay chronology for dispute or claim support is a dated list of what the contemporaneous record actually says. Each populated row is a date, a short factual statement, and a cite to a diary, letter, email, or programme update. If a date has no record, the row stays empty. The model does not invent a delay event, does not infer weather from a blank day, and does not write entitlement or quantum. Counsel and commercial still own the claim.
The table is an evidence index, not an argument. It helps a commercial or claims lead walk the paper trail in order. It does not decide whether an event is a Relevant Event, whether float was available, or what prolongation is worth.
Pull diaries, correspondence, and programme updates first
Do not start from memory or from a contractor's claim narrative. Start from the three source classes that usually exist on a live job, inside a date window you already care about. Do not ask the model to find every delay on the project.
Site diaries and daily reports are the day-by-day record of labour, plant, work areas, weather notes, visitors, and instructions received. Platforms from vendors such as Autodesk and Procore commonly hold that daily paper, as structured forms or as PDFs attached to a date. Pull the diary or daily report for every day in the window, including days that say "no work" and days that are missing. A missing day is a fact about the file, not a delay. If dailies are assembled with assistance, keep this chronology downstream of the issued report in daily site report auto-generation. Cite what was issued, not a regenerated draft.
Correspondence means letters, contractual notices, filed emails, and issued meeting minutes. Pull items in the same window, plus a short look-back so a Tuesday notice is not orphaned from the Friday instruction it answers. Use the job's own identifiers (letter number, email date-time, minute item). State what the document states. Do not paraphrase a letter into a delay event.
Programme updates mean the baseline, accepted revisions, and progress updates that were issued, not working copies on a laptop. Record the data date, the revision ID, and the change the update itself records. The chronology cites the update. It does not rebuild a critical path. A separate schedule product is CPM schedule generation from scope or a planner's delay analysis, not this assembly.
Issued lookaheads, if you pull them, are contemporaneous statements of intent, not proof that a constraint later materialised. Scanning constraints is a different task: lookahead constraint scan.
Assemble dated cites and leave silent days blank
Work date by date inside the window. For each date, list every source that exists that day. If none exist, keep an empty row or mark "no contemporaneous record." Empty stays empty.
Write the statement in the source's language. If the diary says "awaiting setting-out on gridline C," the chronology says that, with a cite. It does not say "employer delay to possession" or "late design." If a letter puts the other party on notice of delay, cite the notice. Do not convert the notice into a finding that delay occurred.
Keep one row per source per date when sources conflict. A diary that records work in Area 2 and a letter that alleges a stoppage on the same day should both appear. The chronology does not reconcile them.
Do not fill a silent day. A Saturday with no diary, no email, and no programme drop is not "assumed continuation of Friday's weather." Filling it fabricates the record.
Do not invent a weather delay. A seasonal climate note, rain in a nearby city, or an undated site photo is not an entry. If weather is in the diary, cite the diary. If it is not, leave it out.
When a programme update lands, cite what the issued document states. Do not compute criticality, concurrency, or culpable delay inside this workflow.
A week of mixed records, assembled as cites
Illustrative only. The window is Monday 3 March to Friday 7 March on a reinforced-concrete frame. The pack contains diaries for Monday, Tuesday, and Thursday; contractor letter L-214 on Wednesday; a programme progress update issued Friday with data date Thursday; no site diary on Wednesday or Friday.
- 3 March. Diary: "Gridline A-B, 12 carpenters, waiting on revised starter-bar schedule from engineer, no pour." Cite: Daily report 3 Mar.
- 4 March. Diary: "Setting-out complete gridline A-B. Rain from 14:00, works stopped 14:30, labour stood down." Cite: Daily report 4 Mar.
- 5 March. No diary. Letter L-214 received: contractor states the starter-bar schedule is still outstanding and puts the employer on notice of delay. Cite: L-214. No weather or pour event is added for this date.
- 6 March. Diary: "Revised starter-bar schedule received 09:15. Fixing commenced gridline A-B." Cite: Daily report 6 Mar.
- 7 March. No diary. Programme update Rev 12 issued, data date 6 March: activity "Level 3 slab pour" shown slipped relative to the previous accepted update, as printed on the issued sheet. Cite: Programme Rev 12. The chronology does not call the slip excusable, concurrent, or critical.
Wednesday stays empty of site facts because no diary exists. The letter is the only Wednesday cite. Friday stays empty of site facts. The programme cite is the issued update, not a reconstructed as-built. Nobody has written entitlement or priced standing time.
If a variation or instruction sits in the same pack, do not fold it into this chronology as a money claim. Entitlement on variations is a separate analysis: variation claim entitlement analysis.
What commercial review has to catch
A commercial or claims lead treats the chronology as a finding aid. Open every cite. Confirm the diary is the issued daily, not a draft. Confirm letter number and date match the contract file. Confirm the programme revision is the one issued to the other party, not an unissued working file.
Mark incomplete rows rather than asking the model to tidy them. If Thursday's diary is unsigned, keep the cite and note the defect in a human comment. If two diaries disagree, keep both rows.
Then stop. Counsel and commercial decide whether to instruct delay analysis, whether to serve a further notice, and whether quantum follows. The chronology is not a particular of delay, an extension-of-time submission, or a witness statement. Opponents will test every inferred cause you allowed the model to write.
Keep quantum out. Hours stood down, plant rates, and prolongation belong in a measured account after people own the facts and the contract position.
Failure modes that poison the file
Inventing a weather delay. The model writes rain against a silent Tuesday because March is often wet. That row has no cite. If it enters the claim file, you are asserting a fact you cannot prove from the contemporaneous record. Delete any row that cannot open a source.
Filling a silent day. The model carries Monday's "waiting on information" into Tuesday because Tuesday's diary is missing. That is not continuity. It is a fabricated diary. Silent days stay blank so a reviewer can see where the record stops.
Treating the chronology as entitlement. The model labels rows "Employer Delay," "Neutral Event," or "Contractor Risk." Those labels are legal conclusions. Cause, concurrency, mitigation, and time entitlement stay with counsel and commercial.
Do not collapse conflicting sources into one agreed fact, cite a programme working copy, or summarise a letter so loosely that the cite no longer supports the sentence. Do not ask the model to hunt the whole job for delays instead of a defined window.
Use the chronology to find dates and documents fast. Write the claim, if there is one, from the contract and the sources, not from the model's table.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first