A Digital Twin You Can Replay

What a digital twin of a building really is, what it isn’t, and what a construction company can build today from records it already keeps, shown on a real Dutch housing project

Digital twins for construction companies, explained on a real project: the open Schependomlaan dataset (Nijmegen, 2015) replayed element by element in a free browser app, and an AI-kept project notebook that turned its records into questions for the site team.
Author

Behzad Samadi

Published

October 30, 2026

A paper-craft building site: a brick housing block whose lower floor is finished in teal, the floor under way in amber with window frames in red, and the upper floor and roof as a faint translucent outline; a tower crane beside it, a laser scanner on a tripod, and a timeline strip with a slider in front. Title: A Digital Twin You Can Replay.

“Digital twin” is one of the most stretched terms in construction. It is used for a 3D model, a dashboard, a sensor feed, and sometimes for a slideshow. This article takes a stricter view, builds one kind of twin from a real project’s open records, and shows what it can and can’t tell a contractor.

The project is Schependomlaan, a housing project in Nijmegen, the Netherlands, built in 2015. A master’s student at TU Eindhoven, working with the contractor and its partners, recorded it in unusual detail and released the records: the building model, the schedule, which task built which part of the building, whether each part went in on time, weekly laser scans of the site, and the coordination checks between the subcontractors’ models. We joined those records into a twin you can replay in your browser, and gave them to an AI assistant to keep as a project notebook.

NoteIn short
  1. A digital twin, strictly, stays in sync with the real thing through live data. A model that is never updated from the site is a model; one updated from the site but not acting back on it is often called a digital shadow.
  2. Most of what a contractor needs for a first twin is already on file: the model, the schedule, and records of what was finished when. The work is linking them, element by element.
  3. On Schependomlaan, linking them shows where the job ran late: 194 of 3,661 element–task records were late, all of them in tasks planned to start on or after 18 June 2015, and 190 of them in facade work. The weekly scans found missing elements in the same trades.
  4. An AI assistant turned the records into 21 questions for the site team, in about 16 minutes, for about C$9 of AI time. It found inconsistencies between the records that a busy planner might not, and it stated no causes the records don’t support.
  5. You can try it: the Schependomlaan Twin runs in your browser, with the whole 2015 build on a timeline.

What counts as a digital twin

The term started in engineering. A digital twin of a jet engine or a production line is a model fed by sensors on the real thing, kept current automatically, used to predict failures and decide what to do. By that strict definition, Wikipedia’s article notes, a model that runs without data from its physical counterpart is a twin only in an “overly broad and largely marketing-oriented” sense.

A much-cited review of the manufacturing literature, by Kritzinger and colleagues (2018), separates three stages: a digital model, a digital shadow and a digital twin, and finds that work on true twins, the highest stage, is scarce. In our own words, for a building:

Data from site to model Model back to site Construction example
Digital model by hand, now and then by hand the BIM model the designers delivered
Digital shadow automatic or routine by hand the model coloured each week from progress records and scans
Digital twin automatic, continuous automatic or decision-ready sensors and scans updating the model, which re-plans the next tasks

For most construction companies, the useful target is the middle row. A shadow is honest about what it knows, and it is built from records most contractors already keep. The Schependomlaan replay sits there, and so does everything in the rest of this article.

The project and its records

The dataset was gathered for Stijn van Schaijk’s master’s thesis in the Information Systems for the Built Environment group at TU Eindhoven, with the contractor Hendriks Bouw en Ontwikkeling, ROOT, TNO and RAAMAC. It is published in buildingSMART’s collection of sample files. What it holds:

  • The contractor’s schedule of 18 February 2015: 157 tasks, from site set-up on 19 February to handover on 17 December 2015.
  • A 4D model: the building model linked to the schedule in Synchro, with 3,505 building elements.
  • An event log exported from it: which task built which element, with planned dates, for 2,358 elements and 72 tasks, and for each, whether the element was in place on time or late.
  • Laser scans of the site in weeks 26 to 30 (22 June to 26 July 2015), each compared with the planned model to list the elements missing.
  • 102 coordination issues from 23 checks of subcontractors’ models against the design, March to June 2015.

Two limits matter. The records give planned dates and an on-time/late flag, but not the actual date each element was built, nor how late. And the records are from 2015; nothing here is live.

Replaying the build

We joined the records element by element: the model’s 3,505 elements, the event log’s tasks and dates, and the as-built flags. Then we built a small app that draws the building in your browser and colours each element by the day you choose: not started (a faint outline), under way (amber), finished on time (teal), or flagged late (red).

Open the Schependomlaan Twin

Drag the timeline through 2015 and the building assembles itself: the foundations in March, the structure floor by floor from April to early July, the facade from mid-June through July, and the roof from mid-July into October. Click any element to see the tasks that built it, with their planned dates and the as-built result. A list on the side ranks the tasks that ran late; pick one and the building shows just those elements.

What the replay makes plain in a minute:

Task Late element–task records
Brickwork (metselwerk), two runs 73
Window and door frames (plaatsen kozijnen), two runs 57
Setting the outer facade elements (stelwerk buitengevel) 50
Precast concrete band (prefab betonband) 10
Calcium silicate walls, and the roof 2 each

Everything before 18 June ran on time. From then on, the facade carried almost all of the lateness: 190 of the 194 late records, on 119 elements.

The weekly scans tell the same story from a different instrument. Each week from 22 June, a laser scan of the site was compared with the elements the model said should be there:

Week (2015) Planned elements missing from the scan
26 (22–28 June) 9
27 (29 June–5 July) 50
28 (6–12 July) 89
29 (13–19 July) 18
30 (20–26 July) 4

Matched to the event log by element name, the missing elements belong to the same tasks: facade elements, window frames and brickwork. That is a digital shadow doing its job: two independent records, a schedule check and a scanner, pointing at the same trades in the same weeks.

The notebook: from records to questions

A replay shows where. It doesn’t say why, and neither do the records. To see how far the records go, we used the method from our article on a business’s single source of truth: we restated the records as five plain files, wrote a one-page rulebook for a construction project, and asked an AI assistant (Claude Code) to keep a notebook from them. The rulebook’s key rule: never state a cause that no record states; write a pattern as a question for the site team.

Request Time AI cost
“Ingest every file in sources/, oldest first.” 8 min C$3.68
“Which parts of the building ran late, and what do the scans and the coordination checks say about them?” 1 min C$1.24
“What was planned for week 28, and what did that week’s scan find?” 1 min C$1.02
“Lint the notebook.” 5 min C$3.17

Costs are pay-as-you-go API prices (US$6.49 in all, at the Bank of Canada rate of 28 October 2026). The result: 21 pages, from an overview to one page per trade and per scanned week, every fact footnoted to its record, and a list of 21 open questions. Some of them:

  • The facade-setting task and the window-frame task have identical figures: 171 elements, 50 late, the same element types. Were these the same windows and doors, recorded under two tasks? If so, what held them up: the frames, the facade elements, or something else?
  • The late brickwork run was planned to start while the second frame run was still under way. Is there a dependency between them on site? The schedule shows none.
  • The scans count frames missing 106 times in five weeks; the event log has 57 late frame records. Were the same frames counted in several weeks?
  • The week 28 scan expected 10 precast band elements that the schedule plans for mid-August. Was the band brought forward, or is the comparison wrong?
  • The 4D model ends eight tasks earlier than the February schedule. Which plan was “late” measured against?

Its last step, the lint, checked its own work and corrected it: several pages had paired scan results with specific tasks more tightly than the scan records allow, and one coordination comment had been attributed to the wrong item. That self-correction is the point of making every fact cite a record.

None of this replaces the site manager. It gives the site manager, on the Monday after a bad week, a short list of the right questions, with the evidence attached.

What it would take to make it live

The replay is a shadow of a finished job. On a live project, the same structure becomes useful week by week, if three things are captured as the work happens:

  1. Progress against the model, element by element. Not “facade 60% done” but which elements are in. A tablet app, a scan, or a site manager ticking off elements in the model each Friday; the format matters less than the habit.
  2. Dates, not flags. Schependomlaan’s records say whether an element was late, not when it was actually built. Recording the actual date costs the same and answers “how late” and “what did it delay”.
  3. Reasons, in words. A one-line note when something slips (“frames delivered short”, “brickwork waiting for frames”) is the record an assistant can later connect to the pattern. Without it, the notebook can only ask.

Construction already has a standard way to hold all of this: the common data environment of the international BIM standard ISO 19650: the agreed source of information for a project, where each document moves through work in progress, shared, published and archived. The twin is what you get when that place also knows when each element was built.

Try it, and the data behind it

Sources