Knowledge / AEC-native data

Site diaries and daily reports

The daily record of labour, plant, weather, progress, deliveries, instructions and events on site, often the evidence base in disputes.

The site diary is written daily and read only when something has gone wrong. Kept by the site manager or the section engineers, on paper or in a site app, it records labour by trade, plant, weather, deliveries, verbal instructions, delays and their causes, and progress against the programme. It is the contemporaneous evidence a delay claim or a compensation event assessment stands on, and it is usually incomplete, inconsistent between authors and hard to search. When a claim arrives, someone reads six months of entries for the one that matters. Site diary AI is worth having if it reads every entry against the programme and the instruction record, so the entries that prove or undermine a claim are found, with every answer traceable to its date and author.

What teams need to ask of it

  • What happened on the days the level 4 slab pour was delayed, and what cause did the diary give each day?

  • Which days were recorded as lost to weather, and what was actually written about the weather on each?

  • When did the subcontractor actually start on this level, and how many operatives did they have?

  • Which verbal instructions were recorded in the diary, and were they later confirmed in writing?

  • What was the labour on site in the weeks the programme required it to be doubled?

  • Which entries record an incident, a near miss or a stoppage, and who wrote them?

  • Where do two authors' diaries describe the same day differently?

Why generic AI gets it wrong

A diary is free text with a date on it, and the date is most of the meaning. A general-purpose tool that reads a month of entries as one block loses which day an event happened on, who wrote the entry, and whether the six mentions of the pump failure are six failures or one failure described by six people. Labour figures are recorded as counts by trade in a layout that changes with the author, and a tool that cannot hold the layout cannot add them up. Asked what the diaries say about the level 4 slab, it produces a summary, and a summary is exactly what a claim does not need.

A diary entry proves nothing on its own. The entry that says the pour was delayed by late reinforcement only supports a claim if the programme shows the pour on that day, the delivery record shows the steel arriving late, and no instruction had already moved the activity. Those documents are not in the diary. A tool working from the diary alone will find the entry, state the cause the site manager wrote down, and present it as the reason for the delay. The commercial team, reading a fluent account with dates in it, may build a claim on it that the other side dismantles with one instruction the tool never saw.

One question, answered

QUESTION

ANSWER

SOURCES

See it on your data.

See it on your data.

We onboard a focused slice of your project data, configure the ingestion paths, extract a structured context graph, and build a workflow against the resulting structured knowledge layer.

Related to

The diary reads against the construction programme, which says what should have happened each day, and the record of change orders, variations and compensation events, which says what was instructed and when. Meeting minutes often record the same delay from the other side of the table. Variation and change impact review draws on diaries for the time effect of a change, and lessons learned capture reads them for what went wrong and why.

Frequently asked questions

Frequently asked questions

Does it read handwritten or scanned diaries?

Can it check the weather days against the contract's threshold?

How do we see it on our own site diaries?

Related pages