I see a lot of talk in our industry about how our buildings are not “ready” for AI? And from what I’ve seen, frankly, much of this comes as philosophical arguments from non-practitioners of AI control system companies.
I can also appreciate the growing industry focus on AI Native and semantic standards such as ASHRAE 223P and ASHRAE 231P. Any effort that improves interoperability, portability, and consistency across building systems has value.
However, I believe there is a fundamental assumption embedded in many discussions of AI-native buildings that warrants challenge.
The assumption is that AI requires perfectly structured semantic models in order to understand and control buildings.
Our experience developing autonomous HVAC optimization systems suggests otherwise.
An example cited typically goes like this: “Edge AI systems cannot afford to waste compute cycles trying to infer what a garbled, unstructured point name like VAV_3_3_DAT_1 means.”
But this statement assumes that semantic interpretation is the primary challenge facing AI.
In reality, it is not!
Consider the example:
VAV_3_3_DAT_1
VAV_3_3_ZNT
VAV_3_3_SPT
VAV_3_3_DMP
A human technician may need documentation to understand these points (Actually in 70’s and 80’s we had point names like “@1.01.03_B03CH1CHWS” – And we did just fine!)
A standards committee may prefer that every point be fully normalized and semantically tagged.
A (Linux) hardware box provider may attempt to push standards around a Linux or Raspberry Pi specification, leaving no room for software (gateway) based solutions.
An autonomous AI system does not care!
The AI only needs to recognize that points share a common relationship. It can determine that they belong to the same equipment object (VAV_3_3), observe their behavior over time, identify cause-and-effect relationships, learn which points are measurements versus commands, build their own Machine Learning model, train itself and expertly control the machine its assigned to.
This is extremely trivial for AI.
We’re doing this all day, every day.
The AI is not reading the (human provided) names as language. They’re markers. Unique identifiers. They could just as easily be named: “adc145-654fe”.
The AI doesn’t care.
It is learning the system as a control problem.
The distinction is important.
Much of the current conversation around AI in buildings appears heavily influenced by Large Language Models and semantic web technologies. These tools are valuable, but they are not the only path to autonomy.
Retail, Commercial and Industrial control systems have been operating autonomously for decades without RDF graphs, ontologies, or semantic twins.
Factory robots do not require an ontology to paint a car.
A CNC machine does not require a knowledge graph to machine a part.
Similarly, an AI chiller controller does not require a semantic model to maintain the perfect leaving water temperature set-point saving up to forty-eight percent (48%) on energy, even if the condenser water temp is named: “m_128_cwt” (actual case).
They operate successfully because they learn and respond to system behavior.
Our own work with Iterative Learning Control in the Frequency Domain (ILC-FD) follows a similar philosophy.
The AI is not attempting to understand the building the way a human engineer understands the building.
It is identifying repetitive patterns, measuring outcomes, and adjusting control actions to improve performance.
In that context, semantic naming conventions are helpful but not mandatory.
A perfectly modeled ASHRAE 223P building may accelerate deployment.
A poorly documented building may require more observation.
Neither condition prevents an autonomous control system from learning.
The article also implies that edge computing resources are too constrained to infer relationships.
That may have been true for earlier generations of AI systems.
Today, however, even modest edge hardware can process thousands of points, identify naming patterns, cluster related signals, calculate correlations, detect causality, and construct equipment relationships automatically.
The computational cost of discovering that VAV_3_3_ZNT and VAV_3_3_SPT belong to the same VAV box is trivial compared to the computational resources consumed by many modern AI workloads.
More importantly, once those relationships are discovered, they do not need to be rediscovered repeatedly.
The model learns them once and moves on.
Where I strongly agree with the article is on the value of standardization.
ASHRAE 223P can reduce engineering effort.
It can simplify integrations.
It can improve portability between vendors.
It can provide a common language for the industry.
Those are worthwhile objectives.
Where I disagree is the suggestion that semantic standards are a prerequisite for autonomous AI.
They are not.
They are an accelerator.
There is a significant difference.
The future of building autonomy will likely include both approaches:
- Buildings with rich semantic models that accelerate deployment.
- AI systems capable of learning directly from raw operational data when semantic models are incomplete, incorrect, outdated, or entirely absent.
The second capability is essential because the vast majority of existing buildings on Earth do not have perfect semantic models today. (And probably never will)
If autonomy only works in perfectly structured environments, it will remain a niche technology.
If autonomy can learn from imperfect environments, it can scale globally.
That is the distinction that matters.
At Facil.AI we’re bringing dozens of AI controlled buildings and HVAC mechanical assets on-line, on a WEEKLY basis.
The goal should not be to build AI systems that require buildings to become perfect.
The goal should be to build AI systems that can thrive in the imperfect reality that already exists.
Once again in this industry, it is being argued that our buildings are “not ready” for significant and disruptive technology that would later go on to become mainstream.
I’ve personally witnessed this same exact phenomenon many times over my forty year career:
1) DDC in the 80’s
2) Ethernet/Internet/IP Communications in the 90’s.
3) XML/Web Services/Web UI/UX in the late 90’s, early 200O’s
4) Fault Detection and Diagnostics (FDD) 2008/2010.
ALL of these technologies took 5-10+ years to be adopted. And all of them were resisted initially by our industry.
And so here we are in 2026 with possibly the most important technology the built environment has ever seen:
AI
The question is: “What have we learned from our past?”
