Every estate has a points schedule somewhere. It is usually a spreadsheet or a PDF produced for a project that finished some years ago, it is usually accurate about the plant that existed then, and it is usually the only record anybody has. The gap between that document and the building as it stands is where most integration effort disappears, and the gap grows every year that nothing owns the record.
The message up front: a project points schedule and an operational point dictionary are different artefacts with different purposes, and treating the first as the second is why nobody trusts it. The dictionary needs fields the schedule does not have, principally quality status, expected update interval, owner and effective dates. It needs update triggers hooked to real events rather than to good intentions. And it needs somewhere to live that is not a file attached to a closed project.
1. Two documents, not one
The project points schedule exists to price, build and prove a system. Its columns are about delivery: point type, signal type, panel and terminal, device, commissioning status. That is the right content for its purpose, and the full set is described in BMS points lists and field devices. When the project closes, the document stops being updated, because the thing it existed to serve has ended.
An operational point dictionary exists to answer questions during the life of the building. Which points does this asset have. Is this reading trustworthy. When did that change. Who do I ask. Those questions need different columns and, more importantly, a different lifecycle: continuous rather than project-bounded.
The practical consequence is that the handover schedule is the seed for the dictionary, not the dictionary itself. Copying it into a new place and calling it live changes nothing unless the maintenance process changes too.
2. What the dictionary holds that the schedule does not
| Field | What it holds | Why only the operational version needs it |
|---|---|---|
| Quality status | Trusted, suspect, known faulty, decommissioned | A project assumes every point works. An operating building knows some do not, and that knowledge is worth recording rather than rediscovering |
| Expected update interval | How often this point should report | The basis for every staleness check. Without it there is no way to decide a value is overdue |
| Collection mechanism | Polled, subscribed, or read from a trend log | Determines how to interpret a gap, per BACnet data logging |
| Asset and relationship | What this point reports on, and in what role | The join that makes a reading mean something, covered in point-to-asset mapping |
| Effective dates | Valid from and valid to | So historical analysis uses the definition that applied at the time rather than today's |
| Owner | A named role responsible for this entry | An unowned register is a register that decays |
| Last verified | Date and by whom | Distinguishes checked from assumed, which is the honest core of the whole document |
| Change history | What changed, when, why, by whom | Explains a discontinuity in the data years later, which nothing else will |
Quality status is the field that changes behaviour
Of everything in that table, the one that earns its place fastest is quality status. Every estate has points that somebody knows are unreliable, and that knowledge lives in one or two people's heads. Writing it down converts tribal knowledge into something an analytics rule can read, a new starter can see, and a report can exclude. It also makes the scale of the problem visible for the first time, which is usually the moment somebody funds fixing it. A dictionary with a quality column and nothing else would still be worth building.
3. Update triggers, because good intentions fail
A register maintained when somebody remembers is a register that is current for about three months. The events that must write to it:
- Controls work of any kind. Points added, removed, renamed, re-ranged or re-mapped. The lever is contractual: make the dictionary update a named deliverable, as with the other handover items in BMS service contracts.
- Instrumentation work. A replaced or recalibrated sensor changes what the history means, which is the subject of sensor replacement and BMS history.
- Asset changes. Plant replaced, retired or re-parented invalidates the mapping, even where the point is untouched.
- Space changes. Fit-outs happen more often than plant replacement and nobody thinks to tell the controls record.
- A point flagged as suspect by monitoring. The quality status should be writable by the automated checks described in BMS data completeness KPIs, not only by people.
- Periodic verification. A scheduled sample, prioritised by criticality, that refreshes the last-verified date on the points that matter.
4. Where it should live
The three candidates, in increasing order of usefulness.
- A spreadsheet. Better than nothing and the usual starting point. Fails on change history, concurrent editing and any automated read. Acceptable for a small single building if somebody genuinely owns it.
- Inside the building system. Tempting, because the points already exist there. The problem is that it dies with the head end, and the operational fields in section 2 usually have nowhere to go. It also puts your record behind whatever access the controls contract allows.
- In the maintenance or facilities system, alongside the asset register. The dictionary is asset metadata, it has the same lifecycle as the asset record, it needs the same governance, and it needs to be readable by the same people. This is where I would put it, for the same reasons set out in master data management for assets.
Wherever it lives, it must be queryable rather than only readable. A dictionary that cannot be joined to telemetry or to the asset register is documentation, and documentation does not participate in anything.
5. Seeding it without a two-year project
The instinct is to build it completely before using it, which is how these efforts stall.
- Start from a discovery scan, not from the handover document, because the scan describes the building now. The method is in BACnet device discovery.
- Populate the structural fields automatically. Identity, device, object type and whatever the devices report about themselves. That is most of the rows and none of the effort.
- Mark everything unverified at the start. Honest, and it makes progress measurable.
- Fill the operational fields only for points that matter: those that alarm, those feeding analytics, those on critical assets. That is a small fraction of the total and nearly all of the value.
- Let the rest accumulate through the triggers. A point nobody has needed in two years does not need a curated entry.
6. Measuring whether it is alive
- Share of points with a verified entry, weighted by asset criticality. The headline.
- Age of verification, trended. A dictionary whose average age only increases is not being maintained, whatever anyone says.
- Entries updated per month, by trigger type. If controls work is happening and producing no dictionary updates, the contractual hook is not working.
- Points in the data with no dictionary entry, and entries with no corresponding point. Both directions matter.
- Points marked suspect or faulty, as a count and as a trend. Rising is not necessarily bad; it may mean the monitoring finally works.
The honest limit
A dictionary records what somebody believed when they wrote the entry. It cannot tell you that a sensor was physically moved during a refurbishment nobody documented, and no field in it will ever catch that. Periodic physical verification on a sample is the only defence, and the right posture is to accept that a proportion of any large register is wrong and to know roughly what that proportion is. An estate claiming a fully verified dictionary that cannot say when it last sampled does not have one. This article is written from the data governance side, which is my domain; establishing what a point physically reports on is a survey task for somebody with the plant in front of them.
The idea to walk away with
The handover schedule and the operational dictionary serve different purposes and have different lifecycles, and conflating them is why most estates have a record that was accurate once. The dictionary needs quality status, expected interval, ownership and effective dates, it needs update triggers wired to real events rather than to memory, and it needs to live with the asset register rather than inside the controls system.
Seed it from a scan, mark everything unverified, curate only the points that matter, and let the triggers do the rest.
Final thoughts
A quick test of where you stand: pick five points that feed something important and try to establish, from documentation alone, what each one measures, when it was last checked and who owns it. Time how long it takes.
In most estates the answer for at least one of the five is that nobody can say, and the effort to find out for the other four is measured in phone calls. That is the cost the dictionary removes, paid once per question rather than once per point.
Disclosure
Alongside advisory work I also build a CMMS and CAFM platform, so I have a commercial interest in this category. Nothing above is a recommendation for it, and no vendor named here has paid for inclusion or had any editorial input. Weigh the analysis accordingly.
Points record that stopped being true?
Independent help turning a handover schedule into a maintained point dictionary: the fields that matter operationally, the update triggers that keep it current, and where it should live. 22+ years across CMMS, CAFM, EAM and ERP implementations.
Book a conversationRelated reading: BMS points lists and field devices, BMS point-to-asset mapping, BACnet device discovery, BACnet data quality flags, Master data management for assets, BMS data completeness KPIs.
Muhammad Abbas
CMMS / CAFM Manager & Independent Advisor · 22+ years across enterprise CMMS, EAM, CAFM and ERP implementations in utilities, oil and gas, manufacturing, government and facility operations.
Work with me