Building AI needs a record separating promise, proof, scale, and authority
A pilot succeeds. The dashboard works, data moves, and the customer gives a testimonial. By the next conference, the technology is “proven.”
Proven where, under what conditions, and against which failure modes? Proven to recommend—or proven to execute?
Building automation has no shortage of demonstrations. It has a shortage of bounded claims.
AutomatedBuildings.com recently asked the industry to distinguish among promising, proven, and proven at scale. That requires a durable record connecting every claim to its evidence.
The industry needs a Proof Ledger.
A Proof Ledger records what was tested, what happened, what failed, what remained unverified, and how far the result may travel.
Start With the Claim
“Our AI optimizes buildings” is not a testable claim.
Does it predict demand, recommend schedules, change setpoints, dispatch technicians, detect faults, or control equipment? Each proposition requires different evidence and carries a different consequence.
Before a pilot begins, its claim should be narrow enough to prove or disprove. Fault detection cannot later be marketed as autonomous control. One air handler cannot silently become an entire portfolio.
Proof begins by preventing the claim from moving after the result is known.
What the Ledger Must Preserve
A useful Proof Ledger should contain at least eight fields.
1. The proposition. What exact capability or outcome was tested?
2. The operational object. Which building, asset, space, workflow, or decision was involved?
3. The evidence. What measurements, records, observations, and outcomes were preserved?
4. The conditions. Which vendors, configurations, policies, people, and time boundaries applied?
5. The failure record. What conflicted, drifted, required correction, or depended on interpretation?
6. The authority ceiling. Was the system authorized to observe, recommend, request, approve, commit, execute, or verify?
7. The replication record. Was the result repeated? By whom? Under the same conditions or meaningfully different ones?
8. The unresolved boundary. What has not yet been established?
Without those fields, “proven” may mean only that something desirable happened once.
Four States of Proof
With a ledger, the industry can distinguish four evidence states.
Promising means the mechanism appears feasible and deserves examination.
Proven means preserved evidence supports a specific claim under declared conditions—not the entire product.
Replicated means the result was produced again without rewriting conditions or erasing earlier failures.
Replication deserves its own category because repeating a result is not scaling it. The same team may establish repeatability but little variation. A different team tests whether the claim survives outside its creators’ knowledge. Replication bridges isolated success and a defensible claim of scale.
Proven at scale means the claim survives material variation across buildings, equipment, vendors, operators, imperfect records, and changing conditions.
These states should be versioned. An update, replaced sensor, changed sequence, or revised owner policy may invalidate an earlier finding. Proof belongs to the tested version and conditions—not every future release.
Authority Is Not the Fifth Rung
Authorized for execution is not another state of proof, and it is not the final step on a technology-maturity ladder.
It is a separate, present-tense determination that evidence and authority support a particular consequence on a particular object now.
A technology may be proven at scale for recommendations while unauthorized for physical control. A mature system may receive HOLD because evidence is stale, identity changed, or present conditions remain unestablished. A new system may receive bounded ALLOW to observe without being proven at scale.
Proof describes what the evidence has established about a capability. Execution authority determines what may be caused now.
That separation is not inconsistency. It is precision.
Failure Belongs in the Proof
Most case studies remove failure before publication. A Proof Ledger preserves it as evidence.
If an identifier was wrong, preserve it. If a technician rejected an instruction, record why. If a person corrected a field, preserve the original and begin a new chain.
This protects innovators.
A vendor that publishes limitations can defend what it proved. An owner can distinguish a boundary from a hazard. An engineer can judge transferability. A researcher can attempt replication.
Success becomes credible when its failure record remains visible.
One Demonstration, Properly Bounded
Last week, I described seven days involving ONUMA, BIMgenie, human participants, live work orders, and TA-14. Errors remained attributable, corrections occurred prospectively, and missing evidence produced HOLD.
That work supports bounded findings about interoperability and investigation. It does not establish autonomous actuation or portfolio-scale performance.
Both statements belong in the same ledger.
The full account, “When the Building Said No,” preserves that demonstration and its limitations.
A Better Standard for AHR Expo 2027
Imagine every education session, demonstration, and case study answering the same questions:
What exactly are you claiming? What evidence supports it? Where did it work? Where did it fail? Has anyone replicated it? What may it recommend? What may it cause? Where does its authority stop?
The result would distinguish invention from evidence, pilot from deployment, replication from scale, and capability from execution authority.
Promising deserves room to develop. Proven deserves recognition. Replicated deserves independent confidence. Proven at scale deserves a declared operational domain.
But each deserves its own record.
And none, by itself, establishes authority for the next physical consequence.
Until that record exists, “proven” is only a word attached to a claim.
The Proof Ledger would make it evidence.
No admissible evidence. No admissible execution.
