GraphRAG answers what your corpus says. Vayl answers what’s true now.

Two different questions

A document doesn’t stop being true. A customer’s plan does.

A corpus store has no reason to implement supersession — a PDF doesn’t become false when a later PDF disagrees; both are simply in the corpus. Agent memory is the opposite: when a customer downgrades, the old plan must stop being returned.

Stated plainly

What Vayl does not do.

So an evaluation doesn’t waste your time.

• No document ingestion or chunking. Vayl ingests statements, not files. There is no loader.
• No community detection or hierarchical summarisation — so no global search. Vayl cannot answer “what are the main themes across these 10,000 documents?”
• No corpus-scale graph. The optional Neo4j projection is bounded and per-tenant. We’ve measured it to 50k edges (3.7 s bulk ingest, ~14 ms/edge write, ~34 ms 2-hop traversal). That’s a healthy per-tenant graph — not a corpus knowledge graph, and we claim nothing there.

If those are your requirements, the honest recommendation is Microsoft GraphRAG, temporal-graph stores, or a a property-graph system. Vayl sits beside them, not against them.

The gap GraphRAG leaves

Point a corpus stack at changing facts and it goes stale.

Under sustained churn — 50 users × 4 facts × 4 revisions = 800 interleaved writes, then 200 current-value queries, with an identical model, embedder and answer synthesizer for every system:

An additive store appended a new memory on every update instead of retiring the old one — 800 memories for 200 facts. For one user’s primary database it held five contradictory values, all timestamped the same day. The reader sees several equally-current answers and can’t choose. That ambiguity compounds with every revision; a reconciling store stays flat at one value per fact.

On removal without replacement — “we dropped Sentry”, “Alice left” — across 14 cases including two controls that must not delete:

A temporal graph retracts well — 10 of 12. An earlier claim of ours that it couldn’t retract at all did not survive a proper benchmark, and we corrected it. Where it struggled was the opposite direction: it deleted a still-true fact on a hedged “considering dropping Redis”, and returned a superseded value on a replacement. Deleting too eagerly is a failure too — which is why the controls are in the suite.

How they compose

Two questions, same turn, neither layer needs to know about the other.

The refund policy comes from the corpus; the customer’s current plan comes from memory that reconciled the downgrade. Ask a GraphRAG index that second question after three plan changes and you get whichever chunk ranks highest.

Which do you need

Usually both — and that’s the point.