The deadline writes the report.

Ask for a report by seven in the morning and you have asked the site to describe work that finished after the crew went home. Nobody walked the floor. Nobody checked with the surveyor. The foreman gave a number from memory, at the gate, on his way out, because the alternative was leaving the field blank.

Ask for the same report by the afternoon and that foreman has had a morning. He can look at what was actually poured, ask the storekeeper what went out, and give you something he counted.

Same document. One is an observation and the other is a recollection, and no amount of formatting will tell the two apart afterwards.

The report before the report

None of this arrives as a report. It arrives as messages.

Two hundred lines a day, from a dozen people, in whatever form was quickest for them. Some send a spreadsheet. Some send a photograph of a handwritten sheet. Some send a voice note that says they finished the area they were on today — not which area, not how much, not against which line of the bill.

The first job of the day is therefore not writing a report. It is translation: turning a dozen formats into one, and going back for the three quarters of it that can't be used as sent. That is where the evening goes, and it is why the report is late even when everybody sent something on time.

A common template doesn't fix the deadline problem, but it removes the translation. When every discipline fills the same sheet, in your units, against your activity codes, the evening stops being spent on interpretation. It gets spent on checking — which is the job.

Not this evening

Some numbers genuinely are not known at the deadline. The concrete is still going in. The survey has not been done. Nobody is being difficult; the day simply has not finished producing its own data.

So the sentence arrives: we don't know that yet, can we correct it tomorrow?

Say yes and you have made a promise most projects then break, because tomorrow has its own report. Say no and you get a made-up number, which is worse. The honest answer is a third one: publish it as not yet reported, and hold the field open. A blank that everybody can see is a smaller problem than a figure that quietly turns out to be wrong.

How one day becomes three versions of itself

Here is the failure that costs the most and gets discussed the least.

A correction comes in two days later. The file is updated. The new file goes out with the same name, into the same folder, and takes the place of the old one. No revision number, no note saying what changed, no record that anything changed at all.

Do that for a few months and the project has several versions of the same day in circulation. Somebody is working from the file they downloaded in March, somebody else from the one that replaced it in April, and both of them believe they are looking at the daily report for the fourteenth.

Nobody is at fault at any single step. Every correction was right. What was missing was the record that a correction had happened.

Contract Week 1 was about a notice reaching the right address. This is the same problem one level down: a document that changes without announcing that it changed is a document nobody can rely on, however accurate its latest version is.

The measure that actually matters

Most projects judge a daily report on whether it went out on time. That is the wrong test, or at least an incomplete one.

The better test is how much it changes afterwards. A report published at seven that gets corrected three times is worth less than one published at two that stands. Timeliness is easy to measure and easy to hit, which is exactly why it becomes the target — and why the thing it is a proxy for gets lost.

So measure both. Track the proportion of a month's daily reports that were never revised after publication. It costs nothing to count, it can't be gamed by sending an emptier report earlier

, and it tells you something the delivery time never will.

Why anyone reads it at all

On most days, nobody does. The daily report goes into a folder and stays there, and it is tempting to conclude that the effort is wasted.

Then something happens. An extension of time claim needs to show which days were lost to weather. A dispute over a delivery needs the date material actually arrived. An incident investigation needs to know who was on site and what plant was running. A concrete result comes back low and somebody needs the pour date and the temperature.

All of that comes from the daily report, months or years later, and none of it can be reconstructed if the report was not kept. Claims Week 6 makes the contemporaneous record the strongest evidence there is. This is where that record is either made or not made, on an ordinary evening when nothing is at stake.

System design

The daily report itself needs no design. What is almost always missing is the record that it changed.

Record	Produced by	Required quality	Verified against	Feeds
Daily report	Site engineers, consolidated	Fields either filled or marked not yet reported	Store, survey, attendance	Weekly report, records
Revision number	Project controls	Incremented, never a new file with the same name	The issue log	Which version is current
What changed and why	Whoever corrected it	The field, the old value, and the reason	The original issue	Audit trail, delay analysis
Not-yet-reported list	Site engineers	Explicit blanks rather than invented figures	Next day's data	Follow-up

Five columns, filled in under a minute, and it removes the failure entirely: nobody can end up holding a different version of the same day without knowing it.

Practical insight

Find out two things about your own project this week, and neither takes long.

First, why the deadline is the hour it is. Ask. It is usually inherited from a meeting that no longer happens, or from a client representative who wanted it before their own morning call. If the reason has expired, moving it three hours can do more for your data than any change to the form.

Second, count how many of last month's daily reports were revised after they were issued, and whether the revision was recorded anywhere. If you can't answer the second half, you already know what to fix first.

Key takeaways

• The deadline decides how much of a daily report was counted and how much was remembered.
• A report due before the site can check its own work is a report of estimates, whatever the form asks for.
• Site data arrives as messages in a dozen formats. A common template removes the translation, not the deadline.
• “We will correct it tomorrow” is a promise projects break. Publish the field as not yet reported instead.
• A correction that replaces a file without a revision record creates several versions of the same day.
• Judge a report by how little it changes after publication, not only by whether it went out on time.
• Nobody reads the daily report until a claim, an incident or a quality failure needs it — and then it can't be reconstructed.

Records born here. Daily report · revision log · the not-yet-reported list for fields the day couldn't close.

What is coming next

The daily report says what happened. The weekly one has to say what happens next, which is a harder document to write and a much harder one to be wrong in.

Next week: the weekly report and the look-ahead — and the only part of either that anybody acts on.