Methodology note. This October 2024 article has been corrected in place. The earlier version described an undocumented TerraCore deployment threshold and a four-stream client dashboard as established practice. Those statements were not independently verifiable and have been removed. This version separates standards-backed concepts from project-specific design choices and treats every technology investment as a decision to be justified.
Factory-to-site delivery creates information handoffs that ordinary drawing workflows often handle poorly: a module can be physically complete while its inspection record is unresolved; a route change can invalidate a delivery sequence; a field interface can change after fabrication release. Calling the remedy a “digital twin” does not solve those problems. A useful strategy starts with the decision that must improve, the minimum data required, and the person authorized to act.
Seven Related Tools—Not One Product
Structured information about a built asset and the process used to manage it. ISO 19650 addresses information management using BIM; a model file alone is not the whole process.
The agreed workflow and repository through which information is collected, reviewed, authorized, shared, and retained. Software does not replace status rules or named authority.
Events linked to a module or assembly: started, inspected, released, loaded, delivered, installed, or held. A scan is evidence of an event only when identity and timestamp controls are reliable.
Continuity of identity and records across design, fabrication, logistics, installation, commissioning, and operations. It is an architecture goal, not a single application.
Measurements such as location, temperature, humidity, or equipment state. Data is useful only when linked to a decision threshold and responsible responder.
A view of selected status and exceptions. It may summarize several systems without representing or controlling the physical process.
A digital representation connected to a defined physical system for a defined purpose. ISO 23247 supplies a manufacturing digital-twin framework; applying it to construction requires an explicit mapping of scope, data, services, and decisions.
Start With the Decision, Not the Label
A steel offsite team should write a short use-case statement before selecting technology: When a defined event occurs, which role needs which information, by when, to make which decision? “Show module status” is too vague. “When a factory-release inspection is rejected, notify production control and logistics before load assignment, with the nonconformance record and affected shipment” is testable.
This framing also limits scope. A project that only needs reliable release and delivery status may need disciplined production tracking and a shared exception register—not simulation, sensor networks, or control-system integration. A facilities operator evaluating equipment performance may need a different representation and data history than the construction team.
Minimum Viable Factory-to-Site Data
Persistent identity. Each tracked module, panel, skid, or critical steel assembly needs one stable identifier across drawings, fabrication records, shipping documents, and installation records. Human-readable and machine-readable markings should resolve to the same controlled record; duplicate or reused identifiers are release blockers.
Controlled status. Status values need definitions, entry criteria, authorized approvers, and reversal rules. “Complete” should not ambiguously mean fabricated, internally inspected, accepted by a third party, released for shipment, or installed.
Event record. Capture the object, event, time, source, actor or system, evidence, and any open exception. The team should specify clock, time-zone, and correction rules. Immutable raw events can coexist with a visible correction record; silently overwriting history defeats auditability.
Interface and revision. Link the assembly to the approved interface information used for fabrication and installation. If a connection, opening, embed, utility point, lifting arrangement, or shipping restraint changes, the system must identify which physical items and downstream records are affected.
Exception ownership. Every exception needs severity, responsible role, due time, disposition authority, and proof of closure. Technology can route an issue; it cannot decide whether an engineering deviation, regulatory hold, or commercial concession is acceptable.
Exchange and Interoperability: Verify the Workflow
Industry Foundation Classes (IFC), standardized as ISO 16739, is an open data schema maintained by buildingSMART. That makes IFC relevant to cross-platform exchange, but an export is not proof that required steel connections, properties, identifiers, classifications, or status data survive the transfer. Test representative assemblies in both directions before accepting an exchange workflow.
Other interfaces may use documented APIs, message queues, or controlled files. The project should define, for each flow, the source of record, schema, trigger, frequency, validation rule, error response, and owner. A screenshot or dashboard should not become an unofficial source of record.
What the NIST Benchmark Does—and Does Not—Show
A 2004 NIST-sponsored study estimated $15.8 billion in annual inadequate-interoperability costs for the U.S. capital-facilities industry using 2002 conditions and interview/survey inputs. It reported that roughly two-thirds of the quantified burden fell on owners and operators, much of it during operations and maintenance. The study remains useful evidence that fragmented information has material lifecycle consequences.
It is not a current percentage of project value, not an offsite-only result, and not a return-on-investment promise for a digital twin. An owner should build its business case from measured project baselines: duplicate entry, time to identify an exception, time to assign it, time to reach an authorized disposition, records missing at handoff, and work released against superseded information.
A Four-Level Maturity Model
Named source of record, revision control, defined status, formal transmittal, and accountable approval.
Persistent object IDs, timestamped production and logistics events, evidence links, and exception ownership.
Selected systems exchange validated data automatically; failed exchanges are visible and recoverable.
A defined physical scope and digital representation support specific analysis, prediction, optimization, or control services with measured performance.
These are editorial decision levels, not an industry standard or a claim about where the market sits. Advancement should follow a demonstrated use case. A reliable Level 2 can be more valuable than a fragile “twin” assembled from ungoverned data.
Implementation Sequence
- Choose one costly decision or handoff. Name the event, user, authority, and required response.
- Map the present workflow. Identify systems, spreadsheets, calls, duplicate entry, delays, and missing evidence.
- Define object identity and status. Freeze identifiers, status criteria, and revision relationships before adding scans or sensors.
- Assign data rights and duties. Contracts should address creation, access, retention, correction, cybersecurity, permitted use, and end-of-project transfer.
- Build the exception workflow. Define routing, escalation, disposition, and closure evidence.
- Test representative steel assemblies. Validate exchanges, permissions, offline behavior, duplicate events, and recovery from a failed interface.
- Pilot at bounded scope. Compare measured baseline and pilot performance; keep a manual recovery path.
- Scale only after acceptance. Require named acceptance criteria, training, support ownership, and an exit/export plan.
Limitations and Risks
- LOD labels communicate expected model-element development; they do not certify approval, fabrication readiness, exchange fidelity, or field accuracy.
- A common data environment can preserve workflow evidence, but only if users follow status and authorization rules.
- Telemetry may create noise, cybersecurity exposure, and false confidence when thresholds and response ownership are undefined.
- Factory process data, design intellectual property, owner records, and installer evidence do not automatically belong to one party; contracts must allocate rights.
- Automated exchange can propagate a wrong identifier or superseded revision faster. Validation and rollback are part of the design.
- ISO 23247 is a manufacturing framework, not a certification that a construction dashboard is a digital twin.
Eight Go/No-Go Checks
- Is the decision use case specific enough to test?
- Does each tracked steel assembly have a persistent identifier across systems and physical labels?
- Are status definitions, approval authority, and reversal rules documented?
- Can representative exchanges preserve the required geometry, properties, IDs, revisions, and exceptions?
- Are data access, correction, retention, cybersecurity, and handover responsibilities contractual?
- Does every exception have an accountable owner and closure evidence?
- Are baseline metrics available for comparison, without relying on the 2004 NIST estimate as a project proxy?
- Can the team operate safely and preserve records if an integration or sensor fails?
Conclusion
Most projects should earn the right to use the “digital twin” label. Start with controlled records, persistent steel-assembly identity, measurable handoffs, and closed-loop exception management. Add integration where it removes verified friction. Pursue a purpose-built twin only when a defined physical scope, reliable data, and a valuable analysis or control service justify the added governance and technical risk.