Frontier models have consumed an extraordinary amount of the public web. The easy text is largely gathered. What remains scarce is the kind of data that shows how the world behaves: how a shelf looks after a busy day, how a technician isolates a fault, how a crew adapts when the plan stops matching the floor.
Beyond scraped text
This data cannot be scraped. It has to be commissioned, collected, reviewed, and maintained. It also decays: stores reset, equipment changes, procedures get revised. A static snapshot is useful for a benchmark and insufficient for a product.
A layer, not a dataset
We think of Kali as a layer beneath our partners' models. The layer has a stable schema, attached provenance, clear licensing, and a refresh path. A team asks for the conditions it needs, not for a folder of files that happens to contain them.
That distinction changes how customers build. They can plan around data arriving on a schedule. They can compare a new collection against an old one because the fields mean the same thing. They can audit where a training example came from.
Where partners use it
- Robotics teams training policies for manipulation and navigation.
- Computer vision teams testing models against real lighting and clutter.
- Operations researchers studying how work actually gets done.
- Product teams building assistants that need grounded, physical context.
Why now
Sensors are inexpensive. Models are capable enough to learn from rich recordings. The bottleneck has moved to data: diverse, labeled, and honest about where it came from.
The next wave of applications will be built on what models can see, not only on what they have read.
That is the layer we are building. If your roadmap depends on data from the physical world, we should talk.