Why we build from real records

Clean data teaches the wrong lesson

Take a water pumping station that reports pressure, flow and the level of its tank every minute. Over three weeks the pressure falls a little, inside the normal daily swing. The level sensor stops reporting for two days. An operator writes about a stop in the log four days after it happened, and the alarm list shows the same alarm forty times in one hour.

A synthetic version of this station would be smooth, complete and labelled. Every reading would arrive on time, every sensor would tell the truth, and a label would say what went wrong. An agent that learns there learns that data are complete and that labels tell the story. Neither is true in a real plant.

The wrong lesson shows up as soon as the agent meets a real record. It adds up a week of flow, treats the two silent days as zero, and reports a drop that never happened. It reads the forty alarms as forty events. It trusts the log entry for the date the operator wrote it, not the date of the stop. Each mistake is small, and together they produce a confident answer about a problem that is not there.

What real records contain

Real records hold the difficulties that an agent meets in real work, in the proportions that real work has them.

• Gaps. A sensor goes quiet, and a missing reading is not a zero.
• Drift. A slow change hides inside the normal noise for weeks.
• Late corrections. A log entry or a reading changes after the fact.
• Disagreement. Two sources tell different stories, and the agent must find out which one is right.
• People. Notes and messages that people write in their own words, at their own time.

The difficulties carry information

None of these is noise to clean away before the real work starts. Each one tells the agent something. A gap may mean that a sensor failed, that a site lost power, or that a link went down, and those three causes lead to different actions. A late correction shows who noticed a problem, and when. Two sources that disagree point at the one that broke.

Drift is the hardest of them. The statistics of a real system change over time, so a pattern that meant one thing last month can mean another thing now. ¹ An agent that has seen only stable synthetic series has no reason to ask whether the ground moved. An agent trained on real histories learns to ask that question first.

Real records make honest answer keys

Each answer key is checked against the records. The key says what happened, not what a generator decided. The records stay messy and the key stays true, so the agent must reach the answer the way an engineer would: from the evidence.

When a generator writes the data, it also writes the answer, and a task built that way tests whether an agent can reverse the generator. A model can learn the generator's habits instead of the world's: the fault always starts on a round hour, the label always follows the spike. Real records have no such habits to learn. The only way to the answer is through the evidence.

Where synthetic data fits

Synthetic data still has a place. It is the right tool for a unit test of a method, for a rare case that a team wants to show on purpose, and for privacy when a record cannot leave its owner.

But a model that learns mostly from generated data drifts away from the real distribution, and the rare cases in its tails disappear first. ² A generator can make a sensor fail, but only in the ways its author imagined. Real failures are stranger: a sensor that repeats its last good value for a week, a clock that jumps an hour twice a year, a technician who logs a repair under the wrong unit. For reasoning over time, the rare cases are the point. The slow leak, the sensor that fails once a year and the correction that arrives a week late are the events that an assistant exists to catch.

What an agent learns from real records

An agent that trains on real records learns habits that clean data never asks for. It checks how much of a period it can actually see before it adds anything up. It looks for a second source before it trusts the first. It reads the date on a log entry with care, because the date a person wrote is not always the date of the event. And when part of the picture is missing, it says so, and it asks someone who can fill the gap.

These habits are what separate an assistant that people trust from one they check behind. They are hard to teach with rules, because every system breaks in its own way. They are easier to learn from many real histories, each with its own gaps and its own mistakes.

Where the records come from

We buy and license months or years of time-stamped records from operations, sensors, labs and compute, and we build RL environments from them. The most useful records are long, come from more than one source for the same system, and keep the notes that people wrote at the time. If you hold records like these, partner with us.

Records like these are rarer than they look. Most organisations collect them to run their own operations, and few think of them as material for training. A history of years, with its notes and its mistakes, is exactly what a model needs to learn the work.