Paper deep dive

Which Buildings Are Artificial Intelligence-Ready? A Measurement-Based Assessment Framework for AI Question Answering and Actuation

Wooyoung Jung

Year: 2026Venue: arXiv preprintArea: cs.AIType: PreprintEmbeddings: 151

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 10/8/2026, 6:55:11 AM

Summary

This paper introduces a measurement-based framework to assess 'AI-readiness' in buildings, defined by the extent to which a building's data infrastructure (Knowledge Graph and time series) can answer operational questions and expose control actions. The framework quantifies 'answerable-readiness' and 'actuation-readiness' ceilings based on a canonical set of questions and compares them against the performance of a fixed reference AI agent. Results from simulated and real-building graphs indicate that missing data, rather than AI capability, is the primary bottleneck for readiness, with real buildings showing low median answerable ceilings.

Entities (8)

Knowledge Graph · data-structure · 99%AI-readiness · concept · 98%Brick · ontologystandard · 97%Actuation-readiness ceiling · metric · 96%Answerable-readiness ceiling · metric · 96%Reference AI Agent · software-system · 95%DOE prototype buildings · dataset · 92%Smart Readiness Indicator · standard · 90%

Relation Signals (6)

AI-readiness → isdefinedby → data infrastructure

confidence 95% · This study calls this property a building’s AI-readiness: the extent to which its data infrastructure can answer the operational questions stakeholders ask and expose the controls to act on them.

Answerable-readiness ceiling → measures → data capability

confidence 94% · The answerable-readiness ceiling is the share of operational questions its data could answer

Actuation-readiness ceiling → measures → control exposure

confidence 94% · the actuation-readiness ceiling is the share of control actions it exposes

Brick → isschemafor → Knowledge Graph

confidence 93% · in a machine-readable schema such as Brick

Reference AI Agent → evaluates → AI-readiness

confidence 92% · a reference AI agent’s accuracy on a fixed set of these questions shows how much of the ceilings is realized

Missing data → limits → AI-readiness

confidence 90% · so missing data, not the AI, limit readiness

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Agentic artificial intelligence (AI) systems are becoming the interface to buildings, answering questions and controlling operations, but a building's readiness for them has not been systematically assessed. This study proposes a framework to quantify it. First, a building's knowledge graph sets two ceilings. The answerable-readiness ceiling is the share of operational questions its data could answer, and the actuation-readiness ceiling is the share of control actions it exposes. Second, a reference AI agent's accuracy on a fixed set of these questions shows how much of the ceilings is realized. On a simulated office, the agent realizes 0.62 of a 0.64 answerable ceiling, so missing data, not the AI, limit readiness, except in naming a fault's cause. Across 37 public real-building graphs, the median answerable ceiling is 0.16, and in 15 of 45, unlinked sensors lower it. The framework turns "is this building AI-ready?" into an auditable, ranked retrofit question.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

148,963 characters extracted from source content.

Expand or collapse full text

Which Buildings Are Artificial Intelligence-Ready? A Measurement-Based Assessment Framework for AI Question Answering and Actuation Wooyoung Jung a a University of Arizona, Tucson, USA Abstract Agentic artificial intelligence (AI) systems are becoming the interface to buildings, answering ques- tions and controlling operations, but a building’s readiness for them has not been systematically assessed. This study proposes a framework to quantify it. First, a building’s knowledge graph sets two ceilings. The answerable-readiness ceiling is the share of operational questions its data could answer, and the actuation-readiness ceiling is the share of control actions it exposes. Second, a reference AI agent’s accuracy on a fixed set of these questions shows how much of the ceilings is realized. On a simulated office, the agent realizes 0.62 of a 0.64 answerable ceiling, so missing data, not the AI, limit readiness, except in naming a fault’s cause. Across 37 public real-building graphs, the median answerable ceiling is 0.16, and in 15 of 45, unlinked sensors lower it. The framework turns “is this building AI-ready?” into an auditable, ranked retrofit question. Keywords: artificial intelligence readiness, building automation, AI-integrated buildings, knowledge graphs, question answering, large language models 1. Introduction The prospect of buildings managed with artificial intelligence (AI) [1, 2], able to answer a user’s questions in natural language, diagnose faults, and eventually close control loops, has moved from speculation to active engineering [3, 4]. Two of these tasks, fault diagnosis and control, al- ready reach real buildings without such AI. Fault detection is commercial practice, with analytics platforms running rule-based checks over building automation data at scale [5, 6]. Learned and model-based control has been tested in field studies. A reinforcement-learning policy controlled a conference room’s supply airflow for three weeks [7], and model predictive control ran an office’s heating, ventilation and air-conditioning (HVAC) for two months [8]. A growing number of studies now put large language models (LLMs) in these roles. LLMs answer operational questions posed in natural language over a building’s sensor streams [9], diagnose HVAC faults and explain them to operators [10], issue control actions in simulated buildings [11], translate natural-language in- structions into building-management actions [12], assist building energy modelling [13], and drive agentic workflows for building energy analysis [14]. To date, most of this research effort is directed at the AI: which model to use, which prompting technique [15], how well the model retrieves and reasons, and what a new AI-integrated system looks like [4, 3, 16]. This focus is natural, because the field is young, AI capabilities change quickly, and the building community needs to understand what the AI can do. But building-AI integration has two sides, and the building’s data infrastructure is the other. That infrastructure is the building’s knowledge graph (KG), which describes its zones, equipment and points and the relations among them, such as which air handler serves which zone, in a machine-readable schema such as Brick, together with the operational, reference and control data the KG exposes. The AI operates on arXiv:2610.09119v1 [cs.AI] 6 Oct 2026 that data, and the data bound what the AI can do however good the AI is. An AI cannot report a zone’s energy use if the zone is not metered, and it cannot attribute a comfort complaint to a fouled coil if the coil’s behaviour is never sensed. This raises a prior question: given a particular building, can its data answer the questions that would be put to such a system? This study calls this property a building’s AI-readiness: the extent to which its data infrastructure can answer the operational questions stakeholders ask and expose the controls to act on them. AI-readiness is upstream of deploying any AI system, so it can be assessed before any model is chosen, yet the assessment tools available today measure something adjacent to it. For example, the European Union (EU) Smart Readiness Indicator (SRI) [17, 18] and SmartScore, the certification of the company WiredScore [19], are expert checklists that credit a building for the services it has installed. Semantic-data standards such as Brick and Standard 223P of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) [20, 21] describe a building’s points and equipment but mandate no sensing. Building question-answering (QA) benchmarks test an AI over the KG, but they hold the buildings fixed and grade the AI. Application shapes check whether a KG declares the points an application needs, not whether the series behind them are usable. None measures what a building’s data can answer, and none separates a building’s data limits from the AI’s shortfall (Section 2). The goal of this study is to define and measure a building’s AI-readiness as a property of its instrumentation, so that “is this building AI-ready?” turns from a judgement into an auditable assessment. Four constructs, formalized in Section 3, carry the measurement: • Question canon: a declared question set formed by building domains, question intents, and answer-completeness levels; • Answerable-readiness ceiling: the share of the canon a building’s stream set can answer in principle, read from the KG without running any AI; • Realized readiness: the share of the canon a fixed reference AI answers correctly, measured level by level, so that the rest of the canon splits into AI failure (the data could answer, the AI did not), unprobed credit (no question tested it), and data limitation (the streams are absent), separating what a better system would fix from what only instrumenting would fix; and • Actuation-readiness: the control handles a building exposes, so that a building’s readiness is a pair of coverage measures, one for answering and one for acting. The separation of data limitation from AI failure is the conceptual core of the paper. The ceiling can be read from any KG, but measuring accuracy automatically and at scale requires the correct answer to every question to be known in advance. The framework is therefore run on a published simulated corpus of U.S. Department of Energy (DOE) prototype buildings, each a Brick KG linked to physics-based time series, in which the answers follow from the simulation that generated the data, fault labels are known, and instrumentation is varied as a controlled variable. It is then applied to 45 public real-building KGs, 37 of which link their points to series, where no fault labels exist and the data are as operators find them. This study makes five contributions. 1. A measurement framework for building AI-readiness, built on these four constructs and com- puted from the KG and one fixed reference agent. 2. A question canon whose data requirements for diagnosis are derived from declared cause sets and checked against two practitioner corpora, with a question bank of 64 automatically graded classes that runs on simulated buildings and, where their data allow, on real ones. 2 3. A controlled study on a published simulated corpus with a pinned open-weight agent, repeated runs and archived transcripts, which measures how much of the ceiling the agent realizes at each instrumentation profile, and, on paired fault scenarios that look alike without the stream that tells their causes apart, whether the agent abstains when a cause is not identifiable and names the right one when it is. 4. A census of real buildings that reports both ceilings, the gap between what a KG declares and what its data support, the usability of the linked series, and how far the ranking of buildings depends on how the domains are weighted. 5. An open assessment tool: code, released under an open license, that computes both ceilings from any Brick KG, generates and grades the question bank, and runs the agent, together with the deposited results and the paired fault scenarios, so that a building owner can assess a building and a reader can regenerate every table and figure. 2. Related work Three lines of prior work bear on measuring a building’s AI-readiness: smart-readiness assess- ments and building data standards, building QA over KGs, and fault diagnosis. 2.1. Data readiness, smart readiness, and building data standards The notion that data carries a readiness for a task predates its building-specific form. Lawrence’s data readiness levels [22] propose a vocabulary for how prepared a dataset is for analysis, by analogy to technology readiness levels. Within buildings, where data-driven technologies increasingly medi- ate operation [23], the SRI [17, 18] scores a building across nine technical domains and three func- tionalities (energy performance and operation, occupant responsiveness, energy flexibility) through an expert assessor cataloguing installed smart-ready services. It is, by design, a checklist of capacity and not a measurement of realized capability, and its own methodology acknowledges that a rating grounded in “actual building performance data” would be preferable but has not been operational- ized. When two expert panels assessed the same building with it, they had to reconcile discrepancies between their assessments [24]. WiredScore’s SmartScore [19], an international smart-building cer- tification, likewise assesses installed capability, from an expert scorecard in nine categories that run from digital services and wellbeing to cybersecurity, data management and systems integration. Appendix A maps the SRI’s 54 services to this study’s questions. On the data side, several conventions shape how a building’s data is represented. Building information models carry it from design into operation [25], with their content graded by the level- of-development specification of BIMForum, a United States industry forum on building informa- tion modelling [26], which describes how far each modelled element is specified and not whether the element is sensed, and with recent work enriching these models with real-time sensor streams for digital-twin monitoring [27]. Brick and ASHRAE 223P [21, 28, 20], with the Smart Applica- tions REFerence (SAREF) ontology family on the Internet of Things (IoT) side [29], are semantic- metadata schemas: a controlled vocabulary for describing a building’s points, equipment, and their relationships in a machine-readable KG. Building such KGs for real buildings is itself a research problem, and the share of a building’s points that end up modelled is a known measure of metadata completeness [30, 31]. Application shapes, written in the Shapes Constraint Language (SHACL) and supported by BuildingMOTIF [32] and the 223P tooling, state what a KG must contain for a given application to run, and validate a KG against that requirement. ASHRAE Guideline 36 [33] is complementary, specifying standardized sequences of operation for common HVAC systems to- gether with the named input and output points each sequence reads and writes. Such standards are a prerequisite for knowledge-graph question answering (KGQA), since they make the KG exist 3 and give its nodes a consistent meaning. They govern how a building’s data is described, however, not what a building measures. An application shape checks the KG and not the series behind it, and a building can carry a complete, valid KG and still lack the streams that a given operational question requires. 2.2. Building question answering over knowledge graphs A closer line of evaluation work asks whether an AI can answer questions over a building’s metadata KG [34], a building-specific case of the broader effort to pair LLMs with KGs for QA [35, 36], with related building-facing chatbots over building data [37]. BuildingQA [38] contributes 188 question–answer pairs over four buildings (three in Brick, one in 223P), built from 27 practitioner queries in SPARQL, the query language of KGs, with LLM-generated paraphrases, and reports that zero-shot KGQA systems reach a top row-matching F 1 of only 0.38, where row-matching F 1 is the overlap between the result rows a generated query returns and the rows the ground-truth query returns. Domain specific building KGQA is far from solved. Its ground-truth answers are the result rows of the expert queries, so it grades whether an AI retrieves the right points and facts, such as which air handler serves a zone, more than whether it computes a value from their series, such as how many hours a zone was out of band on Tuesday. Computing over the series is the harder part, because even strong LLMs struggle to reason zero-shot over raw time series [39]. The Mortar testbed [31] supplies the other half: a library of analytics applications written by practitioners over Brick KGs and their series, which this study uses as a second check on its question canon. Mortar also showed which of its applications could run on which building by querying each KG for the points an application needs, which amounts to a census of portability at the level of applications. The canon generalizes that census from a list of applications to a declared set of questions, and the ceiling adds the check that the series behind the points are usable. 2.3. Fault diagnosis and diagnosability The fault-detection-and-diagnosis (FDD) literature [40, 41] contributes labelled fault datasets [42, 43] and an evaluation vocabulary: Frank et al. [44] define metrics for detection (true and false-alarm rates) and diagnosis (correct-diagnosis rate), and digital-twin-enabled FDD continues this line [45]. Classical FDD evaluates a diagnostic algorithm on a building whose instrumentation is fixed, so it does not treat the availability of the stream that separates two causes as a variable. Which faults a given set of sensors can tell apart is the subject of diagnosability analysis and sensor placement in model-based diagnosis [46, 47], which answers the question from a model of the building. This study applies the same idea at a coarser level. It judges which causes the data can tell apart from the classes of streams a building exposes and a declared list of candidate causes, so the judgement can be read from any Brick KG without a model of the building, and it becomes a property of the building that can be measured before any diagnostic algorithm is chosen. 2.4. Positioning of the present study Table 1 sets the present study beside the constructs it is closest to. None of them conditions its result on instrumentation or separates a data limitation from a model limitation. 4 Table 1: The present study beside the constructs it is closest to. ConstructWhat is scoredEvidenceConditioned on instrumen- tation Data vs. AI SRI, SmartScore [17, 19]installed smart services and their functionality level assessor inspection nono Data readiness levels [22]fitness of a dataset for analysisdata auditnono Sensor coverage, metadata completeness [30] points present or modelledpoint countscounts sensors, not answers no Application shapes [32]whether a KG holds what an application needs KG validationKG only, not the series no Building KGQA benchmarks [38, 34] an AI’s retrieval from the KGground-truth queries nono This studythe share of a question canon the data can answer, and the share a fixed agent realizes KG, series, and a fixed agent yesyes “Data vs. AI”: whether the construct separates a limitation of the building’s data from a limitation of the AI. 3. Building AI-Readiness Assessment Framework The framework holds the AI constant across buildings, so that a difference in the readiness measures reflects a difference between buildings. The premises of the framework are: (1) a question is considered answerable only when the building’s data can determine the answer; (2) a domain is considered actuable only when the building’s KG exposes a handle for the action (a setpoint or a command); and (3) the building’s KG is assumed to be complete and correct, meaning that it models every point the building has and that every point it declares exists and records data (Section 6.2 discusses what happens when this assumption fails). Figure 1 shows how the constructs connect, and Table 2 lists the terms and symbols that recur in later sections. Declared by the framework, the same for every building Read from the KG alone, with no AI run Measured with one fixed AI Question canon (Section 3.1) domain × intent cells, target levels L1–L3 Requirement table R, with L3 rows derived from declared cause sets (Section 3.4) Actuation canon (Section 3.5) per actuable domain: A1 supervisory, A2 direct Building knowledge graph (KG) + time series Instrumentation profile I stream classes the building exposes (Section 3.2) Answerable-readiness ceiling C ans (Section 3.2) Actuation-readiness ceiling C act (Section 3.5) Question bank (Section 4.2) classes per rung, instances from the building's KG and time series Fixed reference agent (Section 4.1) answers each question, and each answer is graded Decomposition (Section 3.3) A r + F + U + D = 1 A r : realized, F: AI failure, U: unprobed, D: data limitation Building AI-readiness (C ans , C act ) with the decomposition → ranked retrofit list Figure 1: Overview of the framework. The section numbers show where each step is defined. 5 Table 2: Key terms and symbols. TermSymbolMeaning Canonthe declared set of operational questions, as domain–intent cells with target levels (question canon), and the declared control rungs of each actuable domain (actuation canon) Cell(d, i)one domain–intent pair of the canon (Table 3) Level, target levelL1–L3answer completeness, from L1 reporting to L2 judging to L3 attributing; the target level is the highest level a cell asks for Rung, canon totalc Σ one level of one cell; the canon has 76 rungs Stream classa kind of measured or commanded point, defined as a set of Brick classes Instrumentation profileIthe set of stream classes a building exposes Requirement table, achieved level R, ℓ d,i (I)the stream classes each level of a cell needs; the highest level whose classes are all in I Candidate causes, separating stream the declared causes of a deviation in a domain, and the stream class that tells them apart Answerable-readiness ceilingC ans (I)the share of the canon that the data can support Handle, actuation rungA1, A2a point through which an agent can act on a domain: one that sets a target or a mode (A1, supervisory) or one that drives the device (A2, direct) Actuation-readiness ceilingC act (I)the share of the actuation rungs that the KG’s handles reach Reference agentthe fixed AI, one local model with three tools, that answers the questions in every building Question class, question banka template that poses questions for one rung and computes their ground truth; the bank is the set of 64 classes, and a rung is probed when the bank poses questions for it Episode, turnone attempt of the agent at one question; one reply of the model within it AccuracyAthe reference agent’s mean accuracy over the probed rungs Realized readiness, AI failure, unprobed credit, data limitation A r , F, U, D the four shares of the canon, which sum to one: answered correctly, answered wrongly, credited but not tested, and not supported by the data Overclaim ratethe share of unanswerable questions that the agent answered Declared, linked, usablea point described in the KG; a point with a time series; a point whose series passes the usability rule 3.1. The question canon This study organizes the operational questions asked of a building along three axes. A question’s domain is the physical subsystem it concerns: thermal, energy, air quality, equipment, occupancy, or lighting. These are the technical domains of the SRI [17] and the subsystems that Brick orga- nizes [20]. Plug loads and thermal energy are end uses inside the energy domain, and illuminance is a lighting quantity. Acoustics is left out because a building automation system records no stream from which an acoustic question has a verifiable answer. A question’s intent is the operation requested: status (the current value), summary (an aggregate over time or space), comparison (against a peer, a baseline, or a prior period), verification (is the intended behaviour occurring), diagnosis (which or where is the problem), or explanation (why). The intents form a progression of increasing inferential demand, from reporting a measured value to explaining a cause. Predictive and prescriptive intents are excluded because the building’s data do not determine their answers. A forecast can be graded against held-out data, but its accuracy measures the forecasting model more than the building’s data. A recommendation is an action, and its quality has no automatically gradable answer. Grad- ing what the data determine is what makes the framework a measurement. A request to change the building, such as lowering a setpoint, belongs to the actuation axis (Section 3.5). Table 3 lists the canon as a matrix of domains and intents. Each entry is a cell, and its value 6 Table 3: The question canon: the target level (1–3) of each (domain, intent) cell. “–” marks a cell left out of the canon, for the reasons given in the text. The target levels sum to the canon total c Σ = 76. Domain Status Summary Comparison Verification Diagnosis Explanation Thermal223333 Energy123–33 Air quality223333 Equipment223333 Occupancy222–2– Lighting222–2– is the cell’s target level, the highest level on a three-step ladder of answer completeness that its questions ask for. At L1 (reporting) the answer reports the quantity as the building automation system records it, such as a zone temperature or a meter reading. At L2 (judging) the answer also judges that quantity against a reference, such as a setpoint, the zone’s own history, a peer zone, or a rated capacity. At L3 (attributing) the answer also attributes a deviation to one cause among a declared set of candidate causes (Section 3.4). For the diagnosis and explanation intents, the lower levels prepare that step. L1 locates or sizes the deviation, such as the warmest zone or the change between two days, and L2 judges it against a reference. L3 then names the cause from the domain’s declared set, such as a stuck damper or a changed schedule for a warm zone, by reading the stream that separates that cause from the others. The intent and the domain set the target level of a cell. Status and summary questions report or aggregate a quantity, so they are complete at L2. Energy status is complete at L1, because a meter reading is reported without a reference. Comparison, verification, diagnosis and explanation questions target L3 in the domains that declare a set of candidate causes, which are thermal, energy, air quality and equipment. Occupancy and lighting declare none, because occupancy is the occupants’ choice and lighting follows occupancy or a schedule, so their cells stop at L2. L3 is the last level, and tracing a named cause to a deeper root cause is left to future work. The instrumentation sets the level a building achieves. One level of one cell is a rung, so a cell whose target level is L3 has three rungs. The canon has c Σ = 76 rungs, its canon total. A cell is left out where another cell already covers its question or where the intent does not apply. Energy has no verification cell, because checking consumption against its expected value is the comparison intent. Occupancy has none, because no intended behaviour is set for occupants, and lighting has none, because checking that lights follow occupancy is lighting status at L2. Without candidate causes, explaining a change in occupancy or lighting is the same question as diagnosing it, so neither domain has an explanation cell. Each level of a cell requires a set of stream classes. A stream class is a kind of measured or commanded point, defined as a set of Brick classes so that it can be read from any Brick KG. A building exposes a stream class when at least one point of that class carries a usable time series. A value stored in the KG itself, such as a setpoint’s design value, does not expose a stream class. Requirements are cumulative. Thermal status needs a zone temperature sensor at L1 and a zone temperature setpoint, heating or cooling, at L2. Thermal verification also needs, at L3, the terminal unit’s actuation command and its response, such as a damper command and the damper position or the airflow it produces. A peer zone’s temperature is the same stream class on another zone, so a comparison with a peer adds no requirement. Air quality is read through zone CO 2 alone. CO 2 tracks the occupant-generated load and the outdoor-air supply, which are the two causes that the air-quality cells attribute, and it is the quantity that demand-controlled ventilation acts on. Particulate matter, volatile organic compounds and humidity have other causes and are outside this 7 Table 4: The requirement table R: the stream classes a cell needs at each level. Each entry lists every class needed to reach that level. “–” marks a level above the cell’s target level. DomainIntent(s)L1L2L3 Thermal status, summaryTT+Sp– Thermal comparisonTTT+Sp+ActC+ActP Thermal verificationTT+SpT+Sp+ActC+ActP Thermal diagnosis, explanationTT+SpT+Sp+SpC+ActC+ActP+SAT EnergystatusWhole– EnergysummaryWholeWhole+Sub– Energycomparison, diagnosis, explanation WholeWholeWhole+Sub2+OAT Air quality status, summaryCO2CO2+Occ– Air quality comparisonCO2CO2CO2+Occ+OAF Air quality verification, diagnosis, explanation CO2CO2+OccCO2+Occ+OAF Equipment status, summaryPwrPwr– Equipment comparison, verification, diagnosis, explanation PwrPwrPwr+Run+Load Occupancy status, summary, comparison, diagnosis OccOcc– Lightingstatus, diagnosisLgtLgt+Occ– Lightingsummary, comparisonLgtLgt– Stream classes: T = zone air temperature; Sp = zone temperature setpoint in effect, heating or cooling; SpC = scheduled (occupied or unoccupied) setpoint held apart from the setpoint in effect; ActC = terminal-unit actuation command (damper, valve or reheat command); ActP = terminal-unit actuation response (damper or valve position, or terminal airflow); SAT = supply air temperature of the air system serving the zone; OAT = outside air temperature; Occ = occupancy (presence or count); CO2 = zone CO 2 concentration; OAF = outdoor-air flow; Whole = whole-building electricity meter; Sub = at least one end-use submeter (HVAC, lighting, plug loads or thermal energy); Sub2 = two end-use groups metered, which fixes the third as the residual; Pwr = equipment input power (electricity or fuel); Run = equipment run command or status; Load = equipment load (air or water flow, or delivered heating or cooling); Lgt = lighting power, lighting status, or illuminance. canon. Table 4 gives the full requirement table. The canon is declared in full so that it can be audited and replaced. Besides Tables 3 and 4, Appendix B gives an example question at each level of every cell, the candidate causes that each domain declares, and the Brick classes that define each stream class. The canon and the question bank were written for this study and checked against two practitioner corpora. Of the 27 expert queries in BuildingQA [38], 21 look up a stream class the canon names, and the others ask for every point of an entity or for metadata. Every quantity computed by the analytics applications published with the Mortar testbed [31] falls in a canon cell, and four of the applications read the supply air temperature or the outside air temperature, which is why the canon includes both streams. All scores are relative to this canon, and a site can substitute its own questions or weight the domains without changing the method. Domain experts enter at three points. They audit the canon’s cells, target levels and cause sets for a building type, they choose a site’s domain weights, and they judge whether a declared point can be trusted before its series is used. Reweighting the domains can reorder two buildings whose strengths lie in different domains, but never the nested profiles of one building, because adding a stream class can only raise the level of a cell. 8 3.2. The answerable-readiness ceiling The instrumentation profile I of a building is the set of stream classes it exposes. The requirement table R (Table 4) lists, for the cell of domain d and intent i, the stream classes R d,i,r needed to reach each level r of the ladder, up to the cell’s target level c d,i . The achieved level ℓ d,i (I) is the highest level whose required classes are all in I (Figure 2), ℓ d,i (I) = max r : R d,i,r ⊆ I,ℓ d,i = 0 if even L1 is unmet.(1) The answerable-readiness ceiling C ans (I) is the share of the canon total that the profile achieves. The subscript marks the answering axis, and the argument marks the dependence on I, C ans (I) = 1 c Σ X d,i ℓ d,i (I) ∈ [0, 1].(2) (a) Points of one zone in the KG Brick class of the pointstatusstream class Zone_Air_Temperature_ Sensor usable T zone temperature Zone_Air_Temperature_ Setpoint handle A1 linked Sp zone setpoint Damper_Position_ Command handle A2 declared ActC actuation command Damper_Position_ Sensor declared ActP actuation response points readmeaningprofile declared typed in the KG I = T, Sp, ActC, ActP linked and its series is in the data I = T, Sp usable and the series passes the usability rule I = T (b) One cell: thermal verification target level L3 declaredlinkedusable L3 attributing: + ActC, ActP ✓✗ L2 judging: + Sp ✓✗ L1 reporting: T ✓ achieved levelL3L2L1 Each level adds stream classes to the one below. A profile reaches a level when it holds every class the level needs. Figure 2: From a zone’s points to a cell’s achieved level. (a) The usability rule (Section 4.6) drops series with large gaps or stuck values. Each point maps to a stream class (Table B.16), and the stream classes of the points read form the instrumentation profile I, so one zone has three nested profiles. A setpoint or command point is also a handle, A1 or A2, for the actuation-readiness ceiling (Section 3.5). (b) The cell reaches the highest level whose required stream classes are all in the profile: L3 on the declared points, L2 on the linked points and L1 on the usable points. C ans (I) depends only on the stream classes the building exposes, not on the AI, the data values or the wording of a question, so it is the most that a perfect AI could realize. It rises in steps as stream classes are added, either by installing a sensor or meter and entering it in the KG, or by mapping a point the automation system already has into the KG and linking its series, which needs no new hardware. The ceiling counts every rung equally, and a site that values some domains more can weight them. With domain weights w d , the weighted ceiling is C w (I) = P d w d P i ℓ d,i (I) P d w d P i c d,i ,(3) 9 A r FU unprobed D 01 realizedAI failuredata limitation C ans : answerable ceiling F : fix with a better system D : fix by instrumenting U : test with more questions Figure 3: Conceptual decomposition of building AI-readiness. The canon total splits into realized readiness, AI failure, unprobed credit and data limitation. which returns C ans (I) when all weights are equal, because the target levels c d,i sum to c Σ . Counting each domain equally is a different choice. It sets w d to 1/ P i c d,i , so that every domain’s own share enters with the same weight. 3.3. Realized readiness and the decomposition A building realizes only part of its ceiling. The ceiling credits one rung for every achieved level of every cell, so c Σ C ans (I) rungs are credited. Each question class targets one rung, and the reference agent’s accuracy is measured rung by rung. Let a d,i,r be the share of the questions targeting level r of cell (d, i) that the agent answers correctly, and let P(I) be the set of credited rungs that the question bank probes, and |P(I)| their number. A credited rung outside P(I) is unprobed, and its accuracy is not assumed. The realized readiness is the share of the canon that is credited, probed and answered correctly, A r = 1 c Σ X (d,i,r)∈P (I) a d,i,r .(4) The whole canon then splits into four shares (Figure 3), 1 = A r + 1 c Σ X (d,i,r)∈P (I) 1− a d,i,r | z F : AI failure + C ans (I)− |P(I)| c Σ |z U : unprobed + 1− C ans (I) | z D : data limitation . (5) The data-limitation share D is readiness lost because streams are absent, and only instrumenting recovers it. The AI-failure share F is readiness lost on questions the data could answer, and a better agent recovers it. The unprobed share U is credit the measurement has not tested, and a larger question bank shrinks it. When the question bank probes every credited rung, U = 0 and A r = C ans (I) A, where A is the mean of a d,i,r over the probed rungs. When it does not, the product C ans (I) A credits the unprobed rungs with the accuracy of the probed ones. The four shares are therefore always reported together, on the canon total. Questions are generated from the building’s own KG, so a question about equipment the building does not have is never posed. Such a question is not applicable and counts nowhere. Applicability acts on questions, not on cells. The cells of the canon are defined over the six service domains, 10 Table 5: How each answer is scored. Answerable questions enter the rung accuracy a d,i,r , and unanswerable ones enter the overclaim rate. Agent answersAgent abstains Answerable questioncorrect if right, AI failure if wrong AI failure Unanswerable question overclaim, even if rightcorrect abstention which every occupied building has, so the ceiling keeps the full canon total as its denominator, and a building without the data for a domain is scored as data-limited in it. A generated question is answerable under a profile when the streams its level requires are exposed. On an answerable question the agent is either correct or it is an AI failure, which covers a wrong answer and an abstention the data did not force. On an unanswerable question an abstention is correct, and any answer is an overclaim, even when the answer happens to be right, because the data did not determine it. Only answerable questions enter a d,i,r . The overclaim rate is the share of unanswerable questions that the agent answered, and it measures whether the agent respects the ceiling. Table 5 summarizes the four outcomes. 3.4. Identifiability of causes A cell is answerable at a level only if the available streams uniquely determine the answer. This matters little at L1 and L2, where a value and its reference settle the answer, and is decisive at L3. A cause is identifiable only when the data separate it from every other cause that would produce the same observations, so identifiability is defined against a declared set of candidate causes. For each domain with L3 cells, the canon declares a small cause set drawn from the fault detection and diagnosis literature [40, 44]. For each cause it names the stream class whose behaviour sets that cause apart from its rivals (Table B.15 in Appendix B). The L3 requirement of a diagnosis or explanation cell is the L2 requirement plus the union of the separating classes of its domain. A comparison or verification cell at L3 attributes one observed difference or deviation, and it needs the separating classes of the causes that difference can have. In the thermal domain a difference between zones, or a deviation from the setpoint, has three kinds of cause. The zones may be asked for different temperatures, which the setpoint shows. The terminal may be stuck, which shows as a command that moves while its response stays. Or the zone may carry a different load, which shows as command and response moving together. Thermal comparison and verification at L3 therefore need the setpoint, the terminal command and its response. In the other domains the comparison and verification cells that reach L3 share the diagnosis requirement. A profile that holds a related stream and still cannot separate two declared causes does not reach L3. Equipment power alone, for example, shows that a unit’s consumption rose, and only its run status and load tell a commanded change from a load change and from degradation. 3.5. The second axis: actuation-readiness Answering is only half of autonomy. An agent that can report a zone’s state but cannot drive any actuator is not ready to operate the building. Control handles, like sensors, are part of the instrumentation and can be read from the same KG. This study therefore defines a second axis, the actuation-readiness ceiling C act (I), built like the answerable-readiness ceiling but over control handles. It records whether the building exposes the handle needed to act on each domain. How well an agent would control is not measured, because a control policy has no automatically gradable ground truth, so actuation enters as a ceiling only and no agent is run on it. 11 Table 6: The actuation canon: the Brick classes that make up each rung of each actuable domain. DomainA1 (supervisory)A2 (direct) Thermalzone cooling/heating setpointdamper / valve / reheat command Air quality airflow / fan-speed setpointoutside-air damper command Equipment on/off, enable or start/stop com- mand compressor command, speed setpoint Lightinglighting-level setpointlighting on/off / luminance command observable & actuable actuable, not observable observable, not actuable neither 00.51 0 0.5 1 answerable-readiness C ans actuation-readiness C act Figure 4: AI-readiness of a building as a point in the plane of the two ceilings. The two points are illustrative. Four of the six domains can in principle be acted on in any building: thermal, air quality through ventilation, equipment, and lighting. Energy can be acted on only where the building has dispatchable electrical assets, such as a battery, a photovoltaic inverter or managed vehicle charging, whose power setpoints an agent can write. Every building can meter its energy, so the answering axis keeps energy in its denominator, while the actuation axis leaves energy out where there are no such assets, as in every building studied here. Occupancy is never actuable. Each actuable domain is scored on a two-rung ladder parallel to the L1/L2/L3 answer ladder. At A1 (supervisory) the KG exposes a point that sets a target or a mode, which the domain’s local controller then carries out, such as a zone setpoint or an equipment enable command. At A2 (direct) it also exposes a point that drives the device itself, such as a damper position, a valve or a compressor command. The achieved rung is cumulative (A2 requires A1), and C act (I) = P d∈D act a d (I) 2|D act | ∈ [0, 1],(6) where a d (I) ∈ 0, 1, 2 is the achieved actuation rung of domain d and D act is the set of actuable domains, four in every building studied here, so the denominator is 8. Table 6 lists the Brick classes that make up each rung, which form the actuation canon. The same zone setpoint can appear in both canons, as a reference read to judge a temperature and as a handle written to change the target. 12 Two axes. A building’s readiness is thus a pair, answerable-readiness and actuation-readiness (Fig- ure 4). A building can be observable but not actuable, or actuable but not observable. An agent could then be asked to diagnose a fault it cannot fix, or to drive a system it cannot see. The two axes are therefore reported side by side and never collapsed into a single index, which would hide this asymmetry. One caveat weighs more on the actuation axis. A setpoint or command point in the KG shows that the handle is modelled and addressable. Whether the deployed automation system lets an external agent write to it is an integration property that no KG records, so C act (I) is an upper bound on what an agent may drive. 4. Measurement Substrate and Study Design The study rests on two evidence bases. The first is a controlled study on a published simulated corpus, in which instrumentation is varied as the only independent variable, the true cause of every fault and the true value behind every reading are known, and the reference agent is probed with the answer withheld. The second is a census of real buildings, in which the two ceilings are read from real Brick KGs and part of the question bank is run on real series. The simulated data are complete and clean, and the real buildings show what simulation cannot: which points real KGs actually link, and how many of their series are usable. Figure 5 lists the experiments, the question each one answers, and the data it uses. Shared: the canon, the reference agent (except in ③), the question bank and its grading (Sections 3, 4.1, 4.2) Simulated offices (BATS) answers known exactly · Sections 4.3 and 4.4 Real buildings (Mortar and BTS) real data, real gaps · Sections 4.5 and 4.6 ① Instrumentation sweep How does readiness change as sensors are added? One office, sensing added in four steps, and the agent answers at each step. ② Building sweep Does the result hold across sizes and climates? Eight more offices, all their published data. ③ Agent sweep How much does the choice of AI matter? Four other models on the same questions. ④ Diagnosis Does the agent name a cause only when the data can tell? Two pairs of look-alike faults, with and without the stream that separates them. ⑤ Census How ready are 45 real buildings, judged from their KGs alone? ⑥ Questions on real data Does the agent still answer on real, messy data? 8 real buildings, only the series with usable data. runs an AI agentread from the KG, no AI run Figure 5: Study design: the question each experiment answers and the data it uses. The top band and the column headings give the sections that describe them. 4.1. The reference agent The system under test is a fixed agent built on an open-weight language model, Qwen3.8 with 27 billion parameters [48], run locally in a compressed four-bit form. An open-weight model is used for three reasons. Its weights can be reloaded after a hosted model is retired, so a readiness score stays reproducible. It runs locally, so a building’s data stay on site. And it costs nothing per question, so an assessment can be repeated as the building changes. The reference agent need not be the 13 strongest model available, because the measurement concerns the building. A stronger agent can only shrink the AI-failure share, which at L1 and L2 stays small next to the ceiling (Section 5.1). The agent has three tools (Figure 6). A KG query tool runs a SPARQL query over the building’s KG, a Python tool computes over the series in an isolated process, and an answer tool hands in the answer in the shape the question names, or abstains and names the streams the agent would need. The model decides when to call each tool. There is no fallback model and no retry after a wrong answer, and an episode ends with no answer after 25 turns. Sampling is left at the model server’s defaults, so repeated runs measure how much the answers vary. Appendix C gives the model build, the prompt, the tool schemas and the token counts, and the agent’s code is released with the study’s code. What the agent sees and nothing else Question with the answer's shape and units Building KG zones, equipment, points and their links Time series only the streams that the profile exposes Reference agent one fixed open-weight model Language model one reply per turn: decides the next step and calls tools Query the KG finds the zone, point or link Analyse the time series writes and runs Python code Submit the answer, or abstain and name the streams it would need (at most 25 turns) Grading hidden from the agent Ground truth computed in code from the series Grader by answer type, with tolerance Outcome (Table 5) Figure 6: One question episode. A turn is one reply of the model, with the tools it calls and their results. An episode ends when the agent submits, when it replies without calling a tool, or after 25 turns. Table C.19 follows one episode call by call. Two choices keep accuracy a fair measurement. First, the agent sees only the question, the KG and the series of the active profile, never the ground-truth answer or the code that computes it. Second, a stream the profile lacks is absent from those series, so a question that needs it is unanswerable to the agent. Each question also states its answer shape and units, so grading targets retrieval and reasoning. These choices guard against the shortcuts a model can exploit in a carelessly designed benchmark [49]. 4.2. The question bank and its grading The canon of Section 3.1 defines the question space. The question bank has 64 question classes over it (Appendix D), each bound to one cell at one level. Together they target 59 of the 76 rungs, among them every rung that the published corpus credits at any profile. Five classes reproduce analyses from the Mortar application library, and four span two KG hops, such as the warmest zone under a named air handler. A class requires at least the streams that the canon requires of its rung, so a question is posed only on a rung that the ceiling credits. The L3 classes compute the quantity that separates the causes, such as the damper signal behind a temperature difference, and grade that quantity. They test whether an agent can reach and use the separating stream that attribution needs, and the diagnosis scenarios of Section 4.4 test the attribution itself. An L3 rung’s accuracy is therefore an upper bound on how well an agent attributes. Instances are sampled from the building’s own KG and series, up to three per class from a fixed seed, over zones, equipment, dates and seasons, and the ground-truth answer is computed in code 14 from the same series. A class whose streams the building lacks yields no instances, and its rungs count as data limitation. Every question states its own conventions, such as the window, the units and the sign of a difference, so that a disagreement over conventions is not scored as an AI failure. Each answer is scored by a grader matched to its type, fixed in advance. A numeric answer is correct within a tolerance set per class, such as ±0.5 ◦ C for a temperature, following benchmarks for numerical question answering [50, 51]. A boolean answer must match the ground-truth verdict, and an entity answer must name the ground-truth entity by any name the KG ties to it. Every episode is then classed by the outcomes of Table 5. On the sweep building each question is asked three times, on the other buildings once, and the accuracy of a rung is the mean over its instances and repeats. Realized readiness is reported with a 95% bootstrap interval, every other proportion with its Wilson 95% interval, and a difference between two small proportions is tested with Fisher’s exact test (Appendix D). A guessing baseline, a fixed answer chosen in advance for each answer type, is scored on the same questions. 4.3. The simulated corpus The corpus is the Building AI Testbed Suite (BATS) [52], a published dataset generated with the BuildStream simulation software from DOE commercial prototype models [53] simulated in EnergyPlus [54]. It holds nine clean office buildings, the small, medium and large office prototypes in three climates (Tampa, 2A; New York, 4A; Buffalo, 5A), all at the ASHRAE 90.1-2019 vintage. Each has a faulted variant with labelled faults. Every building comes as a Brick [20] KG and hourly time series for one year. Each point that has a series carries a reference id that resolves to its series, so an agent can go from a KG entity to its measurements. A high accuracy cannot come from answers the model memorized in training, because the correct answer differs by building and climate and a numeric answer has to be computed from the series. Template-generated benchmarks with controlled ground truth are an established design in machine learning [55]. Three features of the published data affect the study, and each is handled before any question is asked. First, the KG describes more points than the data include. In the large office, 761 points are described as having a series, and the release contains 93 of them. The ceiling is therefore computed both on every point the KG describes and on the points with data, and the gap between the two shows how far the corpus breaks the third premise of Section 3. Second, the KG records equipment links from the equipment’s side and zone links from the point’s side. The study adds every such link in the other direction, a routine step with KGs, and runs four question classes on the original KG to test whether this matters. Third, the zone-level power sensors carry the simulated zone lighting power under a generic type. The study counts zone-attached power as lighting, in the ceiling and in the text of every lighting question, so that the ceiling and the agent apply the same rule. 4.4. Experiments on the simulated corpus Instrumentation sweep. The sweep varies instrumentation on one building, the large office in Tampa, and holds everything else fixed. A profile keeps only the series of its stream classes, which models “this building lacks that sensor” while the physics, the building and the climate stay fixed. Five nested profiles are used (Table 7). The corpus buildings are at the 90.1-2019 vintage, and the metered profile takes its metering from the current edition, ASHRAE 90.1-2022 [56], whose Section 8.4.3 requires the total electrical energy and the HVAC, interior lighting, exterior lighting, receptacle and refrigeration energy to be metered separately. The total is the whole-building meter and the end uses are the submeters of Table 4. The rich profile adds the points that the Guideline 36 sequences [33] read and write. On the published corpus the metered and rich profiles coincide, because the release has none of the rich profile’s points, so the sweep runs four distinct profiles and the rich profile’s points appear only in the real buildings. For each profile, C ans (I) is computed 15 Table 7: Instrumentation profiles of the sweep. Each profile holds the stream classes of the profiles above it and adds those listed. The last column gives which of the added classes the BATS large office includes. ProfileAdds these stream classesBasisIn BATS Minimal zone temperaturethe least a zone controller readsyes Comfort zone heating and cooling setpointsa thermostat’s inputsyes Standard occupancyoccupancy sensingyes Metered whole-building meter, end-use submeters, zone lighting power, equipment power, outside air temperature the building-level metering ASHRAE 90.1-2022 requires of a large building, plus equipment power, zone lighting power and outside air temperature all but outside air temperature Richscheduled setpoint, terminal actuation command and response, supply air temperature, run status, equipment load, zone CO 2 , outdoor-air flow the points the Guideline 36 sequences read and write none from the exposed classes (Eq. 2), the question bank is built on the series the profile keeps, the agent is run, and the four shares of Eq. 5 are reported. The dependence of these results on the canon is tested by recomputing the ceilings, the realized readiness and the census under four alternative canons: without air quality, without occupancy and lighting, with no target level above L2, and with each of the six domains counted equally. To test whether the agent respects the ceiling, every class that a profile cannot support is also posed at that profile, one instance with three repeats, with the question and its ground truth built on all published series and the agent given only the profile’s series. Building and agent sweeps. The reference agent is also run on the other eight buildings of the corpus, on all their published series with one repeat, to test whether the results hold across building sizes and climates. To test how much the choice of agent matters, the same questions are run on the sweep building at the metered profile, one repeat of the 22 classes that made up the question bank when the comparison was run, with a second current open-weight model, Gemma 4 with 31 billion parameters [57], and with three other local models (Qwen2.5 32B, Llama 3.1 8B and Mistral NeMo 12B), each pinned to an exact build. The building, the questions, the tools and the grading are held fixed across models, so a difference between models is AI failure. Diagnosis scenarios. Diagnosis questions need faults with known causes, and a test of attribution needs pairs of faults that look alike without the separating stream. Four scenarios in two pairs are used, all in the large office in Tampa (Appendix E). In pair A, a thermostat offset of 1 ◦ C in one zone, injected through the EnergyPlus fault model [58] so that it propagates through the control loop and the physics, is set against a real schedule change of the same size. The two move the zone temperature and the setpoint in effect alike, and only the scheduled setpoint separates them (Table B.15). In pair B, a sensor drift of 1 ◦ C, a magnitude the sensor-fault literature treats as material [59], is set against an internal-load step of 40 kW in the same zone. The drift is added to a monitoring sensor separate from the controlling thermostat, so it never enters the control loop, and the study makes that assumption. The two raise the reported temperature alike, and only the terminal damper signal separates them, because it stays flat under the drift and opens under the load. The published release exports neither separating stream. A supplement to the release, deposited 16 with the study’s code [60], provides the scheduled setpoint and the damper position, with the series of the two rival scenarios. Appendix E describes how the supplement was produced and gives the checks that the two scenarios of each pair look alike without the separating stream and differ with it. Each scenario is asked with its candidate causes listed in the question. For pair B the question also states that the reported temperature comes from a monitoring sensor and that the zone’s controller uses its own thermostat, the premise under which the damper position separates the causes. A scenario is asked in two conditions, with 20 repeats each. In the base condition the agent has only the zone temperature and setpoint series, the causes are not identifiable, the correct outcome is an abstention, and any answer is an overclaim (Table 5). In the separating condition the stream that separates the pair is added, the question is answerable, and the correct outcome is the true cause, so a wrong cause or an abstention is an AI failure. 4.5. The real buildings Two public sources supply real buildings. Mortar [31, 61] publishes 44 Brick KGs of real buildings with their series, and 36 of them link at least one point to a series. The KGs are read at their revision of 11 August 2026 (commit 8844574c). The Building TimeSeries (BTS) dataset [62] adds one office, Site B, with a Brick KG and metered series. For each KG the stream classes are read by a fixed set of rules that map Brick classes, together with what a point is attached to (a zone, a terminal unit, central equipment or the building), to the 17 stream classes of the canon (Table B.16). A point typed with the successor of a listed class counts as that class. A metered point that the KG attaches to nothing and links to nothing counts as no stream class, because its scope is unknown. 4.6. Experiments on the real buildings Census. Both ceilings then follow from Eqs. 2 and 6. Two answerable-readiness ceilings are com- puted per KG, one from every typed point the KG declares and one from the points that carry a series reference, and their difference is the declared-versus-linked gap. The census reads linked points, not usable series, because usability can be judged only from each building’s series, which are downloaded for the eight buildings run in depth. The ranking robustness of Section 3.1 is tested by drawing 2,000 random weightings, one independent exponential draw per domain, and counting how many reorder at least one pair of buildings whose ceilings differ (Eq. 3). The census is repeated with the unattached meters counted as whole-building meters, and with a strict mapping that cred- its no generic class through what it is attached to. As an external check, each of the ten Mortar analytics applications that compute something is run on each KG by its own qualifying queries, and the number of applications that can run is compared with the ceiling. Questions on real data. The question bank is run on the eight Mortar buildings with the most linked streams, each on the calendar year in which the most of its series are usable. A series is usable when it covers nearly every hour of the year and is neither stuck nor dead, and only usable series are kept, so the ceiling of a real building is computed on the data an agent could use. Appendix F states the rule, its sensitivity variants, and the handling of temperature units. The KGs give no time zone, so an hour window refers to Coordinated Universal Time (UTC), and on these buildings it tests the computation, not an occupied period. The questions and their ground truth are generated as on the simulated corpus (Section 4.2), from the building’s own KG and usable series. On real data the ground truth is what the recorded series say, so the questions test the agent’s computation and not the accuracy of the building’s sensors. Each class yields up to three instances, with three repeats on two buildings and one on the rest. 17 minimalcomfortstandardmetered (= rich) 0.0 0.2 0.4 0.6 0.8 1.0 share of the canon total F = 0.007 7/76 rungs F = 0.003 12/76 rungs F = 0.021 20/76 rungs F = 0.023 49/76 rungs never reached on this building: air quality (16 rungs), L3 of thermal, equipment, energy (11) thermal occupancy lighting equipment energy AI failure F data limitation Figure 7: The instrumentation sweep on the large office in Tampa, by domain, reference agent. The coloured segments are the realized readiness of each domain. 5. Results The results follow the experiments of Figure 5 in order, with the actuation axis reported after the census, and close with the reference agent’s misses across all runs. 5.1. The instrumentation sweep Table 8 and Figure 7 report the sweep. The ceiling rises from 7 to 49 of the 76 rungs as sensing is added. The metered profile reaches C ans (I) = 0.645, which is also the most the published corpus can reach (Section 4.4). Air quality (16 rungs), the L3 rungs of thermal and equipment (8 rungs), and the L3 rungs of energy (3 rungs, which need outside air temperature) stay in the data-limitation share at every profile. Table B.17 gives the achieved level of every cell at every profile. Table 8: The instrumentation sweep on the large office in Tampa, reference agent. n is the number of graded episodes, F/C ans (I) the AI failure as a share of the ceiling, and the interval the 95% bootstrap interval on A r . The unprobed share is zero at every profile, so AI failure is the rest of the ceiling, F = C ans (I)− A r . ProfileC ans (I)nAA r F F/C ans (I) 95% interval minimal7/76 72 0.921 0.085 0.0070.08 0.080–0.089 comfort12/76 114 0.981 0.155 0.0030.02 0.152–0.158 standard20/76 186 0.919 0.242 0.0210.08 0.233–0.251 metered = rich 49/76 456 0.964 0.621 0.0230.04 0.610–0.632 The agent realizes most of what the ceiling credits. Its accuracy over the probed rungs is 0.92 at the minimal profile and 0.96 at the metered profile, where it realizes 0.621 of the 0.645 that the building can support. The AI-failure share never exceeds 0.023 of the canon. Measured against the ceiling, the agent loses 0.08 of what the data can answer at the minimal profile and 0.04 at the metered profile. Every credited rung is probed, so realized readiness equals the product C ans (I) A. 18 Across the three repeats, realized readiness at the metered profile ranged from 0.599 to 0.638, and accuracy from 0.93 to 0.99. The interval of Table 8 is narrower because it is for the mean of the three repeats, and a single run varies by this much. Accuracy is lower at the standard profile than at the comfort profile (0.92 against 0.98), although both pose the same thermal questions on the same graph. Seven of the eleven thermal misses at the standard profile, against one at the comfort profile, are abstentions after the agent failed to find a zone by its label (Fisher’s exact test on the thermal misses, p = 0.02), so the difference lies in how the agent searched. At the metered profile, 40 of the 51 classes scored 1.00 in every repeat. Most of the other 11 missed one of their nine answers, and only one changed by more than one instance between repeats, the equipment explanation at L2, which scored 1 of 3 in one repeat and 3 of 3 in another. Table D.20 gives the score of every class, among them the two-hop classes and those that reproduce Mortar analyses. Of the 16 misses at the metered profile, 5 are abstentions on answerable questions, 9 are wrong answers, and two reached the turn limit without an answer. Questions the data cannot answer. Asked the classes that each profile cannot support, the reference agent answered 8 of 128 questions at the minimal profile (overclaim rate 0.06, 95% interval 0.03– 0.12) and none at the comfort (0 of 113) or standard (0 of 90) profiles. These counts leave out one server error at each of the minimal and comfort profiles, and five episodes ended without an answer. Every one of its 318 abstentions named a stream the profile lacks. All eight were setpoint questions asked without a setpoint series, and the agent answered from the static design value that the published KG stores on each zone setpoint. The answer was right in four of the eight, where the setpoint in effect equalled the design value, and wrong in the other four. All eight count as overclaims, because a design value does not determine the setpoint in effect at a given hour. At the metered profile every class the published series support is answerable, so none is posed there. A guessing baseline. A fixed answer chosen in advance, zero for a number, false for a yes/no question and the most common name for an entity, would pass 0.33 of the 456 questions at the metered profile, against 0.965 answered correctly by the reference agent. On this building seven classes have the same answer, or one within the tolerance, in every instance, so a constant passes all of them. Five are diagnosis and explanation classes whose answer names the same zone, chiller or direction of change at every sampled time. Two are thermal deviations that stay near zero because the simulated zones track their setpoints. On these classes the score cannot tell an answer from a guess. The agent was not guessing, however, as it abstained in 318 of the 331 questions the data cannot answer. Links recorded from one side. On the four classes run on the original KG, without the reverse links added in Section 4.3, the reference agent answered 36 of 36, as it did with them. For this agent the one-sided links cost nothing on those classes, so the added links do not inflate their score. Sensitivity to the canon. Absolute values depend on the canon, and the conclusions drawn from them do not (Table 9). Under the four alternatives, the profiles keep their order, and the simulated large office stays far above the median real building. AI failure stays between 0.034 and 0.040 of the ceiling, and the ranking of the 37 real buildings keeps a rank correlation of at least 0.97 with the declared canon. 5.2. The building and agent sweeps Building sweep. On the other eight buildings of the corpus, the reference agent’s accuracy ranges from 0.910 to 0.959 (Table 10). The ceiling cannot change with climate, because every climate publishes the same streams, so the large and medium offices reach the sweep building’s 49 of 76, 19 Table 9: Headline results under alternative canons: the ceiling and A r of the large office at its metered profile, and the median ceiling of the 37 real KGs with linked series with the Spearman rank correlation of their ceilings against the declared canon. Canonc Σ C ans (I)A r F/C ans (I) Real median Rank correlation declared76 0.645 0.6210.0360.1581.000 no air quality60 0.817 0.7870.0360.2000.994 no occupancy, lighting 60 0.550 0.5280.0400.2000.999 no level above L261 0.803 0.7740.0360.1970.970 equal domain shares 76 0.708 0.6840.0340.1251.000 and accuracy stays within that narrow range. The small offices reach 37, because no equipment power is metered in their release, and the equipment domain falls into the data-limitation share. Every domain scores at least 0.88 in every building except occupancy in two, 0.75 on the small office in New York (18 of 24 episodes) and 0.83 on the medium office in Buffalo (20 of 24). Table 10: The other eight buildings of the published corpus, reference agent, 1 repeat, 113 to 153 graded episodes each. Air quality has no stream in the release, and a dash marks a domain with no instance. Office, climateC ans (I)A Thermal Energy Equipment Occupancy Lighting Large, New York49/76 0.952 0.950.930.970.960.96 Large, Buffalo49/76 0.932 0.950.930.890.960.96 Medium, Tampa49/76 0.940 0.950.930.880.961.00 Medium, New York 49/76 0.957 0.921.000.970.921.00 Medium, Buffalo49/76 0.924 0.951.000.890.831.00 Small, Tampa37/76 0.959 0.940.93–0.961.00 Small, New York37/76 0.910 0.940.93–0.751.00 Small, Buffalo37/76 0.955 0.971.00–0.920.92 Agent sweep. Figure 8 compares the four other local models of Section 4.4 with the reference agent, whose row is the first repeat of the sweep on the same 22 classes (66 episodes). Gemma 4 reaches 0.879, against 0.985 for the reference, and takes more than three times as long per episode (242 s against 70 s). Six of its eight misses ended without an answer. Qwen2.5 answers most questions and gets 4 of 66 right. Llama 3.1 and Mistral NeMo score zero because they almost never call the answer tool. Gemma 2 9B could not be run, because the model server offers no tool calling for it. On one building and one set of questions, accuracy thus spans 0 to 0.985 across five local models. A readiness report must name the agent that realizes it, because the realized share belongs to the building and the agent together. 5.3. The diagnosis scenarios Each of the four scenarios is asked 20 times in each condition (Section 4.4). Without the separating stream the reference agent overclaimed in 48 of 80 episodes (95% interval 0.49–0.70). With it, the agent named the true cause in 33 of 80 (0.31–0.52), a wrong cause in 19, abstained in 24, and ended without an answer in 4 (Figure 9). The data suffice in all four scenarios. A fixed rule that asks only whether the separating stream changed, the scheduled setpoint for pair A and the damper position for pair B, names the true cause of each (Table E.23). The agent did not use the stream in either pair. In pair A it named a cause in 39 of 40 episodes without the scheduled setpoint, most often the controller offset, and it kept favouring the offset with the setpoint. It named the true cause of the schedule change in 9 of 20 episodes with the stream and in 9 of 20 without it 20 01020304050607080 episodes (of 66) Qwen3.8 27B (reference) Gemma 4 31B Qwen2.5 32B Llama 3.1 8B Mistral NeMo 12B 0.98 (0.921.00) 0.88 (0.780.94) 0.06 (0.020.15) 0.00 (0.000.06) 0.00 (0.000.06) accuracy (95% interval) correct wrong answer abstained no answer (turn limit or stop) model-server error Figure 8: Other agents on the sweep building, metered profile, 22 classes, 1 repeat (66 episodes each). The interval is the Wilson 95% interval on accuracy. withoutwithwithoutwithwithoutwithwithoutwith 0 5 10 15 20 episodes 19 17 2 A: thermostat offset 20 9 10 A: schedule change 4 16 3 2 13 2 B: sensor drift 5 15 4 5 10 B: internal- load step true cause named wrong cause named overclaimed (a cause named without the stream) abstained no answer Figure 9: Diagnosis outcomes, reference agent, 20 repeats per scenario and condition. Pair B is asked with the monitoring-sensor premise stated (Section 4.4). Without the separating stream an abstention is correct and any named cause is an overclaim. With it, only the true cause is correct. (Fisher’s exact test, p = 1). In pair B it named the true cause in 7 of 40 episodes with the damper position and in 2 of 40 without it (p = 0.15). In 53 of its 54 abstentions on pair B it asked for a second temperature reading, although the question stated that the controller’s thermostat is not in the data. A first run of pair B without that premise had shown an effect on the load step, 11 of 20 correct with the damper position against 1 of 20 without it. With the premise stated, the effect did not hold (4 of 20 against 2 of 20). 5.4. The census of public real-building KGs Figure 10 places the 37 real building KGs that link at least one point to a series in the plane of the two ceilings, and Table 11 summarizes the census. On the data that is linked, the answerable- readiness ceiling has a median of 0.158 and a maximum of 0.500, against 0.645 for the simulated large office at its metered profile. A few stream classes set the distribution (Figure 11). The real KGs often link the control points of the rich profile, such as supply air temperature (32 of 37), equipment load (25) and run status (23). They rarely link the meters of the metered profile. Twelve 21 0.00.20.40.60.81.0 answerable-readiness ceiling C ans (I) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 actuation-readiness ceiling C act ( I ) Mortar (36 buildings), linked data BTS Site B, linked data declared by the graph Figure 10: Real buildings in the plane of the two ceilings, 37 KGs with linked series. Filled markers use the points that carry a series. An open marker, joined by a grey line, shows the higher ceiling the KG declares. Markers overlap where KGs share both ceilings. Table 11: The real-building census: 45 KGs, 37 of them with linked series. “Declared” counts every typed point; “linked” counts points that carry a series reference. QuantityValue Graphs in the census (Mortar + BTS)45 Graphs with at least one linked series37 C ans (I) on linked data: minimum / median / maximum0.000 / 0.158 / 0.500 Graphs whose declared C ans (I) exceeds the linked C ans (I)15 of 45 C act (I): minimum / median / maximum0.000 / 0.125 / 0.625 Graphs with no actuation handle13 of 37 Random domain weightings that reorder at least one pair1,901 of 2,000 Pairs of buildings that ever change order102 of 575 link an end-use submeter, 11 equipment power, and none a point typed as a whole-building meter. One links occupancy and one CO 2 . Some classes are declared more often than they are linked. The terminal actuation command is declared in 20 KGs and linked in 16, run status in 26 and 23, equipment power in 17 and 11, an end-use submeter in 18 and 12, and a whole-building meter in one KG that links none (Figure 11). The metering that the simulated office has at its metered profile is therefore rare in these KGs. The thermal and equipment domains carry the ceiling of almost every real building, and the energy, occupancy, air-quality and lighting domains sit in its data-limitation share. Declared against linked. In 15 of the 45 KGs the ceiling computed on every typed point exceeds the ceiling computed on the points that carry a series. In nine of them the linked ceiling is zero. Seven 22 05101520253035 real building KGs that link the stream class (of 37) zone temperature zone setpoint occupancy outside air temperature one end-use submeter equipment power two end-use submeters whole-building meter lighting power supply air temperature equipment load run status terminal actuation command terminal actuation response zone CO 2 scheduled setpoint outdoor-air flow 23 17 1 31 12 (18 declared) 11 (17 declared) 1 0 (1 declared) 0 32 25 23 (26 declared) 16 (20 declared) 13 1 0 0 first added at minimal or comfort first added at standard first added at metered first added at rich (Guideline 36 points) outline: declared in the KG Figure 11: Stream classes linked by the 37 real building KGs with linked series, coloured by the profile of the sweep that first adds each class. An outline shows the KGs that declare the class, where more declare it than link it. of these link no point to a series at all, and two link only series that reach no rung of the canon. The eighth KG without any linked series declares no canon stream either, so both its ceilings are zero. The simulated corpus shows the same gap, since the published large-office KG declares 74 of the 76 rungs and its series support 49. Ranking under other weights. Of 2,000 random weightings of the six domains, 1,901 reorder at least one pair of the 37 buildings. Most pairs are stable, and only 102 of the 575 pairs with unequal ceilings change order under any weighting. A site that weights the domains must therefore report the weights with the ranking. Ceiling against a sensor count. A ceiling that only counted sensors would add nothing to a point list. Over the 37 KGs, the linked ceiling has a rank correlation of 0.61 with the number of linked points, and 145 of the 573 pairs that both measures separate are ordered the opposite way. Its rank correlation with the number of linked stream classes is 0.83, and 64 of the 539 pairs that both measures separate are reversed. Graphs that link six stream classes range from 0.158 to 0.211. The ceiling therefore follows which classes are linked and how they combine in the requirement table, not how many points or classes there are. Sensitivity to the mapping rules. The census depends on the rules of Table B.16, which read a KG’s structure and never its point names. Counting the 16 retyped building meters of the Mortar graphs as whole-building meters leaves the median at 0.158, with a rank correlation of 0.98 against the reported ceilings. A strict mapping that credits no generic class through what it is attached to lowers the median to 0.092, with a rank correlation of 0.65, so the attachment rules matter more than any single class (Appendix F). 23 Ceiling against applications that can run. Only three of the ten Mortar applications can run on any KG, and the number that can run has a rank correlation of 0.62 with the linked ceiling, and 0.75 on the June revision of the graphs. The applications cover thermal comfort and setpoint tracking, so this check covers mainly the thermal part of the ceiling (Appendix F). 5.5. Actuation-readiness The actuation-readiness ceiling ranges from 0 to 0.625, with a median of 0.125, and 13 of the 37 KGs expose no handle of the actuation canon at all. Among the 37 KGs, equipment is the domain most often actuable (20 KGs, almost all through an on-off or enable command at A1), thermal next (17 KGs, 16 of them at A2 through a terminal command), air quality through ventilation rarely (3 KGs), and lighting never. No KG reaches the full ceiling of 1.0, and the actuation axis is only loosely related to the answering axis. The five buildings with the same linked answerable ceiling of 0.184 range from 0.25 to 0.625 on the actuation axis. On the simulated large office the actuation ceiling is 0.75, with thermal, air quality and equipment at A2 and no lighting handle, against an answerable ceiling of 0.645. That value counts the command points its KG declares, because the release exports none of their series, so it is not comparable with the linked values of the real buildings. The caveat of Section 3.5 applies with more force to the real KGs. A command point in a Mortar KG shows that the point is modelled, not that an external agent may write to it. 5.6. Questions on real data On the eight Mortar buildings with the most linked streams, 2,683 linked series of the point classes that the questions need were converted, and 2,008 of them (75%) passed the usability rule of Section 4.6. None was absent from the release, so every loss is a series that is present but unusable, and the losses fall on particular classes. Every heating command (0 of 181) and every occupancy sensor (0 of 104) failed, as did 213 of 803 zone temperature sensors, while zone setpoints (622 of 700), damper setpoints (215 of 241), supply airflow (275 of 307) and outside air temperature (42 of 44) mostly passed. The two classes fail for reasons no threshold repairs. The heating commands are sampled about once every eight hours, and holding each value until the next still leaves none usable. Every occupancy series holds a single value over the year. Across the variants of the rule, between 58% and 85% of the linked series are usable, and none makes a heating command or an occupancy sensor usable. A census on declared points would credit one of these buildings with the occupancy domain, and its data cannot support it. On the eight buildings, the question bank yields questions for the thermal classes only, because none of the eight links a usable meter, airflow setpoint or heating command. Thirteen classes instantiate, among them the four that judge a zone against its setpoint on the seven buildings that link a usable one and the L3 comparison of terminal damper commands on the buildings that link both the command and the response. They yield 394 episodes. The reference agent scored 375 of the 394 (0.952, 95% interval 0.93–0.97). Building accuracy ranges from 0.818 to 1.000, and the two buildings run three times range from 0.939 to 0.970 and from 0.917 to 0.972 across repeats. The weakest class is the setpoint diagnosis, the zone farthest above its own setpoint, at 20 of 30, mostly episodes that reached the turn limit. Of the 19 misses, nine ended without an answer, four name the room by its full point path, four are wrong or misplaced answers, and two are abstentions. On the thermal questions that the real data support, the agent is therefore about as accurate as in simulation (0.952 against 0.96 on the same thermal classes at the metered profile). What real data lowers is the number of questions that can be asked. 24 5.7. The reference agent’s misses Over the 2,380 graded episodes of the reference agent on the published corpus and the real buildings, 120 were misses. Each was classed by fixed rules and the rules were checked by hand (Table 12). All but four are the agent’s own errors, and the largest group is one pattern: a question names a zone by its label, the agent searches the identifiers, finds no match, and abstains although the data are present. A second group gives the right value in the wrong field of the answer. The other four are real-building answers that name a room by its full point path, which a looser grader would accept. All 120 are scored as AI failure in the results above, so the AI-failure share is an upper bound on the errors that belong to the agent. Table 12: The 120 misses of the reference agent over 2,380 graded episodes (the sweep, the other eight buildings, the runs on the original KG and the real buildings). ClassCount What happened agent error116 44 abstentions although the data were present, most after failing to find a zone named by its label; 20 episodes without an answer at the turn limit; 14 right values placed outside the answer field; 13 occupied and unoccupied swapped; 25 other wrong values, entities, signs or units grader strictness4 a real-building room named by its full point path 6. Discussion 6.1. Instrumentation bounds reporting and judging On the questions a building’s data can answer at L1 and L2, the reference agent answers nearly all of them, and the AI-failure share stays at or below 0.023 of the canon at every profile of the sweep. This accuracy is far above the top row-matching F 1 of 0.38 that zero-shot systems reach on the BuildingQA benchmark [38]. The two numbers measure different tasks and are not directly comparable, but much of the gap lies in how the questions are posed. BuildingQA poses paraphrased natural-language questions whose answers are the rows of a KG query. Here every question states its conventions and answer shape, the agent can query and compute as often as it needs within 25 turns, and an entity may be named by any name the KG gives it. The accuracy reported here is therefore accuracy on well-posed questions, and that design is what isolates the data as the constraint. What moves realized readiness is the ceiling, which rises from 0.09 to 0.64 as sensing is added, and what caps it on the published corpus is the absence of the control points that Guideline 36 names. For practice, “is this building ready for AI?” is to first order “what can this building’s data answer?”, which can be computed before any AI is run. Naming a cause is the exception (Section 6.3). Because the ceiling rises in steps, a readiness audit yields a ranked list: the stream class that would raise a given building’s ceiling the most. For the simulated office at its metered profile the largest single step is air quality, where a CO 2 sensor per zone [63], with occupancy and outdoor-air flow, opens 16 rungs. For 26 of the 37 real buildings with linked data it is equipment power, which 11 link, for ten it is a whole-building meter, which none links as such, and for one it is CO 2 . The list also has a cost axis. A stream class can be added by installing a sensor or by linking a point that the automation system already records, and the census shows that the second kind is common: 15 of 45 KGs declare more than their linked data support, and on the eight buildings studied in depth 25% of the linked series are present but unusable. Linking and cleaning cost labour and no hardware. The retrofit list should therefore be read in two passes, first the points to link 25 and repair, then the sensors to install, and the ceiling can be recomputed after each pass from the KG alone. The same decomposition gives the return on each kind of application. Reporting and summary applications need the L1 and L2 rungs, which zone temperature, setpoints and a meter supply. Diagnostic applications need the L3 rungs and so the control points. Control applications need the actuation axis. A building can be ready for reporting and not for diagnosis. In the census, 17 of the 37 buildings with linked data link a zone setpoint and none links a point typed as a whole-building meter, so most are not yet ready even for reporting across all domains. 6.2. When the KG is incomplete or wrong The ceiling is read from the KG, so it inherits the KG’s errors, and different errors bias it in different directions. Points that the KG declares but that carry no data make it overstate what the building can answer (Section 5.4). Points that the automation system records but that the KG never models make it understate, and they form the first pass of the retrofit list (Section 6.1). Mistyped or renamed classes make the KG misreport what the building has, and the error is silent. In the Mortar graphs, 1,084 zone setpoints carry renamed Brick classes that rules knowing only the old names would miss without warning, and the census counts them by following Brick’s links to each successor. The 16 building meters are retyped as generic sensors that no rule reading the KG’s structure can recognize. Wrong or one-directional relations leave the data in place but make them harder to reach, so the loss appears as AI failure, not as data limitation. On the four classes tested, one-directional links did not affect the reference agent, but a less thorough agent or a sparser KG could be affected. A KG can also mislead an agent into answering, as the design values stored on the published KG’s setpoints did at the minimal profile (Section 5.1). The same errors move the actuation ceiling. A handle that the KG does not model lowers C act (I), and a handle that it models but the automation system does not let an agent write to raises it (Section 3.5). The measurement is therefore only as good as the KG, and an assessment should begin by comparing the declared, linked and usable ceilings before relying on any one of them. 6.3. Diagnosis and the limits of published data Answerability at L3 is unique determinability (Section 3.4). A richly instrumented building can still be unable to answer “why”, and sensor counts and checklist scores cannot see this, because they credit the presence of a related stream. The requirement table follows from the cause table of Appendix B, so a change in the declared causes changes the requirement in a way a reader can audit. Without the separating stream the agent overclaimed in most diagnosis episodes (Section 5.3). An agent that names a cause the data cannot support is a hazard in a diagnostic role whatever its accuracy elsewhere, so the overclaim rate belongs beside the accuracy in any readiness report. With the stream the data suffice, and the agent still did not use it. The framework scores those outcomes as AI failures, which is the distinction it exists to draw. At L1 and L2 the data bound readiness. At L3 the data are necessary but not sufficient, and for this agent the AI is the constraint. 6.4. Relation to the Smart Readiness Indicator The framework offers the kind of measurement that the EU Smart Readiness Indicator’s own methodology calls preferable and does not provide: a rating grounded in what the building’s data can answer, computed from the KG and the series [17]. The two instruments are complementary and meet in one place. Ten of the SRI’s 54 services report information, and five of them, on heating, cooling, indoor air quality, electricity consumption and central performance reporting, relate to the canon through data. Their upper functionality levels, such as benchmarking or fault detection, are awarded by an assessor on inspection, and the ceiling tells whether the streams behind them 26 exist and hold usable data. The crosswalk of Appendix A maps every service to a canon cell, to the actuation axis, or to neither. The SRI weights its domains by an energy balance, and most weightings reorder at least one pair of real buildings (Section 5.4), so a site that adopts the SRI’s weights should report the ceiling under those weights and with every rung counted equally (Eq. 2) together. 6.5. Two axes, and the gradable boundary of autonomy Readiness for autonomy has two prerequisites a building either affords or does not: the data to answer and the handles to act. Both are measured as coverage, C ans (I) and C act (I), and the measurement stops short of the quality of what an agent then does, because a control policy has no objective ground truth. Simulation benchmarks such as the Building Optimization Testing framework (BOPTEST) [64] do score control policies, against performance indicators in a model of the building, but that scoring needs a calibrated model of the building under test, which a readiness measurement read from the KG does not have. That the two axes are decoupled in the real buildings (Section 5.5) is itself an operational finding, because each mismatch of Section 3.5 implies a different retrofit. The observable-but- not-actuable building needs actuators, and the actuable-but-not-observable building needs sensors before its actions can be trusted. Two extensions could raise readiness without new hardware: virtual sensing [65], which infers an unmetered quantity from correlated streams, on the answering axis, and surfacing already-present but unmapped command points on the actuation axis. 6.6. An evaluation pathway for building digital twins A building digital twin couples a physical asset to a continuously updated virtual model [66], increasingly a semantic one in which sensor streams are linked through a KG [67] and integrated with the automation system for live control [68]. Such a twin is the natural substrate for the AI-driven operation this study concerns, and its fitness for that role is bounded by the same property measured here. The framework therefore doubles as an evaluation pathway for a twin’s answerability layer, with C ans (I) scoring how much of the question canon the twin can support and the decomposition placing any shortfall as missing instrumentation, unprobed credit, or agent error. A deployed twin adds live, bidirectional synchronization with its physical counterpart, which this study does not exercise. 6.7. Limitations The evidence has clear edges. (i) The controlled study is simulated. The sweep, the diagnosis scenarios and the model comparison run on EnergyPlus output. The real buildings supply ceilings, usability and a subset of the question bank, and they show that the simulated profiles are richer than most of the public real-building KGs, not that the simulated accuracy transfers. (i) One reference agent and well-posed questions. One pinned open-weight model is held fixed, so its accuracy is a statement about that model on this question bank. The other models, whose accuracy on the same questions ranges from 0 to 0.88, are a sensitivity analysis, not a survey. The questions are also easier than those operators pose. Each states its conventions and answer shape, and the agent computes over clean or filtered series. Open-ended, ambiguous or multi-step questions, on which KGQA systems still fail often [38], would lower the realized share and raise the AI-failure share, and testing them is left to future work. Seven classes have the same answer in every instance on the sweep building, so a constant would pass them, and sampling instances whose answers differ would make them discriminating. (i) Nine buildings of one family. The published corpus holds three office prototypes in three climates at one code vintage, so the ceilings it spans are those of code-compliant offices with metering and no control points. (iv) Cause attribution rests on four scenarios. The 27 positive test uses two pairs of scenarios with 20 repeats per condition, in one building, and each question names only the two causes of its pair. It shows that this agent did not use a separating stream in these scenarios, not a rate that carries over to other faults. A first run of pair B without the monitoring-sensor premise differed on the load step (Section 5.3), so the result depends on how the question states the sensor’s role. The canon separates a stuck damper by the terminal command and its response, and no scenario tests that pair. The L3 question classes test the use of the separating stream, not the attribution. In pair A, the EnergyPlus thermostat offset shifts the setpoint in effect, which a biased thermostat in a real building would not show. (v) Real data reaches few cells. Real-data accuracy is known only for the 13 thermal classes that instantiate on the eight buildings run in depth (Section 5.6). (vi) Not every miss is the agent’s. Four real-building misses would pass a looser grader, so the AI-failure share is an upper bound on the agent’s own errors (Section 5.7). (vii) Stated rules. Several results rest on rules the study declares: the Brick class-mapping rules that read stream classes from a KG, the rule that zone-attached power in the published corpus is lighting, the 90% coverage and three-distinct-values rule for a usable series, and the Fahrenheit inference for unlabelled temperatures. Each is in the appendix or the code, and per-building ceilings move when the rules move (Section 5.4). (viii) Actuation is coverage. C act (I) records that a handle is modelled, not that an external agent may write to it or that it would act well. (ix) Data sources beyond the KG. Weather, tariffs, grid signals and unstructured records such as work orders are outside the canon by design, and a building with none of them can still be fully ready on the canon. (x) Air quality is CO 2 only. A building that logs particulate matter, volatile organic compounds or humidity but not CO 2 scores zero on air quality, so C ans (I) understates it. Each added pollutant needs a stream class and a cause set of its own, which the canon can take without changing the method. (xi) Presence, not coverage. A stream class counts when one point of it carries usable data, so one CO 2 sensor in one zone credits every air-quality rung. The ceiling states what can be answered somewhere in the building, not everywhere, and the share of zones or units each class covers could be reported beside it. The series are also hourly, which hides fault signatures shorter than an hour. (xii) Air-side requirements. The thermal L3 requirements include the supply air temperature of the air system serving the zone, which suits air-based systems. A radiant or hydronic zone reaches thermal L3 only if equivalent streams, such as a supply water temperature, are added to the stream classes. (xiii) The census reads public research KGs. The Mortar KGs were assembled for a research testbed, so the census measures what those KGs describe and link. Its values move with the mapping rules and the dataset revision (Section 5.4), and they describe public Brick models, not the building stock. (xiv) No expert elicitation. The canon and the cause table were written for this study and checked against two practitioner corpora, not rated by practitioners. A structured review by practitioners is the most direct way to strengthen them. 7. Conclusion This paper has argued that the first question for building AI is not how capable the model is but how much the building’s data can answer, and has made that question measurable. The framework defines a building’s answerable-readiness ceiling as a function of its instrumentation, the realized readiness that a fixed reference agent delivers on the rungs the question bank probes, and a decomposition of the whole canon into realized readiness, AI failure, unprobed credit and data limitation. It adds a second axis, actuation-readiness, and derives the canon’s diagnostic requirements from declared cause sets. The empirical picture is measured, and it is modest. On the published simulated corpus the ceiling of a code-compliant large office reaches 0.64 of the canon at its metered profile, and the published release supports no more, because it exports none of the control points that diagnosis 28 needs. With a question at every credited rung, the reference agent answers 0.96 of them at that profile, so the measured realized readiness is 0.62 and AI failure is 0.02 of the canon. On these fully specified questions, missing data, not the agent, set the limit. Naming a cause is where the agent, not the data, falls short. Without the stream that separates two look-alike causes the agent names a cause in 48 of 80 diagnosis episodes. With it, the agent names the true cause in 33 of 80, and in no scenario does the stream change its answer significantly, although a fixed rule on that stream names every cause. Across 37 public real-building KGs with linked data, the median ceiling is 0.16 and the maximum 0.50, none links a point typed as a whole-building meter, and 15 of 45 KGs declare more than their data support. On the eight real buildings run in depth, 25% of the linked series are unusable, and the agent’s accuracy on the questions that remain, all of them thermal, is as high as in simulation. Most reweightings of the domains reorder at least one pair of real buildings. The actuation axis is only loosely related to the answering axis in real buildings. For practice, this turns “is my building AI-ready?” into an auditable, ranked retrofit question whose first pass costs no hardware and can be run on a building’s own KG with the released code. For policy, it offers one way to supply the measurement-based component that the Smart Readiness Indicator’s own methodology calls for. Several directions follow. The most immediate is to test attribution across a larger fault library, which needs a corpus that exports the control points of every building and belongs to the successor of the corpus used here. Real buildings with linked meters and setpoints, which the census shows exist, would extend real-data accuracy beyond the thermal domain. And because realized readiness depends on the agent as well as the data, tracking how deployed agents close the AI-failure share and hold the overclaim rate down on real data is its own line of study. Data and code availability The simulated corpus, BATS v1.0 [52], is published on Zenodo (https://doi.org/10.5281/ zenodo.20777376) under C BY-NC 4.0. The Mortar KGs and series are public Hugging Face datasets [61], and the BTS data are published on figshare (https://doi.org/10.6084/m9. figshare.28705559). The code that computes both ceilings, builds and grades the question bank and runs the agent is deposited on Zenodo [60] (https://doi.org/10.5281/zenodo.23197610) under the Apache-2.0 license. The same deposit holds, under C BY-NC 4.0, the result tables, the run summaries, the transcripts of the runs on the simulated corpus, and a supplement to BATS with the separating streams and the paired diagnosis scenarios. The Mortar data are not redistributed, so the runs on the real buildings are deposited as scores only. Declaration of competing interest The author declares no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Funding This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors. CRediT authorship contribution statement Wooyoung Jung: Conceptualization, Methodology, Software, Validation, Formal analysis, Investigation, Data curation, Writing – original draft, Writing – review & editing, Visualization. 29 Declaration of generative AI and AI-assisted technologies in the writing process During the preparation of this work the author used Claude Opus 4.8, Claude Opus 5 and Claude Opus 5.5 (Anthropic) in order to proofread the manuscript. After using these tools, the author reviewed and edited the content as needed and takes full responsibility for the content of the published article. References [1] R. Bommasani, D. A. Hudson, E. Adeli, et al., On the opportunities and risks of foundation models, arXiv:2108.07258 (2021). [2] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, Y. Cao, ReAct: Synergizing reasoning and acting in language models, in: Proc. 11th Int. Conf. on Learning Representations (ICLR), 2023. [3] M. Liu, L. Zhang, J. Chen, W.-A. Chen, Z. Yang, L. J. Lo, J. Wen, Z. O’Neill, Large language models for building energy applications: Opportunities and challenges, Building Simulation 18 (2) (2025) 225–234. doi:10.1007/s12273-025-1235-9. [4] M. Arslan, S. Munawar, Large language models in building energy applications: A survey, Energy and Buildings 352 (2026) 116800. doi:10.1016/j.enbuild.2025.116800. [5] Clockworks Analytics, Clockworks analytics: building fault detection and diagnostics software, https://clockworksanalytics.com/software/, product documentation; accessed September 2026. [6] SkyFoundry, SkySpark analytics platform, https://skyfoundry.com/product, product docu- mentation; accessed September 2026. [7] B. Chen, Z. Cai, M. Bergés, Gnu-RL: A precocial reinforcement learning solution for building HVAC control using a differentiable MPC policy, in: Proc. 6th ACM Int. Conf. on Systems for Energy-Efficient Buildings, Cities, and Transportation (BuildSys), 2019, p. 316–325. doi: 10.1145/3360322.3360849. [8] D. Blum, Z. Wang, C. Weyandt, D. Kim, M. Wetter, T. Hong, M. A. Piette, Field demon- stration and implementation analysis of model predictive control in an office HVAC system, Applied Energy 318 (2022) 119104. doi:10.1016/j.apenergy.2022.119104. [9] S. Lee, M. Kang, J. Lee, S. Lee, D. Kim, J. Hong, J. Shin, P. Zhang, J. Ko, LLM-based question- answer framework for sensor-driven HVAC system interaction, arXiv:2507.04748 (2025). [10] J. Zhang, C. Zhang, J. Lu, Y. Zhao, Domain-specific large language models for fault diagnosis of heating, ventilation, and air conditioning systems by labeled-data-supervised fine-tuning, Applied Energy 377 (2025) 124378. doi:10.1016/j.apenergy.2024.124378. [11] L. Song, C. Zhang, L. Zhao, J. Bian, Pre-trained large language models for industrial control, arXiv:2308.03028 (2023). [12] D. Liu, X. Zhou, Y. Li, Lightweight large language models for intent recognition and action invocation in building energy management, Journal of Building Engineering 125 (2026) 116170. doi:10.1016/j.jobe.2026.116170. 30 [13] L. Zhang, Z. Chen, V. Ford, Advancing building energy modeling with large language mod- els: Exploration and case studies, Energy and Buildings 323 (2024) 114788. doi:10.1016/j. enbuild.2024.114788. [14] L. Zhang, X. Fu, Y. Li, J. Chen, Large language model-based agent schema and library for automated building energy analysis and modeling, Automation in Construction 176 (2025) 106244. doi:10.1016/j.autcon.2025.106244. [15] W. Jung, Chain-of-thought prompting for generating personalized home energy-saving strate- gies, E3S Web of Conferences 716 (2026) 06015. doi:10.1051/e3sconf/202671606015. [16] W. Jung, Multi-agent home energy management assistant (HEMA), SoftwareX 34 (2026) 102633. doi:10.1016/j.softx.2026.102633. [17] S. Verbeke, D. Aerts, G. Reynders, Y. Ma, P. Waide, Final report on the technical support to the development of a smart readiness indicator for buildings, Tech. rep., European Commission, Directorate-General for Energy, study on the Smart Readiness Indicator (SRI) (2020). [18] European Commission, Commission delegated regulation (EU) 2020/2155 supplementing di- rective (EU) 2010/31 establishing an optional common scheme for rating the smart readiness of buildings, Official Journal of the European Union L 431, https://eur-lex.europa.eu/eli/ reg_del/2020/2155/oj (2020). [19] WiredScore, SmartScore certification, https://wiredscore.com/certify-a-building/ smartscore/, accessed September 2026. [20] B. Balaji, A. Bhattacharya, G. Fierro, et al., Brick: Metadata schema for portable smart building applications, Applied Energy 226 (2018) 1273–1292. doi:10.1016/j.apenergy.2018. 02.091. [21] ASHRAE, ASHRAE standard 223P: Designation and classification of semantic tags for building data, American Society of Heating, Refrigerating and Air-Conditioning Engineers (2023). [22] N. D. Lawrence, Data readiness levels, arXiv:1705.02245 (2017). [23] J. D. Billanes, Z. G. Ma, B. N. Jørgensen, Data-driven technologies for energy optimization in smart buildings: A scoping review, Energies 18 (2) (2025) 290. doi:10.3390/en18020290. [24] I. Vigna, R. Pernetti, G. Pernigotto, A. Gasparella, Analysis of the building smart readiness indicator calculation: A comparative case-study with two panels of experts, Energies 13 (11) (2020) 2796. doi:10.3390/en13112796. [25] E. Pärn, D. Edwards, M. Sing, The building information modelling trajectory in facilities man- agement: A review, Automation in Construction 75 (2017) 45–55. doi:10.1016/j.autcon. 2016.12.003. [26] BIMForum, Level of development (LOD) specification 2024, Part I, https://bimforum.org/ lod, accessed September 2026. [27] T. Wang, V. J. L. Gan, D. Hu, H. Liu, Digital twin-enabled built environment sensing and monitoring through semantic enrichment of BIM with SensorML, Automation in Construction 144 (2022) 104625. doi:10.1016/j.autcon.2022.104625. 31 [28] B. Balaji, A. Bhattacharya, G. Fierro, J. Gao, J. Gluck, D. Hong, et al., Brick: Towards a unified metadata schema for buildings, in: Proc. 3rd ACM Int. Conf. on Systems for Energy- Efficient Built Environments (BuildSys), 2016. doi:10.1145/2993422.2993577. [29] R. García-Castro, M. Lefrançois, M. Poveda-Villalón, L. Daniele, The ETSI SAREF ontology for smart applications: A long path of development and evolution, in: Energy Smart Appli- ances, 2023, p. 183–215. doi:10.1002/9781119899457.ch7. [30] G. Fierro, A. K. Prakash, C. Mosiman, M. Pritoni, P. Raftery, M. Wetter, D. E. Culler, Shepherding metadata through the building lifecycle, in: Proc. 7th ACM Int. Conf. on Systems for Energy-Efficient Buildings, Cities, and Transportation (BuildSys), 2020, p. 70–79. doi: 10.1145/3408308.3427627. [31] G. Fierro, M. Pritoni, M. AbdelBaky, P. Raftery, T. Peffer, G. Thomson, D. E. Culler, Mortar: An open testbed for portable building analytics, in: Proc. 5th ACM Int. Conf. on Systems for Energy-Efficient Built Environments (BuildSys), 2018. doi:10.1145/3276774.3276796. [32] G. Fierro, A. Saha, T. Shapinsky, M. Steen, H. Eslinger, Application-driven creation of building metadata models with semantic sufficiency, in: Proc. 9th ACM Int. Conf. on Sys- tems for Energy-Efficient Buildings, Cities, and Transportation (BuildSys), 2022. doi: 10.1145/3563357.3564083. [33] ASHRAE, ASHRAE guideline 36-2021: High-performance sequences of operation for HVAC systems (2021). [34] W. Jung, BrickTrace: Separating ontology reasoning from building grounding in knowledge graph question answering, in: Proc. 2026 ACM Sustainability Week, 2026, p. 438–442. doi: 10.1145/3765611.3815486. [35] C. Ma, Y. Chen, T. Wu, A. Khan, H. Wang, Large language models meet knowledge graphs for question answering: Synthesis and opportunities, arXiv:2505.20099 (2025). [36] C. V. S. Avila, M. A. Casanova, V. M. P. Vidal, A framework for question answering on knowledge graphs using large language models, in: Lecture Notes in Computer Science, 2025, p. 168–172. doi:10.1007/978-3-031-78952-6_20. [37] W. Y. Lin, Prototyping a chatbot for site managers using building information modeling (BIM) and natural language understanding (NLU) techniques, Sensors 23 (6) (2023) 2942. doi: 10.3390/s23062942. [38] O. B. Mulayim, A. Anwar, U. M. Saka, L. Paul, A. K. Prakash, G. Fierro, M. Pritoni, M. Bergés, BuildingQA: A benchmark for natural language question answering over building knowledge graphs, in: Proc. 12th ACM Int. Conf. on Systems for Energy-Efficient Buildings, Cities, and Transportation (BuildSys), 2025. doi:10.1145/3736425.3770097. [39] M. A. Merrill, M. Tan, V. Gupta, T. Hartvigsen, T. Althoff, Language models still strug- gle to zero-shot reason about time series, in: Findings of the Association for Computational Linguistics: EMNLP 2024, 2024. doi:10.18653/v1/2024.findings-emnlp.201. [40] S. Katipamula, M. R. Brambley, Review article : Methods for fault detection, diagnostics, and prognostics for building systems—a review, Part I, HVAC&R Research 11 (1) (2005) 3–25. doi:10.1080/10789669.2005.10391123. 32 [41] M. S. Mirnaghi, F. Haghighat, Fault detection and diagnosis of large-scale HVAC systems in buildings using data-driven methods: A comprehensive review, Energy and Buildings 229 (2020) 110492. doi:10.1016/j.enbuild.2020.110492. [42] J. Granderson, G. Lin, A. Harding, P. Im, Y. Chen, Building fault detection data to aid diagnostic algorithm creation and performance testing, Scientific Data 7 (1) (2020) 65. doi: 10.1038/s41597-020-0398-6. [43] J. Granderson, G. Lin, Y. Chen, A. Casillas, J. Wen, Z. Chen, P. Im, S. Huang, J. Ling, A labeled dataset for building HVAC systems operating in faulted and fault-free states, Scientific Data 10 (1) (2023). doi:10.1038/s41597-023-02197-w. [44] S. Frank, G. Lin, X. Jin, R. Singla, A. Farthing, J. Granderson, A performance evaluation framework for building fault detection and diagnosis algorithms, Energy and Buildings 192 (2019) 84–92. doi:10.1016/j.enbuild.2019.03.024. [45] X. Xie, J. Merino, N. Moretti, P. Pauwels, J. Y. Chang, A. K. Parlikad, Digital twin enabled fault detection and diagnosis process for building HVAC systems, Automation in Construction 146 (2023) 104695. doi:10.1016/j.autcon.2023.104695. [46] L. Travé-Massuyès, T. Escobet, X. Olive, Diagnosability analysis based on component- supported analytical redundancy relations, IEEE Transactions on Systems, Man, and Cybernet- ics - Part A: Systems and Humans 36 (6) (2006) 1146–1160. doi:10.1109/TSMCA.2006.878984. [47] M. Krysander, E. Frisk, Sensor placement for fault diagnosis, IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans 38 (6) (2008) 1398–1410. doi:10.1109/ TSMCA.2008.2003968. [48] Qwen Team, Qwen3.8-27b model card, Hugging Face / Ollama model repository, tag qwen3.8:27b, accessed September 2026. [49] R. Geirhos, J.-H. Jacobsen, C. Michaelis, et al., Shortcut learning in deep neural networks, Nature Machine Intelligence 2 (2020) 665–673. doi:10.1038/s42256-020-00257-z. [50] Z. Chen, W. Chen, C. Smiley, S. Shah, et al., FinQA: A dataset of numerical reasoning over financial data, in: Proc. EMNLP, 2021. doi:10.18653/v1/2021.emnlp-main.300. [51] F. Zhu, W. Lei, Y. Huang, et al., Tat-QA: A question answering benchmark on a hybrid of tabular and textual content in finance, in: Proc. ACL, 2021. doi:10.18653/v1/2021. acl-long.254. [52] W. Jung, Building AI testbed suite (BATS): Brick knowledge graphs, physics-grounded time series and answer keys for nine DOE prototype offices, Zenodo, version 1.0, C BY-NC 4.0 (2026). doi:10.5281/zenodo.20777376. [53] S. Goel, R. A. Athalye, W. Wang, et al., Enhancements to ASHRAE standard 90.1 prototype building models, Tech. rep., Pacific Northwest National Laboratory (PNNL-23269) (2014). doi:10.2172/1129366. [54] D. B. Crawley, L. K. Lawrie, F. C. Winkelmann, et al., EnergyPlus: creating a new-generation building energy simulation program, Energy and Buildings 33 (4) (2001) 319–331. doi:10. 1016/S0378-7788(00)00114-6. 33 [55] J. Johnson, B. Hariharan, L. van der Maaten, L. Fei-Fei, C. L. Zitnick, R. Girshick, CLEVR: A diagnostic dataset for compositional language and elementary visual reasoning, in: Proc. IEEE Conf. on Computer Vision and Pattern Recognition (CVPR), 2017. doi:10.1109/CVPR.2017. 215. [56] ASHRAE, ANSI/ASHRAE/IES standard 90.1-2022: Energy standard for sites and buildings except low-rise residential buildings (2022). [57] Gemma Team, Gemma 4 technical report, arXiv:2607.02770 (2026). [58] R. Zhang, T. Hong, Modeling of HVAC operational faults in building performance simulation, Applied Energy 202 (2017) 178–188. doi:10.1016/j.apenergy.2017.05.153. [59] Z. Du, X. Jin, Detection and diagnosis for sensor fault in HVAC systems, Energy Conversion and Management 48 (3) (2007) 693–702. doi:10.1016/j.enconman.2006.09.023. [60] W. Jung, building-ai-readiness: code, results and supplement for a measurement-based AI- readiness assessment of buildings, Zenodo, version 1.0.0, code Apache-2.0; results and BATS supplement C BY-NC 4.0 (2026). doi:10.5281/zenodo.23197610. [61] G. Fierro, Mortar building graphs and time series, Hugging Face datasets gtfierro/mortargraphs and gtfierro/mortar, accessed September 2026. [62] A. Prabowo, X. Lin, I. Razzak, H. Xue, E. W. Yap, M. Amos, F. D. Salim, BTS: Build- ing timeseries dataset: Empowering large-scale building analytics, in: Advances in Neu- ral Information Processing Systems 37 (NeurIPS 2024), 2024, p. 133180–133206, data at https://doi.org/10.6084/m9.figshare.28705559. doi:10.52202/079017-4232. [63] G. Pei, D. Rim, S. Schiavon, M. Vannucci, Effect of sensor position on the performance of CO 2 -based demand controlled ventilation, Energy and Buildings 202 (2019) 109358. doi: 10.1016/j.enbuild.2019.109358. [64] D. Blum, J. Arroyo, S. Huang, J. Drgoňa, F. Jorissen, H. T. Walnum, Y. Chen, K. Benne, D. Vrabie, M. Wetter, L. Helsen, Building optimization testing framework (BOPTEST) for simulation-based benchmarking of control strategies in buildings, Journal of Building Perfor- mance Simulation 14 (5) (2021) 586–610. doi:10.1080/19401493.2021.1986574. [65] G. Li, J. Xiong, S. Sun, J. Chen, Validation of virtual sensor-assisted Bayesian inference-based in-situ sensor calibration strategy for building HVAC systems, Building Simulation 16 (2) (2022) 185–203. doi:10.1007/s12273-022-0935-7. [66] S. Su, R. Y. Zhong, Y. Jiang, Digital twin and its applications in the construction industry: A state-of-art systematic review, Digital Twin 2 (1) (2025). doi:10.12688/digitaltwin.17664. 3. [67] C. Boje, A. Guerriero, S. Kubicki, Y. Rezgui, Towards a semantic construction digital twin: Directions for future research, Automation in Construction 114 (2020) 103179. doi:10.1016/ j.autcon.2020.103179. [68] T. Ma, F. Xiao, C. Zhang, J. Zhang, H. Zhang, K. Xu, X. Luo, Digital twin for 3D interactive building operations: integrating BIM, IoT-enabled building automation systems, AI, and mixed reality, Automation in Construction 176 (2025) 106277. doi:10.1016/j.autcon.2025.106277. 34 Appendix A. The SRI services and the canon Table A.13 lists the services of the SRI’s Method B catalogue [17] that relate to the canon. A service relates to the canon through the data it reports on or acts from (D), or through the control handle it needs on the actuation axis (A). Of the 54 services, 16 relate through data, 22 through actuation (8 through both), and 24 lie outside the canon by design (domestic hot water, the envelope, generation, storage, vehicle charging, and grid interaction). Table A.13: The 30 SRI Method B services that relate to the canon. D = related through data; A = related through the actuation axis; TABS = thermally activated building systems; IAQ = indoor air quality; TBS = technical building systems. SRI domainServiceRelation Canon cell or axis HeatingHeat emission controlAthermal A1 (zone setpoint), A2 (valve or reheat command) HeatingEmission control for TABSAthermal A1 HeatingControl of distribution fluid temperature Aequipment A1 HeatingControl of distribution pumpsAequipment A2 (speed command) HeatingHeat generator control (all except heat pumps) Aequipment A1, A2 HeatingHeat generator control (heat pumps) Aequipment A2 HeatingSequencing of heat generatorsA, Dequipment A2; equipment comparison L2 HeatingReport information regarding heating system performance Dequipment status, summary L1–L2; level 3–4 need equipment comparison L3 and diagnosis L3 CoolingCooling emission controlAthermal A1, A2 CoolingEmission control for TABS (cooling) Athermal A1 CoolingControl of chilled water temperature Aequipment A1 CoolingControl of distribution pumpsAequipment A2 CoolingInterlock: avoiding simultaneous heating and cooling Dequipment verification L3 (q_verification_3_simul) CoolingGenerator control for coolingAequipment A2 CoolingSequencing of cooling generatorsA, Dequipment A2; equipment comparison L2 CoolingReport information regarding cooling system performance Das for heating VentilationSupply air flow control at room level A, Dair quality A1 (airflow setpoint), A2 (outdoor-air damper); air quality status L1–L2 (CO 2 , occupancy) VentilationAir flow or pressure control at the air handler A, Dair quality A1; thermal verification L3 (t_verification_3_flow) VentilationHeat recovery: prevention of overheating Aequipment A2 VentilationSupply air temperature control at the air handler A, Dequipment A1; SAT stream (thermal diagnosis L3) VentilationFree cooling with mechanical ventilation A, Dair quality A2; OAT stream VentilationReporting information regarding IAQ Dair quality status, summary L1–L2; level 3 (warnings) needs air quality verification L3 LightingOccupancy control for indoor lighting A, Dlighting A2; lighting status L2 (l_status_2), lighting diagnosis L2 LightingControl of artificial lighting power based on daylight Alighting A1 (level setpoint) 35 SRI domainServiceRelation Canon cell or axis ElectricityReporting information regarding electricity consumption Denergy status, summary L1–L2; level 3–4 (appliance level, recommendations) need energy comparison L3 (two end-use groups) Monitoring and control Run time management of HVAC systems A, Dequipment A1 (on/off, enable); equipment verification L3 (power while commanded off) Monitoring and control Detecting faults of technical building systems and support to diagnosis Ddiagnosis L3 in every domain; level 3 ("diagnosing functions") is the canon’s L3 Monitoring and control Occupancy detection: connected services Doccupancy status L1; lighting status L2 Monitoring and control Central reporting of TBS performance and energy use Denergy summary L2 (per carrier, per domain: two end-use groups) Monitoring and control Single platform for automated control and coordination Athe actuation axis as a whole (every domain at A2) Appendix B. Canon examples, cause sets, stream classes and achieved levels Table B.14 gives an example question at each level of every canon cell, to show what each level adds. Table B.14: An example question at each level of every canon cell. Each example uses only the stream classes that Table 4 requires at its level. “–” marks a level above the cell’s target level. The questions posed to the agent are the question classes of Appendix D. IntentL1L2L3 Thermal statusWhat is Zone 3’s temperature now? How far is Zone 3 above its cooling setpoint now? – summaryWhat was Zone 3’s mean temperature yesterday? For how many hours yesterday was Zone 3 outside its setpoints? – comparisonWas Zone 3 warmer than Zone 5 at 15:00? How much warmer was Zone 3 than the other zones on its air handler? Was Zone 3 warmer than Zone 5 because its damper delivered less air? verificationDid Zone 3 stay at or below 24 ◦ C all day? Did Zone 3 stay within its setpoints all day? When Zone 3 ran above its cooling setpoint, did its damper open to correct it? diagnosisWhich zone was warmest at 15:00? Which zone was farthest above its own cooling setpoint at 15:00? Zone 3 is too warm: is the cause a setpoint override, a stuck damper or warm supply air? explanationHow much did Zone 3’s mean temperature change from Monday to Tuesday? Did Zone 3 drift further from its setpoint on Tuesday than on Monday? Why did Zone 3 run warmer on Tuesday: a schedule change, an override, a load change or a supply problem? Energy statusHow much electricity did the building use yesterday? – summaryWhat was the building’s peak hourly demand last month? What share of yesterday’s electricity went to lighting? – comparisonDid the building use more electricity on Tuesday than on Monday? Was Tuesday’s use unusual for a weekday this month? Was Tuesday’s increase due to hotter weather, and which end use drove it? diagnosisOn which day last month was use highest? Which days last month were more than 10% above the month’s mean? Which end use caused the high-use days, and were they weather-driven? 36 IntentL1L2L3 explanationBy how much did daily use change from Monday to Tuesday? Did the change fall in the occupied hours or outside them? Why did use rise on Tuesday: the weather, or a change in one end use? Air quality statusWhat is the CO 2 level in Zone 3 now? Is Zone 3’s CO 2 above 1,000 ppm while it is occupied? – summaryWhat was Zone 3’s mean CO 2 yesterday? For how many occupied hours yesterday was CO 2 above 800 ppm? – comparisonWas CO 2 higher in Zone 3 than in Zone 5 at 15:00? How much higher was Zone 3’s mean CO 2 than Zone 5’s yesterday? Was CO 2 higher in Zone 3 than in Zone 5 because it held more people or got less outdoor air? verificationDid Zone 3 stay below 1,000 ppm all day? Did Zone 3 stay below 1,000 ppm in every occupied hour? Did outdoor-air flow rise when Zone 3 was occupied, as the ventilation design intends? diagnosisWhich zone had the highest CO 2 at 15:00? Which zone had the most occupied hours above 1,000 ppm? Is Zone 3’s high CO 2 due to more people than designed or to too little outdoor air? explanationHow much did Zone 3’s peak CO 2 change from Monday to Tuesday? Did the rise fall in the occupied hours? Why was CO 2 higher on Tuesday: more people, or less outdoor air? Equipment statusWhat is AHU-1’s supply fan power now? What fraction of its own peak is AHU-1 drawing now? – summaryWhat was AHU-1’s mean power yesterday? For how many hours yesterday did AHU-1 run above half its peak? – comparisonDid AHU-1 draw more power than AHU-2 at 15:00? Which of the three air handlers used the most electricity yesterday? Did AHU-1 draw more than AHU-2 because it moved more air? verificationDid AHU-1 exceed 20 kW at any hour yesterday? Did AHU-1 stay below 90% of its own peak all day? Did AHU-1 draw power only while it was commanded on? diagnosisWhich item drew the most power at 15:00? Which item ran closest to its own peak yesterday? Is AHU-1’s high power due to a command change, a higher load or degradation? explanationHow much did AHU-1’s daily energy change from Monday to Tuesday? Did the change fall in the occupied hours? Why did AHU-1 use more on Tuesday: longer run hours, more airflow or degradation? Occupancy statusHow many people are in Zone 3 now? Is Zone 3 busier now than its usual daytime mean? – summaryWhat was Zone 3’s peak occupancy yesterday? Was Zone 3’s working-hour occupancy yesterday above its monthly mean? – comparisonWere more people in Zone 3 than in Zone 5 at 15:00? On average, how many more people were in Zone 3 than in Zone 5 during working hours? – diagnosisAt what hour was Zone 3 busiest yesterday? For how many hours was Zone 3 occupied outside working hours? – Lighting statusWhat is Zone 3’s lighting power now? Are Zone 3’s lights on while it is unoccupied? – 37 IntentL1L2L3 summaryWhat was Zone 3’s mean lighting power yesterday? Was Zone 3’s lighting energy yesterday above its usual weekday? – comparisonWas Zone 3’s lighting power higher than Zone 5’s at 15:00? Which zone used the most lighting energy yesterday? – diagnosisWhich zone had the highest lighting power at 15:00? For how many hours were Zone 3’s lights on while it was unoccupied? – Table B.15 lists the declared cause sets from which the L3 rows of the requirement table (Table 4) are derived (Section 3.4). Table B.15: Declared cause sets and the stream that separates each cause from its rivals. “T (peers)” is the zone temperature of other zones on the same air system. DomainCandidate causeWhat the data showSeparating stream Thermal schedule changescheduled setpoint and setpoint in effect move together SpC Thermal local override or controller offset setpoint in effect moves, scheduled setpoint stays SpC Thermal terminal-unit fault (stuck damper or valve) the command moves or saturates while the position stays ActC, ActP Thermal local load changecommand and position move together in the correcting direction ActC, ActP Thermal supply-side capacity losssupply air temperature off its normal value, peer zones deviate together SAT,T (peers) Thermal zone sensor faultreading departs from peers with setpoints, command and position unchanged T(peers), ActC, ActP Equipment commanded changerun command or status changes with powerRun Equipment load changeflow or delivered output changes with power Load Equipment degradation or faultpower rises at unchanged command and load Run, Load Energyweather-driven changeuse moves with outside air temperature, as on comparable days OAT Energywhich end use changedtwo metered end-use groups fix the third as the residual Sub2 Air quality occupancy above designoccupancy rises with CO 2 Occ Air quality insufficient outdoor airoutdoor-air flow low at normal occupancyOAF Table B.16 gives the rules that read the stream classes of a real Brick KG (Section 4.5). A class listed as a root counts wherever the point is, and its Brick subclasses count with it. A generic class counts only when the point is attached as stated. A point’s attachment is the entity it is a point of: a zone or room, a terminal unit, central HVAC equipment, or the building. A point on a damper or valve also takes the attachment of the unit that owns the damper or valve. In the linked census only points that carry a series reference are read. A point typed with a class that Brick names as the successor of a listed class counts as the listed class. A metered point attached to nothing and linked to nothing counts as no stream class. 38 Table B.16: Brick classes read as canon stream classes in the real-building census. StreamBrick classesCondition TZone_Air_Temperature_Sensor, Room_Air_Temperature_Sensor; generic Air_Temperature_Sensor, Temperature_Sensor generic classes only on a zone or terminal unit SpZone and room air temperature setpoints; effective, occupied and unoccupied heating and cooling setpoints; generic Cooling, Heating and Temperature_Setpoint generic classes only on a zone or terminal unit SpCas Spa KG that holds both a scheduled (occupied or unoccupied) and an effective setpoint ActCDamper_Position_Command and _Setpoint; Valve_Command; Heating_Command; Cooling_Command on a zone or terminal unit ActPDamper_Position_Sensor; Valve_Position_Sensor; generic Position_Sensor and supply, discharge and air flow sensors on a zone or terminal unit SATSupply_Air_Temperature_Sensor, Discharge_Air_Temperature_Sensor anywhere OATOutside_Air_Temperature_Sensoranywhere OccOccupancy_Sensor, Occupancy_Count_Sensor, Motion_Sensor anywhere CO2CO2_Sensoranywhere OAFOutside_Air_Flow_Sensoranywhere Runon-off, start-stop, enable, run, system and speed statuses and commands; frequency, pump and fan commands; Output_Frequency_Sensor on central HVAC equipment LoadAir_Flow_Sensor, Water_Flow_Sensor, Thermal_Power_Sensor on central HVAC equipment Wholeelectrical meter, or an electric power or energy sensor on the building or its building meter Pwrelectric power or energy sensoron central HVAC equipment or a terminal unit Lgtelectric power or energy sensor; illuminance and luminance points on lighting equipment, or (power) on a zone with no other attachment Sub, Sub2 a submeterits end uses, found by following feeds for two hops, give one (Sub) or two (Sub2) end-use groups Table B.17 applies the requirement table to the four profiles of the sweep, cell by cell. Table B.17: Achieved level of every canon cell at each profile of the sweep (large office, Tampa; profiles as in Table 7). The column sums are the numerators of C ans (I) in Table 8. DomainIntentTarget minimal comfort standard metered Thermalstatus21222 Thermalsummary21222 Thermalcomparison32222 Thermalverification31222 Thermaldiagnosis31222 Thermalexplanation31222 Energystatus10001 Energysummary20002 Energycomparison30002 Energydiagnosis30002 Energyexplanation30002 39 DomainIntentTarget minimal comfort standard metered Air quality status20000 Air quality summary20000 Air quality comparison30000 Air quality verification30000 Air quality diagnosis30000 Air quality explanation30000 Equipment status20002 Equipment summary20002 Equipment comparison30002 Equipment verification30002 Equipment diagnosis30002 Equipment explanation30002 Occupancy status20022 Occupancy summary20022 Occupancy comparison20022 Occupancy diagnosis20022 Lightingstatus20002 Lightingsummary20002 Lightingcomparison20002 Lightingdiagnosis20002 Credited rungs767122049 C ans (I)0.0920.1580.2630.645 Appendix C. The agent’s prompt and tools The agent is the system under test (Section 4.1). The reference model is qwen3.8:27b in its four- bit build (Q4_K_M), served by Ollama 0.33.3, model ID 22130167c4c2, with its context raised to 131,072 tokens. The server’s default sampling applies: temperature 1.0, nucleus sampling at 1.0 and top-k 20, with no fixed seed. The full digests are recorded in the released code. For each question the agent receives the system prompt of Listing C.1, the question text with its answer shape, and access to the three tools of Table C.18. The agent’s code records every turn, the token count of every prompt, and the outcome (answered, abstained, no answer, or error), and archives the transcript. The model writes out its reasoning before each reply, and that text is neither archived nor passed to later turns. The largest prompt of any turn was 62,031 tokens, under half of the window, and no turn of any model in the study reached its model’s window. Listing C.1: The agent’s system prompt, verbatim except for line breaks. You answer one operational question about one building, using only its data. You have the building’s Brick metadata graph and a time-series store. The store is two CSV files: CATALOG_CSV (timeseries_id, point_uri, point_class, unit, quantity_kind, building_id) and VALUES_CSV (timeseries_id, timestamp, value; hourly). A point in the graph links to its series through ref:hasExternalReference / ref:hasTimeseriesId. The store holds only the streams this building exposes, so a point in the graph may have no series. Work in three steps. Resolve the entities the question names to their series ids with query_graph. Fetch and compute with run_python, which runs standard-library Python with the variables GRAPH_TTL, CATALOG_CSV and VALUES_CSV already defined as file paths. Only the standard library is installed, and each call is a fresh process, so nothing 40 Table C.18: The three tools, as declared to the model. In Section 4.1 they are the KG query, Python and answer tools. ToolInputDescription given to the model query_graph sparql (string)Run a SPARQL SELECT query over the building’s Brick graph. Returns up to 200 rows as JSON. Prefixes brick:, ref:, rdfs: and rdf: are predefined. run_python code (string)Run standard-library Python 3 in an isolated process. GRAPH_TTL, CATALOG_CSV and VALUES_CSV are predefined file paths. Print what you need; stdout and stderr are returned. submit_answer answer (object), abstain (boolean, required), needed_streams (string) Hand in the final answer. Call exactly once, as the last step. The answer is in the JSON shape the question gives; abstain is true if the available data cannot determine the answer; when abstaining, name the streams that would be needed. carries over between calls. Do the arithmetic in code, not in your head. Then call submit_answer once, with the answer in the JSON shape the question gives. If the available streams cannot determine the answer, do not guess. Call submit_answer with abstain set to true and name the streams you would need. Table C.19: One episode of the reference agent on the sweep building at the metered profile. The first query uses relation names the KG does not have and returns nothing, and the agent recovers by finding the zone by its label. The full transcript is in the released code. Question (thermal summary, L1): What was the mean air temperature in zone Perimeter_mid_ZN_4 on 2018-01-02 (all 24 hourly values), in ◦ C? Answer shape "value": <number>. Call ToolWhat the agent didResult 1 KG querylooked for the zone’s temperature point with relation names the KG does not use no rows 2 KG queryfound the zone by its labelZone_F3_Z05 3 Pythonprinted the first lines of the series cataloguecolumn names and 19 series 4 Pythonfiltered the catalogue to Zone_F3_Z05the zone’s temperature series and its id 5 Pythonread that series for 2 January and averaged the 24 values 24 values, mean 24.2313 6 Answersubmitted "value": 24.2313ground truth 24.2313, within ±0.5 ◦ C, correct Appendix D. The question bank Table D.20 lists the 64 question classes (Section 4.2), ordered by domain, intent and level. Each class requires the stream classes shown, in the abbreviations of Appendix B. A class may compute with fewer of those streams, as the weather class uses only the meter and outside air temperature. Instances bind a zone, an item of equipment, an hour, a date or a month. Hops count the KG 41 relations an instance must traverse beyond the entity it names. A numeric answer is correct when it lies within the absolute tolerance, in the question’s units, or within the relative tolerance of the ground-truth value, whichever is met. The five classes marked with a dagger reproduce analyses from the Mortar application library. The score is the mean over the three repeats of the sweep, with its range when the repeats differ. A dash marks a class the published corpus cannot pose. The questions are paraphrased in the table. The verbatim templates, with the conventions each states, are in the released code. The released code also lists one instance of every class the published corpus poses, with its ground truth. Four classes span two KG hops, and three of them instantiate on the published corpus. The two-hop class on the warmest zone under a named air handler scored 0.78 at the minimal profile, 0.89 at the standard profile and 1.00 at the comfort and metered profiles, and the other two two-hop classes scored 1.00 at the metered profile. Of the five classes that reproduce Mortar analyses, only weekday mean energy can be posed on the published corpus, and it scored 1.00 in every repeat. The other four need streams that neither source provides. The two energy classes need both outside air temperature, which the published corpus lacks, and a whole-building meter, which the eight real buildings lack. The airflow class needs a usable airflow setpoint, and the class on simultaneous heating and cooling needs run status, load and valve commands. Only one class, the end use behind an increase in energy use, asks for the attribution directly. An instance is skipped when its conditions are not met, such as two zones too close in temperature to rank, so a class can yield fewer than three. Where the KG gives one label to two entities, such as a room and a thermal zone, the question names the entity type. The interval on realized readiness is a bootstrap that resamples instances within each rung and keeps all repeats of an instance together, with 2,000 resamples, and Fisher’s exact test is two-sided. Table D.21 gives worked examples. No L3 class instantiates on the published corpus, which exports none of the streams they need. For example, the full text of e_explanation_2 is “Between d1 and d2, did whole-building electricity use change more, in absolute joules summed over hours, during the occupied hours 08:00 to 18:00 (both included) or during the other hours of the day? Answer occupied or unoccupied.” Table D.20: The 64 question classes, with the reference agent’s score at the metered profile of the sweep. Each class is named as in the released code. A double dagger marks a class that one fixed answer passes in every instance on the sweep building. Name in codeCell, levelRequires AnswerQuestion (paraphrased) Score t_status_1thermal / status, L1 Tnumber,±0.5 air temperature of a zone at an hour 1.00 t_status_2 ‡ thermal / status, L2 T, Spnumber,±0.5 zone temperature minus its cooling setpoint at an hour 1.00 t_summary_1thermal / summary, L1 Tnumber,±0.5 mean zone temperature over a day 1.00 t_summary_2 ‡ thermal / summary, L2 T, Spnumber,±1 hours in a day outside the zone’s own setpoint band 1.00 t_comparison_1thermal / comparison, L1 Tyes/nowas one zone warmer than another at an hour 1.00 t_comparison_2thermal / comparison, L2 Tnumber,±0.5 temperature of one zone minus another at an hour 0.89 (0.67–1.00) t_comparison_2hop thermal / comparison, L2 Tentitywarmest zone served by a named air handler at an hour (2 hops) 1.00 t_comparison_3thermal / comparison, L3 T, Sp, ActC, ActP number, ±0.01 or±5% mean damper command of one zone minus another, 08:00–18:00 – 42 Name in codeCell, levelRequires AnswerQuestion (paraphrased) Score t_verification_1thermal / verification, L1 Tyes/nodid a zone stay at or below a stated temperature at every hour of a day 0.78 (0.67–1.00) t_verification_2thermal / verification, L2 T, Spyes/nodid the zone stay within its setpoints at every hour of a day 1.00 t_verification_3thermal / verification, L3 T, Sp, ActC, ActP number, ±0.01 or±5% mean damper command over the hours above the cooling setpoint – t_verification_3_ flow † thermal / verification, L3 T, Sp, ActC, ActP (+ airflow setpoint) number,±1 hours the terminal airflow was more than 10% off its setpoint – t_diagnosis_1 ‡ thermal / diagnosis, L1 Tentitywarmest zone in the building at an hour 1.00 t_diagnosis_2 ‡ thermal / diagnosis, L2 T, Spentityzone farthest above its own cooling setpoint at an hour 0.83 (0.50–1.00) t_explanation_1thermal / explanation, L1 Tnumber,±0.5 change in a zone’s daily mean temperature between two days 1.00 t_explanation_2 ‡ thermal / explanation, L2 T, Spentitydid a zone’s mean deviation from its cooling setpoint, 08:00–18:00, increase or decrease between two days 1.00 e_status_1energy / status, L1 Wholenumber,±2% whole-building electricity on a day 1.00 e_summary_1energy / summary, L1 Wholenumber,±2% highest hourly whole-building use in a month 1.00 e_summary_1_ weekday † energy / summary, L1 Wholenumber,±2% mean weekday daily use in a month 1.00 e_summary_2energy / summary, L2 Whole, Sub number, ±0.02 share of a day’s electricity that went to lighting 1.00 e_comparison_1energy / comparison, L1 Wholeyes/nodid the building use more electricity on one day than on another 1.00 e_comparison_2energy / comparison, L2 Wholenumber,±2% whole-building use on one day minus another 1.00 e_comparison_3energy / comparison, L3 Whole, Sub2, OAT entityend use with the largest increase between two days (2 hops) – e_comparison_3_ weather † energy / comparison, L3 Whole, Sub2, OAT number,±5% change in daily use per degree of outside temperature – e_diagnosis_1energy / diagnosis, L1 Wholeentitydate of the highest daily use in a month 1.00 e_diagnosis_2energy / diagnosis, L2 Wholenumber,±1 days in a month more than 10% above the month’s mean daily use 1.00 e_explanation_1energy / explanation, L1 Wholenumber, ±0.01 or±5% fractional change in daily use between two days 1.00 43 Name in codeCell, levelRequires AnswerQuestion (paraphrased) Score e_explanation_2energy / explanation, L2 Wholeentitydid use change more in the occupied hours or the other hours between two days 0.67 e_explanation_occ † energy / explanation, L3 Whole, Sub2, OAT, Occ number, ±0.05 correlation of hourly use with total occupancy on a day – q_status_1equipment / status, L1 Pwrnumber,±1 or±2% power of a named item of equipment at an hour 1.00 q_status_2equipment / status, L2 Pwrnumber, ±0.02 power at an hour as a fraction of the equipment’s own peak 1.00 q_summary_1equipment / summary, L1 Pwrnumber,±1 or±2% mean power of an item over a day 1.00 q_summary_2equipment / summary, L2 Pwrnumber,±1 hours in a day an item ran above half its own peak 1.00 q_comparison_1equipment / comparison, L1 Pwryes/nodid one item draw more power than another at an hour 0.89 (0.67–1.00) q_comparison_2equipment / comparison, L2 Pwrentitywhich of three items used the most electricity on a day (2 hops) 1.00 q_comparison_3equipment / comparison, L3 Pwr, Run, Load number,±5% mean air flow of one item minus another on a day – q_verification_1equipment / verification, L1 Pwryes/nodid an item exceed a stated power at any hour of a day 1.00 q_verification_2equipment / verification, L2 Pwryes/nodid an item stay below 90% of its own peak at every hour of a day 0.89 (0.67–1.00) q_verification_3equipment / verification, L3 Pwr, Run, Load number,±1 hours an item drew power while its run signal was off – q_verification_3_ simul † equipment / verification, L3 Pwr, Run, Load (+ valve commands) number,±1 hours heating and cooling valves were both open – q_diagnosis_1 ‡ equipment / diagnosis, L1 Pwrentityitem drawing the most power at an hour 1.00 q_diagnosis_2equipment / diagnosis, L2 Pwrentityitem that ran closest to its own peak on a day 1.00 q_explanation_1equipment / explanation, L1 Pwrnumber,±5% change in an item’s daily energy between two days 1.00 q_explanation_2equipment / explanation, L2 Pwrentitydid an item’s use change more in the occupied hours or the other hours between two days 0.67 (0.33–1.00) a_status_1air quality / status, L1 CO2number,±2% CO 2 in a zone at an hour – a_summary_2air quality / summary, L2 CO2, Occ number,±1 occupied hours with CO 2 above 800 ppm on a day – a_comparison_2air quality / comparison, L2 CO2number,±5 or±5% mean CO 2 of one zone minus another on a day – a_verification_3air quality / verification, L3 CO2, Occ, OAF yes/nowas outdoor-air flow higher when occupied than when not – 44 Name in codeCell, levelRequires AnswerQuestion (paraphrased) Score o_status_1occupancy / status, L1 Occnumber,±1 or±5% people in a zone at an hour 1.00 o_status_2occupancy / status, L2 Occyes/nowere more people in a zone at an hour than its mean for 08:00–18:00 0.89 (0.67–1.00) o_summary_1occupancy / summary, L1 Occnumber,±1 or±5% highest hourly occupancy of a zone on a day 1.00 o_summary_2occupancy / summary, L2 Occnumber,±1 or±5% mean occupancy 08:00–18:00 on a day 1.00 o_comparison_1occupancy / comparison, L1 Occyes/nowere more people in one zone than another at an hour 1.00 o_comparison_2occupancy / comparison, L2 Occnumber,±1 or±5% mean occupancy of one zone minus another, 08:00–18:00 0.89 (0.67–1.00) o_diagnosis_1occupancy / diagnosis, L1 Occnumber, exact hour of the day with the most people in a zone 1.00 o_diagnosis_2occupancy / diagnosis, L2 Occnumber,±1 hours occupied outside 08:00–18:00 on a day 1.00 l_status_1lighting / status, L1 Lgtnumber,±1 or±2% lighting power of a zone at an hour 1.00 l_status_2lighting / status, L2 Lgt, Occ yes/nolights on while the zone was unoccupied at an hour 1.00 l_summary_1lighting / summary, L1 Lgtnumber,±1 or±2% mean lighting power of a zone over a day 1.00 l_summary_2lighting / summary, L2 Lgtnumber,±2% lighting energy of a zone on a day 1.00 l_comparison_1lighting / comparison, L1 Lgtyes/nowas one zone’s lighting power higher than another’s at an hour 0.89 (0.67–1.00) l_comparison_2lighting / comparison, L2 Lgtentityzone with the most lighting energy on a day (2 hops) 1.00 l_diagnosis_1 ‡ lighting / diagnosis, L1 Lgtentityzone with the highest lighting power at an hour 1.00 l_diagnosis_2lighting / diagnosis, L2 Lgt, Occ number,±1 hours lights were on while the zone was unoccupied 0.89 (0.67–1.00) Table D.21: Worked examples on the sweep building at the metered profile, one per answer type and domain, and a typical miss. The ground truth of the instance shown is followed, in brackets, by those of the class’s other two instances. The agent’s answers are its three repeats. ExampleQuestion (abridged)Ground truth (other instances) Agent, 3 repeats L1 number (t_status_1) air temperature of DataCenter_ basement_ZN_6 at 2018-01-02 08:00, ◦ C 27.0 (27.001, 24.0)27×3 L2 difference (t_comparison_2) Basement minus the HVAC zone DataCenter_top_ZN_6 at 2018-01-14 16:00, ◦ C −3.0 (−0.899,−3.001)−3×3 yes/no (t_verification_2) did Perimeter_mid_ZN_4 stay within its setpoints all of 2018-07-04 false (true, true)false×3 45 ExampleQuestion (abridged)Ground truth (other instances) Agent, 3 repeats entity, lighting (l_comparison_2) which of three zones used the most lighting energy on 2018-10-12 Core_bottom (Core_bottom, Core_mid) Core_bottom×3 two KG hops (t_comparison_2hop) warmest zone served by AHU02 at 2018-10-09 11:00 Perimeter_mid_ZN_2 (Perimeter_top_ZN_1, Perimeter_mid_ZN_2) Zone_F3_Z03 (its identifier)×3 energy (e_summary_1) highest hourly whole-building electricity use in 2018-10, J 5.22× 10 9 (5.82× 10 9 , 4.29× 10 9 ) 5.22× 10 9 ×3 equipment (q_summary_1) mean power of Chiller01 on 2018-10-10, W 85,849 (3,358; 7,135)85,849×3 occupancy (o_status_1) people in Perimeter_top_ZN_2 at 2018-10-11 09:00 10.3 (1.85, 142.1)10.3×3 a miss (t_verification_1) did Perimeter_bot_ZN_4 stay at or below 26 ◦ C all of 2018-10-25 false (false, true)abstained, false, abstained Appendix E. Diagnosis scenarios In each scenario question (Section 4.4) the answer shape is "cause": "<one of the candidate causes, copied exactly>", and the agent may abstain as in every other episode. The question reads: “observation Which one of these causes do the data support: cause A; cause B? Use only the data available for this building. If the available streams cannot tell these causes apart, abstain and name the streams you would need.” The two scenarios of a pair share one observation. For pair A it is that from mid-June the zone has run about 1 ◦ C cooler during occupied hours than before, while the other core zones have not changed. For pair B it is that since July the reported temperature of the zone has risen relative to the other zones, followed by the premise “The reported zone temperature comes from a monitoring sensor. The zone’s controller uses its own thermostat, which is not in the data.” Both causes act on one zone, so the unchanged neighbouring zones that the observation mentions do not separate them. In pair A, EnergyPlus emulates a biased thermostat by shifting the setpoint in effect and leaving the schedule unchanged, so the offset is posed as “local override or controller offset”, and its rival lowers the zone’s own heating and cooling setpoint schedules from the same date. In pair B, the drift is added after simulation to the monitoring series with the telemetry injector of BuildStream, the software that generated BATS. The scheduled setpoint of the supplement comes from the simulation of the faulted building, which reproduces the release exactly. The damper position comes from a re-simulation of the clean building with one added output variable, attached to the damper point the release declares. The re-simulation matches 65 of the 93 released series and differs on the other 28 by at most 0.063 ◦ C in zone temperature, so the three scenarios built on the clean building use the re-simulated series throughout. Table E.22: The four diagnosis scenarios, all in the large office in Tampa. Base streams are T and Sp in every scenario. The separating streams come from the supplement to the release. ScenarioInjectionTrue cause / rivalSeparating stream A: thermostat offset EnergyPlus fault model, 1 ◦ C offset in the Core_bottom zone of the published faulted building from 15 June local override or controller offset / schedule change SpC A: schedule change the zone’s own heating and cooling setpoint schedules lowered by 1 ◦ C from 15 June (re-simulated clean building) schedule change / local override or controller offset SpC 46 ScenarioInjectionTrue cause / rivalSeparating stream B: sensor driftBuildStream telemetry injector, drift to +1 ◦ C on the reported temperature of the Core_mid zone from 1 July to year end (re-simulated clean building) zone sensor fault / local load change ActP B: internal-load step an always-on equipment load of 40 kW in the Core_mid zone from 1 July (re-simulated clean building) local load change / zone sensor fault ActP Before the runs, each pair was checked against the clean building over occupied weekday hours, from 16 to 29 June for pair A and from October to December for pair B (Table E.23). Within a pair the base streams move alike and the peer zone does not, so the causes are not identifiable in the base condition. The separating stream differs clearly between the two scenarios of a pair, so they are identifiable in the separating condition. Table E.23: Look-alike and separation checks: change against the clean building, mean over occupied weekday hours. The peer is the core zone on another floor. Pair ScenarioZone T Setpoint in effect Peer T Separating stream A thermostat offset−0.87 ◦ C−1.00 ◦ C +0.01 ◦ CSpC +0.00 ◦ C A schedule change−0.91 ◦ C−1.00 ◦ C +0.01 ◦ CSpC−1.00 ◦ C B sensor drift+0.75 ◦ C0.00 ◦ C 0.00 ◦ Cdamper +0.000 B internal-load step +0.67 ◦ C0.00 ◦ C 0.00 ◦ Cdamper +0.180 Appendix F. The real buildings: series processing and census checks The series of the eight buildings run in depth (Section 4.6) are converted to hourly means on the UTC clock of Section 4.6. No KG declares a unit on any temperature point, and an air temperature or setpoint series, the only temperatures the questions use, whose median exceeds 35 is read as Fahrenheit and converted. A series is usable when it holds a value for at least 90% of the year’s hours and takes at least three distinct hourly values, which excludes stuck and dead points. Each declared series is classed as usable, as present but unusable, or as absent from the release. The rule’s sensitivity is tested by holding each value until the next sample, and by varying the coverage from 80% to 95% and the distinct values from two to three (Section 5.6). The ground-truth values of one instance of each of two classes per building were recomputed from the raw files with a script independent of the study’s code, and all 16 matched. The revision of the Mortar graphs used for the census retypes its 16 former building meters, four of them linked, as generic energy sensors with no link to the building. The mapping rules count none of these points. Counted as whole-building meters, they raise the ceiling of four buildings and the maximum to 0.513. The strict mapping lowers the maximum to 0.263, because the power points of the Mortar KGs are generic power sensors that count only through their attachment. Of the ten Mortar applications that compute something, three can run on some KG: zone comfort evaluation on 23 of the 37, the comparison of sensors with their setpoints on 16, and the rogue-zone airflow check on one. The five energy applications run on none, because no KG in the revision used types a building meter. On the June revision, which still typed them, two energy applications run on four KGs. The application count and the ceiling disagree most where the ceiling comes from equipment streams (power, run status and load), which no Mortar application uses. 47

Instant research discovery