The first RAG application I built felt like a magic trick. Load a pile of documents — contracts, reports, research papers, whatever — into a vector store, and suddenly you could have a conversation with them. Ask a question, get an answer, see the sources. Compared to keyword search, it felt like going from finding needles to having the haystack understand what you were looking for.
So I built another one. Then another. Each time the architecture got more sophisticated. I added semantic chunking strategies, because naive paragraph splits lose context. I added hybrid search — vector similarity plus BM25 — because some questions need keyword precision and others need semantic breadth. I added reranking with cross-encoders, because first-pass retrieval often gets the order wrong. Each addition improved things.
Then I added a knowledge graph.
That was the inflection point. A knowledge graph doesn't just store what documents say — it stores relationships between what documents say. Two contracts may never mention each other, but they share a counterparty, a jurisdiction, a standard clause pattern that appears across eighty of them. The graph knows this. The vector store doesn't. Once I had both working together, I could answer questions that required reasoning across documents, not just within them.
But I still felt like I was missing something.
The limitation no one names
Here's the problem with all of it: retrieval — even sophisticated hybrid retrieval with a knowledge graph — only answers the questions you think to ask. You have to know what you're looking for. You have to already have the hypothesis.
I kept thinking about what a real analyst does with a stack of documents. They don't just answer questions — they read the whole stack. They look for patterns. They notice when something that should be there isn't. They find the anomaly in document 847 that nobody flagged because nobody thought to check. They bring you findings you didn't commission.
Can software do that? Not in the "generate five confident-sounding paragraphs of nothing" way. Real findings. Evidenced, specific, occasionally surprising. The kind a sharp analyst would bring you after spending two weeks with a corpus.
I spent a long time working on algorithms that would produce this. The hard part isn't the idea — it's the signal-to-noise problem. If you ask a language model to "find interesting things," you get interesting-sounding things that mostly rephrase the obvious, or worse, fabrications dressed as analysis. You need a process disciplined enough to distinguish between "this is a real pattern in the data" and "this seemed interesting to a language model."
What I eventually hit on was a multi-wave approach. You don't ask for insights directly. You extract raw material — entities, concepts, thematic fragments — at scale across every document. Then you cluster that material without labels, letting the structure of the corpus reveal its own schema. Then you validate: is this cluster coherent? Is it evidenced by specific passages, not inferred? Is it something that wasn't already obvious from the documents' own structure?
The result is what I started calling emergent metadata. Not metadata you assigned, not metadata extracted from structured fields — but thematic structure that emerged from the corpus itself, bottom-up, without being told what to look for. And crucially, every finding is pinned to specific evidence in specific documents. Not inference. Not a guess. A tile that actually exists in the mosaic.
The harder design problem: how often do you run it?
Once you have emergent discovery working, a second problem appears — one that took me longer to see. How often does a user actually trigger it? Monthly? Quarterly? When a big document batch arrives?
Not every day. Discovery is computationally expensive, and a corpus doesn't change fast enough for daily discovery to produce meaningfully different results. You run it after a quarter closes. When a significant document batch comes in. When someone says "I feel like we're missing something and I can't name what."
Here's the trap: if your main value proposition is emergent discovery and users only trigger it once a month, you have a product that's used once a month. No product survives that cadence. You also need to be the thing users reach for every day — answering specific questions, pulling specific clauses, comparing specific documents — the daily work that earns trust through consistent accuracy.
This forced me to think of the product as three systems sharing one architecture, each with a different rhythm:
Daily: a production-grade RAG system. Hybrid retrieval, multi-agent deliberation for complex queries, hallucination detection, citation quality scoring. The kind of question-answering that earns trust because it's right, consistently, on mundane requests.
Weekly: thematic intelligence. Cross-document questions that weren't possible without the schema emergent discovery built. Not "what does this contract say about termination" but "which contracts have the most aggressive termination provisions, and what's the clause pattern driving it."
Monthly or quarterly: emergent discovery itself. The "tell me what you found" run. The headline capability — but it only works because the other two layers are excellent on their own.
The thing that surprised me
One pattern I didn't expect: the discovery layer makes the daily RAG better.
When you have a thematic map of your corpus — the conceptual clusters that emerged without you naming them — that map becomes structural scaffolding for retrieval. A question about "liability" retrieves better when the system knows that liability in your corpus is a cluster of eleven related themes, not a single concept. The emergent schema informs the query. Discovery and retrieval aren't separate systems — they're entangled.
You can't bolt emergent discovery onto an existing RAG system and have it just work. The architecture has to be designed from the start around the idea that a corpus has intelligence the system needs to discover before it can fully retrieve.
Epistemic honesty
Every RAG system I've built has a failure mode: confident-sounding wrong answers. This isn't unique to RAG — it's inherent to language models. The challenge isn't eliminating it. It's surfacing it honestly.
I've come to think of this as the dark hallway principle: it's better to admit the light doesn't reach a particular corner than to pretend the whole building is illuminated. If the system can't find enough evidence to support a claim, it says so. If a discovery finding has low coherence across the corpus, it marks that. The goal is findings you can act on — which requires knowing both what was found and how much to trust it.
That's what I've been building toward with Tessera. Not a smarter search engine — a different category of thing. A system that surfaces what's in your documents, including things you didn't know were there.
One document has metadata. A thousand documents have a pattern. A million documents have intelligence.