One Hour to Train a Robot. Six Months to Train a Building.

On April 2, a robotics company called Generalist AI published a model named GEN-1. The headline number, buried inside a long list of demos, is the one that should change how you think about your building.

GEN-1 needs about one hour of robot-specific data to specialize on a new task or new piece of hardware. The previous generation hit roughly 64% success on the same benchmarks. GEN-1 hits 99%, three times faster, and adapts to new tasks on a corpus that you could collect over a long lunch.

Reporters who watched it in person noted what they called "moments of physical common sense." A washer slipped during automotive kitting. The robot put it down, regrasped, then used its other hand to rotate the part into position and slot it. Nobody scripted that recovery. The model figured it out.

This is the part of the story that matters for buildings. Not the dexterity. The data efficiency.

The Number That Changes the Bet

Twelve months ago, the prevailing wisdom on robot foundation models said you needed enormous, fleet-scale datasets to get past a demo. The RT-X dataset that triggered most of 2024's progress required 33 institutes, 22 hardware platforms, and a million episodes of teleoperation. That's not something a small business can produce.

That ceiling just dropped.

One hour of high-quality, task-relevant data is now enough to specialize a foundation model on new hardware. NVIDIA's Cosmos Predict 2.5, which shipped in robot-policy-evaluation form during National Robotics Week, lets you score the candidate policies in simulation before you deploy them. Sony's Project Ace, also published this month, demonstrated that two well-chosen sensor types — event cameras for spin, 200 Hz RGB for position — beat a generic deep-learning-on-everything stack at elite-human performance.

Each of these results, on its own, is a research milestone. Together, they describe a stack: collect a small amount of well-targeted data, fine-tune a model on it, evaluate against a generic world model in simulation, deploy. The hard part is no longer the model. The hard part is owning the data.

What an Hour of Building Data Actually Looks Like

The sump pump system I run, the one I've written about before, generates power-draw readings every few seconds, twenty-four hours a day. Add the float-switch state, the basement humidity, the outside temperature, the rainfall forecast, and the pump cycle history, and you have a multi-channel time series of physical state.

An hour of that data, at the resolution I capture it, is roughly 3,000 sample points across a dozen channels. A useful hour — meaning, an hour where something interesting happens — comes along every few days during normal operation, and dozens of times during a storm. In six months of monitoring, the system has accumulated something on the order of a hundred storm cycles, several thousand routine cycles, and one float-switch failure mode that the AI caught at 3am.

That's not a research dataset. That's a fine-tuning corpus.

The community center I monitor has forty devices. HVAC, lighting, smart plugs on equipment, temperature sensors in zones, the booking calendar correlated with occupancy. An hour of useful data — meaning an hour where the system can compare actual operation to scheduled operation — comes along every single day. Six months in, we have a baseline that captures the building's normal state across two seasons, three vendor failures, one bad weather week, and the discovery that the HVAC was running on weekends because the booking calendar was never wired into the schedule.

Both of these buildings have, today, more high-quality, task-relevant physical data than GEN-1 needs to specialize on a new domain.

The Owners Who Started Six Months Ago

This is the part of the math that most building owners haven't done.

The current generation of building monitoring tools — the ones I deploy — is already useful on its own. Anomaly detection. Energy savings. Catching the float switch before the basement floods. That's the value proposition I sell, and it pays for itself.

But there's a second value proposition stacking on top of it, on a 6-to-18-month horizon. The data your building generates today, sitting in a properly-structured local database, becomes the substrate for the next generation of models. Domain-specific foundation models for HVAC. For mechanical equipment. For commercial-building energy patterns. These models do not exist yet at the level GEN-1 reached for kitting and folding. They will. The data efficiency curve says they will reach SMB facilities sooner than most owners think.

When they ship, the buildings that already have six months of structured baseline data will be ready to fine-tune them on their actual physical signal. The buildings that haven't started will be six months from being able to.

The Architecture That Captures the Substrate

You don't need a big system to start collecting useful data. You need a small one with the right properties.

• Sensors placed on the components where failure modes actually live. Not blanket coverage. Sony Ace used two sensor types because each one captured one specific physical property. Buildings work the same way: vibration sensors on the bearings, current monitors on the motors, temperature sensors in the zones, not 100 generic devices everywhere.
• Local storage, properly structured. Time-series database, not log files. The data has to survive a Wi-Fi outage, a vendor going out of business, a five-year monitoring window. SQLite or InfluxDB on commodity hardware does this for less than the cost of one cloud subscription.
• Local AI watching for anomalies in real time. This is the value proposition that pays today. It also keeps the data flow honest — if the local AI is making decisions on the data, you'll notice when a sensor drifts or fails, which keeps the long-term corpus clean.
• The customer owns every byte. No cloud lock-in. No vendor subscription that disappears in three years. The building's signal, in the building owner's hands, ready for whatever model lands next.

This is the same stack I use for the sump pump and the community center. It costs under $500 to start. It runs on a small always-on computer, off-the-shelf sensors, open-source software, and a local model that fits on commodity hardware.

It's not flashy. It doesn't require a sales cycle with an enterprise vendor. And it has been generating an hour of useful, task-relevant building data per day for the better part of a year.

Why This Is the Sales Motion That Survives the Next Two Model Generations

I don't sell against Siemens or Johnson Controls. They serve a market that does not look like the small businesses I work with. What I sell against is inertia. The building owner who says, "we've always done it this way." The property manager who says, "we've got a service contract for that." The church board that says, "we'll deal with the HVAC when it breaks."

The GEN-1 result reframes that conversation in a way that I think will land. The dashboards and alerts I deploy today — those are the product I'm selling now. But the data my customers' buildings are accumulating, the substrate that sits underneath the alerts, is the asset that compounds. In a year, when the next domain-specific physical-AI model lands, the customers who started in 2026 will be the ones who can use it. The customers who waited will be paying somebody else to catch up.

One hour of robot data, in a research lab, gets you a 99% success rate on a new task. Six months of building data, in your facility, gets you a substrate that survives the next two model generations.

The starting cost is the same in both cases. Whoever's already collecting wins.

Read the case studies: How edge AI prevented a basement flood | Smart building on a shoestring | A closed work order is not a resolved condition | Buildings don't need a world model. They need yesterday's data.