Beyond retrieval: assistants that understand a place
Retrieval gets you relevant text. Understanding a place means knowing how its pieces relate — and what to do when they don't line up.
Retrieval-augmented generation is a good default: find relevant passages, hand them to the model, let it answer. It solves a real problem. But a place is more than a pile of passages, and treating it that way shows.
The limits of "find the passage"
Two failure modes come up constantly:
- Conflicts. The house manual says checkout is 11am; a later note says late checkout is fine this week. Naive retrieval surfaces both and lets the model pick.
- Structure. "Where do I park?" depends on which unit, which day, and whether the driveway is shared. That's a small graph, not a paragraph.
Neither is solved by fetching more text. They're solved by understanding how the pieces of a place relate.
Modeling the place, not just its documents
We treat a space as structured knowledge with relationships and precedence rules, then let language sit on top of it:
- Facts have scope (which unit, which surface, which audience).
- Facts have freshness (a temporary note overrides the manual).
- Facts have provenance (so an answer can point back to where it came from).
The model's job shifts from "summarize the retrieved text" to "answer from a place that has been made legible."
Good answers are a property of good structure. The model is the last mile, not the whole road.
What this buys us
When the structure is right, the assistant can do things retrieval alone can't: reconcile conflicting notes, scope an answer to the right room, and explain why it answered the way it did. That's the difference between a chatbot bolted onto a PDF and something that actually understands where it is.
