Knowledge Graphs: Organizing Identity, Relationships, Time, and Evidence into Queryable Facts

Vector retrieval can already efficiently find passages semantically similar to the question, so why do we still need knowledge graphs? The answer lies in that the two types of systems answer questions of different natures. Vector space excels at answering "what is semantically similar to what": mapping questions and passages into the same vector space, measuring relevance by distance, and returning the closest content. Graphs excel at answering "who is connected to whom through what relationships": starting from explicit entities, walking along typed, directed edges, and answering questions with the structure of the paths themselves.

This difference determines their respective applicable boundaries. When tasks require the following capabilities, explicit edges make queries explainable and verifiable:

• Unique identity: the question asks about "a specific X", not "a pile of text similar to X". Vector similarity naturally returns approximate sets; graphs use node identifiers to ensure unique reference.
• Multi-hop constraints: answers need to satisfy path conditions like "starting from A, going through relation R₁ to B, then through relation R₂ to C". In a graph, one edge corresponds to one relationship, and each hop can be checked against constraints; vector retrieval can only provide a passage that may mention these entities together, leaving the model to guess whether the path holds.
• Dependency propagation: the validity of one fact depends on another fact, for example, "the indications of a drug" depend on "the version of the drug that was approved". Graphs model dependencies as structure, and queries propagate along dependency directions; vector passages bury dependency relationships in free text.
• Temporal versioning: facts evolve with events, and we need to know "what holds at time t". Graphs can attach time intervals to edges, and queries prune by time conditions; vector retrieval cannot reliably distinguish different versions.
• Global communities: requires structure at the aggregate level, such as "which entities form the same thematic cluster, and which bridging entities connect clusters". This requires global structural analysis of the entire graph, rather than local similarity matching for individual queries.

Therefore, graph inputs and outputs differ from those of vector stores. The inputs to a knowledge graph are entities with stable identities, controlled relationship types, temporal information, and evidence pointing to the source text; the output is a factual graph that can be queried by relationships and constraints. Queries take the form of structured paths and conditions, not similarity rankings.

But graphs are not unconditionally the better choice. Their construction and maintenance costs—entity recognition, relationship normalization, temporal alignment, evidence linking—are significantly higher than slicing text to build an index. Therefore, judge by task: for questions that can be answered by ordinary FAQ or a single passage, the benefits of a graph do not justify the cost, so there is no need to build one; only when unique identity, multi-hop, temporal versioning, or global structure become hard requirements are the explainability and verifiability brought by explicit edges worth these costs.

Finally, a key point to distinguish: a graph query returns apath existence conclusion—that the graph indeed has a connection from A through R₁ to B and then through R₂ to C. Path existence only indicates that the graph records this connection; it does not automatically guarantee that the connection is true in the real world. The reliability of the graph depends on the factual quality of each edge at graph construction time, which is why subsequent chapters address evidence and temporal modeling.

"Alice works at Acme" looks like just three words; why can't it be stored directly in the graph as three strings? Because before this fact can be reliably queried, validated, and retracted by a machine, a series of questions must be answered: Which Alice is being referred to? Is "works at" an employment relationship or an advisory relationship? When does this relationship start and end? What makes it true? Is it currently in a confirmed state or a candidate state?

The answers to these questions must become part of the edge itself. The inputs to fact modeling are six types of information—subject, predicate, object, validTime, source, confidence—plus a status that distinguishes the processing stage. The output of modeling is a traceable, retractable qualified edge, which can be written as:

Fact = (subject, predicate, object, validTime, source, confidence, status)

Each field addresses a specific type of failure mode.

subject and object use stable IDs, and display names are just attributes. The name "Alice" may correspond to multiple different people in the corpus. If the two ends of an edge store name strings, two facts about different Alices will be incorrectly merged into the same node; if in the future one Alice changes her name, a graph that uses names as identifiers will suffer identity breakage. Therefore, the identifier of an entity is a stable ID, and the display name is just a mutable attribute attached to the node. IDs ensure that entities with the same name each remain in their proper place, and name changes do not affect the graph structure.

predicate comes from a controlled ontology. "works at", "is employed by", and "serves as" if each becomes an independent edge type, the graph will accumulate a large number of relationships with overlapping meanings. When querying, either synonymous relationships will be missed, or different meanings will be mistakenly treated as the same relationship. The ontology predefines the set of allowed relationships and their meanings, making the semantics of each edge definite and comparable.

validTime indicates when the fact holds. An employment relationship has start and end dates: before joining, querying "Alice works at Acme" should answer no; after leaving, querying also answers no, but a historical query should still be able to return "held from 2019 to 2023." A triple without a time field can only give the same answer to questions at any point in time, unable to distinguish between "now" and "once".

source points to the original text span. Each edge must be able to answer "which piece of text does this fact come from". The source is anchored to a specific text position, so that a reviewer can go back to the original text to check whether the extraction is correct, and also locate facts that need to be updated when the original text is revised.

confidence and status distinguish between confidence level and processing stage. confidence is the extractor's numerical estimate of the likelihood that the fact holds; status marks the lifecycle stage that the fact is in—candidate, confirmed, conflict, retracted. The two answer different questions: confidence asks "how reliable is this extraction", status asks "what state is this fact currently in". A low-confidence fact that has been manually confirmed and a high-confidence record that conflicts with other facts are handled completely differently.

Complex facts should model events as nodes. A simple edge can only express a binary relationship, but many facts are inherently n-ary: "Alice signed an agreement with Bob in Tokyo in March 2022" involves multiple roles such as signatory, counterparty, time, place, and object. Cramming this event into a single edge either loses roles or fabricates false edges where roles are intertwined. The correct approach is to model the "signing" event as a node, and connect participants, place, and time as separate edges to that event node. Event nodes carry n-ary relationships, preventing complex facts from being flattened into uninterpretable binary edges.

By combining these fields, the graph does not obtain a pile of bare triples, but qualified facts that are each traceable and retractable. Triples lacking these fields cannot support reliable historical queries and conflict detection: without IDs, entities cannot be distinguished; without time, "when" cannot be answered; without source, "why it holds" cannot be verified; without status, it cannot express "whether this fact is currently valid." This also explains where the cost of building the graph comes from—every qualifying field of every edge must be extracted, normalized, and aligned with evidence, so the cost is naturally higher than simple indexing.

Consider a specific corpus: "Apple acquired Beats" "Tim leads Apple" "The founder of Beats is Dre". The question is: "Who is Tim indirectly associated with?" In vector retrieval, these four pieces of text would be treated as relevant fragments stitched together for the model, which guesses the chain "Tim → Apple → Beats → Dre" from context; in a graph, this chain must actually exist as a verifiable path.

The first step in building the graph is entity resolution; the key is to assign different stable IDs to same-name entities. "Apple" here is a company, assigned org:apple, and must never be merged with the food entity food:apple; "Tim" is resolved to person:cook (Tim Cook), and "Dre" is resolved to person:dre (Dr. Dre). If this step merges the company Apple and the fruit apple into a single node, all subsequent paths through this node will point to the wrong object.

The second step is to extract edges with sources. The three sentences produce three edges: person:cook → leads → org:apple, org:apple → acquired → org:beats, and person:dre → founded_by⁻¹, that is, the inverse edge org:beats → founded_by → person:dre. Each edge is attached to its corresponding source text span as provenance.

The third step is to answer the multi-hop query. The question "Who is Tim indirectly associated with?" is translated into a graph traversal: start from person:cook, follow leads to org:apple, follow acquired to org:beats, then follow the inverse edge of founded_by to reach person:dre. The query returns not just a name, but this complete path and its corresponding three pieces of original-text evidence—the definition of "indirectly associated" lies in the path structure; if any hop is missing, this answer does not hold.

But every step along the path can be wrong, and these errors accumulate. Let pEntity be the accuracy of entity resolution, pEdge the correctness of each edge, and h the number of edges in the path. Under the rough assumption that "errors at each step are independent," the probability that the entire path is correct is approximately:

Ppath = pEntity × pEdge^h

Applying this to the example: take the Apple resolution accuracy as 0.9 and the correctness of each of the three edges as 0.95, then Ppath = 0.9 × 0.95³ ≈ 0.772. Each additional hop multiplies by the edge correctness once more, and the error is magnified accordingly—this is why multi-hop queries are more fragile than single-hop ones: a single hop carries only one edge error, while a multi-hop query carries the multiplied risk across all hops.

This independent approximation formula itself is only an intuitive tool. In real systems, entity resolution errors and relation extraction errors are often correlated: resolving "Apple" as the fruit is often followed by extracting the "acquired" edge incorrectly; errors in the same source passage can simultaneously contaminate multiple adjacent edges. Correlated errors make the true confidence even more unreliable than the independent multiplication estimate, so the final conclusion must be checked against the original text.

Different errors occur at different stages and have different consequences:

Entity resolution errors are the most destructive because they affect all edges passing through that node. Relation errors make the path "appear to exist but be semantically wrong"; direction errors invert the subject-object relationship such as "who acquired whom"; source errors cause the entire path to lose verifiability—the path appears connected, but the original text supporting it cannot be found. Therefore, the correctness of a multi-hop answer cannot be judged only by whether the path is connected; each hop must be checked for entity, relation, direction, and evidence.

Are more relationship types always better? Does a richer set of relationships in a graph mean the graph has more knowledge? The answer is no. The goal of an ontology is not to exhaust all concepts in the world, but to use minimal constraints to reliably support a class of queries.

The inputs to ontology design are real questions and decision needs, not "what concepts exist in the world". The correct order is: first collect the questions users actually ask and the decisions they need to make, then define the minimal entity types, relationships, directions, cardinality rules, and time rules accordingly. The output is a schema that can support exactly these target queries. There is only one standard for judging ontology quality—whether it can consistently answer business questions, not how many types it defines.

Deviation at either end will undermine this goal.An overly broad ontology—for example, cramming everything into a vaguely defined related_to edge—cannot support precise queries: related_to does not distinguish "acquisition", "competition", "supply", or "being sued", and graph traversal cannot apply semantic constraints on this edge, so multi-hop paths become meaningless connectivity.An overly fine-grained ontologyis equally harmful: if relationships are split too finely, extraction systems find it hard to reliably distinguish adjacent types in real text, annotation costs rise accordingly, edges under each fine-grained category become sparse, and queries end up having to enumerate many types to cover the same semantics. The principle for choosing granularity is: distinguish exactly those relationships that produce different answers for business queries; anything finer is over-engineering.

A schema is not immutable, but changes must be controlled. Every modification—adding types, splitting relationships, adjusting direction—must have a migration and compatibility strategy: existing old edges must either be migrated to new types or explicitly annotated with their old semantics; their meaning must never be silently changed. If an edge was created as "cooperation" and is later interpreted as "holding" after schema adjustment, all historical query conclusions that depend on this edge will be overturned without anyone noticing.

Identity rules in the ontology must be explicitly written out, because this is the root of the same-name entity problem. Two rules balance each other:Same name does not mean same entity—two nodes both called "Apple", one a company and one a fruit, must never be automatically merged;An alias does not mean a different entity—when "Tim Cook" and "Apple CEO" refer to the same person, they must not be split into two nodes just because they are written differently. The means for implementing identity determination, in order, are: use a canonical ID as the node primary key, attach external identifiers (such as organization numbers, person IDs) for cross-checking, use attribute evidence (address, tenure, etc.) to assist judgment, and for high-impact operations where merging or splitting would affect important conclusions, manual review is required. Automatic merging is convenient, but incorrectly merging a high-impact entity will contaminate all paths through that node; incorrect splitting will make queries that should be connected never work.

Therefore, an ontology is not better the more complete it is, and a schema is not better the more stable it is: it is a set of constraints that evolve with questions and scale with data capabilities. If constraints are too broad, queries lose precision; if too fine, extraction loses density; if changes are uncontrolled, history loses semantics. The only anchor among the three is: the question to be answered right now.

After the graph is built, can we just hand the edge list (the set of subject → predicate → object triples) to the model to generate answers? No. Because the information lost by the edge list is exactly what previous chapters worked hard to model: each edge's qualifiers (time, source, confidence, state) and the uncertainty of the extraction itself. When the model gets a bare edge list, all it sees is "there are some connections"; it does not know when the connection holds, which original text it is based on, or whether this edge is confirmed or candidate. Answers generated from it cannot be verified, and errors cannot be located.

The evidence closed-loop architecture clarifies the division of labor between the graph and the original text. The input side is the source documents and their versions. Document chunks first go through entity resolution (same-name disambiguation, stable ID assignment), relation extraction, and time and source binding, entering a temporal graph—Figure 1 shows exactly this construction pipeline from document chunks to the temporal graph. When answering questions, queries obtain structural clues in the graph through path traversal and community aggregation, then mix them with text retrieval, and the model synthesizes the answer.

The division of labor here is:The graph is responsible for pathfinding and aggregation, while the original text spans are responsible for fact verification and correction. The value of the graph is to point out this path—"starting from which entity, passing through which relations, arriving at which entity"—and aggregate structures such as "which entities belong to the same community"; but the final evidence for "whether this edge is true" always lies in the original text. Therefore the evidence closed loop is bidirectional: from the original text into the graph (extraction, binding), and then from the graph back to the original text (retrieval, verification). Every answer path must be able to return to accessible original-text evidence—reviewers following the path in the answer can find the specific sentence supporting each hop; if a hop cannot be returned to, the answer lacks verifiability.

The consequences of not being able to return to the original text hold at the system level: when an extraction error is discovered, it is impossible to locate which segment of text and which extraction went wrong, so targeted repair is impossible; after the original text is updated, it is impossible to determine which edges need synchronized changes. The graph path gives "what the answer might be," while the original text span gives "why this is true" and "where to correct when wrong." Treating the graph as the answer machine and discarding the original text is equivalent to discarding all guarantees of fact quality.

When the CEO changes from A to B, how should the edge for "who is leading the company" in the graph be handled? The easiest approach is to delete the old edge and write a new edge, but what is lost is not just the old fact, but also the ability to answer "which CEOs has the company had in its history" and "when did A's tenure end". Time is a component of facts and must be modeled as a first-class element, not replaced by overwriting.

Temporal modeling requires distinguishing two different time concepts.validFrom and validTo represent the validity interval of the fact itself: the period in the real world from when to when this edge holds.observedAt indicates when the system learned of this fact: the moment evidence enters the corpus and is extracted by the system. The two answer completely different questions—valid interval asks "when is the fact true", observedAt asks "when did we know it". A news item published in 2020 may not be ingested until 2023, so observedAt is later than the fact's occurrence; when an old archive is newly incorporated, observedAt may also be later than the time the fact had long ended. Confusing the two makes it impossible to distinguish "it had not happened yet" from "we did not know it yet".

Temporal updates follow the principle of "close, don't delete". When new evidence shows that the CEO has changed, the correct operation is to write validTo = handover time on the old edge, closing its validity interval, and at the same time create a new edge valid from the handover time onward; the old edge and its historical provenance must be retained in the graph. This way, querying "who was the CEO at that time" at any point in time yields a unique answer, while historical queries can see the complete tenure sequence. Although deleting the old edge keeps the "current CEO" query correct, it permanently destroys the ability to query history—all downstream queries that depend on time intervals lose past information.

Conflicts arise when different sources make contradictory statements about the same fact, and the time intervals overlap. In this case, you cannot silently select one to overwrite another: the conflict itself is valuable information, indicating disagreement or evolution among information sources. The correct approach is to let conflicting edgescoexist, each retaining its sources and marked with conflict status. At query time, decide how to handle them: filter edges by time to those relevant to the question's interval; weight credibility by source authority; choose by purpose—for example, Q&A for the general public can use the statement from the authoritative source, while public opinion analysis precisely needs to expose the disagreement itself. For unresolved conflicts, the system must either present them truthfully to the user or make a choice according to predefined, explicit purpose rules; in no case is silent overwriting allowed.

This yields the complete picture of temporal modeling. The inputs are the fact's validity interval validFrom/validTo, the system's knowledge time observedAt, source authority, and conflict status; the output is a set of edges that can be queried by point in time and can coexist. When a new CEO appears, close the old edge's validity period without deleting historical evidence; observedAt is only the system's knowledge time, not equal to the fact's effective time; when source conflicts are unresolved, they must be displayed or handled by explicit rules. Time allows the same relation to give different answers at different moments, and conflict allows answers at the same moment to retain uncertainty; together they transform the graph from a "static snapshot of current facts" into a "time-evolving, auditable fact record".

Faced with a question, what should the retriever fetch? The shortest path from start to target, or simply hand the model a summary of the entire graph? The answer depends on what type of question it is. GraphRAG retrieval works at three scales—path, neighborhood, and community—each scale corresponds to a type of question, and each scale requires strict size limits.

Entity questions: expand a limited neighborhood from an anchor. "What do we know about X?" questions like this have no predefined path. The retriever first locates the anchor entity X, then expands outward along edges for a few limited hops, using information about X and its neighboring entities and edges as context. The radius of the neighborhood must be limited by hop count; otherwise, when encountering highly connected hub nodes—for example, entities like "United States" and "the Internet" that are referenced by many facts—the neighborhood will instantly balloon and drown out all relevant information.

Multi-hop relationship questions: search for paths constrained by type. "Who is indirectly connected to whom through acquisition relationships?" questions like this have clear structural requirements. The retriever searches the graph for paths that satisfy edge-type constraints: the relationship type of each hop must match the type specified by the question, and path length is limited by the maximum hop count. This is exactly where graphs differ from vector retrieval—instead of returning passages that mention related entities, it returns a path whose every hop can be verified.

Global topic questions: use community detection and hierarchical summaries. "What are the overall research themes in this field and how do they relate to each other?" questions like this have no single anchor; they require a structural view of the entire graph. The retriever runs community detection, clusters entities into communities, then creates hierarchical summaries of the communities, distilling a thematic overview layer by layer.

The three scales share the same discipline:Every expansion must limit hop count, node count, and edge type. Without budget constraints, graph traversal will inevitably hit hub nodes and unbounded expansion—one hop from "some startup" to "United States", and after two hops half the graph is in the neighborhood, relevant information is diluted to nothing, and the model gets noise rather than evidence. Size budget is not a performance optimization; it is a component of retrieval quality.

We must also draw a clear boundary around community summaries. Community summaries are secondary artifacts generated from the graph structure: they condense community content, but the condensation process discards details and is a lossy index. It can be used for navigation—indicating which community is worth diving into and which topic covers what—but must never serve as evidence for final answers. Before answering, the original text corresponding to the path must be retrieved again and verified hop by hop.

Finally, graph retrieval cannot be closed. New facts not yet structured in the graph—information that has just entered the corpus and has not yet been extracted into edges—cannot be found in the graph. Therefore, the output of the graph must be fused with the results of vector retrieval and keyword retrieval: the graph provides interpretable structural clues, vector and keyword retrieval cover content missing from the graph, and original text spans provide the final evidence. The three scales determine "what to take from the graph," fusion determines "what else is outside the graph," and retrieving the original text determines "whether these are true."

Graph retrieval has a natural entry problem: if the question contains no exact entity name—for example, the user asks "Who later acquired that company that made noise-canceling headphones?" rather than "Who did Apple acquire?"—where should the graph start traversing? Graph traversal needs an anchor, and anchor identification is exactly the strength of vector retrieval. This question itself provides the answer: graph and vector are not mutually substitutable relations, but two complementary stages in the workflow.

The input of the hybrid workflow is a natural language question, and the output is candidate evidence that has undergone entity resolution, path constraints, and text reranking, with three intermediate stages.

Vector retrieval is responsible for finding anchors. Problems and corpus paragraphs are vector-matched, returning semantically similar candidate text; from these texts candidate entities are then parsed—"noise-canceling headphone company" corresponds to Beats. When there is no exact entity name, vector retrieval turns the fuzzy natural language question into concrete entity candidates, and graph traversal can start.

After entity resolution, it enters the graph, and the graph is responsible for imposing relationship constraints. After candidate entities enter the graph, the relationship constraint "acquired by whom" in the question becomes an edge type constraint: starting from Beats, traverse the reverse edge of acquired to find Apple. The value of the graph here is structural—not "which texts mention these words", but "there exists a path that satisfies the acquisition relationship".

Text reranking is responsible for selecting evidence. The candidate paths returned by the graph may be more than one, and may also bring in unrelated but connected entities. Use text reranking to score and rank candidate evidence, selecting the path and original text that best match the question. The other direction is also feasible: textualize the graph's neighborhood structure—write the entities and edges near the anchor as a description—and then embed it into the vector space to participate in retrieval, allowing structural information to enter the vector side in text form.

This hybrid approach has two key disciplines. First,retain each recall source, do not discard candidates from the other path just because the graph (or vector) unilaterally hits: each recall path may be the only clue to the answer; when fusing, let them complement each other rather than cover each other. Second,the contribution of each path must be observable: in the evidence for an answer, which parts come from vector recall, which from graph paths, and which from text reranking should be distinguishable. Otherwise the system degrades into a black box, and when errors occur you cannot determine which path to fix.

This also determines how to compare graph and vector. Asking "which is better, graph or vector?" is meaningless—they only make sense when placed underthe same quality, latency, and cost budget, comparing the three configurations "vector-only, graph-only, hybrid" is meaningful. The hybrid configuration usually has higher quality, but graph construction and path queries increase latency and cost; if the budget is strictly limited, vector-only may be the correct choice. The value of complementarity must be quantified and verified under budget constraints, rather than relying on architectural prior preferences.

Does a correct end-to-end QA answer prove that all edges in the graph are correct? No. The model may "guess" the answer from parameter memory when evidence is missing, may find the answer from vector-retrieved snippets and bypass the graph entirely, or the graph may happen to have one correct path but many other edges are wrong. QA accuracy measures the output of the whole system, not the quality of the graph. Graph evaluation must measure build quality and task contribution separately, at three levels.

Build layerDirectly measures how accurate the graph itself is. Compare against gold-standard entities, relations, times, and sources, and compute precision and recall for entity recognition and entity linking, accuracy of relation types and directions, accuracy of time intervals, and alignment of source spans. The question this layer answers is: "For the extracted edges, how many are correct, how many are wrong, and how many are missing compared with the gold standard?"

Query layerMeasures the actual contribution of the graph in the retrieval stage. Metrics include anchor hit rate (whether entities in the question are correctly linked to nodes in the graph), path recall (whether gold-standard paths are retrieved by the graph), evidence correctness (whether the original text corresponding to the path really supports the conclusion), and latency. The question this layer answers is: "When the answer requires the graph, did the graph provide the paths it should?"

Application layerMeasures the value of the entire system to end users. Metrics include end-to-end answer accuracy, citation completeness (whether each hop in the answer can be traced back to the original text), and gain relative to the hybrid retrieval baseline—after enabling the graph, whether and by how much answer quality actually improves. The question this layer answers is: "Does the existence of the graph ultimately make answers better?"

Only by measuring the three layers separately can you locate problems: if the build layer is poor but the application layer is good, the graph is not really being used; if the build layer is good but the query layer is poor, the retrieval strategy has issues; if the query layer is good but the application layer shows no gain, the graph's contribution is diluted in the fusion stage.

In addition, evaluation mustbe sliced by dimensions, rather than only looking at the global average. The four key slices are: path length (the error rate of long paths is much higher than short paths, and the global average hides the fragility of multi-hop), entity popularity (high-popularity entities are mentioned in large amounts of text, and extraction and linking behavior is completely different from long-tail entities), time updates (whether the timing of new facts overwriting old facts is accurate), and conflicts (whether conflict detection and preservation are correct).

Among these, erroneous merging requires dedicated metrics. An erroneous merge of a highly connected entity—for example, merging the company Apple with the fruit apple into a single node—will make all paths through that node wrong at the same time; one wrong merge pollutes dozens of paths. Average edge accuracy is almost insensitive to this nonlinear harm: when 99% of the edges are correct, as long as that 1% of errors happens to fall on hub entities, many queries will still fail systematically. Therefore, erroneous merging must be measured separately, exposed with metrics such as "the proportion of paths affected by erroneous merges" rather than being buried in average accuracy.

The inputs to graph evaluation are gold-standard entities, relations, times, sources, query paths, and final answers; the outputs are three sets of metrics: build layer, query layer, and application layer. A QA system getting the answer right by chance does not prove all edges are correct; average metrics cannot represent all situations—this is the most important difference between graph evaluation and ordinary retrieval evaluation.

If you import a CSV into a graph database and then draw a nice-looking network graph, do you get a Knowledge Graph? No. What this action produces is "a network visualization stored in a graph database", and it is still separated from a Knowledge Graph by five barriers: identity, semantics, time, source, and governance.

These four concepts are at different levels and are often conflated.

A graph database is a storage and query technology. It can store any nodes and edges and provide query capability for traversing along edges, but it does not care whether the identity of a node is stable or whether the semantics of an edge are clear. If you stuff two columns of names and the relationships between them into a graph database, the graph database faithfully stores them and does not judge right or wrong. Its value lies in the efficiency of storage and traversal, not in the quality of the facts.

A network graph is a visual representation. A graphical layout of nodes and edges helps people see the structure clearly, but it only presents what is already in the data. A graph may look richly connected either because there are indeed many relationships in the data or because the extractor produced a large number of noisy edges. Visualization does not change the quality of the facts; what it amplifies depends on what is in the data.

Knowledge Graph, on top of the former two, adds a whole set of requirements: stable entity identity (name disambiguation, stable IDs), explicit relationship semantics (controlled ontology, direction and cardinality), time (validity interval and acquisition time), source (each edge can be traced back to the original text evidence), and governance (conflict handling, schema migration, state management). These are precisely the contents that the previous chapters expanded on item by item. The reverse also holds: a small Knowledge Graph can perfectly well be stored in relational tables—one table for entities, one table for relationships, with time and source as fields—without necessarily needing a dedicated graph database. A graph database is one of the storage options, not a defining element of a Knowledge Graph.

GraphRAG, on the other hand, is a different thing: It is a system pattern that uses a graph index to assist retrieval and generation. In it, the graph plays the role of an index—pathfinding, neighborhood expansion, community aggregation—used to select context for the model. GraphRAG is "the use of graphs", not "the graph itself". A GraphRAG system may contain a very low-quality Knowledge Graph, while a high-quality Knowledge Graph may not be used for retrieval at all.

The input to concept disambiguation is a concrete object—some graph storage, some network visualization, or some GraphRAG system—and the output is its correct positioning in the hierarchy of "graph database / visualization / Knowledge Graph / graph-assisted retrieval". A beginner's typical confusion is to think that "being able to query along edges" equals "the edges express true knowledge". Being able to query along edges only proves that the structure exists, not that the structure is true. To determine whether an object is a Knowledge Graph, do not look at where it is stored or how nice it looks when drawn, but whether it can withstand verification: whether the identity is unique, whether the relationship direction is correct, and whether each edge can be traced back to the original text evidence span. Before verification passes, it is just a pile of connected strings.

Connect the preceding chapters into a complete causal chain. Knowledge graph practice is a cycle: start from questions to define constraints, use constraints to construct verifiable facts, use facts to serve queries, and then use queries and corrections to feed back into the graph itself.

First step: Define a minimal ontology from real multi-hop questions.Everything starts from the questions users actually need to answer. Collect real multi-hop questions and decision needs, and based on them define the minimal entity types, relations, directions, cardinalities, and time rules. An ontology is not an encyclopedia of the world, but a constraint set that exactly supports the target queries.

Second step: Extract candidate entities and relations.Run extraction on the original documents to produce candidate entities and candidate relations. The output of this step is only candidates—identities are not yet confirmed, relations are not yet aligned, and sources are not yet bound.

Third step: Resolve identities and bind original text spans.Assign stable IDs to candidate entities, disambiguate identical names and merge aliases; anchor each candidate relation to the original text span that produced it. Without this step, the graph contains only linked strings, not verifiable facts.

Fourth step: Write time-versioned edges.Write facts with qualifying conditions into the graph: valid interval validFrom/validTo, system acquisition time observedAt, source, confidence, and status. New evidence closes the valid interval of old edges without deleting history; conflicting edges coexist and are marked with status. At this point, the graph becomes a fact record that evolves over time and is auditable.

Fifth step: Establish anchors through entity or text retrieval.When answering a question, if it contains a precise entity name, locate the anchor directly; if there is no entity name, first use vector retrieval to retrieve candidate text, then parse out candidate entities and enter the graph. These two entry points ensure the graph can still be started even for ambiguous questions.

Sixth step: Expand paths, neighborhoods, or communities under constraints.Entity questions expand a limited-hop neighborhood; multi-hop questions search for type-constrained paths; global topic questions use community detection and hierarchical summaries. Each expansion step limits hop count, node count, and edge types to prevent hub nodes and unbounded expansion from drowning relevant information.

Seventh step: Retrieve the original text and generate cited answers.The graph path provides only structural clues; community summaries are lossy indexes and cannot serve as final evidence. Follow the path back to the original text spans, fuse with vector and keyword retrieval results, and generate cited answers—every hop in the answer can be traced back to the original text.

Eighth step: Update the graph with corrections and new evidence.Errors exposed by evaluation, erroneous merges discovered during review, and new facts from the corpus all flow back into the graph as an update stream: correct extractions, close expired intervals, and write new edges. This step turns a one-time pipeline into a continuously running loop.

Every link in this chain depends on the previous link holding: the ontology constrains what extraction can produce, identity and source determine whether edges are verifiable, time and status determine whether the graph can answer "when", anchors and expansion determine whether queries can hit, original text retrieval determines whether answers can be verified, and updates keep all links continuously valid over time. Cut any link—without ontology you lose semantics, without source you lose evidence, without time you lose history, without budget you lose precision—the value of the entire chain breaks at that link. The total cost of a knowledge graph is exactly what is paid to maintain the integrity of this chain; all its benefits also come from every link in this chain being traceable, verifiable, and correctable.