Structured Context Retrieval: Your Content Had Structure. Your Retrieval Pipeline Threw It Away.

Somewhere in your organization is a document that took years to get right. A clinical protocol, a maintenance manual, a product catalog, a policy handbook. Teams argued over its sections. Its tables were checked. Its cross-references were deliberate. Every heading, every step number, every "see section 4.2" encodes a decision about what things mean and how they connect. Then someone connected it to an AI system, and the first thing the pipeline did was run it through a shredder.

That is not a metaphor for anything exotic. It is a literal description of how standard retrieval-augmented generation works. Documents are split into fixed-size chunks — 512 tokens, give or take — because that is the size the machinery finds convenient. The section hierarchy is gone. The tables dissolve into orphaned rows. Step 7 of a procedure floats free of steps 1 through 6. The condition detaches from the instruction it governed. Each fragment still reads fluently on its own, which is exactly why nobody notices the damage.

Then the system is asked to answer questions by finding the fragments that sound most similar to the question, and hoping the meaning survived.

For simple lookups, it often does. For the questions that matter — the ones whose answers live in relationships, sequences, and constraints — it structurally cannot. The information was destroyed at ingestion. No amount of re-ranking, bigger models, or prompt engineering repairs a loss that happened before the first query arrived.

Components, not chunks

There is a name for the alternative, and a distinction that carries it.

• Chunk: An arbitrary fragment. Its boundary is wherever the token counter stopped. It carries no type, no relationships, no memory of where it came from.

• Component: A unit of content created with intent — a task, a lab observation, a contract clause, a product entry. Its boundaries mean something. It knows what kind of thing it is, and its connections are declared, not guessed.

Structured Context Retrieval (SCR) is the discipline of retrieving components instead of chunks. The premise is one sentence: structure is meaning. The hierarchy of a document is not formatting — it is semantics your organization already paid for. A retrieval system that preserves it inherits that investment. One that shreds it spends the rest of its life trying to statistically reconstruct what it deliberately threw away.

You already have the graph

The industry has broadly figured out that graphs fix what vectors miss — "Graph RAG" is everywhere. But most of the conversation assumes the graph must be built: run a language model over your documents, extract entities and relations, pay a famously large indexing bill, and accept that the result is the model's best guess at your structure.

Here is what that conversation keeps missing: for most enterprises, the structure already exists. Your content schemas, your data models, your document architectures — DITA, FHIR, Schema.org, take your pick — already form a graph. It was authored by people, governed by process, and fought over in meetings years ago. It is authoritative by construction, not by extraction.

The graph is not a project. It is an asset you have been quietly ignoring.

That inverts the cost argument. The eye-watering indexing bills belong to reconstructing structure from raw text. Recovering structure you already own is cheap — the expensive intellectual work of deciding what the types and relationships are was finished long before anyone said "RAG."

SCR uses both tools for what they are good at. Vector similarity is genuinely excellent at finding — surfacing the right region of a knowledge base from a loosely worded question. So SCR uses similarity to discover where to look, then retrieves what is actually there: the whole component, with its type, its relationships, its version and status, and a provenance trail back to the source. Discovery by similarity; retrieval by structure.

Does it matter? Measurably.

• 92% schema-aware retrieval accuracy, versus 68% for a vector-only baseline on the same workloads.

• ~90% reduction in hallucination on tested production workloads.

• ~87% drop in interpretation error in life-sciences work when retrieval went structure-first.

The pattern replicates far beyond us. A 2026 industrial benchmark took an agent from 65% to 99% by making a typed graph the source of truth and letting the model read rather than guess. Anthropic reported its own analytics agents at 21% accuracy without a curated structural layer and 95% with one. Even model architecture is converging on the same lesson — recent frontier work separates lookup from reasoning inside the network itself. Looking things up and making things up are different operations. Systems get reliable when they stop conflating them.

The gap is widest exactly where the stakes are highest: multi-hop questions."Which medications prescribed for conditions in Department A interact with treatments in Department B" is a walk across six or more relationships. A structured graph performs that walk deterministically. Similarity over shredded fragments performs it by luck.

The honest boundary

SCR is not a claim that vectors are useless or that every corpus needs a graph. Genuinely unstructured prose with no schema worth recovering is a fair job for extraction and similarity search. The claim is narrower and sharper: where structured content exists, destroying its structure at ingestion is an unforced error. And the content enterprises most need AI to get right — regulated, clinical, financial, contractual — is precisely the content that is already structured, because safety and compliance demanded it decades before AI did. We have argued elsewhere that trustworthy AI systems should look up before they make up — consult authoritative structure before generating. SCR is the second half of that sentence. Looking up is only worth doing if what comes back is intact. Retrieve components, not chunks, and the lookup returns meaning instead of debris. Your organization does not need to manufacture meaning for its AI. It needs to stop destroying the meaning it already has.

Read the research paper →