Documents are rarely wrong in the same way.
A project proposal can be relevant but obsolete. A meeting note can be accurate but non-binding. A market-size estimate can be useful but contradicted by later due diligence. A regulatory question can be unanswered and still more important than a polished paragraph that sounds certain. This is the small, boring, expensive problem hiding inside many enterprise AI deployments: the system finds the right files, then treats unlike things as if they had the same authority.
The paper Retrieval Is Not Enough: AI for Organizations Needs Epistemic Infrastructure introduces OIDA, an architecture for storing organizational memory as typed, signed, time-indexed graph state rather than as flat text chunks waiting to be retrieved.1
The tempting summary is: “Graph memory beats RAG.”
That is not what the paper shows. In fact, the reported pilot results say almost the opposite in the in-window setting: when the full relevant corpus fits inside the model context, the full-context baseline achieves better aggregate answer quality than structured graph retrieval. Awkward for a paper about graph memory? Only if we insist on reading research as product marketing. The useful result is more precise: structured retrieval uses dramatically fewer input tokens, surfaces open knowledge gaps more consistently in one diagnostic pilot, and clarifies what a graph memory layer must prove before anyone should pay the engineering cost.
That makes the paper more interesting, not less. The value is not a victory lap for another retrieval architecture. It is a decision procedure for when retrieval is not enough.
The main result is a quality-cost tradeoff, not a graph-retrieval victory
The paper reports pilot evaluations on synthetic organizational corpora designed to stress epistemic state: current decisions, unresolved questions, superseded plans, contradictions, uncertain evidence, and multi-document dependencies. The evaluation compares structured retrieval against a full-context baseline in a regime where the whole corpus can be placed inside the model context.
That regime matters. Full context is given a very strong advantage: it sees everything. If the baseline sees the whole corpus and structured retrieval sees only a selected context, the baseline should usually do better on coverage. And it does.
For Corpus A, ClearPath, the full-context condition reaches an aggregate Epistemic Quality Score, or EQS, of 0.8329 versus 0.5574 for structured retrieval. For Corpus C, Vertex Minds, full context reaches 0.8438 versus 0.5395. In both cases, the largest gap is contextual recall, meaning the full-context baseline wins mainly because it has broader access to source material.
| Corpus | Structured input tokens | Full-context input tokens | Structured EQS | Full-context EQS | How to read it |
|---|---|---|---|---|---|
| ClearPath / Corpus A | 2,623 | 110,539 | 0.5574 | 0.8329 | Full context wins quality; structured retrieval uses far less context. |
| Vertex Minds / Corpus C | 1,944 | 109,303 | 0.5395 | 0.8438 | Same pattern; the failure mode is missing relevant tension. |
The current live version of many enterprise AI arguments would quietly skip this table. It would lead with the elegant architecture, mention “knowledge gravity,” and then glide into a sentence about auditability. Lovely. Also premature.
The evidence-first reading is stricter: the paper does not prove that graph memory beats long-context reasoning. It shows that full context wins when full context is available, and then asks the more practical question: what happens when full context is too expensive, too slow, too noisy, or simply impossible?
That is the question organizations actually face. Not “Can we design a beautiful memory graph?” but “When does the graph recover operational state that ordinary retrieval misses at an acceptable token budget?”
The clean positive signal is knowledge-gap surfacing
The strongest positive behavioral signal in the paper is not aggregate EQS. It is gap surfacing.
In a ClearPath diagnostic pilot, structured graph retrieval included a dedicated knowledge-gap section in all 10 runs. The full-context baseline surfaced the same limitation in 5 of 10 runs. This does not prove the entire architecture. It does suggest that representing open questions as first-class memory objects changes answer behavior.
| Behavior tested | Structured graph retrieval | Full-context baseline | Likely purpose of the test | What it supports | What it does not prove |
|---|---|---|---|---|---|
| Explicit knowledge-gap surfacing | 10 / 10 runs | 5 / 10 runs | Main diagnostic signal for open-question representation | Open information needs can be made more visible to the answer generator | Dynamic node weights caused the result; graph retrieval is globally superior |
That distinction is important. In most organizational systems, unanswered questions disappear into the archive. They are semantically retrievable, yes, in the same way a fire extinguisher is technically available behind five locked doors. A model might mention them if they are salient enough in context. Or it might not. The answer will still be fluent either way, which is the traditional camouflage of enterprise AI failure.
OIDA’s design choice is to model unresolved questions directly. A question is not just a sentence in a document. It is a memory object with a type, provenance, timestamp, urgency behavior, and graph relationships. In the paper’s taxonomy, a QUESTION begins with relatively low priority but can gain urgency while unresolved. The point is not philosophical. The point is retrieval behavior.
A business decision often fails not because the team lacked documents, but because the unresolved dependency was not raised at the moment of action. The system answered the question asked. Unfortunately, the real risk was the question nobody remembered to ask. Very efficient. Also how expensive surprises happen.
OIDA’s real contribution is epistemic typing
OIDA’s central architectural claim is simple: organizational records need persistent epistemic state.
A memory item is not merely a chunk of text. It has a role. The paper’s node types include decisions, constraints, evidence, narratives, plans, evaluations, observations, hypotheses, and open information needs. Edges encode relations such as support, dependency, contradiction, blocking, implementation, refinement, and supersession. Retrieval then combines semantic similarity with graph state, so a system can condition relevance on what the memory item is and how it relates to other memory items.
The obvious version of RAG asks: “Which passages are similar to this query?”
OIDA asks a more operational question: “Which pieces of organizational state should guide this answer now?”
Those are not equivalent. A draft plan can be semantically close to a query about strategy. A binding decision can be less verbose and therefore less retrievable. A contradicted claim can be highly relevant precisely because it should not be treated as settled. A question can contain no answer and still be the most important item to surface.
| Memory object | Ordinary retrieval may treat it as | OIDA wants the system to treat it as | Business consequence |
|---|---|---|---|
| Decision | Relevant text | Binding commitment until superseded | Prevents the AI from reopening settled choices casually. |
| Plan | Relevant text | Time-bounded intention | Prevents old intentions from masquerading as current policy. |
| Evidence | Relevant text | Support or refutation with provenance | Makes the answer explain why a claim is believed. |
| Hypothesis | Relevant text | Unverified testable claim | Keeps speculation out of the “known facts” bucket. |
| Observation | Relevant text | Weak signal unless reinforced | Reduces overreaction to isolated notes. |
| Question | Often ignored unless salient | Open information need | Makes uncertainty operationally visible. |
| Contradicted claim | Relevant text | Claim under tension | Prevents false consistency. |
This is the paper’s most useful mental model for enterprise AI. Many failures are not hallucinations in the simple sense. They are status errors. The model says something supported by a document, but the document was only an early proposal. The system gives a confident answer, but the underlying evidence is contradicted. The summary is grounded, but grounded in the wrong epistemic layer.
Grounded nonsense is still nonsense. It just comes with citations.
Contradictions should be stored, not rediscovered every time
The paper’s treatment of contradiction is especially relevant for organizations because corporate knowledge is not a clean database of facts. It is a landfill with version history, politics, and meeting minutes.
OIDA represents contradiction as a signed graph relation. A node can support another node, refine it, implement it, block it, contradict it, or supersede it. Importantly, contradiction is non-destructive. A contradicted item is not deleted. It can be demoted, paired with the contradicting item, or retrieved as part of a tension.
That is the right design instinct. In real organizations, contradictions are often not resolved immediately. A sales deck says the total addressable market is huge. A diligence memo says the estimate depends on a heroic assumption. A product team says latency is acceptable. A customer escalation says otherwise. Deleting one side would be dangerous. Treating both sides as equal would also be dangerous.
The Vertex Minds result shows the problem sharply. In one contradiction-sensitive query about NovaTech AI’s market size and reliability, structured retrieval may present a single total-addressable-market figure and miss the pitch-deck versus dossier gap. The full-context baseline recovers both figures and treats them as unverified hypotheses.
That is not a small implementation footnote. It is the core risk of graph memory: if extraction misses one side of a contradiction, the graph can manufacture false clarity.
| Failure mode | Why it matters | What a serious deployment must measure |
|---|---|---|
| Missing one side of a contradiction | The answer becomes confidently one-sided while looking structured. | Edge-type precision and recall for CONTRADICTS, BLOCKS, and SUPERSEDES. |
| Misclassifying a hypothesis as evidence | Speculation becomes “support.” | Node-type accuracy on a labeled audit set. |
| Treating old plans as current state | The AI gives obsolete operational guidance. | Supersession detection and timestamp-sensitive retrieval tests. |
| Ignoring open questions | The system hides decision risk. | Open-question recall and gap-surfacing rate. |
This is where the paper usefully avoids the usual graph-RAG hand waving. A graph is not magic. A bad graph is a high-resolution error generator. The architecture is valuable only if the node and edge extraction is good enough to support the decisions being made from it.
The dynamic scoring mechanism is a design hypothesis, not a proven result
OIDA includes a node-priority mechanism: a memory object’s retrieval priority can depend on type, time, usage, evidence/support, graph influence, open-question urgency, and contradiction penalties. The intended behavior is intuitive. Decisions remain stable until superseded. Evidence decays slowly. Observations decay faster. Questions gain urgency while unresolved. Contradictions penalize or reshape priority.
This is a useful implementation idea. It is not yet an empirical result.
The paper is explicit about this boundary. It does not report longitudinal telemetry showing node-priority weights evolving over repeated update cycles. It also does not isolate dynamic weighting from the simpler value of typed graph representation. In other words, we do not yet know whether the dynamic layer adds value beyond a static typed graph with signed edges.
That distinction matters for business adoption because every dynamic mechanism adds maintenance cost, debugging complexity, and governance burden. A static graph that marks decisions, hypotheses, contradictions, and open questions may already solve much of the problem. If so, the elegant dynamics are optional machinery. Very nice machinery, perhaps. Still machinery.
A responsible evaluation should therefore separate four conditions:
| Condition | What it tests | Practical decision rule |
|---|---|---|
| Full context | Best answer quality when the corpus fits in context | Use it if cost, latency, and noise are acceptable. |
| Dense or hybrid RAG | Standard retrieval without typed epistemic state | Use it for mostly factual, single-hop queries. |
| Static typed graph | Value of typed nodes and signed edges | Use it if state-sensitive queries improve at equal token budget. |
| Dynamic typed graph | Added value of time-dependent priority weights | Use it only if it beats the static typed graph. |
This table is the paper’s adoption logic in miniature. Do not buy the architecture. Test the failure mode.
The released corpora are useful because they test epistemic stress, not topical relevance
A secondary contribution of the paper is the release of three synthetic organizational epistemic-stress corpora: ClearPath, FireGlass, and Vertex Minds.
ClearPath covers consulting and operations. FireGlass covers IoT product development. Vertex Minds covers venture-capital deliberation. The corpora are synthetic but structurally realistic, and they are designed around organizational situations where relevance alone is insufficient: evolving decisions, open information needs, contradictions, prior-deal lessons, architecture constraints, technical debt, and integration risk.
This dataset contribution should not be underrated. Most retrieval evaluations ask whether the system found relevant content. That is a low bar for organizational reasoning. A system can retrieve a relevant note and still fail the task because it misses whether the note is current, binding, contradicted, superseded, or unresolved.
The better evaluation question is: did the system recover the organization’s current epistemic state?
That question changes what counts as a good AI answer. It is not enough to quote a relevant document. The answer must know whether that document is a decision, an option, a warning, an unresolved dependency, or a corpse from last quarter’s strategy deck. The corpse may still have keywords. This is why search engines should not run companies.
The business value is state recovery under constraint
For business users, the paper’s practical message is not “replace RAG with graph memory.” The better rule is conditional.
Use full context when the relevant corpus fits, the cost is acceptable, and the result is not degraded by excessive noise. Use ordinary RAG when queries are mostly factual and single-hop. Consider an epistemic graph layer when the organization has enough state complexity that relevant documents are no longer enough.
That complexity usually shows up in five places:
| Diagnostic quantity | How to estimate it | Why it matters |
|---|---|---|
| Window pressure | Tokens in the task-relevant corpus divided by usable context budget | If pressure is low, full context may be best. |
| Epistemic heterogeneity | Share of units that are decisions, plans, hypotheses, evidence, or open questions | Flat chunks are less dangerous when all records have similar roles. |
| Conflict or supersession rate | Share of claim-like units contradicted or replaced later | Signed edges matter only when tension and change are common. |
| Open-question rate | Unresolved information needs per document or per query | Question nodes matter only if uncertainty must be surfaced. |
| Multi-document dependency | Number of source documents required for a correct answer | Graph state helps most when answers require chains, tensions, or lineage. |
| Extraction quality | Precision and recall for node types and edge types on a small audit set | Bad structure can be worse than no structure. |
This is where Cognaptus would turn the paper into a deployment checklist, not a slogan. First, sample real organizational documents. Second, label realistic queries by answer type: current decision, contradiction, unresolved question, superseded plan, evidence chain, or ordinary factual lookup. Third, compare full context, ordinary RAG, static typed graph, and dynamic typed graph at equal token budgets. Fourth, audit extraction quality before celebrating answer quality.
The ROI case is not “graphs are smarter.” It is narrower and more defensible: a typed memory layer is worth building if it reduces decision-state errors under context budget pressure.
That includes errors like:
- answering from a superseded plan;
- treating a hypothesis as evidence;
- omitting an unresolved dependency;
- hiding contradictions behind a smooth summary;
- retrieving many relevant snippets while missing the binding decision;
- giving a current-state answer without knowing what “current” means.
Those are expensive errors because they look professional. Nobody panics when the AI says something obviously absurd. The dangerous answer is the one that is plausible, sourced, and organizationally wrong.
The limitations are not decorative; they define the next experiment
The paper’s limitations are unusually important because they determine whether OIDA is an architecture ready for deployment or a research direction ready for falsification.
First, the experiments are in-window. The full-context baseline sees the entire corpus and wins aggregate quality. This means the reported evidence does not justify replacing full context when full context is feasible.
Second, the dynamic priority mechanism is not longitudinally validated. The paper specifies how node priorities could evolve, but does not prove that those dynamics improve organizational memory over time.
Third, the evaluation does not isolate dynamic graph memory from a static typed graph. This is the decisive ablation. If a static graph performs just as well, then the practical contribution is typed epistemic state, not time-dependent weighting.
Fourth, EQS is based on an LLM-judge protocol. That is useful for within-benchmark diagnostics, but it is not the same as expert evaluation of organizational decision quality.
Fifth, the corpora are synthetic. That is good for controlled stress testing and public release. It is not enough for deployment claims in messy real organizations, where documents are inconsistent in more imaginative and less polite ways.
These limitations do not weaken the article’s central point. They make it usable. The correct conclusion is not “OIDA works.” The correct conclusion is “OIDA identifies the tests an organizational memory layer must pass.”
What should change in enterprise AI design
The paper pushes enterprise AI away from a retrieval-only worldview.
In a retrieval-only system, the memory layer is mostly a search problem: embed, index, rank, rerank, stuff into context, generate. Better engineering improves access to relevant material, but the model still has to infer status at answer time. Was this note final? Was it superseded? Is this claim contradicted? Is this risk unresolved? The model may infer correctly. It may not. The prompt will look serious either way.
In an epistemic infrastructure view, memory carries state before the question is asked. The system stores not only what was said, but what kind of organizational object it is: decision, plan, constraint, evidence, hypothesis, observation, evaluation, narrative, or question. It stores not only relation, but signed relation: support, contradiction, blocking, supersession. Retrieval becomes conditional on organizational status, not just semantic similarity.
That shift is less glamorous than a bigger context window and more annoying than a new embedding model. Unfortunately, boring infrastructure is often where enterprise value lives.
A good organizational AI system should be able to answer:
- What do we currently believe?
- What has been decided?
- What is merely proposed?
- What evidence supports the decision?
- What contradicts it?
- What replaced the earlier plan?
- What remains unknown but decision-relevant?
If the system cannot answer those questions, it does not have organizational memory. It has document access with confidence issues.
Conclusion: retrieval finds the text; epistemic memory finds the status
OIDA’s most important contribution is not that it defeats long context. It does not, at least not in the reported in-window pilots. The important contribution is sharper: it turns organizational epistemic state into something that can be represented, retrieved, tested, and falsified.
That is the right standard. Enterprise AI does not merely need more information. It needs a disciplined way to distinguish current commitments from old plans, evidence from hypotheses, contradictions from noise, and unresolved questions from absent data.
The paper’s evidence is preliminary, but its diagnostic frame is valuable. If full context is cheap and clean, use it. If ordinary RAG answers the real query set, use that. If the organization’s decisions live in a shifting mess of plans, contradictions, supersessions, and unanswered dependencies, then retrieval alone is probably not enough.
Not because retrieval is bad. Because relevance is not status.
And in organizations, status is often the whole point.
Cognaptus: Automate the Present, Incubate the Future.
-
Federico Bottino, Carlo Ferrero, Nicholas Dosio, and Pierfrancesco Beneventano, “Retrieval Is Not Enough: AI for Organizations Needs Epistemic Infrastructure,” arXiv:2604.11759v2, 2026. https://arxiv.org/html/2604.11759 ↩︎