Griotech Field Guide / Volume Two
The Field Guide to Building Performance
Second edition · Revision 2 · Oct 2026
The Continuous
Audit.
a continuous, causal evaluation of how a building is performing, delivered as a briefing, ranked by what the building is exposed to, verified against baseline.
Foreword / Why this guide exists
A note from
the founder.
a thirty-year observation that buildings drift, our tools describe, and the gap between intent and operation has stayed open longer than anyone has the right to defend.
've spent the better part of three decades inside commercial buildings, watching them underperform. Not dramatically. Most of the time, just quietly, persistently, expensively. A chiller short-cycles. A valve lets by. A setpoint drifts. A schedule gets overridden and nobody remembers. The BMS logs it all and flags very little. The energy bill arrives. Nobody quite knows why it's larger than it should be.
The buildings I saw weren't broken. They were working. They just weren't working well, and nobody could say by how much.
Our industry has spent twenty years trying to close that gap with tools that describe it instead of closing it.
We built dashboards. We deployed analytics platforms. We commissioned annual audits. We layered AI onto BMS data and called it intelligence. And the gap stayed open, because none of those tools were actually designed for the job. They were designed to show. The job is to judge.
I started GRIOTech to build the tool I always wanted as an engineer. Something that runs continuously, reasons causally, and tells me what to fix first and why. Not a dashboard to interpret. A judgement to act on.
This guide is about what it takes to close the performance gap, not describe it. It's about what a continuous audit actually requires, architecturally and methodologically. It doesn't name our product much. There's a time and a place for that, and it isn't here. What it does is try to give you a clear framework for evaluating any platform that claims to close the gap in your buildings, ours included.
If you read this and come away better equipped to ask the right questions of any vendor, we'll have done our job. If you read it and want to see what the answers look like in practice, you'll know where to find us.
A note on this edition. When this guide first appeared in April, it measured everything in recoverable value. That was half the picture. Some of the most consequential findings in a building carry no honest price: a standby pump that has never proved it can take over, a sensor that has quietly gone blind, a floor that is cheap to run because it is not being served. This edition widens the measure. The argument has not changed. The ledger has.
Designed to show. The job is to judge.
— Horace Cyrus, Founder/London · April 2026 · Revised October 2026
Chapter One / The problem, measured
The Performance Gap.
the measurable difference between what a building consumes and what it should consume, given its systems, occupancy, and conditions; the largest untapped efficiency opportunity in the built environment.
etween the building you designed and the building you operate, a gap opens. It opens slowly, and it opens in ways that no single system sees.
Sensors drift out of calibration. Equipment ages and loses efficiency. Setpoints wander, nudged by complaints, edited during commissioning, forgotten about afterwards. Occupancy patterns shift. Weather compensation curves that made sense in year one stop matching reality in year five. Override commands get entered and never removed. The building stops behaving the way the design engineer intended, and nobody's job is to notice.
By year five of operation, most commercial buildings run 20–40% below their design intent. Not because they're faulty. Because they're drifting. And because the tools built to watch them can only show what they're doing. Not whether what they're doing is right.
The building isn't broken. It's drifting. And nothing in the operational stack is designed to catch drift.
This is the performance gap: the difference between what a building consumes and what it should consume. Multiplied across a portfolio, it is one of the largest untapped efficiency opportunities in the built environment. Buildings account for roughly a third of global emissions. A meaningful portion of that share is waste. The arithmetic is not subtle.
Consumption is where the gap is easiest to see, but it is not the whole of it. A supply fan that fails to start uses less energy, not more, while the floor it serves goes without air. A standby pump that has never proved it can take over costs nothing at all, right up until the day it is needed. A drifting sensor hides its own consequences. A building can look efficient on its bill while withholding service, carrying risk and running partly blind. The gap is measured in consumption. What a building is exposed to by leaving it open is wider than that.
What is subtle is why the gap is so hard to close. It isn't a technology problem, at least not in the sense of needing new sensors or better hardware. The data is mostly there. The BMS has been streaming it for years. The gap persists because nobody is looking continuously, and because the tools that do look weren't designed to judge.
Closing the gap requires three things that the current operational stack does not deliver: continuous evaluation, causal reasoning, and a communication model that replaces dashboards with decisions. That's what this guide is about.
Chapter Two / A taxonomy of shortfalls
Why existing
tools can't close it.
the four categories of building performance software currently in market (BMS analytics, fault detection, smart building OS, and digital twin), each addressing a fragment of the problem. None designed to close the gap.
he market for building performance software is crowded. Most platforms fall into one of four categories. Each gets part of the problem right, and structurally leaves the rest of it on the table.
BMS analytics platforms
BMS analytics platforms sit on top of your existing Building Management System and surface its data. They are, at their best, excellent at visualisation. Trend graphs, consumption charts, alarm feeds, weekly summaries. The better platforms in this category process billions of data points a year and deliver the kind of reporting that satisfies an ESG team.
Their limitation is structural. They show what the BMS is doing. They don't judge whether it's working. An analytics platform can tell you that the supply air temperature is 14°C. It cannot tell you that 14°C is 2°C high for these conditions and costing you £6.40 a day at this AHU. The human has to make that judgement, every time, for every deviation, across thousands of points. At the scale of a modern portfolio, this is the needle-in-the-haystack problem that the analytics category was meant to solve and didn't.
Fault detection and diagnostics (FDD)
FDD platforms go one step further. They apply rules to the data and flag faults. A valve stuck open. A damper stuck closed. Simultaneous heating and cooling. Schedule violations. The strongest FDD platforms have libraries of thousands of rules and can detect genuine faults reliably.
The structural limitation is different. FDD flags symptoms in isolation. A valve-letting-by alarm tells you the valve is failing. It does not tell you the fault is upstream of three AHUs and costing £27 a day in parasitic heat load, or that the downstream effect is a 2.4% comfort degradation across twelve zones. The fault list grows every day. Prioritisation becomes a workshop exercise, not a system output. And the loop, from detection to action to verification, rarely closes.
Smart building operating systems
A newer category of platform positions itself as an operating system for the building, unifying BMS data, IoT streams, lighting, access control, metering, work order management, and a dozen other systems into a single interface. The ambition is admirable. At scale, the integration work these platforms do is genuinely valuable.
But an operating system unifies. It does not judge. The tools that sit on top of a unified data layer are still BMS analytics, still FDD, still monitoring dashboards, just richer in data sources. You end up with more context around each alert and the same fundamental problem. Who is making the judgement call about what to do next?
The digital twin
The term "digital twin" has become the most overloaded phrase in building technology. It means at least four different things depending on who's using it.
Sometimes a physics-based simulation model of individual equipment. Sometimes a data integration ontology, a normalised schema layered on top of diverse building systems. Sometimes a statistical or machine-learning consumption baseline that predicts expected energy use. And sometimes simply a 3D geometric visualisation with sensor data pinned to it, often BIM-derived.
These are four different technologies solving four different problems. None of them, individually or together, closes the performance gap. A simulation tells you how a chiller should behave. It doesn't cost the deviation across the system chain. An ontology unifies data. It doesn't judge it. A baseline predicts consumption. It doesn't isolate which fault is responsible for the deviation. A 3D model shows you where things are. It doesn't tell you how they affect each other.
There is a quieter limitation shared by all four. Where these tools measure consequence at all, they measure it in energy. A fault that wastes energy rises to the top of the list. A standby pump that failed its last changeover wastes nothing, so it barely registers, though it is the fault most likely to take a floor out of service. A tool that can only count kilowatt-hours will always rank the visible loss above the hidden one.
The BMS tells you what it's doing. Analytics tells you what it's done. FDD tells you what's broken. None of them tell you whether it's working.
Chapter Three / Five principles
The Continuous Audit.
a deliberate replacement for the operational stack: continuous in time, causal in reasoning, conclusion-first in communication, ranked by exposure, and verified against baseline through the closing of the loop.
continuous audit is the deliberate opposite of the current operational stack. Where the stack shows, the audit judges. Where the stack reports monthly, the audit runs continuously. Where the stack flags symptoms, the audit traces causes. Where the stack produces dashboards, the audit delivers briefings.
Five principles define what a continuous audit actually requires. A platform that claims to deliver one should deliver all five. Anything less is a rebrand of the tools this guide has just described.
Continuous, not occasional
Annual audits and quarterly reviews are structurally unable to close a gap that opens every day. By the time a fault is surfaced in a quarterly report, it has been costing money for weeks or months. By the time it's actioned, the next fault has already opened. The arithmetic of occasional auditing cannot keep up with the arithmetic of continuous drift.
Continuous means always-on, not periodic. A real continuous audit evaluates every system, continuously, against what it should be doing under current conditions. Not just the systems that have triggered alarms. All of them.
Causal, not correlational
A correlational model notices that two things happened together. A causal model knows why. Most existing tools are correlational. They see that chiller output is elevated and zone temperatures are high, and correlate the two into an alert. A causal model traces the relationship through the system chain (Generation, Distribution, Air Handling, Zones), and identifies which system is driving which effect, with cost attributed at every node.
Causal reasoning is what turns a fault list into an action plan. Without it, every alert is equivalent. With it, every alert is ranked by what fixing it is worth to the building.
A conclusion, not a chart
An audit is communication as much as it is analysis. The primary output of a continuous audit should not be a dashboard. It should be a briefing — a document that opens with a conclusion. The evidence is underneath, one click away, when you want it. The conclusion is at the top because that is where conclusions belong.
A dashboard is a test of the reader. A briefing is a test of the author. Only one of them respects your time.
Exposure, not alerts
The unit of output of a continuous audit is not an alert in a feed. It is a plain statement of what the building is exposed to by not acting, attached to every finding, in terms the reader can weigh. That exposure takes five forms, and a continuous audit reports all of them.
Recoverable value. Energy and money lost to a fault, measured against a defensible baseline and stated per operating day. It accrues while the fault is open and is projected forward if the fault is left.
Service withheld. The shortfall between the service a system was asked for and the service it delivered, counted only while it was demanded. A floor that went without cooling for forty occupied hours was withheld forty hours of service, whatever the energy bill says.
Risk. The vulnerability a building carries if a function is called on: a standby that cannot take over, a plant running without its redundancy. Risk is counted in days carried, with the consequence stated in plain words.
Assurance. Whether a required capability has been proven, and whether an obligation to prove it has been met. A changeover test that is overdue under the maintenance contract is a finding in its own right.
Observability. What the audit can no longer measure. A drifting sensor does more than produce one bad reading. It blinds every calculation that depends on it, and those calculations are marked unmeasured, never quietly reported as zero.
The first two are losses. They can be measured, and they can be priced. The last three are states. They have no honest price, because pricing them would mean inventing the probability of a failure that has not happened, or guessing the value of something the audit cannot see. So they are counted in days and hours, and the audit says when each will get worse: this becomes urgent in nine days if nothing is done.
Three rules keep the whole thing honest. Unlike exposures are never added into one number; hours of withheld service cannot offset pounds, and energy saved because a fan has failed is not a saving. Every figure says how it was reached: at least, where it was measured, approximately, where any part was estimated. And missing evidence is never zero impact.
Some findings cost money. Some cost nothing until the day they are needed. A continuous audit counts both, in their own terms.
Verification, not just detection
The final principle is the one most existing tools fail to close. A fault is detected. An action is recommended. A work order is issued. An engineer resolves it. Then what?
In most tools, the fault disappears from the list and the system moves on. A continuous audit treats that as the start of the verification phase, not the end of the action. Did the saving hold? Did the value actually recover, or did the same fault return three days later under a different ticket? Was the fix durable, or did it compensate by shifting load to another system?
Without verification, the loop never closes. A continuous audit measures the outcome against baseline until it is confident the exposure has gone, and surfaces it again the moment it returns. It verifies on the right clock, too. A performance fault is proven cleared over clean operating periods; a weekend proves nothing. A sensor fault is proven over calendar days, including the still hours when two sensors in the same air should agree.
Chapter Four / A worked example
What good looks like.
to walk two faults through detection, reasoning, exposure, action and verification: one that costs money every day, and one that costs nothing until the day it is needed.
he abstract is clarifying. The concrete is persuasive. Here is what a continuous audit does in practice, walked through two faults from detection to verification. The first is the kind every tool can see. The second is the kind most tools miss. The numbers are illustrative, taken from a real commercial building we audit, rounded for readability.
Monday morning, 06:47
A continuous audit runs overnight against every system in the building. At 06:47 on Monday, the cognitive engine flags a fault on AHU-01: the low-temperature hot water (LTHW) valve is "letting by." Not closing fully when commanded shut, allowing hot water to pass through the coil when it should be inactive.
The symptom, detected by the fast heuristic layer, would be familiar to any good FDD platform. Supply air temperature deviating upward from setpoint under commanded-closed conditions. The fault flag is the easy part. What happens next is where the continuous audit separates from the rest.
The cognitive engine asks why
The deeper reasoning layer does not accept the detection at face value. It follows a deliberate sequence — curiosity, coincidence, contradiction, reframing — to cross-examine the data.
Curiosity: what would this fault normally cause, and is that actually what we're seeing? Coincidence: what else changed at the same time? Contradiction: do any of the metrics contradict the fault hypothesis? Reframing: if the valve isn't the problem, what else could produce this signature?
In this case, the engine validates the hypothesis. The Mixed Air Temperature is stable, the chilled water circuits show the expected parasitic load, the adjacent AHU is behaving normally, and the fault signature is consistent across multiple reasoning axes. Confidence: Medium. The engine assigns a scope: six systems affected.
The impact trace
This is where a continuous audit looks nothing like FDD. The engine doesn't just log the fault. It traces its impact upstream and downstream, attributing consequence at every node in the Performance Chain.
Upstream: the parasitic heat load is raising demand on the Chilled Water Secondary loop (≈ £2.20 a day), the LTHW Secondary loop (≈ £2.16 a day), and by extension the Chilled Water Primary circuit (≈ £3.20 a day). Total upstream: ≈ £7.56 a day.
Local: AHU-01 is running harder to compensate, consuming an additional 9.3 kWh a day at ≈ £1.77. Downstream: elevated return temperatures are reducing the effectiveness of the FCUs it serves (≈ £1.63 a day), and comfort across the affected zones has degraded by 2.4% against baseline.
The finding then states its exposure in full. Recoverable value: ≈ £10.97 per operating day and 63 kWh in excess consumption, projecting to ≈ £2,700 a year if left. Service withheld: none; the zones are warm, but every system is still delivering what was asked of it. Risk and assurance: not applicable to this fault. Observability: evaluated, all points healthy. Each line is a statement, including the ones that say nothing is there.
A valve fails upstream. The air handler compensates. The zones drift. Every effect, counted.
Action, verification, closure
The engineering team replaces the actuator. From that moment, the audit verifies. The parasitic heat load drops. AHU-01's comfort score recovers. The downstream FCUs return to baseline. Over the clean operating days that follow, the engine measures the saving against the pre-fault baseline, banks it against the work order, and moves the fault to the closed state.
Over the course of one month: one fault identified, one action prioritised, one fix completed, and at least £340 of recoverable value banked. Not merely flagged. Measured.
Tuesday afternoon, 14:10
The second fault looks nothing like the first. On Tuesday afternoon the controls run the monthly changeover test on the chilled water secondary pumps. Duty pump A is commanded off and standby pump B is commanded on. Pump B never reports running. After a short delay the controls fall back to pump A, which picks the load straight back up. No zone warms. No alarm escalates. The energy bill will not move by a penny.
Most tools would log a status mismatch and move on. There is nothing to price, so there is nothing to rank. A continuous audit asks a different question: what is this building now exposed to?
Risk: the secondary circuit is running at N rather than N+1. If pump A trips, chilled water circulation is lost, and with it cooling to every air handler the circuit serves. The audit states that consequence in those words and starts counting the days it is carried. Assurance: the maintenance contract requires a proven changeover every month, and this was the month's test. The obligation is now unmet, and that is recorded as a finding of its own, against the clause that sets it. Recoverable value: not applicable. Service withheld: none yet.
No pound sign appears anywhere on this work order, and none should. Pricing it would mean inventing the odds of pump A failing and the cost of the day it does. What the audit can say with certainty is when the finding gets worse. It is ranked second priority today, and it becomes first priority if the next changeover attempt also fails.
The most consequential finding of the week had no price. It had a date by which it would get worse.
The engineer finds a tripped overload on pump B and replaces a worn contactor. The audit does not take the fix on trust. It commands a fresh changeover, watches pump B take the load and hold it, records the redundancy as proven, and closes the finding against the obligation. Twelve days carried. Nothing lost. Nothing priced. Something real removed from the building's exposure.
That morning's briefing for the whole building reads one line per kind of exposure, each in its own terms: ≈ £18,400 a year of open recoverable value, thirteen service-hours withheld, one asset without proven standby, one obligation overdue, one point blind. Nothing is added to anything else. Across thirty-one active faults, and a portfolio of twenty similar buildings, that is the arithmetic that matters.
Chapter Five / Five questions for any vendor
Choosing the right tool.
five questions to ask any vendor in the building performance space; five answers that distinguish a tool that describes the gap from a tool that closes it.
f you take nothing else from this guide, take these five questions. Every vendor in the building performance space should be able to answer them. Most cannot. The gap between "can" and "cannot" is the gap between a tool that describes the performance gap and a tool that closes it.
01
How often does the platform evaluate every system in the building?
Not "how often does it collect data." Every tool collects continuously. The question is how often it judges. If the answer involves "weekly," "monthly," or "when a user runs a report," the platform is not a continuous audit. It is a reporting tool with a real-time feed.
02
When a fault is surfaced, what is attached to it?
A good answer: its exposure, stated in its own terms. Recoverable value per operating day where there is a loss to price. Service-hours withheld where a system has fallen short. Days carried, and a plain consequence, where resilience is unproven. An overdue date where an obligation has lapsed. A list of what the platform can no longer see. Then a confidence score, a scope across connected systems, and a recommended action. Ask what it shows when it cannot measure something. If the answer is zero, be careful. A typical answer: a severity label and a timestamp.
03
Can the platform show me how a fault propagates upstream and downstream?
Most cannot. Ask to see the impact trace for a real fault on a real building. If the demonstration shows you a single equipment-level view, the platform is doing FDD. If it shows you a causal chain with consequence attributed at each node, the platform is doing something closer to an audit.
04
What does the platform do after a fault is resolved?
A good answer: it verifies the outcome against baseline, confirms the exposure has gone, and surfaces the fault again the moment it returns. A typical answer: the fault is marked as closed and the platform moves on. Without verification, every platform produces the same faults year after year.
05
When I ask the platform a question, does it give me an answer or a dashboard?
This is the cultural question, and it is more important than it sounds. A platform built to show will give you charts. A platform built to judge will give you conclusions. Ask: “what should I fix first in this building today, and why?” If the answer is “here are the active alerts,” the platform is not doing the job. If the answer is “this fault, for this reason, and this is what it exposes you to,” the platform is.
The vendors who can answer these are in a different category from the ones who cannot.
The cultural question is the one that matters most.
Closing / The category has moved
The category has moved.
to recognise that an industry's tools have outlived their original job, and that the language, the architecture, and the deliverable have all shifted underneath them.
The performance gap is real. It is measurable. Closing it requires the work, and the work requires a different kind of tool than the one most buildings have.
The performance gap is not a new problem. The industry has been aware of it, and trying to close it, for at least two decades. What is new is the recognition that the operational stack we built to close it — analytics platforms, FDD, smart building operating systems, digital twins — was architected around the wrong primary job. Each of those categories was built to describe. The job is to judge.
A continuous performance audit is the category that replaces description with judgement. It runs continuously. It reasons causally. It communicates in briefings, not dashboards. It states what the building is exposed to, in its own terms: pounds where there is a loss to price, and hours, days and plain consequence where there is not. And it verifies every action against baseline until the exposure has gone and the loop closes.
No single principle among those is new. Good engineers have been practising every one of them for years. Manually, expensively, intermittently, inside consultancies and energy management teams and late-night troubleshooting sessions. What is new is the ability to industrialise them. To run them continuously, across every system, at the scale of a portfolio, with the rigour of a first-principles platform.
That is the work GRIOTech has done, and that is the category we are building. We called our platform ABIE: the Advanced Building Intelligence Ecosystem. A continuous performance audit with a dual-layer cognitive engine, patent pending, built by a team with over thirty years of combined experience in building controls, energy management, and data science. And £7 million of verified energy savings behind them from the years before we started this company.
We did not write this guide to sell you ABIE. We wrote it because we think the language and the framework matter more than any single product. If you read this and go on to buy one of our competitors, but you buy them equipped to ask better questions, we will have done useful work.
See the platform in action.
In thirty minutes.
A walkthrough of the platform. Faults priced where they can be and scored where they cannot, traced through the system chain, briefed in plain language. Bring your hardest questions about how it would work in your portfolio. We'll answer them in the demo.
Prefer to read it on paper?
About this edition
This is volume two of GRIOTech's Field Guide series, in a second edition revised in October 2026 to cover the full range of exposure a continuous audit reports: recoverable value, service withheld, risk, assurance and observability. A sequence of short, rigorous publications about how the building performance category is shifting. Companion to FG/01: The Performance Chain Model. Related volumes: FG/03: The Psychology of Insight, FG/04: Evidence-Led Maintenance, and FG/05: The Briefing. Future volumes will cover the closed loop, human-in-the-loop diagnostics, and case studies as they land.
View supporting research and methods
Explore the ABIE engineering engines, supporting evidence and methodology and building applications.
Field Guide Series