Minimum Viable Digital Twin for Existing Buildings: A Facility Manager's Practical Framework for 360° Reality Capture, Structured Asset Data and Operational Integration

Guidance on digital twins in the built environment generally assumes a coordinated model already exists — a reasonable premise for new construction, and the wrong starting point for the buildings most facility managers actually run. A twenty-, forty- or eighty-year-old building typically begins from incomplete or superseded drawings, an asset register of uncertain accuracy, renovations that never reached the record set, work-order history rich in text but poor in spatial context, and operational knowledge held by two or three long-serving technicians. For those buildings, Hanov argues, the standard advice — model the asset, instrument it, then analyse it — describes a destination without a route.

Minimum Viable Digital Twin for Existing Buildings supplies the route. It defines a minimum viable digital twin as the least amount of connected spatial, asset and workflow information that measurably improves one operational outcome, is synchronized with the physical facility at a stated frequency and fidelity, and can be governed and audited. The recommendation is narrow by design: begin with one operational problem, one governed spatial baseline and one trustworthy set of linked asset information, and add geometry, sensors, analytics and automation only when a demonstrated operational need justifies them.

Existing buildings start differently

The paper opens by naming three assumptions imported from new construction that cause most of the difficulty. The completeness assumption — aiming at a comprehensive dataset covering every system — becomes a survey of the whole building before any operational benefit is available, and such programmes tend to exhaust their budget during data collection. The geometry-first assumption inverts the real priority: in an operating building, geometry is the expensive part and often the least urgent, because a technician dispatched to an unfamiliar mechanical room needs to know which unit, where it is, what it serves and what was last done to it — not its exact dimensions. The single-handover assumption fails because an existing building has no single moment when information transfers; it arrives unevenly from contractors, vendors, inspections and internal projects, so a programme that treats collection as a one-time event produces a record that begins ageing immediately. The practical consequence is to start with an operational use case, not a technology.

Hanov reinforces the point with cited research: work published by the IFMA IT Community with Autodesk reports that 85 percent of surveyed facility operators struggle with poor-quality data, 80 percent of firms do not consistently involve operations teams in design and construction, and more than half of facility teams waited over six months after project completion for final closeout documentation; and a 2004 NIST study estimated the annual cost of inadequate interoperability in the U.S. capital facilities industry at US$15.8 billion, roughly two-thirds of which fell on owners and operators rather than designers or constructors.

What a twin is — and what a virtual tour is not

The paper’s central distinction concerns 360-degree imagery. A virtual tour is a reality-capture layer — valuable, quick to produce, easy for technicians to use — but on its own a visual record, not a digital twin. It becomes part of a minimum viable digital twin only when locations and assets carry stable identifiers, those identifiers resolve to records in an authoritative system such as a maintenance platform, and the imagery is refreshed on a defined schedule as the building changes. Drawing on the Digital Twin Consortium and NIBS definitions, Hanov isolates the two elements that do the real work: synchronization separates a twin from a record, and specified frequency and fidelity make the claim testable. A representation synchronized quarterly at room-level fidelity is a legitimate twin for the decisions quarterly room-level information can serve — and is not one where hourly equipment-level state is required. Most minimum viable twins receive condition information and act on it through human-mediated workflow rather than automated control, and continuous data earns its cost only where a decision is genuinely time-sensitive, which is a reason to instrument specific equipment, not a whole building.

The discipline that follows is a one-sentence written claim for any representation the organization operates or procures: what is represented, at what fidelity, refreshed at what frequency or on which triggers, connected to which systems of record, and owned by whom. “Panoramas of all mechanical spaces, refreshed annually and on project closeout, linked to the maintenance system, owned by the facility information manager” can be tested, budgeted and audited; “a digital twin of Building C” cannot.

Six minimum requirements and a maturity ladder

A representation qualifies as a minimum viable digital twin when it satisfies six requirements, each stated with its least acceptable implementation, its common failure mode and the evidence an auditor could inspect: a defined operational outcome (a named, measurable, baselined problem, not a technology objective); navigable spatial context (dated 360-degree panoramas under a documented building, floor and space hierarchy); unique location and asset identities (one persistent, opaque, non-reused identifier per item, used identically across every system); connections to authoritative information and workflows (each asset resolves to its record in the system authoritative for it — the twin is a route to authoritative data, not a competing store); defined synchronization and change management (a written schedule of frequency, fidelity, triggers and owner); and governance, cybersecurity and trust. The requirements function as a set, and the weakest determines what the twin can be trusted to do — omit identity and the record cannot be integrated; omit synchronization and it expires.

A six-stage maturity ladder describes capability rather than expenditure: Stage 0, fragmented facility information; Stage 1, a navigable visual record (normally not a twin); Stage 2, a contextual model (a minimum viable twin only when paired with a documented synchronization process); Stage 3, the minimum viable operational twin, where most of the operational value available in an existing building already sits and which most buildings can reach for a bounded scope within one budget cycle; Stage 4, an analytical twin; and Stage 5, a predictive or closed-loop twin. Two rules govern movement: progression is per use case and per scope — a portfolio may coherently hold one building at Stage 3 and the rest at Stage 0 — and stages are not skippable in substance, because an organization can buy Stage 5 technology at any time but not the identity discipline and synchronization habit that make its outputs believable.

Capture methods, data and the pilot

A vendor-neutral comparison of eight capture methods — from 360-degree still photography (low cost, high context, but not measurement-grade) through smartphone LiDAR, photogrammetry and mobile mapping to terrestrial laser scanning — is framed by a single question: what decision must the information support, and what is the consequence of it being wrong by a measurable margin? The paper is emphatic that ordinary 360-degree imagery is not survey- or measurement-grade; where a decision depends on a dimension, accuracy should be specified in procurement against a recognized framework such as the USIBD Level of Accuracy Specification and the deliverable validated against it.

For asset data, the paper prescribes a deliberately small minimum dataset that can actually be completed, verified and dated, with each field assigned to exactly one authoritative system — the CMMS or EAM, the workplace management system, the building management system, or the document management system. Its governing rule: any field mastered elsewhere should be displayed by the twin, not stored by it. The single most useful field in an inherited asset register, Hanov argues, is the date each value was last verified — and inherited values should be carried across as “reported” until field verification upgrades them, because bulk-importing them as “verified” is the fastest way to make that field meaningless.

A fourteen-step capture-to-operations sequence runs from selecting use cases and establishing the location hierarchy (the administrative step most often skipped, and the one that determines whether every later link is possible) through capture, identifier validation, linking, access control, synchronization rules, task-based training and outcome measurement. The pilot is bounded to a single building and no more than three use cases, exists to produce evidence rather than coverage, and requires baselines measured before implementation — because a baseline measured afterwards is an estimate, and estimates cannot support a business case.

A defensible business case, and honest governance

The paper insists that generic digital-twin savings percentages — usually drawn from sensor-dense or new-construction deployments, often vendor-sponsored, rarely disclosing their method — should never be used as evidence of value in a particular building. It supplies transparent formulas instead, and a discipline: every line in the case is labelled a measurement, an assumption or an estimate, visible to whoever approves it. Its worked scenario is explicitly hypothetical, offered to demonstrate the arithmetic rather than any real outcome, and its own honest conclusion is that a case in which most benefit lines are assumptions justifies a measured pilot, not a portfolio rollout.

Governance, privacy and cybersecurity are treated as founding requirements settled before capture, not retrofitted after publication: a named data owner distinct from the platform administrator, least-privilege role-based access, time-bounded contractor access reviewed on a schedule, restricted-area registration with the security function, written privacy rules communicated to occupants, tested backups and — given as much weight as implementation — exit provisions covering data ownership, export rights in a documented non-proprietary format, hosting jurisdiction and obligations on termination. A risk table pairs each common failure mode with an early indicator and a control, and a procurement section — expanded into a paste-ready RFP question set — reframes platform selection as an information-governance decision: who owns and can export the data, what is authoritative and how integration is achieved, who can see what, and what happens on termination.

The paper’s closing discipline captures its argument: identity before capture, connection before expansion, measurement before claims — the practical meaning of minimum viable being “not the least that can be bought, but the least that can be trusted.” It is vendor-neutral, naming no commercial platform; the full framework, figures, five working appendices (the minimum-viable-twin checklist, the 360-degree field checklist, the asset data dictionary, the pilot scorecard and the RFP question set) and references are in the PDF.