There is a simple question I wanted to be able to ask about my home network: what has been talking to the internet overnight? A language model can answer that beautifully, and that is exactly the problem.
There is a correct answer to the question, and it does not live in the model. It lives in network telemetry. Devices either made connections or they did not. Traffic went to particular destinations at particular times, bytes moved, alarms fired, DNS lookups happened. None of those facts become more or less true because a model produces a convincing explanation of them.
So when I built HomeScope, a small home telemetry and security platform, the decision that mattered most was not which model to use. It was deciding what the model would never be allowed to decide.
Build the fact before you ask what it means
HomeScope started as a practical project. I had an older iMac sitting idle, so I repurposed it with Debian, hardened the host, installed SQLite and Grafana, connected it to Firewalla MSP, and started ingesting telemetry. A local model running through Ollama became the natural-language layer on top. The goal was one place where I could see what the house was doing and ask ordinary questions about it, without turning every question into a manual log-analysis exercise.
The obvious architecture would have been to gather a large pile of telemetry, hand it to the model, and ask what looks unusual. That would have worked surprisingly well, and it would have been the wrong design. A model is good at interpretation. It connects ideas, explains patterns, and translates technical evidence into ordinary language. What it should not be responsible for is deciding whether the observation existed in the first place.
So HomeScope works in the opposite order. A question is reduced to deterministic evidence first. The database answers which devices communicated, the query fixes the time range, and the stored telemetry establishes destinations, counts, timestamps, and volumes. Only after those facts exist does the model get to explain them. The separation sounds almost trivial. I think it matters a great deal.
Fluency is not measurement
Take the question, "did anything unusual contact Russia last night." Two very different jobs hide inside it. The first is measurement: which devices communicated externally, which destinations mapped to infrastructure attributed or geolocated to Russia, during what period, how much traffic moved, and whether the evidence contains such a connection at all. The second is interpretation: whether the activity is expected, whether it belongs to a known service, whether it is unusual for that device, whether it is worth investigating. A model is useful for the second. It should not get to invent the first.
If the database says there were no matching flows, the model does not get to create one because a connection would make a better security story. If there were 37 connections, it does not get to report 42 because the difference reads as insignificant in prose. If the source data is stale, the correct answer is not a confident explanation built on yesterday's state. It is that the system does not currently have fresh enough evidence to answer. The model is downstream of reality, not part of the mechanism that establishes it.
More than grounding the model
Ground your model has become the standard answer to almost every hallucination problem. Give it retrieval, give it documents, give it tool access, give it more context. All of those can help, but grounded describes architectures with very different assurance properties. There is a real difference between handing the model several pages of telemetry and asking it to tell you what happened, and handing it the twelve rows a deterministic query returned and asking it to explain them. The first asks the model to find the facts and explain them. The second establishes the facts before the model begins reasoning.
That difference matters most when the output contains numbers. Observability systems produce quantities: counts, rates, durations, volumes, timestamps, baseline deviations. Those values need provenance that does not depend on the model getting them right. If HomeScope reports that a device transferred 2.4 GB, there is a query underneath that number that also returns 2.4 GB. If the model disappeared tomorrow, the measurement would still be true.
Who writes the query
There is a fair objection to all of this, and it is the first thing a careful reader will reach for. If the question is reduced to a query before the model reasons, who writes the query? If the model generates the SQL, it is back upstream of the measurement, and the boundary I just described is thinner than it looks.
The model still cannot fabricate a row, but it can shape the query so that real rows answer the wrong question: a time range that misses the overnight window, a geo or ASN match that mislabels what counts as Russian infrastructure, or a device filter that silently drops the camera you were asking about. The result is a confident answer, fully grounded in real data, and wrong.
So the boundary has to cover query construction, not just query results. The model does not get an open SQL prompt against the database. It selects from a set of human-authored, parameterized queries whose logic I can read and test, and it supplies the parameters the question implies, typed and validated, so the shape of the measurement is never something the model gets to author. Every query runs read-only, which bounds a bad parameter to returning the wrong rows rather than writing, escalating, or reaching outside the telemetry store. Preserving each executed query as an artifact is what lets a result be reproduced and challenged, but that is audit sitting on top of the boundary, not the boundary itself. This is the same shape as the read-only tool I wrote about recently, where a model-controlled argument turned a read into a write. The fix is the same too: make sure the model shapes the parameters, never the operation.
The trusting-user problem
The design became more important once I stopped picturing HomeScope as something only I would use. I can inspect the database, open Grafana, and read the underlying Firewalla telemetry. If an answer sounds wrong, I know how to challenge it. Someone else in the house should not need to.
That changes the threat model. There is a large difference between building an AI interface for an operator who can independently verify its output and building one for a user who reasonably assumes the system knows what it is talking about. The second user is not less capable in general. They simply should not have to know SQL or network telemetry to ask whether anything weird is happening with the kids' devices, or whether a camera has been talking somewhere it normally does not. If the system answers confidently, that user needs some basis for trusting that the factual substrate underneath the answer is real. The grounding requirement gets stronger as the user's ability to verify gets weaker. The system has to be honest before it matters who is asking.
The platform has to know when it does not know
There is another failure that looks like hallucination from the user's side: stale data. At one point a collector stopped ingesting for about 22 hours. Nothing in the dashboard looked dramatic. The existing data still looked like data, queries still returned rows, and a system that only asked whether the database contained information could have kept producing coherent explanations. The problem was that reality had moved on and the telemetry had not.
So freshness has to be a measured property, not an assumption. A collector should not merely produce data. It should produce evidence that it is still producing data. The same holds as the platform grows. If one poller dies while six others run normally, the system is up is not a useful statement, because each source needs its own last-success state or silence starts to look like normality. Whether a source is fresh, whether a query returned enough evidence, and whether a device was observed during the requested interval are all deterministic questions. I do not want the model deciding any of them. It can explain an absence of data, but it cannot be allowed to treat that absence as evidence that nothing is wrong.
The architecture has to survive the model being wrong
The test I keep coming back to is this. Assume the model gets fooled, misunderstands the question, gives poor advice, or is replaced with a worse model tomorrow. What still holds? In HomeScope, the telemetry remains what the sensors observed, the query results remain reproducible, the dashboard remains independently inspectable, and an event that never happened does not enter the database because the model imagined it. A model cannot rewrite history by narrating it differently.
That does not make the system correct. A deterministic query can still be wrong, a parser can misclassify data, a collector can fail, a device name can mislead. The difference is that those failures live in mechanisms I can test directly. I can read the SQL, reproduce the query, compare source telemetry, put a canary on freshness, and fix the parser. I am not trying to solve factual correctness by asking the model to be more confident about the right answer.
Interpretation is a judgment too
There is one thing that boundary does not protect, and it is worth stating rather than implying. Keeping the model out of measurement bounds the risk that the facts are wrong. It does nothing about the risk that the facts are right and the reading is wrong. "That destination is just a known cloud provider, nothing to worry about" is a measurement-clean, interpretation-wrong answer, and it is exactly the false all-clear a non-verifying user cannot catch. The architecture I have described bounds measurement risk. Interpretation risk stays on the table. The rule I hold the interpreter to is narrow: cite the rows it is reasoning from, carry uncertainty forward instead of resolving it for effect, and never turn an absence or an ambiguity into reassurance, because a confident all-clear is the one answer a trusting user has no way to check.
The model still does the interesting part
None of this reduces the model to a decorative summary generator. The reason I put a local model into HomeScope is that interpretation is genuinely useful. Raw network telemetry is terrible household UX. A table of addresses, ports, domains, byte counts, and timestamps can contain the answer while being a bad way to communicate it. The model bridges that gap. It can explain that a strange-looking destination belongs to a known cloud provider, summarize a pattern across several devices, turn an alarm into language someone can act on, and answer follow-up questions without the user needing to know which table holds the evidence. That is where I want the model, as the interpreter sitting above systems whose answers already exist, not as the sensor, the database, or the calculator that produces them.
What I ended up caring about
One reason I like this architecture is that it makes the specific model less important. Models will improve, I may change what runs locally, and the prompts and the interface will keep changing. HomeScope has already grown past the original idea into a broader household telemetry platform. The boundary survives all of it. Facts come from deterministic systems, and the model works on top of them, receiving evidence and producing interpretation. That also gives the rest of the architecture a stable core to defend: the ask interface can be authenticated, the service bound to localhost, access enforced at the proxy, the TLS certificate verified, and network-sourced strings escaped before display. Those controls protect a system whose factual core sits outside the model, which is far easier to reason about than a design where the model is retrieving, deciding, calculating, and explaining the state of the world at once.
I started the project to get better visibility into my own network. What I ended up caring about was the boundary between evidence and explanation. Most of the essays I write are autopsies of controls that turned out not to be there. This one is the opposite exercise, a note on building a boundary and keeping it in place. The database measures, the query establishes the result, the freshness checks say whether the evidence is current, and the model explains what those facts mean after they exist rather than deciding them into being.