A single continuous pipeline that reads whole documents attentively, compresses them against a fixed schema, makes every claim addressable, and reasons over the result with the exhaustiveness of a solver and the auditability of a ledger.
This document specifies a unified pipeline that converts unstructured documents into a machine addressable, provenance anchored, schema uniform layer of claims, and then reasons over that layer with a combination of language models and symbolic computation. The premise is simple to state and hard to build: an organization's documents contain a body of knowledge that is currently locked in prose, scattered across formats, and unreachable by anything other than a human reader willing to sit down and read all of it. This pipeline exists to unlock that knowledge without losing the two properties that make it trustworthy in the first place, namely where each fact came from and how confident anyone should be in it.
Most of the current generation of document AI tooling treats the problem as a retrieval and generation exercise. Chunk the documents, embed the chunks, retrieve the most similar ones to a query, and ask a language model to compose an answer from what came back. That approach is fast to build and genuinely useful for a narrow class of questions, specifically the ones that ask "find me the passage that says X." It is fundamentally unsuited to a different and more valuable class of questions, the ones that ask what the corpus as a whole implies, where it contradicts itself, and what has changed since the last time anyone looked. Those questions are not about finding a passage. They are about the relationships between many passages, and no amount of better retrieval fixes that, because the structure those questions depend on was never built in the first place.
This architecture takes a different starting position. It treats extraction as the first step rather than the whole job, and it treats the resulting claims as data that belongs in a graph, not as text that belongs in a vector index. Once claims live in a graph with typed relationships between them, a solver can check them for consistency, a query can traverse them for structure, and a human reviewer can ratify or reject individual edges without having to re-read the source material each time. The rest of this document walks through why that separation of concerns exists, how the two halves of the system hand off to each other, and what it actually looks like to run five specific classes of high value question against the resulting graph.
Summarizing documents with AI is now a commodity: every vendor can do it. What is rare, and what this architecture is built to produce, is a durable asset: a structured layer of claims, each traceable to its source, that your organization's own people have reviewed and stood behind. That accumulated judgment compounds over time. It is the one part of an AI system that a competitor cannot replicate simply by pointing a language model at the same documents.
Language models read, extract, translate, and draft. They handle ambiguity and prose well, but they are unreliable at consistency, counting, and exhaustive inference.
The graph store and solver hold, check, and infer over claims, and never hallucinate. They are unreliable at interpretation and ambiguity, which is why they need the neural layer.
People set evidence standards, ratify proposed edges, and own the final verdicts. This ratified judgment is the accumulating asset the whole system exists to build.
What do we collectively believe, and how confident should we be. Where do our sources contradict each other. What does a conclusion rest on, and is any of it now false. What has changed, and what does that change invalidate. What evidence would change our mind, and has it arrived. None of these are retrieval questions. All five are graph and reasoning questions, which is why chunk based search demos well and fails in production.
Every document heavy knowledge function, whether it sits in legal, finance, pharma, or government, runs into the same five walls eventually, usually in that order. The corpus is large and it keeps growing, so any solution that assumes a fixed, readable size is already wrong on day one. The important questions asked of that corpus are structural rather than local, meaning they are about relationships between many documents rather than the content of any single one, which is precisely the kind of question that a bigger context window does not solve, because a bigger window is still a window onto one moment in time rather than a persistent model of what the corpus as a whole contains.
The answers also need to be traceable to a specific source, not merely plausible, because in regulated and high stakes domains a claim without a citation is not a weaker claim, it is an unusable one that nobody will act on. And underneath all of this sits a quieter but equally damaging problem, which is that most tooling in this space answers a different question than the one actually being asked. A retrieval system answers "where is the passage that mentions this," while the analyst actually wants to know "what does the corpus as a whole believe, and how sure should we be." Those are not the same question, and no amount of speed or scale on the first one gets you closer to the second.
Five distinct failure modes fall out of this: a corpus problem where scale alone breaks naive approaches, a retrieval problem where the tooling answers local questions instead of global ones, a persistence problem where the same query run twice yields two different answers with no memory of which was right, a provenance problem where claims cannot be traced back to their source, and a replication problem where any competitor with access to the same documents can reproduce your output overnight because nothing about the process itself was proprietary. The table below breaks down exactly where five common approaches, from a standalone language model through to traditional keyword search, run into one or more of these walls, and why patching around them does not actually solve the underlying architecture problem.
Enterprise corpora run to tens of thousands of documents and grow daily. A million token context window holds roughly one large book. Bigger context windows move the problem. They do not solve it.
Naive retrieval answers "find me the passage." Real analytical questions are global: what are the fault lines, what does the corpus as a whole imply. Retrieval over chunks cannot see structure it never built.
Ask a model the same question twice and get two answers, with no record of which was right or what changed. An organization cannot build institutional knowledge on a process that forgets.
In law, pharma, finance, and government, a claim without a traceable source is not a weak claim. It is an unusable one. Retrofitting provenance into an embedding based system is genuinely hard.
Two firms can run extraction over the same filings and get similar claims. Only one has accumulated verdicts about which claims to trust. That judgment compounds, and it does not leak when the model changes.
| Approach | What it does | Why it fails for this problem class |
|---|---|---|
| Standalone LLM | Answers questions about text | Ephemeral and unauditable. No persistence. Cannot compute over structure, and forgets between runs. |
| Simple RAG | Retrieves passages, generates answers | Finds the passage but not what the corpus believes. Cannot see contradiction, dependency, or global structure. |
| Agentic loop | Plans, retrieves, iterates | Better at multi step retrieval, but still stateless across sessions and still cannot compute over structure. |
| Fine tuned model | Encodes domain knowledge in weights | Cannot cite sources, cannot be audited, and cannot be updated incrementally. |
| Traditional search | Exact match retrieval | Cannot handle paraphrase, cannot compute relations, and cannot synthesize. |
This is why so many AI pilots impress in a demo and stall in production. A demo asks "find me the passage," which any of these tools can do. Production asks "what does our organization believe, and why," which none of them are built to answer. The gap between those two questions is exactly the gap this architecture fills.
The pipeline is the integration of two independently developed systems, each of which was built to be good at something the other one is bad at. Neither system is sufficient on its own, and understanding why is the single most important idea in this entire document, because everything downstream of it, from the ontology design to the reasoning layer to the five standing queries, follows directly from this one architectural decision. Language models are extraordinary readers. They handle ambiguity, informal phrasing, contradiction between sources, and messy real world prose better than any symbolic system ever built, and they can draft, translate, and summarize at a speed no human team can match.
What language models are not good at, no matter how large they get or how well they are prompted, is exhaustive and reliable consistency checking. Ask a large model to verify that five hundred claims are mutually consistent and it will miss violations, invent ones that are not there, and give a different answer if you ask again tomorrow. This is not a solvable prompting problem, it is a structural property of how these models generate text, and no amount of scale changes that property in a way that would make it safe to rely on for exhaustive checking. A graph database and a constraint solver, on the other hand, are exactly the opposite. They will never hallucinate a relationship that is not in the data, and they will check every single constraint every single time with total consistency, but they are blind to meaning. A solver has no idea whether a sentence is true, only whether a formally stated claim is consistent with the other formally stated claims already in the graph.
The handoff between these two systems, then, is not a minor implementation detail bolted on afterward. It is the central design decision of the entire architecture. Language models read the messy prose and translate it into formally typed claims and relationships. The graph and solver take over from there, checking consistency, running inference, and surfacing contradictions that no single reading of any one document would ever reveal. Humans sit at the boundary between the two, reviewing the language model's proposed claims before they are allowed to affect the graph's formal state, which is what keeps the whole system auditable rather than merely fast. The rest of this document is essentially a detailed account of how that handoff actually works in practice, stage by stage.
Project 1 without Project 2 produces beautiful summaries that cannot be computed over. Project 2 without Project 1 produces a graph built from noisy extraction, with no human readable intermediate layer. The unification is not a convenience bolted on afterward. It is the necessary architecture: the domain is the configuration, and the substrate is the product.
Documents flow through eight distinct stages on their way from raw, unstructured files to a queryable, reasoned graph, and the diagram below lays out the full shape of that journey. The pipeline begins with acquisition, where source material of every format, from scanned PDFs to structured filings to internal memos, is ingested and normalized into a common representation the rest of the system can work with. From there it moves into compression, where a first pass model reduces the sheer volume of raw text down to the passages and statements that are actually candidates for extraction, because attempting to run the full extraction and reasoning pipeline over every sentence in a large corpus would be both computationally wasteful and analytically noisy.
After compression comes synthesis, where the surviving material is organized into coherent units before the extraction stage proper begins. Claim extraction is where language models do their most important work, converting prose into individually typed, source anchored statements that can be represented as nodes and edges rather than free text. Graph construction takes those extracted claims and assembles them into the actual persistent structure, checking for duplicate or conflicting entries as it goes, and this is also the point at which the human review loop first engages, since claims do not enter the graph as accepted fact until someone with domain authority has looked at them.
Reasoning is the stage where the solver and the graph query engine actually do their computation, running consistency checks, propagating implications, and flagging contradictions that were never visible from within any single source document. The final stage is the application surface, which is where all of this accumulated structure becomes usable by an actual person asking an actual question, whether that question comes through a dashboard, an API, or a natural language interface layered on top of the graph. Every one of the five standing queries introduced earlier in this document routes through this same eight stage pipeline, which is precisely why the architecture generalizes across so many different domains without requiring a rebuild each time.
The overview earlier in this document shows the shape of the pipeline at a level of abstraction suitable for an executive summary, eight named stages connected by arrows moving generally left to right. That level of detail is useful for understanding the architecture's overall philosophy, but it deliberately hides the messier reality of how the system actually behaves when it encounters ambiguous input, conflicting evidence, or a case that does not cleanly fit the expected schema. The two flowcharts in this section exist to remove that abstraction and show the real decision logic, including every conditional branch, every fallback path, and every point at which the system routes a decision to a human rather than resolving it automatically.
This distinction matters because a pipeline diagram that only shows the happy path gives a false impression of how deterministic and automatic the system is. In reality, a meaningful fraction of the decisions made while processing any real corpus involve some form of uncertainty, whether that is a language model expressing low confidence in an extracted claim, a newly proposed edge that conflicts with an existing one already in the graph, or a document that does not clearly belong to any of the ontology's frozen node types. Each of these situations has an explicit, designed for path in the flowcharts below, rather than being silently discarded or forced into the nearest available category, which is exactly the kind of silent failure mode that makes so many document AI systems untrustworthy in production even when they perform well in a demo.
Reading these flowcharts closely is the fastest way to understand what actually differentiates this architecture from a simpler retrieval and generation system, because the differentiation lives almost entirely in these branches and fallbacks rather than in the main line of the pipeline, which looks broadly similar to what many other systems do. Pay particular attention to the points where a human reviewer is inserted into the loop, since those insertion points are not incidental, they are the exact locations where the architecture deliberately trades some amount of automation for a large gain in trustworthiness and auditability, which is the trade this entire document argues is worth making for any high stakes application.
The two flowcharts above show the full decision logic of the pipeline in engineering detail, which is the right level of precision for a technical implementer but not necessarily the right level for someone deciding whether to sponsor this work. This section restates each of the eight stages in plain, executive facing language, focused less on the exact conditional logic and more on what each stage is actually for, what it produces, and why it needs to exist as a distinct step rather than being folded into the stage before or after it.
One useful way to read the cards below is as a chain of custody for a single fact. A statement about the world begins its life as a sentence somewhere in a source document, and by the time it reaches the application surface at the end of the pipeline, it has been compressed, extracted, formally typed, checked for consistency against everything else the system already believes, and in most cases explicitly reviewed by a person with the domain authority to ratify it. Each stage card below describes one link in that chain, what transforms at that link, and what would break if that link were skipped.
The practical value of walking through the stages this way is that it makes clear which parts of the pipeline are where cost and time actually get spent, and which parts are comparatively cheap once the earlier stages have done their job well. Acquisition and compression tend to be the most computationally intensive stages simply because of sheer document volume, while the reasoning and application stages are comparatively lightweight once a well formed graph already exists, which is an important consideration for anyone thinking about where to invest engineering effort first.
Documents rarely arrive clean. This stage detects chapter boundaries from embedded outlines where they exist, and falls back to a library of pattern detectors where they do not, before routing text free pages through OCR. Every output file is traceable to an exact page, which is what makes every later claim auditable.
Each chapter is read in its entirety, never chunked, and compressed into a fixed eight part structure covering the bottom line, the core claim, the argument chain, supporting evidence, counterarguments, key terms, its place in the book, and a read or skip verdict. The fixed schema is what makes chapters from entirely different books comparable to each other later.
Chapter level summaries are synthesized upward into a single whole book argument, giving a one page view of what an entire book is claiming without re-reading it.
Where a single book thesis looks inward, a syntopicon looks across many books in the same category, mapping where authors agree, where they contradict each other, and where the evidence is thin. This is the last output of the Reading Machine, and the handoff point into Project 2.
A language model reads each structured summary file and emits individually addressable claims, entities, concepts, and questions. Extraction runs against summaries rather than raw chapters, because the schema discipline from Stage 2 means every summary has the same predictable slots, which makes extraction dramatically more reliable.
Nodes and direct edges load first, then embedding similarity proposes candidate relations between claims, which a language model classifies as supporting, contradicting, refining, or assuming. Every proposed edge sits in a queue until a human ratifies or rejects it. Only ratified edges enter the belief layer.
With a trustworthy graph in place, the system can mine contradictions, compute which sets of claims are jointly defensible, apply defeasible rules that encode an organization's own evidence standards, and answer questions about what was believed at any point in time.
Everything upstream exists to make these final answers trustworthy: what does the organization believe, where is there disagreement, what does a conclusion depend on, what changed, and what would prove the organization wrong.
The graph that sits at the center of this architecture runs on a deliberately small vocabulary, six node types and eight edge types, and that smallness is not a limitation the team is working to overcome, it is a design decision the team is actively protecting. The vocabulary is frozen for a year at a time by policy, meaning that proposals to add a new node or edge type are batched, reviewed, and only ever incorporated on a fixed annual cycle rather than whenever an individual team feels a new use case demands one. This might look overly conservative next to systems that let their schema evolve continuously, but the conservatism is the point.
Every ontology in this problem domain that was allowed to grow quickly, adding a new node type whenever a new use case appeared plausible, died young, typically within eighteen months of its first real deployment. The failure mode is consistent across every case study the team examined: a rapidly growing schema eventually accumulates enough near duplicate and overlapping types that queries written against it stop returning consistent results, migrations become too risky to attempt, and the graph's internal consistency guarantees, which is the entire reason to use a graph in the first place, quietly erode until nobody fully trusts what the graph contains anymore.
A small, frozen vocabulary forces every new use case to be expressed in terms of the existing six node types and eight edge types, which sounds restrictive until you notice how much expressive range a well chosen small vocabulary actually has. Claims, sources, entities, events, evidence, and verdicts, connected by relationships like supports, contradicts, supersedes, and depends on, turn out to cover the overwhelming majority of analytical questions that come up across legal, financial, scientific, and regulatory domains. The domain specific part of any deployment lives in the schema used at the summary and extraction stage, not in the graph's core ontology, which is exactly the separation of concerns that lets this architecture generalize across so many industries without a rewrite for each one.
Claims are the center of gravity. Everything else exists to give a claim context: which book and chapter it came from, which entities and concepts it concerns, and which open question it addresses. Click a node type above for a worked example.
The root provenance anchor. One node per source document, holding title, author, edition, and ingestion date.
Example: a Book node for "The Wealth of Nations, 1776 edition" is the ancestor of every Chapter, and transitively every Claim, that traces back to it. Delete the book from the corpus and every downstream claim's provenance chain still resolves, because the edge is never broken, only marked superseded.
The unit the pipeline actually summarizes against the 8-slot schema. One node per chapter, section, or filing subsection.
Example: "Chapter 4: Of the Origin and Use of Money" becomes one Chapter node holding the compressed schema output, plus a made_in edge from every Claim extracted out of it back to this exact chapter, so a reader can jump straight to source.
An atomic, checkable assertion pulled out of the text. Not a sentence, not a paragraph: one proposition, extractable and independently verifiable.
Example: "Division of labor is limited by the extent of the market" is a single Claim node. It carries its own confidence score, its source chapter, and every supports, contradicts, refines, and assumes edge that touches it. This is the node type every standing query is actually answering questions about. It also carries a fixed depth rating and a fixed basis rating (see 5.1 below), which is how the graph tells apart a claim that was pulled off a page from one that took real reasoning to reach.
A real-world person, organization, place, or thing a claim is about. Deduplicated across every naming variant via entity resolution (see below).
Example: one Entity node for "Vereenigde Oostindische Compagnie" absorbs "VOC," "the Dutch East India Company," and "the Company" as same_as aliases, so a query about the VOC returns every claim regardless of which name the source document used.
An abstract idea, theory, or mechanism a claim invokes, distinct from a concrete Entity.
Example: "comparative advantage" is a Concept node. Dozens of Claims across unrelated books can carry an about edge to the same Concept node, which is what makes the syntopicon, the cross-book debate map, possible in the first place.
A standing, open question the corpus is being read to answer. Claims attach to it via addresses edges as evidence accumulates.
Example: "Does free trade raise wages for unskilled labor in the near term?" is a persistent Question node. As new documents are ingested, new Claims addressing it get linked in, and the aggregate confidence the graph reports for that question can shift, without anyone re-reading the whole corpus.
"VOC," "the Dutch East India Company," "the Company," and "Vereenigde Oostindische Compagnie" are one entity under four names across ten thousand documents. Candidate matches come from string similarity and embeddings, a model adjudicates ambiguous pairs, and a human ratifies before an alias becomes permanent. This unglamorous work is what makes every later query actually correct.
Every node and edge carries two timestamps: when the source document was written, and when the system ingested it. This is cheap to add at construction time and effectively impossible to reconstruct later, and it is what enables a question like what did we believe before we read this document, versus what we believe now.
Ratification answers one question: did a qualified human confirm this claim and its edges. It deliberately does not answer a second, different question: how much reasoning did it take to arrive at this claim, and how deep does its support actually run. Two ratified claims can sit in the graph as formally identical, one lifted almost verbatim off a single page, the other only reachable by synthesizing four sources that individually said nothing of the kind, and today the ontology has no way to tell them apart once both are marked ratified. That gap matters most exactly where the standing queries matter most: knowing what a conclusion rests on is a much better answer when it also says how solid each piece of that foundation actually is.
The fix is not a new node type. It is two small, frozen attributes carried on every Claim node, populated at the same adjudication step where the model already classifies supports, contradicts, refines, or assumes. A depth rating records whether the claim was pulled directly off the page, followed from a single stated premise, or only reachable by synthesizing multiple sources, the same distinction DOK draws between recall, reasoning with a given fact, and reasoning across facts nobody had connected before. A basis rating records how integrated the claim is with everything else the graph already believes, whether it stands alone, echoes something already ratified, or is now load-bearing for other ratified claims, the same distinction SOLO draws between an isolated fact and a fact folded into a coherent structure. Both ratings are fixed, five-level rubrics decided once and frozen alongside the six node types and eight edge types, never inferred loosely by the model on the fly.
Every section up to this point has used "confidence," "evidence strength," and "weight" as if they already compose in some agreed way, and they do not. A Claim node today carries a confidence score the same way it carries a title: as a value sitting on the node, not as the output of any defined operation. There is no answer yet to what happens to that number when a second, independent claim arrives to support it; no answer to what a claim with zero incoming edges should report; no answer to how far a ratified contradiction should be allowed to travel once it lands. The graph can already tell a reviewer whether two formally typed claims are logically consistent, which is the solver's job from section 06, but consistency checking and uncertainty propagation are different capabilities, and this document has so far only built the first one. This section decides all of it: what a confidence value formally is, how it sits next to the depth and basis ratings already frozen in 5.1, what each uncertainty-bearing edge type does to the numbers on either side of it, how a ratified contradiction gets resolved, and what a calibrated version of this whole apparatus would even mean in practice.
Three candidate formalisms were evaluated, each held against this architecture's actual shape rather than against a textbook comparison of belief calculi in the abstract: subjective Bayesian probability, Dempster-Shafer belief functions, and imprecise probability expressed as confidence intervals. The comparison below evaluates each one on four questions that matter specifically here — composition across supports chains, behavior on a claim with no incoming evidence, representation of a deliberately hedged claim, and legibility to the human reviewer who has to ratify what the number means — and the recommendation that follows is a considered hybrid, not a clean winner, because no single one of the three does well on all four at once.
| Formalism | Composition across supports chains | Zero-evidence claim | Hedged / qualified claim | Legible to a non-technical ratifier |
|---|---|---|---|---|
| Subjective Bayesian | Clean and well understood: independent corroboration multiplies likelihood ratios, so two supporting claims genuinely move belief further than one. But the chain only stays honest if independence actually holds, and two claims drawn from the same underlying source are not independent evidence even when the graph draws them as two separate supports edges. | Must be assigned some prior, commonly 0.5 or a domain default. That default is indistinguishable, once stored, from "the evidence was actually balanced," which erases exactly the distinction the self-critique section already flags as a needed extraction fallback. | Forces the hedge into a single point value somewhere between confident-true and confident-false, which is precisely the flattening the extraction blind spots failure mode describes: the qualification that made the original statement defensible does not survive being represented as one number. | Highest of the three. "Sixty percent likely to be true" is a sentence most reviewers already have working intuition for, with no new vocabulary required at ratification time. |
| Dempster-Shafer | Composes via Dempster's combination rule, which handles independent corroborating sources reasonably well but becomes both computationally heavier and philosophically contestable under high conflict, exactly the case that matters most here, a ratified contradiction between two credible sources. | Represented natively and correctly: a claim with no incoming edges gets belief mass 0, disbelief mass 0, and unknown mass 1, which is a first class, honestly labeled state rather than a borrowed default. | Represented natively: a hedged claim can carry high unknown mass alongside modest belief and disbelief mass, distinguishing "we don't know" from "the evidence is evenly split," which is the exact distinction a single probability number structurally cannot hold. | Weakest of the three. Explaining belief mass, disbelief mass, and unknown mass as three separate quantities to a reviewer mid-ratification is a real training cost, and Dempster's combination rule under conflict produces results that have a documented history of confusing even technical audiences. |
| Imprecise probability (intervals) | Interval width can only grow or hold steady as more sources are combined honestly under the standard bounding rules; it never manufactures false precision, which fits a graph whose evidence arrives in ratified batches rather than as a single continuous stream. The cost is that intervals widen quickly under naive combination and need a deliberate tightening rule to stay useful after more than a few supports edges. | Represented natively as the maximally wide interval, [0, 1], which states plainly that nothing is known without borrowing a point value from anywhere. | Represented reasonably well as a wide interval, though it cannot distinguish "wide because unknown" from "wide because the source explicitly hedged," collapsing two distinct situations that Dempster-Shafer keeps separate. | Middling. "Somewhere between 40 and 75 percent" is intuitive on first hearing, but reviewers reliably want to collapse it to a midpoint anyway, which quietly reintroduces the point-estimate problem the interval was chosen to avoid. |
The chosen calculus is Dempster-Shafer at the Claim node level, collapsed to a single reported number only at the point where a Question node surfaces an aggregate to a human, per Q1. Every Claim node carries three masses — belief, disbelief, unknown — computed from its incoming supports and contradicts edges. A Question node, which exists specifically to answer "what do we collectively believe" across many claims, is where that three-valued state is finally reduced to something a person reads as a single confidence figure, alongside its unknown mass reported as a visible caveat rather than discarded.
The case for this over plain Bayesian probability rests entirely on one requirement this document already commits to elsewhere: the self-critique section names an explicit "unclassifiable or qualified" claim type as a required containment for extraction blind spots, precisely so that low-confidence extractions get flagged rather than silently smoothed over. A single probability number has no honest way to hold that state; every claim must resolve to some point on a line from false to true, and "we don't actually know" has no address on that line other than an arbitrary midpoint that looks identical to "the evidence is genuinely split." Dempster-Shafer's unknown mass is the only one of the three formalisms that gives the "unclassifiable or qualified" claim type a real mathematical home instead of a label with no computational consequence.
The case against plain intervals is narrower but still decisive for this graph specifically: intervals communicate range well but conflate two situations this system needs to tell apart, a claim nobody has evidenced yet and a claim whose source was explicitly, deliberately hedged. Dempster-Shafer keeps those as different combinations of belief, disbelief, and unknown mass; an interval just reports both as "wide."
The cost being paid for this is real and is stated plainly rather than waved off: Dempster-Shafer is the least legible of the three formalisms to the non-technical reviewer standing at the ratification gate described in section 09, and its combination rule behaves in ways that are known to be counterintuitive under high conflict, which is exactly the condition a ratified contradiction produces. The mitigation is architectural, not mathematical: the three-mass representation never needs to be shown to a human at claim-ratification time at all. What a reviewer sees and adjudicates is still the same supports or contradicts edge proposal described in 4.1, in ordinary language; the belief-mass bookkeeping happens underneath that decision, invisible until a Question node collapses it into a single reported figure with a caveat, which is the one place a human actually needs to read an aggregate number rather than adjudicate an edge.
5.1 is explicit, twice, that depth and basis are "a triage signal, not a trust signal," and that boundary is respected here rather than crossed. Depth and basis ratings do not feed into the Dempster-Shafer calculation as inputs. A multi-source-synthesis claim does not receive a wider default unknown mass than a recall-depth claim before any edges are evaluated; a load-bearing claim does not receive an inflated belief mass by virtue of what it is load-bearing for. The two systems stay formally parallel: depth and basis route a claim to the right reviewer and the right level of scrutiny at ratification time, while belief, disbelief, and unknown mass are computed strictly from what has actually been ratified onto the claim's supports and contradicts edges.
The reasoning for keeping them parallel rather than merged is that depth and basis measure something about how a claim was arrived at and how integrated it now is with everything else, while confidence is meant to measure something about the current state of the evidence for or against it, and those two things can and regularly do diverge. A recall-depth claim, a fact pulled directly off a single page, can carry very high confidence, because a well-sourced direct statement corroborated by nothing else can still be almost entirely believed. A multi-source-synthesis claim, reasoned across four documents that individually said nothing of the kind, can carry genuinely low confidence precisely because that synthesis is exactly the kind of reasoning most likely to have missed a fifth source that would have overturned it. Folding depth and basis into the confidence calculation would make the number quietly represent two different things at once, effort expended and belief warranted, and a reviewer reading a single figure would have no way to tell which one moved it.
This does not mean the two systems are blind to each other; the flow caption already in 5.1 notes that basis rating sharpens the "what would change our mind" query by prioritizing high-basis claims for monitoring, since a collapse there propagates furthest. That is a genuine, useful interaction, but it is a routing interaction, not a mathematical one: basis rating tells the system which claims' confidence values are worth watching most closely for change, it never adjusts the value itself.
Three of the eight edge types carry no uncertainty and are excluded here without further comment: same_as merges identity, made_in and about/addresses record provenance, and none of the three ever touches belief, disbelief, or unknown mass. The remaining five are where the actual arithmetic lives.
supports. A single ratified supports edge updates the target claim's belief mass by combining the source claim's own belief mass into the target under Dempster's combination rule, discounted by the source claim's residual unknown mass, so a source that is itself only weakly believed cannot lend the target more certainty than it actually has. Multiple independent supports edges combine the same way, applied pairwise, and each additional independent source narrows unknown mass further, which is the intended behavior: real corroboration should make the graph more certain, not just more populated. The case that has to be caught before that combination runs is two "independent" supporting claims that trace back to the same root source through the provenance chain, one made_in edge or one shared upstream supports chain apart. When the graph detects that shared ancestry, the second edge is combined at a steeply discounted weight rather than treated as fresh corroboration, because two restatements of one source are one piece of evidence wearing two edges, and letting them compound as if independent is exactly the failure mode that makes a thin, single-sourced claim look falsely well-supported.
contradicts. A ratified contradicts edge computes a conflict quantity between the two claims from their respective belief masses, the standard Dempster-Shafer measure of how much probability mass the two claims' evidence assigns to mutually exclusive outcomes. That conflict quantity is reported and stored on the edge itself. What happens to each claim's own belief and disbelief mass as a result of that conflict is not decided here; it is decided by whichever conflict resolution policy from the menu below the deployment has configured, because the same conflict number legitimately produces different downstream mass adjustments depending on that choice.
refines. A refines edge is structurally different from a supports edge and must never be scored as one. Where a supporting claim corroborates a target from the outside, a refining claim narrows or adds precision to a target that both claims already agree on, and treating the arrival of a more precise version as new disagreement would penalize the graph for getting more specific. The operator therefore does not touch belief or disbelief mass at all; it only permits the target claim's stated content to be replaced by the more precise formulation while carrying the original mass forward unchanged. A claim refined from "the clause was likely still in force" to "the clause was in force through March 2020, per the renewal amendment's stated term" keeps whatever belief mass it already had; refinement spends no confidence to buy precision.
assumes. Every claim that carries an assumes edge into a given premise is watching that premise's mass, not just its ratified status. A drop in the premise's belief mass, from a newly ratified contradiction or from a downstream conflict-policy adjustment, propagates automatically to every claim assuming it, discounted by however directly that claim depends on the premise, rather than waiting for a human to notice and manually re-touch each dependent claim. The moment a premise is superseded or newly contradicted, two things happen at once rather than one: the existing "flagged for review" behavior still fires, putting every dependent claim in front of a reviewer, and the dependent claims' confidence figures also auto-adjust immediately, pending that re-review, rather than sitting at their old, now-unjustified values until someone gets to the queue. The reasoning for doing both rather than either alone is that a flag with no numeric consequence is easy to deprioritize when the backlog is long, and a silent numeric adjustment with no flag is easy for the auto-adjustment itself to be wrong about; together, the dependent claim's displayed number is honest in the interim and a human still gets the final say.
supersedes. A superseded claim leaves the live query surface entirely: Q1 and Q3 no longer count its mass toward any aggregate or dependency check, and a claim that assumed it now assumes nothing until re-pointed at whatever replaced it. The claim itself is not deleted. It moves to a decayed, still-queryable state addressable only by an explicit "what did we believe before" query, its original masses preserved exactly as they were ratified rather than zeroed out, because the historical fact of what the organization believed and when is itself sometimes the thing being asked about, and overwriting it would destroy an audit trail this document elsewhere treats as non-negotiable.
The conflict quantity computed on a ratified contradicts edge has to resolve into an actual adjustment to both claims' belief and disbelief mass, and this document deliberately does not pick one universal rule for how, because the correct answer plainly differs by domain. Three policies are specified as genuine, equally supported alternatives, selected once per deployment rather than per claim.
| Policy | Mechanism | Fits |
|---|---|---|
| Symmetric penalty | Both claims lose belief mass proportional to the conflict quantity, converting it to shared unknown mass on both sides. Neither claim is treated as more credible by default. | Domains where the graph has no principled basis for preferring one source over another and adjudication should start from a level field, such as competing legal interpretations of ambiguous statutory language. |
| Dominant-claim-wins | The claim with the higher pre-conflict belief mass keeps its mass unchanged; the weaker claim is quarantined, its mass frozen and excluded from live aggregation, pending explicit human review. | Domains with an established evidentiary hierarchy the organization already trusts, such as a pharmacovigilance graph where a phase 3 trial result should not be knocked down to parity by a single case report simply because both are now formally in conflict. |
| Irreducible uncertainty inheritance | Neither claim's mass is adjusted directly. Instead every claim that assumes either one inherits an explicit, visible "unresolved conflict" flag alongside its own mass, so the disagreement propagates as a labeled condition rather than as a silent number change on either side. | Domains where prematurely picking a side would itself be the error, such as a finance graph tracking two credible but conflicting analyst theses where the honest state is "we don't yet know which is right," and collapsing that into one winner would misrepresent the organization's actual epistemic position. |
The document's own example domains argue for different defaults precisely because their cost of being wrong about a contradiction differs: legal and pharmacovigilance settings can reasonably prefer dominant-claim-wins, where an established hierarchy exists and quarantining the weaker claim protects against a false demotion of well-supported prior work; a finance graph tracking live, contested theses is a more natural fit for irreducible uncertainty inheritance, where the cost of falsely resolving a disagreement outweighs the cost of carrying it forward explicitly. No single policy is designated the platform default; the deployment configuration decides, and the choice is itself a ratified, logged decision rather than a silent engineering default.
Q1 stops being a structural traversal and becomes an actual aggregation: every claim addressing a given Question node contributes its belief and disbelief mass, pooled under Dempster's combination rule exactly as two supporting claims are pooled at the individual-claim level, and the Question node reports the resulting figure alongside its own residual unknown mass as a visible caveat, plus a ranked list of which specific claims contributed the most mass to the result, so a reviewer reading "72 percent, with meaningful unknown mass remaining" can also see exactly which three claims are carrying that 72 percent rather than treating it as an opaque summary statistic.
Q3 gains a genuinely new capability beyond traversing assumes edges downward to check for contradiction or supersession: a ranked sensitivity output. For any conclusion, the graph can now report which upstream claims would move that conclusion's confidence the most if their own mass were revised, computed by re-running the assumes-propagation operator against a hypothetically adjusted mass for each upstream claim in turn and measuring the resulting delta at the conclusion. This turns "what does this rest on" from a list into a priority order: a reviewer deciding where to spend re-verification effort can now see that revising claim A would move the conclusion three times as much as revising claim B, even though both are formally assumed premises, which is exactly the information a flat dependency list cannot provide.
Q5 gains an actual quantitative falsification threshold rather than a qualitative "watch for this" flag. Each belief's falsification condition is now paired with a numeric trigger: how much new contradicting belief mass, ratified and combined under the conflict policy in force, would need to arrive before the claim's confidence crosses a reconsideration point set in advance. That threshold is not computed by the system; it is set by whoever ratifies the claim in the first place, at the same adjudication step described in section 09, because the correct threshold is a domain judgment about how much doubt is tolerable before a belief needs re-examination, not a mathematical property the graph can derive on its own. Once set, the check itself is mechanical: every newly ratified contradicting claim recomputes the target's disbelief mass, compares it against the stored threshold, and surfaces the claim for reconsideration automatically the moment the threshold is crossed, rather than waiting for a scheduled review or a person happening to notice.
None of the preceding machinery is worth anything if the numbers it produces are not calibrated, and calibration has a specific, checkable meaning here rather than being a synonym for "seems about right." A calibrated confidence figure means that of every set of claims the graph reports at roughly a given confidence level, that same proportion should actually hold up over a defined horizon: of all claims the Question node reports around 80 percent belief mass, roughly 80 percent of them should later prove correct, remain unchallenged, or survive their stated falsification threshold without being crossed, rather than the number simply reflecting how confident the extraction and ratification process felt in the moment.
Checking this requires outcomes to check against, which this system does not have on day one, and the calibration discipline is honest about that rather than presenting a checklist that looks available immediately. Two concrete mechanisms are specified for once the graph has run long enough to accumulate them. The first is a held-out set of claims with known, independently verifiable outcomes, scored against the graph's own reported confidence at the time the outcome became known, producing an actual calibration curve rather than an impression of one. The second is a scheduled retrospective, run on a fixed interval, specifically on the set of high-confidence claims that were later superseded or newly contradicted, asking in each case whether the original confidence figure was defensible given what was known then or whether the ratification process itself was systematically overconfident in a way worth correcting.
Both mechanisms depend on accumulated history that only exists once the pipeline has been running for a while, which ties calibration directly to the roadmap's phased structure in section 11 rather than treating it as a feature available at launch. Phase 3 is where the claim layer and ratification first exist in a form that produces outcomes worth checking; a calibration retrospective is realistically a Phase 4 activity, run against a graph that Phase 3 has already populated with enough ratified history to make the check meaningful, and presenting it any earlier would be asking the organization to trust a calibration claim the system has not yet had time to earn.
Every claim in this graph carries a rigorous chain of custody back to its source: a made_in edge to an exact chapter, a page anchor, two timestamps recording when the source was written and when it was ingested. What the architecture has, until now, tracked far less carefully is the provenance of its own construction — which model extracted a given claim, under which prompt version, from which ingestion run, ratified by which specific human. Over a lifespan measured in years rather than months, that gap stops being theoretical. Claims will have been extracted by model versions that no longer exist, ratified by reviewers who have since left the organization, and sourced from documents whose reliability wasn't knowable at ingestion but becomes clear only in hindsight. Enterprise corpora now routinely include documents a language model itself drafted, and if that isn't detected, the graph can end up extracting claims from model output and having them ratified as though they were primary evidence: a closed epistemic loop that looks rigorous but isn't.
This section specifies how the graph monitors the health of its own substrate, using the same frozen-attribute discipline section 05 already established rather than reaching for new vocabulary. Almost everything below is a new attribute on a node or edge type that already exists. One piece is not, and it is named plainly rather than hedged around.
Each of these lives on a Book node, a Claim node, or the made_in edge that already connects them — the same three types this document has used for provenance since section 05. Click a signal above for what it carries and why it belongs there.
A reputation score, a source-class label (peer-reviewed, vendor whitepaper, internal memo, leaked/unverified, LLM-suspected), and a rolling track-record statistic, seeded at ingestion and updated as claims made_in that source are later superseded or contradicted at a rate compared against the corpus-wide typical rate for its class.
A peer-reviewed paper, a vendor whitepaper, a leaked memo, and an LLM-generated summary do not start at the same default. Reputation feeds into confidence as one input the calculus in 5.2 already combines with the rest — visible to the ratifying reviewer as a trend line, never applied as a silent multiplier before a human sees the claim. Full automation here risks quietly encoding "trust the sources we already trusted" as a self-reinforcing loop, which is itself a named risk, not a side effect to overlook.
Model name and version, prompt/schema version, ingestion-run identifier, and ratifying reviewer identity, populated automatically at extraction. Cheap to capture at construction time, effectively impossible to reconstruct later — the same justification section 05 already gives for bi-temporal timestamps.
Enables "show every claim extracted by model version 2.3 that hasn't been re-verified since the model changed," and "isolate every claim ratified by a reviewer who has since left, for a re-verification sweep." Neither triggers automatic re-verification: both populate a prioritized human review queue, ranked by basis rating and downstream dependency, because the ratification bottleneck named in 7.2 does not scale with a second, unbounded source of review demand stacked on top of the first.
An llm_suspected flag and confidence band on Book, set from stylistic and statistical detection signals, explicit metadata where available, and provenance-chain tracing against this system's own prior exports — combined the way entity resolution already combines weak signals before a human adjudicates, never resolved to a verdict automatically.
A claim from a flagged source starts with a wider uncertainty band and a lower default reputation, and is explicitly barred from counting as independent corroboration for another claim already sourced from a different LLM-generated document: two model outputs agreeing with each other is not independent evidence. A document tracing back to this system's own prior output is flagged self-referential, a stricter category, closing the loop before it can close on itself.
A decay rate attached at the Concept or Question a claim addresses, not authored per claim: market share, personnel, and regulatory status decay fast; a mathematical proof or a settled historical date effectively doesn't. A Claim inherits its rate via the existing about/addresses edges.
An expired claim isn't silently discounted; it's flagged for review and surfaced in the health dashboard (7.3), with a computed effective confidence shown as a visible caveat rather than folded into a headline number. Propagation reuses the assumes-edge logic that already handles supersession and contradiction — decay becomes a third trigger condition on machinery that already exists, not a new reasoning path.
A vendor whitepaper on mid-cap industrial margins, ingested two years ago: three Claims extracted by a now-retired model, ratified by a reviewer who has since left, one of them now an assumed premise under a live investment thesis. A retroactive stylistic sweep flags the whitepaper as LLM-suspected.
The dashboard's model-drift metric had already listed these claims as unverified since retirement; the departed-reviewer query surfaces the same three independently; the new contamination flag widens their uncertainty band and blocks the load-bearing claim from serving as corroboration for any other now-flagged vendor source. Because something live depends on it, that claim jumps to the top of the re-verification queue, ahead of its two inert siblings — surfaced to a senior reviewer with the full picture attached, never auto-resolved.
One piece here does not fit as an attribute. An Extraction-run node — the record of one ingestion pass: the model and prompt versions pinned to it, the documents it covered, who supervised it — is not a fact about any single claim's origin, it is a fact about a batch shared by potentially thousands of claims at once, and it needs to be queried as a thing in its own right ("which run does this now-anomalous cluster trace back to, and what else came out of it"). Storing that redundantly on every made_in edge from the run works today and breaks the moment that query needs to run in the other direction. By the same test this document already applies to justify its existing six node types — something is a node when it is reasoned about as a first-class thing, not merely referenced — this is a genuine new node type. It goes on the fixed annual ontology docket described in section 05, not shipped ad hoc alongside the attributes above.
A graph that tracks where every claim came from but not who or what built the graph itself is only half auditable. This section closes that gap: every claim now carries a record of the model, prompt, and reviewer behind it, every source carries a reputation that moves with its track record, and suspected AI-generated sources are barred from corroborating each other. None of this required touching the frozen ontology. The one piece that does — a record of each ingestion run as its own trackable object — is deferred to the annual review, on schedule, not rushed in.
Language models are strong at reading and weak at exhaustive consistency, and this single sentence is worth sitting with for a moment because so much of the industry's current disappointment with AI in high stakes settings traces back to ignoring exactly this asymmetry. A model can read a contract, a research paper, or a filing with genuine comprehension of nuance, tone, and implicit meaning that would take a human analyst real time and expertise to match. Ask that same model to check five hundred formally stated claims against each other for logical consistency, however, and its performance degrades in ways that are neither predictable nor improvable through better prompting, because exhaustive symbolic consistency checking is simply not the kind of task a next token predictor is built to do reliably.
Solvers occupy the exact opposite position on this spectrum. A constraint solver or graph reasoning engine will check every single constraint in a system with total, repeatable consistency, and it will never once hallucinate a relationship that does not exist in the underlying data, which is a guarantee no language model can currently offer at any scale. The cost of that guarantee is that a solver is completely blind to meaning. It has no way of knowing whether a formally typed claim like "Company A acquired Company B in Q3" is actually true in the world, only whether that claim, once represented as a formal statement, is logically consistent with everything else already in the graph.
The architecture's central design principle is to route each task to whichever of these two layers is actually good at it, rather than asking either one to do work it is structurally unsuited for. Reading, interpreting ambiguity, and drafting stay with the language model. Exhaustive checking, inference over structure, and consistency guarantees stay with the solver and the graph. The interesting engineering work, and the reason this is harder to build than either half alone, lives entirely in the interface between the two: how a model's interpretation gets translated into a formal claim the solver can reason over, and how the solver's findings get translated back into language a human reviewer can act on without needing to read raw graph output.
Natural language inference runs over embedding similar claim pairs corpus wide, producing a standing disagreement ledger per category. This is the cheapest neuro-symbolic win, and it feeds directly into syntopicons.
Claims become arguments and contradictions become attacks in a Dung style framework, which computes which positions are jointly defensible. This turns "who is right" into a computed answer, conditional on which evidence you accept.
Answer set programming encodes an organization's own evidence standards, such as trusting archival records over narrative accounts, and computes what those standards imply about open contradictions, retracting conclusions when new evidence defeats old claims.
Every genuinely high value question this architecture is built to answer reduces to one of five standing queries, and understanding the split between them is the fastest way to understand what makes this system different from a document search tool. Two of these five are fundamentally about what the corpus itself says: what do the source documents collectively assert, and where do those sources contradict one another. These are already harder questions than most retrieval systems can answer well, because answering them requires seeing structure across the entire corpus rather than finding the single most relevant passage, but they are still, in an important sense, questions about the input material rather than questions about the organization's own conclusions.
The remaining three standing queries are about something categorically different: what the organization itself has concluded, and how that conclusion holds up over time. What does a given conclusion actually rest on, and has any part of that foundation since become false. What has changed since the last time anyone looked, and what does that change invalidate downstream. What evidence would be sufficient to change the organization's mind about something it currently believes, and has that evidence already arrived without anyone noticing. These questions cannot be answered by looking at the source documents alone, because they depend on a persistent record of what was previously concluded and why, which is exactly the kind of state a stateless retrieval system has no way to maintain.
That second group of three is what separates a genuine instrument of institutional judgment from a research tool that merely helps someone read faster. A research tool answers questions about the input. An instrument of judgment answers questions about the organization's own accumulated conclusions, tracks how those conclusions were reached, and flags when new evidence undermines something the organization currently relies on. Building a system that can answer all five of these queries with genuine reliability, rather than three of them well and two of them by coincidence, is the actual engineering target this entire architecture is built around, and the remainder of this document works through exactly how each of the five gets answered in practice.
A system that only tells you what documents say is a search engine. A system that also tells you what your own organization has concluded, what those conclusions depend on, and what would prove them wrong, is a decision system. That last mile is where nearly all of the business value sits.
Rather than argue abstractly that other approaches fall short, this section takes one specific standing query, "where do our sources contradict each other," and traces exactly what happens when that question is put to each of five common approaches in turn: a standalone large language model, a simple retrieval augmented generation system, an agentic loop that plans and iterates over multiple retrieval steps, a fine-tuned model with domain knowledge baked into its weights, and traditional keyword based search. The goal of walking through all five side by side is to make the failure points concrete and specific rather than leaving them as a vague sense that "this system isn't quite right for enterprise use."
What the comparison reveals is that all five approaches stop at a meaningfully earlier point in the reasoning process than the unified pipeline described in this document, and critically, each one stops at a different point for a different reason. A standalone model stops almost immediately because it has no access to the corpus at all beyond what fits in its context window, and no memory of what it concluded the last time this question was asked. A simple retrieval system finds passages that are topically similar to the question but has no representation of the corpus's global structure, so it cannot see a contradiction between two documents unless both happen to be retrieved for the same query, which is closer to luck than to a reliable answer.
An agentic loop improves on simple retrieval by iterating and gathering more context across multiple steps, but it remains stateless between sessions and still has no formal structure to reason over, meaning it is doing multiple rounds of the same fundamentally local search rather than actually computing over relationships. A fine-tuned model bakes some domain knowledge into its weights but cannot cite sources for what it produces and cannot be audited or updated incrementally as new documents arrive. Traditional search can find exact string matches but has no way to compute a relationship between two claims that use different words to say contradictory things. The unified pipeline is the only one of the five that actually builds a persistent, queryable structure capable of answering the contradiction question directly, rather than approximating an answer to a different, easier question.
The comparison above holds five other approaches to a standard this architecture is not automatically exempt from. A frozen ontology, a human ratification step, and a similarity-based contradiction detector are all real engineering commitments, and each one buys a capability at a real cost. The six failure modes below are not hypothetical edge cases raised for the sake of appearing balanced; they are the specific places in the eight stage pipeline where the architecture's own design choices are most likely to bite, named at the stage where they originate rather than left as a general disclaimer.
The ontology is deliberately frozen so that claims stay comparable across the whole corpus, but a real organization's questions change faster than a one page schema is designed to. Six months in, a category the ontology never anticipated will show up in the source material, and the honest options are to force fit it into an existing slot, silently distorting every downstream count and comparison, or to leave it unclassified, which quietly shrinks the graph's coverage without anyone noticing.
Categorical extraction assumes a claim can be cleanly stated, but hedged, ironic, conditional, or context-dependent statements resist exactly that. A source that says a result "might" hold "under certain conditions" gets flattened into a flat assertion the moment it is forced into a claim slot, and the nuance that made the original statement defensible is exactly what gets lost.
Human ratification is what gives the ledger its authority, but review throughput does not scale with ingestion rate. The moment document volume outpaces the organization's willingness to read and adjudicate, the "ratified" graph starts to mean "ratified, eventually, for the claims someone got to," and the queue itself becomes a second, unratified layer of judgment about what matters.
Contradiction detection here runs on embedding similarity, which is a proxy for logical relation, not the relation itself. Two claims phrased differently about the same underlying fact can score as dissimilar and get missed as a genuine contradiction, while two claims that merely use similar vocabulary about unrelated things can score as similar and get flagged as a false one, costing an adjudicator's attention on nothing.
Every ratified verdict encodes the judgment of whoever ratified it, and the graph presents that judgment back with the same visual confidence regardless of whether one person decided it alone or a whole team debated it. At scale this quietly concentrates epistemic authority in a small number of reviewers, and their blind spots become the organization's blind spots, now with a ledger that makes them look settled.
The provenance discipline runs deep from source to claim, but has almost nothing, absent an epidemiology layer, about the provenance of the graph's own construction: which model extracted a claim, under which prompt version, ratified by whom. Over a multi-year lifespan, claims accumulate that were extracted by retired model versions, ratified by reviewers no longer at the organization, and sourced from documents whose reliability wasn't known at ingestion. Enterprise corpora now routinely include documents a language model itself drafted, and if that source isn't flagged, the graph risks extracting claims from it and ratifying them as though they were primary evidence, a closed epistemic loop that carries every visual marker of rigor while resting on nothing independent. This is a distinct failure from authority concentration below: a perfectly staffed, dissent-preserving review process still fails silently if the substrate it's judging isn't clean.
The belief calculus in 5.2 turns a claim's confidence into a real computed figure, and a computed figure looks more authoritative than an estimate, which is exactly the problem. A number derived from sparse, ratification-gated evidence, two supporting claims and a contradiction, say, is still built on a thin evidentiary base, but "72 percent" reads to a human decision maker as a precise, well-founded measurement rather than as the honest output of a small amount of formally combined evidence. This is a direct cost of building the calculus at all, not a separate risk that could have been avoided by building it more carefully.
The five standing queries in section 07 and the seven failure modes in 7.2 both assume the graph itself is sound. This dashboard exists to check that assumption continuously, rather than discovering its failure the hard way, inside a query result someone was already relying on. It is surfaced as a first class output alongside the five standing queries, not confined to a separate admin view a busy reviewer can reasonably ignore.
Every other dashboard in this system answers questions about what the organization believes. This one answers a prior question: can the organization trust the mechanism that produced those beliefs in the first place. It is the difference between an instrument that reports its own conclusions confidently and one that also reports, honestly, how much scrutiny its own foundations have had.
One of the more counterintuitive claims in this document is that the exact same eight stage pipeline, with the exact same six node types and eight edge types underneath it, can be deployed with genuine effectiveness across domains as different as pharmaceutical regulatory review, financial due diligence, legal discovery, and government policy analysis, without a structural rewrite for each one. Every application built on this architecture is, in a very literal sense, the identical pipeline running underneath, with two things changed: the schema used to interpret documents at the summary and extraction stage, and the specific set of standing queries exposed at the application layer for that domain's users.
This works because the schema, not the graph's core ontology, is where all of the domain specific knowledge actually lives. A pharmaceutical deployment's schema teaches the extraction stage to recognize dosages, adverse events, and trial phases as meaningful entities. A financial due diligence deployment's schema teaches it to recognize covenants, liabilities, and counterparties instead. In both cases, once those domain concepts are extracted, they still get represented using the same six frozen node types and eight frozen edge types described earlier in this document, which is what allows the solver and graph query engine underneath to remain completely unchanged between deployments.
The schema, in other words, is the configuration surface, the place where a new deployment is actually customized for its domain, and it is comparatively cheap and fast to build relative to the graph reasoning engine underneath it, which never needs to change at all. The graph query, meanwhile, is the product, in the sense that the actual value delivered to any given customer is the specific set of standing queries their domain cares about, running against a graph that has accumulated their organization's own ratified judgment over time. This is also why the moat described elsewhere in this document, the accumulated verdicts an organization builds up through use, does not transfer between domains or competitors even though the underlying pipeline is identical everywhere it is deployed.
Depositions and trial reports, schema built around issue tags, standing queries built around contradiction and dependency across testimony.
Trial reports and filings, schema built around PICO structure, standing queries built around what would falsify an efficacy claim.
Filings and analyst reports, schema built around thesis assumptions, standing queries built around dependency and change propagation.
None of this requires rebuilding the pipeline for a new domain. It requires writing a new schema for what a summary should capture, and choosing which of the five standing queries matter most for that business. Everything else, acquisition, graph construction, ratification, and reasoning, is reused as is.
To make the previous section concrete, this is what the identical pipeline looks like once its schema and standing queries are configured for the Public Prosecution's actual working material: a mother case file running from as few as fifty to as many as several hundred documents, many scanned, handwritten, degraded, or written in colloquial Arabic field notes. Nothing about the underlying graph, ratification workflow, or reasoning engine changes from the general architecture described earlier. What changes is the intake pipeline built to survive Arabic handwriting and scan quality, the schema built around what a prosecutor needs from a document, and the standing queries reframed around building and stress-testing a case theory.
The dossier below traces one case file's path through the five stages in order, including the specific failure modes the team has already identified and mitigated at each one.
This is the same five-stage pipeline, node and edge types, ratification gate, and standing queries described throughout this document — reconfigured with an intake pipeline hardened for Arabic and handwritten material, a schema built around what a prosecutor needs from a document, and a delivery surface built around a charge sheet and its elements. Every failure mode above was identified and mitigated during the same design process that produced the general architecture, not discovered after deployment.
The diagram below walks through the same eight-stage architecture described in the preceding sections as an interactive, color-coded flowchart, including the branch and failure paths that the prose descriptions above cover in text.
Overview: an interactive, color-coded flowchart tracing an eight-stage document intelligence pipeline across five phases, from raw case files to a governed, court-ready analytical product. Each phase has its own color and contains rows of nodes (process steps, decisions, and known failure modes) connected by directional edges, including some cross-phase feedback loops.
A language model can propose a new edge in the graph, meaning a formally typed relationship between two claims such as "this statement contradicts that one" or "this conclusion depends on that piece of evidence," in a matter of seconds and at essentially unlimited scale. That speed is genuinely valuable, and it is the reason this architecture can process document volumes that would take a human team months to work through manually. But a proposed edge, no matter how confident the model sounds when it generates one, is still fundamentally a guess, an inference drawn by a system that reads well but is known to be unreliable at exhaustive, high stakes judgment calls of exactly the kind that matter most in regulated domains.
What turns that guess into something an organization can actually rely on is ratification: a human with real domain authority reviewing the proposed edge, checking it against the source material the model cited, and either confirming it, rejecting it, or amending it before it is allowed to affect the graph's formal state. This is not a rubber stamp step bolted onto the pipeline to satisfy a compliance checkbox. It is the exact point at which unverified machine output becomes verified institutional knowledge, and it is the single most important reason this architecture produces something durable rather than something merely fast.
Ratification is also, not incidentally, the actual moat this architecture builds over time. Any competitor with access to the same source documents and a comparably capable language model can reproduce the same set of proposed edges overnight, because proposing edges is now a commodity capability. What a competitor cannot instantly reproduce is a graph full of edges that specific human reviewers, with specific domain expertise, have already checked, ratified, and stood behind, along with the accumulated record of which claims turned out to be right and which had to be revised later. That accumulated, ratified judgment compounds every time a reviewer makes a decision, it does not depreciate when the underlying language model is swapped out for a newer one, and it is the one part of the entire system that genuinely gets more valuable simply through continued, careful use.
This argument has a precondition that is easy to state and easy to overlook: it only holds if what's being ratified is independent evidence in the first place. A moat built partly on claims extracted from a source that was itself model output is not durable, it's circular, and it degrades the exact asset this section claims a competitor cannot copy. The reputation, provenance, and contamination attributes specified in 5.3 exist for this reason as much as for data hygiene — an uncontaminated graph is a precondition for this argument to hold, not a separate concern sitting beside it.
This is the part of the system that compounds and that no competitor can copy by running the same model over the same documents. A rival can extract similar claims. They cannot extract your organization's accumulated verdicts about which claims to trust, which sources have been wrong before, and what evidence standard your organization actually applies. That is the durable asset, and it is why the human layer is not a bottleneck to route around, it is the point.
Section 09 argues that ratification is the moat, because accumulated human judgment compounds in a way a commodity model call cannot. That argument holds up in prose, but a prose argument about a moat invites a fair question: a moat costs something to dig, so what does this one cost, and does the number it protects against actually justify the digging? This section does not yet answer that question. It defines the variables the answer will be built from, on both sides of the ledger, and it labels each one honestly by how much confidence it deserves right now, which for almost all of them is not very much. The goal here is scaffolding, not persuasion: a later section can assemble these into a real cost-per-claim and cost-of-error argument, but only if the raw inputs are stated plainly enough to be checked, argued with, and eventually replaced with pilot data.
On the cost side, the unit of work is a single reviewer adjudicating a single proposed claim or edge, and the two ratings the graph already carries on every claim, depth and basis, are also exactly the two variables that should predict how expensive that adjudication is. A claim with a shallow depth rating (recall) and a low basis rating (isolated) is, by construction, cheap to check: a reviewer confirms the claim matches the cited passage and moves on, which is a task that scales down toward a couple of minutes of attention and does not require deep domain seniority to perform correctly. A claim with a deep depth rating (multi-source synthesis) and a high basis rating (load-bearing) is a different task entirely. Verifying it means tracing every source it synthesizes, checking that the synthesis is actually valid rather than merely plausible-sounding, and weighing the fact that other ratified claims will inherit whatever error survives here — which is exactly the reasoning that already justifies routing high-depth, high-basis claims to a more senior reviewer in the adjudication flow described in 5.1. That routing rule is also a cost driver: it means the fully-loaded cost of a claim is not just a function of time spent, it is a function of whose time gets spent, and seniority is expensive in a way that does not compress just because the underlying model got faster.
Reviewer seniority itself splits, roughly, into two tiers — a junior analyst or trained reviewer who can handle shallow and mid-tier claims, and a senior analyst or genuine subject-matter expert who is required for anything load-bearing or high-depth — but the actual cost multiple between those two tiers varies enormously by domain, and this document is explicit that the three domains it names throughout, legal, pharma, and finance, are not interchangeable here. A senior reviewer for a legal claim graph might be a licensed attorney billing at a rate that dwarfs a paralegal's; a senior reviewer for a pharma systematic review might be a PhD-level scientist whose calendar is the actual bottleneck regardless of pay rate; a senior reviewer for a finance claim graph might be a credentialed analyst whose time is priced by opportunity cost against deals they are not working on instead. None of these numbers can be honestly stated as a single figure without picking a domain and a market, so what follows treats the multiple between junior and senior review cost as a labeled variable, not a constant. Against all of this sits the marginal cost of the model proposing the candidate edge in the first place, which is worth stating plainly because of how stark the asymmetry is: that proposal cost is already close to zero per edge at current model pricing, and every available trend points toward it falling further, while reviewer-hour cost does not follow anything like the same curve. That asymmetry is the entire economic argument for why ratification, not proposal, is where the durable cost and the durable value both live.
The ratification bottleneck named in the failure-mode analysis is not a separate concern from this cost model, it is a direct consequence of it: throughput is capped by available qualified reviewer-hours, not by compute, which means the cost side of this ledger cannot be reduced by buying more GPUs or a faster model, only by adding reviewer capacity, changing the triage rules that decide what gets reviewed first, or accepting a larger backlog. On the value side, the honest way to frame what ratification is actually buying is the cost of the error it catches, and that cost is domain-specific in a way that resists a single number even more than reviewer cost does. A missed contradiction that survives into a legal case theory can mean an adverse ruling, a sanctions exposure, or a settlement negotiated from a materially weaker position — plausibly ranging from tens of thousands of dollars in wasted attorney time on a narrow issue up to a case-losing exposure that could run into the millions, depending entirely on what the contradiction was about and how late it surfaced. A stale claim that survives uncorrected in a pharma systematic review can propagate into a dosing recommendation or a safety conclusion that downstream researchers and possibly regulators rely on, where the cost is not measured in review-hours at all but in something closer to patient risk and regulatory exposure that does not have a clean dollar figure and should not be forced into one. An undetected covenant conflict feeding a finance investment thesis can mean a position sized against a risk that was never actually priced in, with a loss magnitude that scales directly with position size and could range from a rounding error to a fund-defining mistake. All three of these are stated as illustrative orders of magnitude, not fabricated precision, in keeping with this document's general refusal to present confidence it has not earned, and every one of them should be treated as a placeholder until an actual deployment has real incidents to point to.
| Component | Description | Illustrative range |
|---|---|---|
| Model proposal cost | Marginal cost of the model generating one candidate claim or edge | Near-zero per edge today; falling with model pricing trends, not expected to be a meaningful line item at any tier |
| Shallow / isolated review | Depth: recall. Basis: isolated. Junior reviewer confirms claim against cited source | A few minutes of junior reviewer time per claim |
| Mid-tier review | Depth: single-premise reasoning. Basis: echoes existing belief. Junior or mid-level reviewer traces one inferential step | Roughly an order of magnitude more reviewer-minutes than the shallow tier |
| Deep / load-bearing review | Depth: multi-source synthesis. Basis: load-bearing. Routed to senior analyst or subject-matter expert | Meaningfully more reviewer-time than mid-tier, at a senior hourly rate that itself varies by domain (legal / pharma / finance) |
| Senior/junior cost multiple | Ratio between senior and junior reviewer hourly cost, domain-dependent | Varies widely by domain; not assumed to be a single constant across legal, pharma, and finance |
| Backlog / bottleneck cost | Opportunity cost of claims sitting unratified because reviewer-hours, not compute, are the constraint | Not yet quantified; tracked today only as a backlog-size metric, per the ratification bottleneck containment in the failure-mode analysis |
Every number above is a placeholder, not a finding. The depth/basis-to-review-time relationship is a structural claim this architecture makes by design; the actual minutes-per-tier have not been measured against a real reviewer population. The junior/senior cost multiple is asserted to vary by domain but is not pinned to any real legal, pharma, or finance rate card. The three error-cost scenarios are illustrative orders of magnitude chosen to be directionally plausible, not figures drawn from an actual incident. The only inputs here that are not placeholders are the two that are structural and already frozen elsewhere in this document: that model proposal cost is falling while reviewer cost is not, and that review throughput is capped by reviewer-hours rather than compute. Everything else needs a pilot before it should be treated as anything more than a labeled assumption.
Section 09 claims the ratified graph compounds. Section 9.1 defined what a unit of ratification costs and what a unit of avoided error is worth. This section puts those two things together and asks the question a skeptical reader should ask next: compounds how, exactly, and is the resulting number big enough to call it a moat, or is that word doing more work than the arithmetic supports? The honest answer, worked through below, is that the moat is real but not uniform. It is a genuine, mechanically explainable structural advantage in domains where a missed contradiction is expensive, and it is a much thinner advantage everywhere else, which is a distinction the prose in section 09 does not make and probably should.
"Compounds" is doing real work in section 09, and it deserves an actual mechanism rather than the general intuition that old knowledge is somehow worth more than new knowledge. The mechanism is this: once a claim has been ratified, every subsequent ingestion run checks newly arriving material against it automatically, as a byproduct of the contradiction-mining and consistency-checking machinery this architecture already runs on every document that enters the pipeline. That checking is essentially free at the margin, because it is the same reasoning pass the system performs on every new claim regardless of what else is in the graph. A ratified claim, in other words, gets re-verified against the world continuously and at near-zero marginal cost, and it only consumes a reviewer's attention again if that automated pass actually surfaces a candidate contradiction worth a second human look. An unratified claim gets none of this for free. Every time it resurfaces, whether cited again in a new document or relied on by a new piece of reasoning, it either has to be re-evaluated from scratch by a human, which is the full cost from section 9.1 paid again, or it has to be used un-verified, which is exactly the risk the value-of-avoided-error model in 9.1 is trying to price. The compounding, then, is not a metaphor for "old data is good." It is the literal statement that ratification converts a claim from something that costs reviewer-hours every time it is touched into something that costs reviewer-hours once and then rides the free machine-checking loop indefinitely, with human attention only re-engaged when the loop actually finds something.
This has a direct consequence for the depth and basis tiers defined in 5.1 and priced in 9.1: a load-bearing, high-depth claim is disproportionately valuable to have already ratified, precisely because it is the claim other reasoning depends on, so it is checked against fresh material more often, by construction, than an isolated shallow claim that few other nodes ever touch. The senior-reviewer cost paid once to ratify a load-bearing claim is therefore amortized across every future ingestion run that would otherwise have had to re-litigate whether that claim still holds. This is also why an organization that has been ratifying for longer does not just have more claims than a newcomer, it has a graph whose average claim is cheaper to keep trusting per unit of time, because a larger fraction of it has already crossed the one-time ratification cost and is now running on the free loop rather than accumulating deferred review debt.
Take an incumbent that has been running this pipeline for some duration of N months, ratifying claims at whatever throughput its reviewer pool allows, and a rival that starts today with an equally capable or genuinely newer language model, the same source documents, and zero ratified claims. The rival's proposal step is not a disadvantage; per 9.1, proposing candidate edges is already commodity-cheap and a newer model does not change that asymmetry in the rival's favor by much, because the incumbent's proposal cost is also already near zero. Where the rival is actually behind is in the stock of ratified claims sitting in the incumbent's graph, and closing that gap requires reviewer-hours, not model calls. If the incumbent has ratified some number of claims per month at a throughput set by its reviewer capacity and the tier mix described in 9.1, the rival needs to ratify that same cumulative volume, at the same tier mix, before the two graphs represent comparable institutional judgment. That is a reviewer-hours problem with a reviewer-hours solution, and reviewer-hours do not compress just because the rival's model is faster, which is precisely the ratification bottleneck named in the failure-mode analysis, applying here not to the incumbent's operations but to the rival's catch-up effort. A rival cannot buy its way past this constraint with more compute. It can only buy its way past it with more qualified reviewer capacity, and qualified reviewer capacity, especially at the senior tier this architecture routes load-bearing claims to, is exactly the scarce, slow-to-scale resource the bottleneck names. This is the sense in which the incumbent's months of accumulated ratification are not just a head start, they are a head start denominated in the one input a rival cannot accelerate by spending more on infrastructure.
It is worth being precise about what this model does and does not claim. It does not claim the rival can never catch up; a rival with a much larger review staff, or one willing to pay a much larger senior-reviewer premium to accelerate the high-tier claims specifically, can compress the catch-up timeline meaningfully, which is addressed directly in the limitations below. What the model does claim is that catch-up time scales with the incumbent's accumulated ratified volume and is bounded below by the rival's own achievable reviewer throughput, and that this bound is structural rather than incidental, because it is the same bottleneck this document already identifies as a first-class risk for the incumbent's own operations. A rival is not exempt from a constraint the incumbent is explicitly warned about elsewhere in this document; if anything, the rival faces it in a more acute form, because the rival is trying to build years of judgment in months, which pushes hard against the exact throughput ceiling the bottleneck describes.
The system pays for itself, in the crudest possible framing, whenever avoided-error value ratifies at a rate that exceeds the fully-loaded ratification spend it took to catch that error, and that break-even condition is a function of two things that both vary by domain: how often a load-bearing claim would otherwise have gone unratified and later caused a problem, and how expensive that problem would have been. Both of those numbers are large in the domains this document already names as its core targets, and small almost everywhere else, which is exactly why the moat argument should not be read as domain-independent. In legal work, a single missed contradiction feeding a live case theory can, per the 9.1 estimate, cost anywhere from tens of thousands of dollars to a case-defining exposure, against a ratification spend measured in reviewer-minutes to reviewer-hours per claim; the break-even bar here is low enough that a system needs to catch only a small number of real contradictions per year to justify its entire ratification cost. In pharma systematic review, the same logic holds even more strongly because the downside is not purely financial: a stale or wrong claim surviving into a safety conclusion carries a cost that, per 9.1, resists being priced in dollars at all, which means the break-even condition is met almost by definition the moment the system catches even one genuinely dangerous stale claim before it propagates. In finance, an undetected covenant conflict feeding an investment thesis scales with position size in a way that can be very large for a concentrated fund and comparatively modest for a diversified one, so the break-even point in finance is the most sensitive of the three to the specific portfolio and mandate, not a fixed domain-level constant.
Outside these three domains, or inside them but applied to low-stakes claims, the same math runs the other way. A shallow, isolated claim in a low-consequence context, per the 9.1 cost table, is cheap to ratify, but it is also cheap to be wrong about, because nothing else in the graph depends on it and the downside of an error is small by construction. Spending senior-reviewer-equivalent care on claims like that would fail the break-even test badly, which is itself an argument for the triage logic in 5.1 and the backlog-prioritization containment named in the failure-mode analysis: the moat's economics only work if review effort is actually allocated toward the high-basis, high-depth, high-stakes claims where the avoided-error value is large, and the same architecture applied indiscriminately to every claim regardless of stakes would be considerably harder to justify on cost grounds alone. The moat, in short, is not a property of the architecture in the abstract. It is a property of the architecture applied to claims where being wrong is expensive, and the document should be read with that qualifier attached rather than as a claim that ratification pays for itself everywhere it is used.
Take a mid-size litigation support team processing roughly 2,000 documents a month during active discovery, an illustrative volume chosen for round numbers rather than measured from any real engagement. Suppose extraction yields on the order of 6,000 candidate claims and edges from that volume, a plausible multiple of a few claims per document once supporting and contradicting relations are counted alongside the underlying claims themselves. If the tier mix roughly follows the shape implied in 9.1, with the large majority landing in the shallow or mid tier and a smaller fraction, say a few hundred, landing in the deep, load-bearing tier that gets routed to senior review, then the monthly ratification spend is dominated by two very different unit costs: a few minutes of junior-reviewer time across the bulk of the volume, plus meaningfully more senior-reviewer time, at whatever attorney or senior-analyst rate applies, across the smaller load-bearing slice. Stated only as an order of magnitude, and explicitly not as a forecast, that monthly spend plausibly lands somewhere in the low tens of thousands of dollars for a team of this size, driven mostly by the senior-tier hours rather than the much larger but much cheaper shallow-tier volume.
Set that monthly spend against the cost of a single plausible missed contradiction of the kind 9.1 describes: a load-bearing claim in a case theory that goes unratified, survives into a filing or a strategy decision, and is later discovered to conflict with testimony or a document already in the record. Per the 9.1 range, a contradiction like that, depending on how central it is and how late it surfaces, plausibly costs anywhere from the tens of thousands of dollars in wasted attorney time on a narrow issue up to a genuinely case-altering exposure. Even at the low end of that range, one caught contradiction of this kind is worth roughly a month of the team's entire ratification spend, and at the high end it is worth many months of it. This is the concrete version of the break-even argument above: for a team in this domain, at this volume, the system does not need to catch contradictions often to justify its cost, it needs to catch a small number of genuinely load-bearing ones over the course of a year, which is a considerably lower bar than the prose in section 09 might otherwise lead a reader to assume is required. This entire paragraph is illustrative arithmetic built on placeholder inputs from 9.1, not a projection for any actual team, and it should be re-run with real numbers before anyone relies on it.
The moat argument is strongest exactly where the stakes are highest: litigation, drug safety, and material financial disclosure, where one avoided error can be worth months of ratification spend and where a rival cannot shortcut the catch-up period with a faster model. It is a considerably weaker argument for low-stakes claims or domains where being wrong is cheap, and this document should not be read as implying otherwise. The right question for any deployment is not "does ratification compound," which it structurally does, but "are we ratifying the claims where compounding is worth what it costs."
Section 09 argues that ratification is the moat, and that the moat only fills if people keep ratifying. That argument has a quiet dependency it never states outright: the people who need to do the ratifying are domain reviewers, not engineers, and domain reviewers will not sustain voluntary use of a system whose only user-facing surface is a one-sentence tooltip and a JSON endpoint. A demo can survive on a tooltip. A moat cannot. This section specifies the layer that sits between the graph and the reviewer — not a new subsystem, but an extension of what the working demo already has: the data-verdict attribute, the edge-popover, and the doc-grid. Everything below builds on that existing surface rather than replacing it.
When the system reports a belief, the reader should never see "the system believes X." They should see the graph structure that produced X, walked outward from the target node along supports, contradicts, and assumes edges to a bounded depth (two hops by default), ranked by basis rating, then depth rating, then recency — reusing ratings the ontology already tracks rather than inventing a new scoring pass. If a formal belief calculus exists elsewhere in this document, it supersedes this ranking; until then, this is the rule. The output is always two things paired: a short natural-language sentence, and a structured citation list of the exact node IDs it draws from, so every explanation is auditable back to specific graph elements rather than free-form prose the reviewer has to trust.
Generic, unfalsifiable, and impossible to audit. The reader has no way to check which claims this sentence is actually built from.
Every noun is a specific, clickable graph element. The citation list sits one click away, always.
The existing edge/node popover keeps its current job exactly as-is: a one- or two-sentence tooltip, cheap and immediate. What's new is a single added affordance inside it — an "Explain" action. Clicking it expands the same popover, or hands off to a docked panel on wider viewports, into the longer explanation above. The popover is the entry point, not a competing widget. A reviewer who never clicks "Explain" experiences the demo exactly as it works today.
Two interaction modes, triggered as primary actions directly from a claim or conclusion's popover or detail view — never from a separate query console.
| Interaction | Trigger | What visibly happens |
|---|---|---|
| "What if claim X were false?" | "Explore: if this were false" action on any claim | Claims connected via supports lose that support in the exploratory view; conclusions resting on X via an assumes edge are flagged as now resting on a broken assumption — a structural risk, shown distinctly from a mere confidence drop |
| "What's the weakest link?" | "Explore: weakest link" action on a conclusion | A ranked list of upstream claims, ordered by how much the outcome would move if each were removed or reversed — lowest independent corroboration and lowest basis rating rank highest |
Both interactions compute against a snapshot of the ratified graph and never write back to it. The only way a counterfactual becomes real is if a human, having seen it, deliberately opens an ordinary ratification action afterward through the existing Propose → Verify → Ratify flow — the counterfactual itself triggers nothing automatically. Given how much this document cares about never confusing a proposal with a ratified fact, the visual break cannot be subtle: the canvas desaturates everything untouched by the recompute, every changed edge switches to a dashed stroke, and a persistent banner names the hypothesis in force with one visible exit action.
The existing data-verdict attribute (neutral / corrob / clash / noise) already renders one axis of disagreement: disagreement in the source material. That axis is untouched. What's missing is a second, orthogonal axis — disagreement among the reviewers ratifying a claim, a fact about the adjudication process, not the evidence. A claim can be uncontested evidence with a contested ratification, or clashing evidence with a unanimous one; collapsing these into one signal erases exactly the distinction a reviewer needs.
The sources contradict each other. Already handled by the existing data-verdict color and animation.
A dual-tone border or hatch marker, layered on top of any verdict color, present regardless of whether the underlying evidence is clash, corrob, or otherwise.
A toggle — "Show only contested ratifications" — dims everything without the marker, mirroring how a reviewer already filters to clash-only edges. Once ratification resolves to a majority verdict, the dissent is not deleted: a "dissent noted" affordance stays on the edge, openable on demand, showing who dissented and why. This is the direct interface-level expression of 7.2's containment for authority concentration — dissent as a first-class field, not overwritten once a verdict is reached.
Four levels, one click from its neighbor, with the current level always visibly labeled via a persistent breadcrumb that lets a reviewer jump back up any number of levels at once.
The top-line answer to a standing query, plus a confidence indicator. Where a Question node lands first.
The claims and edges behind the answer — the existing force-directed graph, unchanged. No new UI required here.
Source pages via made_in edges and page anchors, in a docked panel; the graph stays visible but dims behind it.
The original source document, opened at the anchored page — the one full handoff, since close reading needs the whole viewport.
A naive interface shows the same thing — nothing — for three situations that mean entirely different things to a reviewer judging how much to trust a conclusion. Silence because nobody has looked must never look like silence because the answer is genuinely negative.
Rendered as a neutral empty state, not an error, with an invitation to add a claim. Silence carries no meaning yet.
Given the same explanation treatment as a positive answer — e.g. "contradicted by claim E, ratified with high basis; no supporting claim exists." Must visually read as populated, never empty.
Neither unknown nor no — a structural limit, labeled as such, with a note on the ontology's next review cycle where useful.
Section 09's argument only holds if ratification keeps happening, and ratification only keeps happening if the people whose judgment the moat is built from — domain reviewers, not engineers — find the system usable enough to return to voluntarily. A JSON API and a one-sentence tooltip are enough to prove the architecture works in a demo watched by people who already understand claim graphs. They are not enough to earn repeated, unprompted use from a reviewer whose actual job is domain expertise, not graph traversal. This layer is not a UI nicety layered on top of the real system; it is the part of the system that determines whether section 09's central claim is true in practice or only true in principle.
A well-formed, confident-sounding auto-generated sentence can read as more authoritative than the sparse evidence underneath it. Two claims and a shaky assumption, rendered in clean prose, look more settled than they are — the fluency of the sentence, not the strength of the graph, is what a rushed reviewer ends up trusting. This compounds with progressive disclosure: a reviewer who reads a good summary and never clicks through to evidence has effectively been told a confident story about a thin graph, a distinct risk from, though related to, the miscalibration failure mode in 7.2.
This is a new standalone card, not an extension of "Authority concentration in the adjudicator" (7.2) — that card is about power concentrating in a person; this one is about fluency concentrating unearned trust in a generated artifact, a distinct mechanism with a distinct containment.
A domain reviewer opens a Question node — "Did the vendor's Q3 filing disclose the pending litigation before the acquisition closed?" — and lands on the summary level: a single sentence stating moderate confidence in "yes, disclosed, but late." Wanting to know why confidence isn't higher, she clicks through to evidence and sees the familiar graph: one supporting claim, and one claim — flagged with the contested-ratification marker — where reviewers had split on how to weigh an ambiguous internal memo.
She opens "Explain" on the supporting claim and reads the structured explanation: disclosure is supported by a filed amendment, but the conclusion assumes the amendment was actually received by the counterparty — an assumption currently unchallenged. She clicks "Explore: weakest link" on the top-line conclusion and gets back a ranked list with that same receipt assumption at the top.
She clicks through into "what if this were false," watches the graph desaturate, the assumption edge switch to a dashed stroke, and the banner confirm she's in an exploratory state — confidence drops from moderate to low in the recompute, exactly as she'd have guessed, but now she can see precisely why. Satisfied she's found the real crux, she exits the counterfactual, moves down through provenance to the page anchor for the amendment filing, and finally opens the raw source document to read the actual filing language and judge the receipt question herself. She never once had to trust a paragraph she couldn't trace back to a specific page.
A common assumption about any system built around a graph database, a reasoning engine, and multiple language model calls is that it must require a substantial operational footprint to run: a cluster of servers, one or more long running daemons, and a dedicated database administrator to keep the whole thing healthy. This architecture was deliberately designed to avoid that assumption for as long as possible, on the theory that operational complexity introduced before it is actually needed tends to slow a project down without adding value proportional to its cost, and that most organizations evaluating this kind of system want to see it work before committing to a heavier infrastructure investment.
In practice, this means the architecture runs comfortably on flat files and embedded storage for a meaningful stretch of its adoption curve, with no servers to provision, no daemons that need monitoring, and no database administration overhead at all. A single machine, whether that is a laptop, a workstation, or a modest cloud instance, is sufficient to run the full pipeline, including document acquisition, extraction, graph construction, and reasoning, through its first several levels of real maturity, covering corpora that are large enough to matter for an actual team doing actual analytical work rather than a toy demonstration.
This low ceremony approach is not a permanent ceiling on the architecture's scale, it is a deliberate sequencing choice. As a deployment grows past what a single machine can comfortably handle, the same underlying data model, the same six node types and eight edge types, the same schema driven extraction process, migrates cleanly onto more conventional infrastructure without requiring a redesign of the architecture itself. The point of starting low ceremony is that an organization gets to prove the value of the ratified claim graph, and start accumulating that ratified judgment, well before it needs to make any significant infrastructure investment, which meaningfully lowers the risk of adopting this approach in the first place.
Everything described in this document up to this point is the architecture exactly as specified today, a working, well defined pipeline that converts documents into a reasoned, ratified claim graph and answers five standing queries against it. That is already a substantial amount of value on its own, but it is worth pausing to consider what becomes possible once such a graph actually exists inside an organization and has been accumulating ratified judgment for a meaningful period of time, because the answer is a category of value that has genuinely little precedent in current enterprise software.
Most enterprise software value propositions are incremental: a faster way to do a task someone was already doing, a cheaper way to store data someone was already storing, a better dashboard for a report someone was already generating. The value that becomes available once a ratified claim graph exists is different in kind, not just in degree, because it depends on having a persistent, structured, human verified record of an organization's own accumulated judgment, which very few organizations currently have in any usable form. Once that record exists, questions that were previously unanswerable, or answerable only through an expensive one-off research project, become queries that return in seconds against a graph that already contains the relevant, verified structure.
The sections that follow describe several specific categories of new value that open up once the substrate exists, and it is worth being clear that these are not incremental features added on top of the existing pipeline, in the way a new dashboard or export format might be. They are new products in their own right, ones that simply do not make sense to build, and could not be built with any real reliability, until an organization already has a ratified claim graph sitting underneath them. This is also, not coincidentally, the strongest argument for starting to build this substrate now rather than waiting, because the value described below only becomes available after the graph has had time to accumulate genuine institutional judgment.
Most AI investment today buys a better way to answer questions about documents. The applications below are different in kind: they use the accumulated, ratified graph as a foundation for products that do not exist yet in the market, because no other architecture produces the substrate they need to run on. Each one below compounds in value the longer the graph has been alive.
Every scientific and regulatory field has a body of literature too large to review manually and too important to leave stale. A claim graph over the field's literature turns a periodic, expensive, months long review process into something that stays current continuously, flagging exactly which conclusions a new paper touches.
Organizations lose knowledge every time a senior person leaves, a project ends, or a document gets archived. A bi-temporal, provenance anchored graph preserves not just what was decided, but why, on what evidence, and what has changed since. New hires inherit the reasoning, not just the conclusions.
For any belief an organization holds, from an investment thesis to a safety assumption, the system continuously tracks what evidence would prove it wrong and searches new documents for exactly that evidence as it arrives. This is Karl Popper's epistemology, running as an always-on background process rather than a one time review.
In any domain where reasonable people disagree, from policy to litigation strategy, the argumentation layer can compute which sets of positions are jointly defensible against each other, conditional on which evidence a reader is willing to accept. It turns "who is right" from a debate into a structured, inspectable computation.
Once the ontology is frozen and the schema is stable, the same pipeline ingests documents in any language and any domain without re-architecture. A multinational could run one graph over filings, contracts, and internal reports across a dozen languages, with entity resolution linking the same organization or person across all of them.
A curiosity agent patrols the graph for high value anomalies: claims with no counter-evidence anywhere, questions where every source suspiciously agrees, and load-bearing conclusions resting on a single source. It surfaces what to read or investigate next, not by a recommendation algorithm, but by identifying what would most reduce uncertainty in the organization's own belief structure.
Before any synthesis is accepted into the belief layer, a second, independent agent actively attacks it: checking every cited claim against its source pages and hunting the corpus for contradicting passages the synthesis conveniently ignored. This becomes a standing internal auditor that never gets tired or complacent.
Legal holds, information barriers, and need-to-know restrictions can be enforced at the level of individual claims and subgraphs rather than whole documents, so a single graph can safely serve multiple teams with different clearance levels without duplicating the underlying corpus.
Instead of teams of analysts manually cross-referencing thousands of contracts, filings, and disclosures, a claim graph built over both parties' documents can surface every direct contradiction, every undisclosed dependency, and every assumption that the deal thesis rests on, in a fraction of the usual time and with a full audit trail.
When a new regulation or ruling is published, the change propagation logic already used for internal belief revision can trace exactly which internal policies, contracts, and product decisions the change invalidates or puts at risk, turning a scramble across departments into a single traversal.
Individually, the system already tracks not just what the source library says but what a specific reader believes and why. Extended to teams, this becomes a map of what each expert in an organization actually believes, where experts disagree with each other, and whose judgment has been right before, which is a fundamentally new kind of internal expertise directory.
The underlying pattern, neural extraction, symbolic storage, human ratification, generalizes far beyond documents. Any enterprise process that produces a stream of claims needing verification, from customer support tickets to incident postmortems to scientific lab notebooks, is a candidate for the same substrate, meaning the architecture itself can become internal infrastructure other teams build on rather than a single application.
The roadmap for building and rolling out this architecture is deliberately front loaded rather than evenly paced, and that sequencing is itself a considered decision rather than an accident of how the work happened to break down into phases. Each of the five phases described below is structured so that it earns the case for the phase that follows it, meaning the team is never asked to invest in a later, more expensive phase purely on faith, but rather on the strength of demonstrated value from the phase immediately before it.
The earliest phase in particular is worth calling out specifically, because it requires no new code at all, and yet it delivers a meaningful share of the architecture's intellectual value entirely on its own. This phase is essentially an exercise in applying the pipeline's underlying thinking, the separation between what the corpus says and what the organization concludes, the five standing queries, the discipline of a small frozen ontology, to a manageable slice of an organization's existing documents using largely manual or lightly tooled methods. Doing this early and cheaply serves two purposes: it validates that the standing queries this architecture is built around are actually the questions the organization cares about, and it produces an early, tangible sense of what a ratified claim graph looks like and feels like to work with, well before any significant engineering investment has been made.
Later phases progressively automate more of what the first phase did by hand, moving from manual extraction to model assisted extraction, from ad hoc review to a structured ratification workflow, and eventually to the full eight stage pipeline with reasoning and application layers running against a graph that has already accumulated real, ratified judgment from the earlier phases. Because each phase is justified by evidence the previous phase actually produced, rather than by a projection made at the very start of the project, the roadmap is unusually resistant to the common failure mode where an ambitious architecture gets fully specified up front and then stalls midway through implementation once the first hard technical problem is encountered.
Summaries are a commodity that any vendor can produce. A provenance anchored, human ratified layer of claims that your organization has actually reasoned over is not, and it compounds every time someone uses it.