Where information gets lost in construction document flow

Łukasz Mikucki · Published Jul 20, 2026 · 8 min read

This text is not documentation-management theory. It is a record of what repeats on infrastructure contracts regardless of company size and the number of subcontractors. The information-loss points are surprisingly repeatable — and almost none of them stems from negligence.

It is worth starting from the fact that site documentation is a contractually defined category, not a set of files everyone keeps their own way. The GDDKiA technical specification lists the Site Documents in a dedicated item: the Dziennik Budowy (the construction logbook — the statutory site diary under Polish construction law), the Rejestr obmiarów (the measurement register), Dokumenty laboratoryjne (laboratory documents), the remaining site documents, and the rules for storing them. The PKP PLK PFU keeps a similar list, opening with the construction logbook and going on to site handover protocols, works acceptance protocols, and minutes of meetings and arrangements. Information usually gets lost outside that list — in emails, phone calls, and files that no contract document provides for.

Point 1 — the arrangement was made over the phone

The most common and the most expensive. A decision to change the technology, the sequence of works, or the scope is made in a conversation and then executed. A trail appears only when a dispute does — after the fact and from memory.

What helps without a system: the rule that "a phone arrangement comes back as an email the same day, one paragraph long". It costs a minute and turns a memory into a document with a date and an author.

Point 2 — an attachment instead of a register

The document circulates as an email attachment. The binding version is recognized by file name (_final_v3_ost), not by status. Six months later, nobody can say which version the works were executed against.

What helps: giving every document a status and a version in one place — which is exactly what separates a CDE from a shared drive. The drive alone does not solve the problem, because it does not enforce status.

Point 3 — no link to the scope

A letter or protocol describes the scope in words: "earthworks, section II". A month later there is no unambiguous way to establish which bill-of-quantities items it covered.

What helps: requiring every settlement document to reference a work front or a BoQ item. That single field eliminates most of the reconstruction work at settlement.

Point 4 — the entry date instead of the event date

The event took place on Tuesday; the entry was made on Friday. The register records Friday. The consequences surface only during delay analysis, when the sequence of events has to be established.

This is not a purely analytical problem. The GDDKiA technical specification ties a concrete deadline to the notification date: acceptance of works that become hidden or covered up takes place "no later than 3 days from the date of notification by an entry in the Construction Logbook". With a deadline like that, the difference between the event date and the entry date stops being a bookkeeping nuance.

What helps: splitting the two fields — event_date and entry_date. A cosmetic change in the form, a fundamental one in analysis.

Point 5 — a decision with no trace of who made it

The document was approved, but nobody knows by whom or at which stage. When people change on the contract, accountability dissolves completely.

What helps: an explicit path — an approval workflow built on roles, not names, with an entry date for every step.

Point 6 — a double flow: formal and real

Formally, the case follows the path described in the procedure. In fact, half the cases take a shortcut, because the procedure is too slow for the pace of the works. The register records the formal path — that is, fiction.

What helps: agreeing on a process that can actually be executed before it is written into a system. Mapping a procedure nobody follows is the most expensive rollout mistake there is — you pay for a system that records untruth.

Point 7 — knowledge leaves with the person

The site manager knows the contract's history: why a solution was changed, what was agreed with the investor's site inspector, where the problems were. That knowledge is written down nowhere, because there is no format it was ever meant to be written in.

What helps: a short, mandatory decision note for every change of technology or scope — three sentences: what changed, why, and who agreed to it. It does not replace the construction logbook; it supplements it with the context the logbook does not capture.

What this means for a rollout

Putting these seven points side by side shows something that tends to surprise at system-planning time: most information loss comes not from a missing tool but from three missing fields — the event date, the author, and the scope reference.

That is why the first stage of putting document flow in order requires no rollout. It requires a decision that those three elements are mandatory — and only when maintaining them by hand turns out to cost more than automating them does a conversation about an application make sense.

Interested in a contractor-side deployment? See how we do it.