The daily log is the project's memory of what actually happened - weather, work performed, who was on site, what went wrong - written the day it happened, when it is cheap, instead of reconstructed in a dispute, when it is expensive. It is the least creative tool in Ceruleo, and that is its virtue: by the time a project is pouring concrete and hanging steel, the non-linear phase has funneled into days that need faithful recording. The judgment here is almost entirely front-loaded - the structure of the record is decided before day one, and then the days just fill it.
The mental model
Three layers, deliberately separated:
- A company log template defines the kinds of entries a day can hold - "Work performed," "Weather," "Safety incident" - each with its own settings: structured fields or free text, whether photos and files attach, whether an entry type can appear only once per day, and - the important one - whether an entry of this type raises a flag.
- A project log config adopts a template into one project, names the log ("Aurora Site Log"), and can extend it with project-only entry types for the peculiarities of this job - without touching the company template every other project uses.
- Daily logs are then just dates: a log for the 20th, entries accumulating through the day, and a lifecycle of exactly two states - draft while the day is being written, issued when the record is distributed and sealed.
The flag-type entry is where the log stops being passive. "Safety incident" configured as a flag-type means the act of recording the incident also raises it - the entry lands in the day's record and a flag opens in the project's issue pipeline, with the log as its provenance. The log observes; the flag pursues.
The scenario
Avery built the Site Daily Report template months before Aurora Pavilion existed: work performed (free text, attachments on - site photos live here), weather (once per day, because two weather entries is a data-entry argument, not data), and safety incident (flag-type, non-negotiable). When the project went to site, Morgan adopted it as the Aurora Site Log in minutes - the thinking had already been done.
Now the rhythm: Riley - the fabrication vendor, phone in hand - records the day. "Queue rail sections 1 through 4 welded and staged," photos attached, "clear, 78°F, no delays." Morgan reviews and issues the log that evening; the 20th is sealed and distributed. The 31st sits in draft with the powder-coat delay already noted - tomorrow's issue, today's honesty. Months from now, when someone asks why the rails slipped, the answer is not in anyone's memory; it is in log #2, dated, attributed, and sealed.
Decision rules
Rule: design entry types for the person filling them in at 5 PM with dirty hands. Structured fields when you will query the answer later (crew counts, temperatures); free text when you won't; attachments on wherever photos are the real record; once-per-day for facts that are facts. Every field you add is a tax on every day of the project - charge it only where the data pays rent.
Cost of choosing wrong: an over-engineered form gets filled with "n/a" until people stop opening it; an under-engineered one ("Notes: text box") records a project you cannot search when it matters.
Rule: make anything that demands follow-up a flag-type entry. Safety incidents, damage, visitor issues - if recording it should start something rather than merely note it, wire the flag at the template level so the escalation is automatic, not a memory.
Cost of choosing wrong: incidents recorded but never pursued - the log says it happened, nobody's plate says it matters.
Rule: issue daily, backfill honestly, reopen loudly. A log issued the same evening is a record; a week of drafts issued together is a reconstruction wearing a record's clothes. Backfilling a missed day is supported and legitimate - dated as the day it describes, created when it was created. Reopening an issued log is possible (admin-level) and leaves the reopen on the record - treat it as a correction with a paper trail, never a quiet rewrite.
Cost of choosing wrong: the first time a sealed record turns out to have been quietly edited, every sealed record in the project becomes negotiable.
⚙ Make it yours - the template family is the company's (see the Company Admin edition), but each project's config can add project-only entry types for this job's realities - a themed-water-feature project can log water chemistry without the company template ever knowing.
Allow flagsand flag persistence are per-config choices. Capture is phone-first by design (the seeded rhythm: field crew drafts on mobile through the day, a lead reviews and issues on the web at night - issuing is deliberately web-only). Pocket captures (Part 5) attach straight into log entries, so the photo taken at 10 AM finds the 5 PM entry without a cable in sight.
Troubleshooting
- "The log won't let me add a second weather entry." Once-per-day is set on that type, and it is protecting you - edit the existing entry instead.
- "Someone recorded an incident and nothing happened." Check whether the entry type is flag-wired. If it is, the flag exists - chase it in Flags. If it isn't, that is a template gap: fix the type, not the person.
- "We missed three days." Backfill them now, dated correctly, and issue them. An honest gap filled late beats a fabricated continuity - and the creation timestamps keep everyone honest anyway.
- "I need to change an issued log." Reopen it (your project admin can), make the correction, re-issue. The reopen is part of the record - that is the feature, not the embarrassment.
Mechanics - template building, project configs, entry capture on mobile, issuing and distribution, and reopening are covered click-by-click in the in-app Field Guide → Logs.
Where you fit
If you are on site, the log is mostly a phone habit: record as things happen, attach the photo now, and let the once-per-day and flag-type rails do their job. If you issue the log, the evening review is your quality gate - read the day as the future reader will, then seal it. You do not need company membership for any of this: log capture and reading follow your project's logs permission, so outside crews record their own days as first-class citizens.