Grounding language in physical space
Most language models answer from the open internet. The interesting problems start when the answer has to come from a specific place.
A general model can tell you how thermostats work. It cannot tell you how this thermostat works — the one on the wall by the front door, set to hold 21°C, that a guest is standing in front of right now.
That gap is the whole problem we care about. The value of an assistant inside a real place is not fluency; it is being right about that place. A confident, well-written answer that happens to be wrong about the checkout time is worse than no answer at all.
The space is the context window
We think of a physical space as a structured context that the model should be conditioned on: its layout, its policies, its hours, the objects in it, and the things people repeatedly ask about. The job of the system is to keep that context accurate and to make sure responses are drawn from it rather than from a plausible-sounding prior.
- Specific over general. Prefer the place's own answer, even when a generic one exists.
- Current over cached. A space changes. The knowledge layer has to change with it.
- Scoped over global. What is true in one room is not true in the next.
Why this is hard
Language models are optimized to be helpful in general. That same instinct makes them fill gaps — to answer even when the specific fact isn't available. Inside a real place, filling the gap is exactly the failure mode.
The hard part isn't generating an answer. It's refusing to generate the wrong one.
So grounding is not a retrieval add-on; it is a design constraint that runs through the whole system — how knowledge is captured, how it's kept fresh, and how the model is taught to defer to it.
Where we're headed
The goal is an assistant that feels like it lives in the space: it knows what's there, it knows what it doesn't know, and it never guesses about the things that matter. Everything else we build follows from getting that right.
