I want to be upfront about something before I say anything else. LOOM is not an acronym. It is not a carefully constructed abbreviation reverse-engineered to fit a clever name. The name came first, as a reference to weaving, to the idea of threads being brought together into something coherent and structured. Everything else followed from the problem we kept running into on live NHS estate projects.
This is the story of how it developed, because I think the context matters if you are trying to understand what LOOM actually is and what it is not.
It started with two documents nobody could agree on
Anyone who has spent time on NHS capital or estates programmes will know this situation. A project kicks off. The information management conversation eventually lands, as it always does, on the same two questions: what asset data does the Trust actually need to collect, and how do you define that clearly enough that it can go into a contract and be tracked through to delivery?
In practice, that meant two documents. An Asset Data Dictionary, which is a structured reference set of every data parameter required for every asset type across the estate. And an EIR Appendix, the technical annex to the Exchange Information Requirements that turns those parameters into enforceable handover obligations tied to RIBA stage gates and COBie.
Neither of those documents had a reliable home. They existed in various forms across various projects, none of them consistent, none of them fully auditable, and none of them easy to maintain. Every time a project needed them, somebody was rebuilding them from scratch, using whatever the previous project had done as a loose reference, and issuing them with varying degrees of confidence in whether they actually reflected current regulatory requirements.
That was the starting frustration. Not a grand market insight. Just a recurring, practical problem that was costing time and creating risk on every engagement we touched.
The Building Safety Act changed the stakes
While we were working through this, the regulatory landscape shifted considerably. The Building Safety Act introduced the concept of the Golden Thread into statute. A complete, accurate, and maintained digital record of every asset, system, and safety-critical component in a building was no longer just good practice. It was a legal obligation.
That matters because the NHS estate was nowhere near ready for it. Industry data consistently shows that as-built information completeness across the NHS averages around 40% of what is actually required. The remaining 60% is a mix of missing records, legacy paper, conflicting datasets, and information buried in CAD files or unstructured O&M manuals. That is not a minor gap. It represents legal exposure at Building Safety Gateways, operational risk for maintenance teams working from incomplete records, and significant financial cost from reactive maintenance driven by poor asset intelligence.
The gap was always there. The Act made it visible and made closing it unavoidable.
Building the documents revealed the bigger problem
So we built the Asset Data Dictionary properly. Over 500 parameters, classified by discipline, aligned to ISO 55000 and cross-referenced against every relevant compliance framework including COBie and FIREie. Then we built the EIR Appendix to sit alongside it: a structured, stage-gated document that gave projects something they had never had before, which was a consistent and auditable basis for defining what information was required, from whom, by when, and to what standard.
Both documents worked. But building and applying them made something else very clear. Knowing what information you need is only the first part of the problem. The harder questions are whether you currently have it, how far from compliant you actually are right now, who is accountable for closing that gap at each stage of a project, and how you demonstrate to a regulator, an insurer, or a Trust Board that progress is being made in a structured and evidenced way.
Documents could not answer those questions. That is when the idea of a platform started to take shape.
What LOOM became
LOOM takes the Asset Data Dictionary and EIR Appendix as its foundation and builds around them a set of structured capabilities for golden thread governance and compliance assurance across the full lifecycle of an NHS estate.
LOOM | Map is the Asset Data Dictionary itself. The 500-plus parameter reference framework, classified by discipline and cross-referenced against ISO 55000, COBie, and FIREie. It is the authoritative baseline against which everything else is measured.
LOOM | Lens is the gap analysis engine. It takes the data a Trust currently holds, assesses it against the ADD, and produces a Data Maturity Score with a remediation-ready gap report broken down by discipline. It tells you exactly where you are and exactly what needs to change. Lens provides the Board-level view. RAG status, risk narrative, and structured assurance evidence, presented in a format that works for all stakeholders.
LOOM | Trace maps EIR obligations to RIBA Plan of Work stage gates and assigns named accountability for each data delivery milestone. It is the mechanism for tracking progress against legal thresholds throughout a project or programme.
What LOOM deliberately is not
This is the part I think is most important to be clear about, because it is where a lot of platforms in this space get it wrong.
LOOM does not replace a Common Data Environment. It governs what goes into one. LOOM does not store asset data. It defines, audits, and tracks it. LOOM does not duplicate CAFM, CMMS, or clinical systems. It references and validates against them. LOOM is not a data collection tool. It is a compliance and assurance layer.
The NHS estate already has places to store information. That has never been the problem. The problem is the absence of governance around what information should be held, whether what is currently held meets regulatory requirements, and who carries accountability when it does not. That is the gap LOOM was built to fill, and staying within that scope is a deliberate design choice, not a limitation.
The temptation when building any platform is to expand scope: to become the system of record, to ingest the data, to own more of the workflow. We have resisted that consistently. LOOM’s value is in the governance layer, and every time we have considered extending beyond it, we have come back to the same conclusion, which is that the market does not need another place to put information. It needs a structured and evidenced way to know whether the information it already has is good enough.
Where it stands now
LOOM is developed and maintained by 42DC, with implementation delivered in partnership with specialist BIM and information management consultancies working at the programme level.
The regulatory direction is not changing. Building Safety Act obligations are not softening. NHS England’s guidance on digital estates and the National Hospital Programme’s information management requirements consistently point toward more structured, more accountable, and more auditable asset information management. The 60% gap is not going to close by itself.
LOOM exists because two practical documents, built in response to a problem we kept seeing on real projects, revealed something the documents alone could not solve. The platform that came out of that process is not the one anyone planned at the outset. It is the one the problem required.