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.
The admin's half: the template family
Log templates live in company settings, and their design is the highest-leverage twenty minutes in this part - every project that adopts a template inherits your choices for its entire site life. Build one general-purpose site template well (the scenario's three types are an honest minimum), and resist per-project template forks: the extension point for job peculiarities is the project config's own entry types, which is exactly what it is for. Fork the company template only when a whole category of project (interiors vs. site builds) needs a different record.
Retire templates by deactivating, not deleting - projects mid-flight keep their adopted structure, and your library stops offering the stale option to new ones.
⚙ Make it yours - flag-type wiring is where you encode company policy ("safety incidents are never just notes") so it executes without supervision. Distribution lists, reopen rights, and which grid level can issue are per-project decisions that your permission templates should already answer.