A Closed Work Order Is Not a Resolved Condition.

Last week, Nexus Labs polled 100+ building-owner organizations on a five-stage maturity scale for condition-based maintenance. The audience was self-selected — these were owners who signed up for a half-day CBM event on a Wednesday afternoon, the most engaged segment of the market. The result was unforgiving.

51% graded themselves at Level 1. Reactive and calendar PM. No condition signals in the workflow. 17% at Level 2. FDD or sensors deployed, maintenance behavior unchanged. Two-thirds of the most committed owners in the field haven't crossed into a working CBM program.

The same week, a German robotics startup called Sereact closed a $110 million Series B for Cortex 2.0, a vision-language-action model augmented with a world model. Their warehouse pick robots have completed over a billion production picks. The current intervention rate is roughly 1 in every 53,000 picks.

That's the same week. Two ends of the same spectrum. The frontier of physical AI is shipping at five-9s reliability. Two-thirds of the most engaged building owners in the country can't get past Level 2.

The bottleneck is not the technology. The bottleneck is the resolution loop.

What Hannah Baker Actually Said

In the same Nexus Labs session, Hannah Baker described what happens at DFW Airport before they tightened their CBM program. The QA team could manually verify roughly 1–2% of work orders. Of the ones they sampled, the resolution rate was under 10%.

That number deserves to be sat with. Less than ten percent of randomly sampled, supposedly closed work orders actually resolved the condition that triggered them. The ticket said done. The system said done. The condition kept happening.

Their fix was operational, not technological: a fault that persisted after the ticket closed reopened the same ticket and was flagged with a KPI called "Unsuccessfully Actioned." Rework went back on the original record. Contractors stayed accountable to the actual fault clearing, not the paperwork.

"A closed work order is not a resolved condition." — Hannah Baker, Willow / DFW Airport CBM program

That sentence is, quietly, the diagnosis for why most CBM programs stall. Owners buy sensors. Sensors generate alerts. Alerts become tickets. Tickets get closed. The fault, more often than not, is still there. Without a feedback loop that re-checks the physical signal after the fix, the program looks like it's working while the actual condition decays.

The Maturity Gap Is a Verification Problem

Travis Criner runs an asset management group at CBRE, eighteen years removed from his start as an HVAC technician. His team's data on what actually moves the needle is concrete: only about 20% of maintenance efficiency gains come from CBM technology itself. The other 80% come from auditing the existing PM plan and retiring tasks that should never have been on it.

Tearle Whitson, who spent seventeen years inside Microsoft's smart buildings program before taking over OT at MetroNational, has the cautionary story. A fault-detection algorithm once live-calculated $2.5 million in energy savings off a single rule. Leadership saw the number. Then a current transducer on one VFD turned out to be misreading. The $2.5 million disappeared. Credibility with the CFO had to be clawed back.

The University of Iowa's FDD generates over 3,500 faults a day. Brad Dameron's team routes them through two field-experienced humans into three triage buckets — Asset Optimization for investigation, controls for programming, frontline for mechanical. Each shop carries about a dozen active CBM work orders at any given time. Anything more and the program collapses under its own volume.

None of those problems are technology problems. They're verification problems. Calibrate the sensor before the first fault. Audit the PM plan before adding more signals. Triage the alerts before they overwhelm the techs. Reopen the ticket if the fault persists. The maturity gap from Level 2 to Level 3 is the gap between firing alerts and trusting them.

What the Sereact Result Actually Shows

It's tempting to read the Sereact $110M news as a story about robot brains and skip the operational layer. That's the wrong takeaway. What Cortex 2.0 demonstrates, deployed at scale, is what verification looks like in production:

• The model generates candidate movements from the current state
• It runs those candidates through a learned model of the physics
• It scores each one for stability, risk, and efficiency
• It executes the best one
• It observes the result and updates

That's a closed loop. Every action gets verified against the next observation. The 1-in-53,000 intervention rate isn't because the model is smart. It's because the loop closes on the physical signal, not on a ticket. The robot doesn't trust the work order. It trusts the data.

This is the same architecture available to a building. It's a smaller version of the same idea. The intelligence is not in the size of the model. The intelligence is in the closure of the loop.

What This Looks Like for a Sump Pump

I have a sump pump in a basement. There is no work order system for that pump. There is no CMMS where a contractor can mark a ticket "closed." There is only the next cycle.

When the float switch sticks — and it has been sticking since March 2025 — the system doesn't fire an alert and wait for someone to acknowledge it. The system records that the pump did not start when the water rose. It records the duration of the next cycle. It records the time between cycles during the next rainstorm. The condition is either resolved on the next event, or it isn't. There is no place for "closed but unresolved" to live.

That's the architecture. It is unglamorous. It is also exactly what 68% of the building-owner audience at NexusCast was unable to achieve with their existing investment in sensors and FDD platforms — because the sensors fed tickets, and the tickets weren't being verified against the physical signal.

The same logic applies to a 40-device smart building project. Every override, every setpoint drift, every after-hours anomaly is a signal that either persists or doesn't. The maintenance team's behavior changes not because the dashboard tells them to, but because the system reopens its own observation when the fault hasn't actually cleared.

Why the Frontier's Money Helps Here

This connects directly to last week's piece about world models and baselines. The frontier of physical AI — Cosmos, GR00T, DreamDojo, now Cortex 2.0 — is solving the hardest version of the problem: closing the loop in unseen environments, with unseen objects, against unseen physics. Sereact's $110 million is buying the right to do that at warehouse scale.

Building monitoring sits on the easy version. The environment is fixed. The objects are fixed. The physics, for any one boiler or pump or air handler, are knowable from the recording. The loop only has to close on the equipment that's already there.

Every dollar that pours into world-model research at the frontier subsidizes the tooling, the open weights, and the pattern. The owners who already have a baseline for their specific equipment are positioned to drop those models into their own infrastructure as the cost curve falls. The owners who are still at Level 1 — calendar PM, no condition signals — are not.

The maturity gap is a verification gap, and the verification gap closes the moment the system starts watching the signal instead of the ticket.

The Frame Shift

If you run a facility, here is what is worth taking from this week's data:

1. The dashboards are commodity. Buying more visibility into faults you can't verify just floods your CMMS.
2. The differentiator is the resolution loop. A program that re-checks the physical signal after every fix is operationally on a different level than one that trusts the work-order status.
3. The PM audit usually pays for the CBM program by itself. Criner's 80/20 split is not theoretical — half the quarterly inspections on a BAS-connected air handler are failure-finding tasks that FDD does more accurately. Retire them, and the savings fund the upgrade.
4. The signal is what closes the loop, not the ticket. Edge-AI monitoring forecloses the "closed but unresolved" failure mode by design. There is no version of "the system thinks it's fixed" that survives the next observation.

What I'm Doing About It

For the buildings I monitor, the priority for the next 90 days is not adding more sensors. It's continuing to verify, every cycle, that the conditions the system already knows about resolve when the system says they should. Every confirmed resolution makes the baseline tighter. Every unconfirmed one becomes the next thing to investigate.

If you operate a facility and your maintenance program is anywhere in the 68% — sensors deployed, behavior unchanged, tickets closing without anyone checking the signal — the path to Level 3 is not a procurement decision. It's an architectural one. The system has to watch the signal, not the work order, and it has to do that continuously, on-device, without waiting for anyone to acknowledge anything.

That's the version of physical AI that pays for itself in an SMB facility. Not a humanoid in the basement. Not a world model in the cloud. A loop that closes on the next observation, every time, and keeps doing it through every season the building has left.