Site records · One module of the operating system
The diary that actually gets written,
because it is a feed, not a form.
Daily logs in VIABUILD are a running project feed rather than a compliance form. A supervisor posts what happened, tags the entry as progress, an issue, a delay, safety, a delivery or an inspection, attaches photos, marks the weather and records which trades were on site and for how long. Every entry carries a visibility setting, so the same feed serves the office, the trades and the client without three separate updates.
The Founding Builders Programme · Onboarding in small cohorts
01 / What it does
What this feature does
Daily logs is the project feed each job carries. It is deliberately shaped like something people post to rather than something they fill in, because the failure mode of a site diary is not that it is badly designed, it is that it is empty. Why the record matters, and what a diary is worth when a dispute arrives years later, is covered in the reference on site diaries and daily records. This page is about what the module actually does.
An entry is free text plus structure. You tag what kind of day it was, attach photos or video, mark the morning and afternoon weather and the day’s high and low, and pick the trades who were on site from your own contact records, each with a headcount and hours. The people who read it can react to it and comment on it, and comments can mention both your own staff and the subcontractor companies on the job. Entries appear live, so the office sees the day as it is posted rather than at a Friday catch-up.
The part worth understanding properly is visibility. Every entry, and every comment on it, is marked internal, trades, client or all, and that boundary is enforced on the server rather than by hiding things in the interface. Entries marked visible to the client, and the photos on them, flow into the client portal, which is how the same act of logging the day also keeps a homeowner informed.
02 / Why it matters
Why builders need it
A diary that takes ten minutes never exists
The single reason site records fail is friction. An entry here is a short post with photos from a phone, which is why there is a record at all rather than a well-designed template with nothing in it.
The same day, told three ways, is three jobs
Most builders write the day once for the office, again for the trades and again for the client. One entry with a visibility setting removes two of those without letting internal notes reach a homeowner.
Photos on personal phones are gone
The photo that settles an argument about what was under the slab is on a supervisor’s phone, which left with the supervisor. Photos attached to the job stay with the job.
Nobody remembers July
Who was on site, what the weather did and what went wrong are all obvious on the day and unrecoverable within a month. The value of the entry is created the moment it is posted or not at all.
A client who is told nothing assumes the worst
Silence on a build reads as a problem. Client-visible entries with photos give a homeowner a running account of their job without anyone writing a separate update.
Deleted records look like hidden records
A record that can be quietly removed is not a record. Deleting an entry here requires a reason and keeps the row, and an edited entry is marked as edited, so the feed cannot be silently tidied up.
03 / The VIABUILD way
How VIABUILD handles it
One entry, four audiences, decided when you post rather than by who you remembered to copy in.
Posting is the whole interaction. A supervisor opens the job, writes what happened, taps a type, drags in photos and posts. Photos are uploaded when the entry is published, with a progress bar per file, and stored in a private bucket that is only ever read through short-lived signed links rather than public URLs. If a file fails to attach, the upload is rolled back rather than leaving a broken reference.
The structured fields around the text are deliberately few, because every extra field is a reason not to post. Morning and afternoon weather are marked by the person who was there, along with the day’s high and low. Trades on site are chosen from your existing supplier and subcontractor records, so the entry names the same companies the rest of the system knows, with a headcount and hours against each. That is a supervisor’s observation rather than a timesheet, and it is worth being clear that it is not a payroll record.
Visibility is chosen on the entry. Internal keeps it to your team. Trades opens it to the subcontractors on the job. Client makes it part of what the homeowner sees. All means everyone. The check runs on the server for entries and again for individual comments, so a comment cannot leak from an entry a reader was allowed to see, and a client-visible entry reaches the portal without anyone re-posting it there.
The record trail is honest rather than absolute. Entries are never hard deleted. Removing one requires a reason, keeps the row and records who removed it and when. Editing marks the entry as edited with the time it changed. What the module does not do is keep a version history of the text, so an edited entry shows that it was edited rather than what it previously said. If you need a document that cannot change once issued, that is a document, not a diary entry, and the two are different tools on purpose.
- Post from the job in seconds, photos uploaded on publish
- Tag the entry as progress, issue, delay, safety, delivery or inspection
- Weather morning and afternoon, plus the day’s high and low
- Trades on site chosen from your own contacts, with headcount and hours
- Visibility per entry, internal, trades, client or all, enforced server side
- Reactions and comments, with mentions of staff and trade companies
- Live updates, so the office reads the day as it happens
- Client-visible entries and photos flow to the client portal
04 / The workflow
How it runs, step by step
- 01
Open the job and write the entry
A short account of the day in plain words. No template to complete and no mandatory fields to fight, because an entry that is quick to write is an entry that exists.
- 02
Tag what kind of day it was
Progress, an issue, a delay, safety, a delivery or an inspection. The tag is what lets you read back only the difficult days later instead of scrolling the whole build.
- 03
Attach the photos
Dragged in or picked from the phone, uploaded when you publish with a progress bar for each file. They land in the job’s own private storage rather than a camera roll.
- 04
Mark the weather and who was there
Morning and afternoon conditions and the day’s high and low, marked by the person on site. Trades are picked from your contact records with a headcount and hours against each.
- 05
Choose who sees it
Internal, trades, client or all, set on the entry itself. The rule is applied on the server for the entry and for every comment underneath it, so nothing crosses the boundary by accident.
- 06
Post it, and the office already has it
The entry appears live for everyone entitled to see it. Client-visible entries and their photos become part of the client portal without a second update being written.
- 07
The job talks back
Reactions and comments sit under the entry, and a comment can mention your own staff or a subcontractor company on the job, so the conversation about the day stays attached to the day.
- 08
The record holds
Entries are never hard deleted. Removing one requires a reason and keeps the row with who removed it. An edit is marked as an edit. The feed can be corrected, but it cannot be quietly cleaned up.
05 / FAQ
Common questions.
Free text describing the day, a type tag from progress, issue, delay, safety, delivery, inspection or general, any number of photos or videos, the morning and afternoon weather with the day’s high and low temperature, and which trades were on site with a headcount and hours against each. The trades are chosen from your existing supplier and subcontractor records rather than typed fresh, so the entry names the same companies the rest of the system knows. Every entry carries the author, the time it was published, and a visibility setting that decides who can read it.
No, and we would rather say so plainly than imply otherwise. The person on site marks the morning and afternoon conditions and types the day’s high and low. There is no weather service feeding the entry. The practical consequence is that the record reflects what the site actually experienced, which is often not what a regional observation says, but it also means the diary is only as complete as the person posting it. If weather is going to matter on a job, the discipline is to mark it every day rather than only on the bad ones.
It contributes evidence, but it is not an extension of time workflow, and it is worth being precise about that. You can tag an entry as a delay, describe what happened, attach photos and mark the weather, and that dated, authored, photographed account is exactly the material a claim is later built from. What the module does not do is quantify the delay, link the entry to a schedule task or a claim, or produce an extension of time notice. Delay days and reschedule reasons live in the scheduling module against the affected tasks. The contractual side, what an entitlement requires and how notice periods work, is covered in the reference on extensions of time and delays.
Only what you mark for them. Every entry is set to internal, trades, client or all when it is posted, and the check is applied on the server rather than by hiding things in the interface. Entries marked visible to the client, and the photos attached to them, appear in the client portal, which means the same post that updates your office also updates the homeowner. Comments carry their own visibility too, so an internal remark cannot surface under an entry a client can read.
Both, with a trail. An edited entry is marked as edited with the time it was changed. Deleting is a soft delete that requires a reason, keeps the row, and records who removed it and when, so an entry can disappear from the feed but not from the record. What is not kept is a version history of the text itself, so an edited entry tells you that it changed rather than what it previously said. That is the honest limit of the module, and it is why anything that must be unchangeable once issued belongs in documents rather than in a diary entry.
No, those are two separate records and we do not pretend otherwise. The trades listed on a diary entry are the supervisor’s account of who was on site, chosen from your contacts with a headcount and hours. QR site sign-in and induction records are a separate register in the safety module, capturing who actually signed in, their company, whether they acknowledged the site rules, and when they signed in and out. Both are useful and they answer different questions, one being what the supervisor observed and the other being who registered at the gate.
No. A diary entry is a person’s account of their day, and there is nothing for a model to be more accurate about than the person who was standing there. Oryn™ is not involved in composing, summarising or scoring daily log entries. Where the intelligence layer works on site records is in the documents that arrive around them, reading and filing what comes in by email, which is described on the document intelligence page.
06 / Keep reading
Related features & guides
Post the day from the job, once.
Log a real day on a real job with photos and the trades who were there, mark it visible to the client, and watch it reach the office live and the homeowner’s portal without a second update being written.