Daily Site Report Auto-Generation

The daily report is a signed record of what the job already stored for that calendar day. Pull weather, crew counts, progress, and open issues from the structured fields the foreman (or you) entered. Do not harvest emails, radio traffic, or last week's diary to complete a thin day.

Field platforms in the same class as Procore and Autodesk already hold those four items as fields, not as prose. Some products in that class can draft the daily report from those fields. Treat that output as unsigned text. Weather is the recorded site condition at the times someone logged it. Crew is a count by trade or contractor, only if a count was entered. Progress is the quantity, location, or percent complete against the work packages you actually track. Open issues are the items still unresolved at cutoff. If a field is empty, it stays empty in the draft.

Who enters and who signs can be different people. A foreman can complete weather, crew, progress, and issues. You still review cites and sign. If a foreman left a field blank, you either enter what you observed into that field, with a time, or you leave it blank and sign the blank. Typing the missing number only in the generated paragraph does not count as entering it.

You still own cutoff. Freeze inputs at the same hour you would freeze a handwritten diary: after the last recorded event you will stand behind. On a two-shift job, freeze a cutoff per shift rather than letting overnight entries rewrite the day shift's signed page. Do not wait for the model to round out the day.

Photographs and model comparisons are not a substitute for the progress field. If a photo was never coded into a quantity or location, it is not an input to this report. Keep visual comparison work on AI visual progress monitoring.

Every factual sentence in the draft needs a cite to a named field and a timestamp or record id from that day's package. A weather cite points at the weather row. A crew cite points at the crew row, including when that row is blank. An issue cite points at the issue id. A sentence with no cite does not belong in the draft.

The model may stitch short sentences so the page is readable. It may not add causes, blame, or lost-time language unless that language already exists in a field you are citing. Joining "rain" and "no slab pour" into "rain delayed the pour" is inventing a delay narrative. Strike that sentence even if you privately believe it is true. If you want the delay on the record, write it yourself in a signed comments field, or assemble it later with delay claim chronology assembly. Generated diary prose is the wrong place to start a time-impact story.

Cites must be visible while you review: field labels and ids in parentheses or footnotes, consistent enough that you can open the source row without hunting. If you cannot find the source quickly, delete the sentence.

Do not let the daily report answer an RFI that appears in an open issue. Name the RFI number in the issue cite and keep the response work on RFI auto-response drafting.

A blank crew count stays blank. Filling it with yesterday's headcount, a typical crew, or a round number so the report looks complete fabricates labor on the project record. Later readers will treat those people as having been on site. Payroll, extra work, and delay files all get read against this page.

The same rule applies to quantities and weather. If the progress field has no cubic yards, the draft does not invent cubic yards. If weather was not logged, the draft does not import a forecast and present it as the site observation. Tomorrow's planned work is not today's progress. Do not let the model copy a lookahead task into the progress paragraph because the names look similar.

Open issues stay as logged. Closing an issue in prose because the wording sounds resolved is a quality failure. If the issue list is empty at cutoff, the draft says the list is empty and cites the empty list. It does not infer "no issues" from a failed query.

Future constraints that have not become today's issues stay on the lookahead. Review them with lookahead constraint scan. Do not promote a next-week constraint into today's open-issue paragraph.

The model output is a draft. You sign. Until you sign, it is not the official daily report, daily diary, or project record. Do not email the draft to the owner, construction manager, or trade list as if it were the diary. Do not attach it to a transmittal. Do not allow a scheduled job to send it at a fixed hour because the text looked finished.

Before you sign, walk three checks. First, every sentence has a cite you can open. Second, every empty field is still empty in the prose. Third, send-as-diary is off until your name is on the page. If any check fails, the draft stays in your queue.

Signing means you accept every cited sentence and you accept every blank. If a cite is wrong, fix the source field or strike the sentence, then edit or re-draft, then sign. If you change a number in the prose without changing the field, you now have two records. Correct the field first.

Distribution of the signed report follows the path you already use for the form-based or handwritten diary. The draft's only extra audience is you, and anyone you designate to check cites before you sign.

Cutoff is 3:30 p.m. The weather field shows rain starting at 11:10 a.m., still raining at cutoff. The forming contractor's crew field is empty. The progress field shows west wing, level 2, wall forms, with no quantity. Open issues show Issue 441, missing embed drawings at grid D-4, opened Monday, still open.

A usable draft restates those four facts, each with a cite, and stops. It does not assign a headcount to the forming crew. It does not say rain delayed a pour. It does not close Issue 441. It does not add that the site is generally on schedule.

A failed draft does all of that, then emails the owner at 5:00 p.m. You now have an unsigned, padded diary in someone else's inbox. Retrieve it if you can. Correct nothing in the email thread. Correct the fields, re-draft, sign, and send the signed copy through the normal diary channel. Note, in the signed record, that the earlier message was not the official report.

You may still add a superintendent comment in a separate comments field: you saw the forming crew leave at lunch and you did not receive a headcount. That comment is your observation, timestamped, signed with the rest. The model must cite it as your comment. It is not a crew count, and it does not fill the empty crew field.