RT monogram — RAIL-TECH logoRAIL-TECH
ArtifactConstruction process digitization

Construction dashboard: 12 data points that need an owner

Short answer
A dashboard does not fail for lack of charts — it fails on fields without an owner. Data with no role accountable for its correctness always degrades to a default value, and the whole cockpit starts showing an assessment of the situation instead of its state. Below are twelve fields that need an unambiguous owner before the first chart is built.

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

Most construction dashboards die the same way: for two months they look great, then someone notices that progress on one of the work fronts has been sitting at the same value for three weeks. Not because the works stopped — because the person entering the number stopped, and nobody noticed, since the field had no owner.

A field's owner is a role, not a named individual, accountable for the value being current and correct. A role survives a vacation, a change on the contract, and a person leaving the company.

How to read this list

Each field is described by its technical name, type, responsible role, and where the value comes from. The list is minimal — it does not cover everything that can be measured, only what the cockpit cannot stay credible without.

The technical names are our own — but every field has a counterpart in the contract documentation, and wherever such a counterpart exists, we name it explicitly. This is not decoration: a dashboard whose fields cannot be mapped onto the artifacts the employer requires will sooner or later start living next to the settlement instead of with it.

Layer 1 — where we are

work_frontreferenceowner: Contract manager

The shared dimension for all the other data. Without it, progress, materials, and acceptances cannot be combined. Definition: work front.

quantity_completednumber + unitowner: Works manager

The actual quantity, linked to a bill-of-quantities item. Source: as-built measurement, not a percentage estimate. Contract counterpart: „Rejestr obmiarów” (the measurement register). The GDDKiA specification describes it as a document that allows "the actual progress of each element of the works" to be settled, kept continuously, in the units adopted in the bill of quantities — with entries made by the Site Manager and confirmed by the Engineer. If your field lacks that confirmation, you have a number, not a basis for settlement.

event_datedateowner: Works manager

When the works were performed — not when someone got around to entering them. Confusing these two dates is the most common source of false progress "jumps" on charts.

schedule_itemreferenceowner: Planner

The link to the directive schedule. Without it you can compute progress, but not deviation.

Layer 2 — what is accepted and settled

acceptance_statusconfigurable enumowner: Engineer / works manager

An enum, never a free-text field — otherwise after six months you have twenty variants of the word "ok". But note: the values of this enum cannot be hard-coded. The GDDKiA specification lists four acceptance types (works that become hidden or covered up, partial, final, post-warranty). The PKP PLK PFU — six, with its own definitions, including the operational acceptance („odbiór eksploatacyjny”), after which the commission "determines the necessary restrictions for train traffic". The CPK OPW has no acceptance chapter at all. Three contracts, three different status dictionaries.

protocol_datedateowner: Commercial department

The date of the acceptance protocol. The starting point of the payment and warranty deadlines.

protocol_scopereferenceowner: Commercial department

An unambiguous statement of what the protocol covers: a BoQ item, a structure, or a work front. A verbal description is not enough for settlement. On a GDDKiA contract, partial acceptance has a document of its own — the Świadectwo Przejęcia (Taking-Over Certificate), issued by the Engineer under the sub-clauses on taking over the Works and Sections — while final acceptance is confirmed by a final works acceptance protocol drawn up to the Employer's template. Two different artifacts, and the register must tell them apart.

invoiced_valueamountowner: Commercial department

Compared against the quantity completed. A gap between "completed" and "invoiced" is the earliest signal of trouble in contract settlement.

Layer 3 — what is blocking

material_statusenumowner: Procurement / works manager

Ordered / delivered / approved / installed — four separate states, not one "quantity" column. Details: material register.

approval_stepenumowner: System

Which stage of the approval workflow the case is at. Answers the question "who holds the decision right now".

step_entry_datedateowner: System

Lets you measure idle time instead of guessing it. One of the cheapest fields with the highest analytical payoff.

schedule_riskenum + justificationowner: Contract manager

An expert judgment — but with a mandatory justification and date. The only field on this list that is an opinion, and precisely for that reason it must be clearly labeled as one.

Three rules without which the list will not work

Step 1.One role per field

Two roles responsible for the same field means zero roles responsible. Competence disputes are resolved at process-design time, not after go-live.

Step 2.The field's owner must use the field

A field filled in only for head office degrades within a few weeks. If the data serves no purpose for the person entering it, either change the field or change the process.

Step 3.A visible last-updated date

Every dashboard tile shows when its data was last refreshed. A stale number without a date is worse than no number, because it looks exactly like a current one.

What this list deliberately leaves out

There are no synthetic indicators like "overall contract health in percent". Not because they are useless — but because they are computed from the fields above. An indicator built on data without owners inherits all of their flaws and additionally hides them behind one tidy number.

The order is always the same: field owners first, then the register, then the charts. The reverse order produces a cockpit nobody looks at after a quarter.

Sources

The substantive basis of this text. Items marked as own practice do not come from a document — they are delivery experience that cannot be verified with a publisher.

  1. DocumentGeneralny Dyrektor Dróg Krajowych i Autostrad / GDDKiA Oddział w Katowicach
    STWiORB DM.00.00.00 (GDDKiA technical specification, in Polish), item 6.7.2 — „Rejestr obmiarów” (the measurement register): entries made by the Site Manager, confirmed by the Engineer (p. 31)
  2. DocumentPKP Polskie Linie Kolejowe S.A.
    PFU (TOM III SWZ) (PKP PLK employer's requirements, in Polish) — a catalog of six acceptance types with definitions (pp. 104–106)
  3. Own practice
    Observations from building registers and management reporting on infrastructure contracts

Terms used in this article

Work frontAs-built measurementDirective scheduleAcceptance protocolMaterial registerApproval workflow

Related articles

ComparisonJul 20, 2026 · 9 min

Excel or a custom application — where the break-even point lies

When a spreadsheet stops being enough in a construction process and how to tell. Decision criteria, hidden spreadsheet costs, and when a custom application pays off.

First-handJul 20, 2026 · 8 min

Where information gets lost in construction document flow

Seven points where information on an infrastructure contract disappears or loses credibility — and what can be done about them without deploying a system.