Arity · RAG metadata · Semantic graphs

Why Richer RAG Metadata Still Cannot Hold Relational Meaning

Tags, titles, summaries, and embeddings describe one object. Contradiction, extension, dependency, and significance-in-context live in pair-space — and pair-space cannot be manufactured by annotating each chunk independently.

By Scott Farrell · LeverageAI · Extends The Index Is the Data

Here is a pattern I keep seeing on RAG programmes that are already past the demo stage. The team has done the sensible things. Chunking is cleaner. Titles and headings are stored. Authors, dates, product lines, and access tags are attached. Someone has even run an LLM over every passage to write a crisp abstract and a list of entities. The dashboards look mature. Then a relationship question lands — does this policy exception overturn last year’s rule, or only narrow it for one region? — and the system still behaves like a well-labelled filing cabinet.

The usual diagnosis is “we need richer metadata.” Another field. A better summary model. A multi-vector index. Those moves help routing. They do not fix the structural hole. Relational meaning is not a property you can paint onto a single record no matter how carefully you describe it.

RAG looks weak on relation. Adding metadata is its strongest tool — but metadata is mostly a different resolution of summary, not meaning.

That is the whole thesis in one breath. The rest of this article derives why: arity. It shows the failure on a controlled pair of documents, draws the type boundary between annotation and a concluded edge, and answers the objection that “we already store related IDs.”

What the parent already settled

This piece is an extender. The parent argument is load-bearing and will not be re-derived here.

The Index Is the Data established that for relationship-heavy corpora the wiki-graph of claims and typed edges is the durable substrate: intelligence is pre-computed into navigable structure rather than re-synthesised from similar passages at every query. Meaning lives in edges, not merely in retrieved text; the system gets smaller and smarter when claims compress into relationships rather than piling up as more chunks.¹

What this article adds is narrower and sharper: the arity explanation for why indefinitely expanding per-record metadata cannot smuggle you across that boundary — and a practical type test you can run on Monday morning without buying a new platform.

Two questions that look similar and are not

Most metadata work answers one family of questions extremely well:

Those are unary questions. One object is enough. You can answer them having never opened any other document in the corpus.

Relational work answers a different family:

Those are at least binary. They take two operands: the new unit and something already in the worldview. “Interesting” is not an intrinsic glow around a paragraph. It is a relation between the paragraph and what you already know — a diff, not a label.²

When I talk about pulling a pillar post into smaller pieces, I am not primarily chasing shorter text. I am chasing relational precision. A fifty-idea ebook forces a general answer about “how this relates.” Fifty meaning-complete pieces can each be positioned against the corpus on their own axis — contradiction here, extension there, evidence for a third claim, audience fit for a fourth. That grain argument is developed fully in Semantic Refraction; the point for this article is simpler: even at ideal grain, the relation still has to be concluded. Grain makes the judgment tractable. It does not write the edge for free.³

The mechanism: unary annotation versus pair-space

In mathematics and computer science, arity is the number of arguments an operation takes. A unary operation has one; a binary operation has two.⁴ A binary relation is not a property of a singleton; it is a structured association over pairs.⁵

Ordinary metadata, as practitioners use the word, is data about data — descriptive, structural, administrative facts attached to an object.⁶ That definition already exposes the type:

So the structural reason metadata cannot “graduate” into meaning by getting thicker is not that teams write bad abstracts. It is arity. Metadata is the same epistemic type as the chunk it decorates — description, at another resolution. Relational meaning is a different type: a judgment in pair-space.

Pair-space is also combinatorially different. If you have n addressable units, the number of possible pairs grows with n². You cannot honestly precompute “all relations” as per-chunk annotation written without looking at partners. Something has to select candidate pairs, visit both ends, form a view, and keep a receipt. That is why edges discovered by travel — ingest acting as a query against the existing corpus — are a different operation from stamping cosine neighbours into a field.⁷

The open web’s own data model made the same call decades ago. RDF does not store “smarter tags on a node” as the unit of meaning between resources; it stores subject–predicate–object triples — two ends and a typed link.⁸⁹ Knowledge graphs, likewise, earn multi-hop reasoning by representing entities and the relations between them — not by multiplying labels on isolated documents.¹⁰

Controlled case: two excellent chunks, one failed join

Consider a small policy corpus. Two passages, both real enough to ship in any enterprise RAG pilot.

Ask the system an aboutness question: What is our refund policy? Retrieval will likely surface both. A careful reader — or a careful model with both chunks in context — can reconcile them. That is not nothing. Vector similarity remains a good single-passage sensor and a useful candidate generator.¹¹

Now ask the relationship question the business actually needs on a support ticket:

What did the 2025 APAC memo change about the 2024 global rule — and for whom does the global rule still stand?

Look at the metadata. Every field is excellent. None of it contains the answer as a maintained fact. The summaries describe each document. The tags overlap enough to co-retrieve. The embeddings may even be near each other in “refund policy” space. Still missing:

• a typed edge: B supersedes A (partially, scoped);
• scope: APAC enterprise contracts after a date;
• residual: retail and non-APAC remain on A;
• reason: explicit supersession language in B about the global window;
• provenance: who or what process compared A and B, when, under what policy of interpretation.

The join is not a finer summary of B. It is a judgment that only exists once something has held A and B together and concluded a relation. If you only ever annotate A alone and B alone, you can improve forever and still not store that judgment.

The representation that actually answers

A concluded edge is a different object:

Notice what changed. We no longer ask metadata to be a better abstract of one chunk. We store a relation with two ends, a type, a scope, a reason, and a receipt. That is already the shape of a semantic intermediate representation — claims and edges — whether you file it in a wiki page, a graph database, or a JSON column beside the chunk.¹

Significance is the next layer up from the edge: not only that B supersedes A in scope, but why that matters to a support agent, a finance auditor, or a renewal negotiation. Significance is compiled judgment relative to a worldview and a purpose; it is not an intrinsic field you can regenerate from B’s text alone once the surrounding context is gone. Cache it with a pointer, or you are doing marketing, not memory.¹²

The layer table teams keep flattening

It helps to keep the layers separate instead of renaming everything “metadata” once it is stored next to a chunk:

RAG retrieves written material. It does not naturally store the work of understanding that material. The wiki distinction is exactly that: documents and their aboutness on one side; readable claims and reasoned edges — understanding done ahead of the next question — on the other.¹³

If RAG metadata starts containing maintained claims, typed relationships, reasons, and provenance, it has started turning into a semantic IR. It is no longer “just better metadata.” The storage engine can stay the same. The type has changed.

The type-boundary test

Use this as a checklist on any schema that claims to “understand relationships.”

The second list is not a moral victory over the first. Unary metadata is the right tool for filters, ACLs, recency, and “find me passages about refunds.” The failure mode is believing the second list will appear automatically if the first list gets long enough.

People often reach for the phrase “smart metadata” when they feel the second list approaching. I have used that temptation myself: augmented fields that say how a record fits, what it changes, how it will be reused. The honest reframe is stronger — that layer is a semantic derivative compiled from the document in relation to an existing worldview, not a deluxe label set. Call it cognitive IR if you want the compiler metaphor; call it a wiki-graph if you want the navigable artefact. Just do not pretend arity changed because the column family was named metadata.

Objection: “We already store related_ids”

This is the sharpest pushback, and it deserves a clean answer.

Storing identifiers is not yet concluding a relation. A list of document IDs can be any of the following, and only one of them is an edge in the sense above:

1. Similarity stamp — top-k cosine neighbours written at ingest. Useful as a sensor cache. Not a typed judgment. Neighbours of “refund” will happily link A and B without saying supersession versus restatement.
2. Editorial cross-link — a human added “see also.” Better, but often untyped (“see also” is not supersedes_in_scope).
3. Reasoned edge with provenance — two ends visited, type chosen, reason written, evidence pointed. This is relational meaning. If this is what your “metadata” holds, congratulations: you are maintaining a graph. The argument is not that edges cannot live in the same database as chunks. The argument is that you have left pure unary annotation and should design, budget, and lint for the graph you actually have.

So the caveat in the formal definition matters: metadata can store an edge once a two-ended judgment process has created it. The ceiling is not “columns cannot hold JSON.” The ceiling is “unary write-time description cannot invent pair-space conclusions.”

Objection: “The model will join at query time”

Sometimes it will — especially when both chunks are retrieved and the prompt is careful. That is a real capability and a reason not to declare vector search useless.

What query-time joining does not give you, by itself:

• Compounding. The same expensive pair judgment is paid again on the next ticket unless someone writes it back.
• Audit. A fluent synthesis in a chat trace is weaker than a typed edge with bronze pointers when legal asks what the system believed last Tuesday.
• Selective activation. Agents that must walk a world — not just stuff a context window — need edges as a page table, not a hope that the right two chunks co-occur in the top-k.

This is the parent doctrine in operational clothes: relationships need a native slot if you want navigation rather than rediscovery.¹ RAG remains the smoke detector — “here are things that might be nearby and currently lack an edge.” It is a poor substitute for structural steel.¹¹

Why the ceiling hurts more as the corpus grows

No invented benchmark is required to see the shape.

Unary annotation scales roughly with corpus size: each new chunk gets titles, tags, a summary. Pair-space does not. Candidate pairs grow much faster than records. Exhaustive “relate everything to everything” at ingest is not a plan; it is a combinatorial fantasy. Production systems need a cheaper way to choose which pairs deserve judgment — travel along existing structure, natural keys, entity collision, human attention, contradiction alarms, or sensor hits from RAG itself.

That is also why decomposition into claim-sized units is not a publishing flourish. It multiplies addressable ends, which multiplies possible joins, which multiplies the value of edges that are actually concluded. Semantic decompilation is the method for recovering those ends and their call graph from prose and code; this article only needs the consequence for metadata: more atoms without edge-forming work produces a denser haystack, not a worldview.¹⁴

Maintenance follows the same split. Unary fields go stale when the document changes. Edges go stale when either end changes or when a third document supersedes the relation. Graph lint — contradiction sweeps, orphan detection, supersession chains — is not optional decoration once you claim relational intelligence. If you refuse that cost, you should also refuse the claim.

Division of labour, not a holy war

None of this is a campaign to delete your vector index. The durable split looks like this:

• RAG / embeddings: fast neighbourhood sensing, single-passage retrieval, candidate generation for pairs that might deserve an edge.
• Unary metadata: filters, ACLs, chronology, routing, human-facing labels.
• Claims and reasoned edges: the compiled understanding that answers change/consequence questions without re-deriving the join every time.

Agents need the third layer more than chatbots do, because agents traverse, write, and compound rather than answering one shot and forgetting.¹³ Coexistence is normal: keep bronze sources, keep sensors, and stop asking the sensor to be the map.

Where this sits in the wider sequence

This run’s earlier pieces already own adjacent ground. Attention-native publishing owns how meaning-complete units earn an interrupt without spamming the feed.¹⁵ Semantic Refraction owns relational grain — why pieces can form joins the undifferentiated whole was too coarse to hold.³ Semantic Decompilation owns recovery of design from compiled prose and the round-trip lint against implementation.¹⁴ The prompt-as-source argument owns stage-relative source packages in AI-generated software — another place teams confuse description of an artefact with the judgment that produced it.¹⁶

Later pieces in the same sequence will push further into quotes without premature canonical authority, experiment graphs, publishing as sensor, executable worldview, intent-conditioned task worlds, orientation capital, and institutional memory as distinct from raw cognition. Those are separate arguments. This article only needs to fix the arity mistake that makes “more metadata” feel like a substitute for them.

What to do Monday

Pick one multi-document failure from the last month. Write down the relationship question that failed — in the about-versus-changes form. Then inspect the fields you trusted:

1. Which fields are well-formed if the partner document does not exist?
2. Where is the typed edge with two ends, reason, and evidence pointers — if anywhere?
3. Was any process paid to visit both ends, or did you hope the chat model would notice?
4. If you added one concluded edge by hand (or by a deliberate ingest walk), does the failure disappear for the next agent without re-prompting the join?

If step 4 works, you have not “improved metadata.” You have begun building the semantic graph the parent article argued for — one honest edge at a time.