"The test isn't whether it works when everything is up. The test is what still works when the fancy part is gone."
The 3 A.M. Test
Imagine the embedding-and-rerank server is down — rebooting, out of memory, unplugged, doesn't matter. It's 3 a.m. and you need to find a line you wrote two years ago. In a model-in-the-path system, you're stuck: no model, no search. In Lantern, you type your query and the corpus answers, because the paths you rely on most were built to touch no model at all. That's not luck or a fallback that kicked in — it's the shape of the engine.
Two Paths That Touch No Model
Two of Lantern's retrieval paths are pure functions of the local index and your query:
- Keyword search (full-text) matches your terms against an inverted index living right there on disk. No network, no model, just term matching and ranking.
- Phrase completion mines the corpus for continuations of what you typed, again from the local index, at keystroke speed.
Neither one has a wire to the model server. You could delete the model server from existence and both would return identical results.
What Degrades, and How
The paths that do need the model server — dense vector search, the vector half of hybrid, and reranking — degrade honestly rather than pretending. A pure vector query returns a clear service unavailable when the model is unreachable. A hybrid query serves its keyword half and flags in the response that the vector half was skipped. Nothing silently returns worse results dressed up as good ones. Degradation is visible, named, and never contagious to the deterministic paths.
The Guarantee Is Structural, Not Hopeful
This is worth saying twice: the always-works property isn't caching, isn't a retry loop, isn't a generous timeout. Those are patches that reduce the chance of failure. Lantern's deterministic paths cannot fail from a model outage because they were never connected to the model. Structural guarantees beat hopeful ones — you don't have to test every failure mode of a dependency you don't have.