02.1
Graph Structure and Knowledge Claims
A graph consists of nodes and edges, but a knowledge graph must additionally explain what its nodes denote, what its edges mean, and in which context a record applies. A service counter, a dish, and an ingredient can be represented as different entities, while serves and contains can be directed relationships. A name is an attribute of an entity rather than a complete identity. Two dishes with the same name can belong to different merchants, recipes, or time periods. If identical names are treated as identical entities, an apparently plausible path can connect objects that should remain separate. Stable identifiers, types, and source constraints are prerequisites for useful graph retrieval. [R15][R16]
The claim represented by a record should also be distinguished from the form in which it is stored. A record stating that a dish contains peanuts is a source-attributed assertion. Encoding it as an edge changes its representation without verifying its truth. A graph makes connections queryable, composable, and inspectable; it does not automatically transform text into established knowledge. We therefore treat an entity relationship graph as a computational structure of claims and require supporting material for important edges. After retrieving a path, a generative system still has to determine whether the meanings of its relationships answer the question. Connectivity alone is insufficient. A path can be mathematically valid while being semantically irrelevant, temporally inconsistent, or supported by evidence that does not apply to the object under discussion.
02.2
Ontology and Relationship Granularity
An ontology provides shared conventions for entity types, relationship types, and applicable constraints. Its design should begin with the questions to be answered and then determine which objects need independent identity. Cuisine can be stored as an attribute when the only requirement is filtering dishes. If the system must maintain cuisine hierarchies, aliases, and research sources, representing cuisines as entities can be more useful. There is no task-independent optimal representation. Excessive detail increases annotation and maintenance costs, while excessive aggregation removes distinctions needed by the questions. Appropriate granularity depends on the relationship among queries, evidence, and responsibility for updates.
Relationships involving several participants are particularly vulnerable to distortion when compressed into a simple binary edge. A merchant serving a specific recipe on a particular date involves a merchant, a date, a dish version, and a supply status. Storing only merchant serves dish loses the period of validity. A supply record or menu version can instead be represented as an intermediate object to which time and provenance are attached. Likewise, a region belongs to an image and is classified as an ingredient by a particular model. That observation should remain distinct from an ingredient documented in the dish's actual recipe. This report recommends making observation, assertion, inference, and confirmation explicit in the relationship scheme. Doing so preserves an inspectable transition between visual recognition and business facts, rather than silently converting every model prediction into an authoritative property of the world.
02.3
Provenance Records and Traceable Chains
Provenance should explain where a piece of knowledge came from, how it was processed, which person or system produced it, and when it applies. The W3C PROV framework supplies concepts including entities, activities, and agents for describing production and derivation. An application need not adopt every element of a standard, but it should retain enough information for a conclusion to be traced to a document, page, image region, or original record. A link to a website's home page is usually inadequate for fine-grained verification. [R28]
In GraphRAG, source text, extracted relationships, community reports, and final answers form a chain of derived objects. When an answer cites a community report, the reader should be able to continue to the passages supporting that report. A multimodal system must additionally preserve image versions, crop coordinates, and recognition outputs. Otherwise an updated image can leave an old region reference without a meaningful target. We propose recording the input identifier, model or rule version, output identifier, and status for each processing activity. A withdrawn or corrected source can then be connected to the relationships, summaries, and caches that depend on it. Such a chain creates conditions for inspection; it does not establish that the original source is reliable. Independent factual verification and auditing the derivation process remain separate activities. A well-recorded transformation can faithfully preserve an unreliable claim, which is why both activities need an explicit place in the system.
Original design
02.4
Entity Identity and Ambiguity Resolution
Entity alignment begins with an identity decision rather than with a similarity calculation. The same name can refer to different objects, and different names can refer to the same object. Ingredient aliases, abbreviated organization names, people sharing a name, and product versions create different ambiguity patterns. They should not be governed by one unvalidated merge rule. Candidate generation can use names, context, relationship neighborhoods, or visual features, but a merge decision should also satisfy domain constraints. Records with incompatible periods of validity should not be merged merely because their embeddings are close. Nor should an image labeled only as vegetables automatically be assigned a specific ingredient identity. [R16][R22]
We recommend separating confirmed identity, candidate association, and confirmed difference. Candidate associations can support recall, but should not silently support conclusions that require exact identity. A merge should preserve original identifiers and a reversible mapping rather than deleting the former records. Splitting and correction deserve equal attention, because an incorrect merge can propagate relationships through the wrong identity. Multimodal information offers additional clues and additional opportunities for ambiguity. An image may depict several objects while the accompanying text mentions only one. An illustration may be representative rather than a photograph of the exact item described. Consequently, an image-text pairing does not imply a one-to-one correspondence between every visual object and a textual entity. An alignment record should state the scope of the correspondence and retain unresolved cases for examination.
02.5
Storage Structures and Retrieval Interfaces
Graph storage, a vector index, and a repository of original assets can perform complementary functions. The graph preserves explicit relationships and constraints. The vector index generates candidates through semantic or visual similarity. The asset repository retains full documents and high-resolution images. Separating these responsibilities does not necessarily require three different products. It requires a clear account of ownership, update behavior, and query semantics for each category of data. A relational database can represent some graph structures, and a graph database can provide vector retrieval. Research comparisons should therefore examine models and query behavior instead of inferring performance from a database category alone.
A retrieval interface should ideally return typed evidence objects rather than only a concatenated block of prose. An evidence object can carry entity identifiers, relationships, source locations, time, permissions, and an uncertainty status. The generation layer can use this information to formulate a qualified conclusion, while the audit layer can determine whether the answer used applicable material. For an image requiring review, the interface should preserve the connection between a region and the original image instead of exposing only an opaque vector score. We treat this evidence interface as a stable architectural contract. Models and storage systems can change, but supporting information must continue to move in an inspectable form. If an interface converts structure into prose too early, downstream components may be unable to recover the constraints that were discarded. Keeping these constraints explicit makes both integration and debugging more reliable.
02.6
Graph Quality and Query Boundaries
Graph quality involves coverage, correctness, consistency, timeliness, and completeness of provenance. These dimensions can pull in different directions. Increasing the recall of automatic extraction may introduce additional incorrect edges, whereas strict filtering may remove rare but important relationships. A highly connected graph can also be dominated by overly broad labels that are unsuitable for specific questions. Node counts, edge counts, and connectivity can monitor changes in the data, but they cannot independently establish knowledge quality. Evaluation should begin with actual queries and examine whether the relevant objects, relationships, and evidence have been preserved at an appropriate granularity.
The interpretation of a missing edge is especially important. In an open collection of material, failing to find a relationship normally means that the system lacks sufficient records. It does not establish that the relationship is false in the world. Absence can be interpreted as negation only when the data scope, collection completeness, and domain rules justify a closed interpretation. Path length is likewise no substitute for reasoning quality. A short path can be semantically wrong, while a longer one may retain essential time or provenance conditions. We recommend that the query layer explicitly distinguish positive evidence, negative evidence, unknown information, and conflict, and that the answer layer preserve those distinctions. This enables a system to explain evidential insufficiency rather than filling gaps in its graph with confident conclusions. The ability to represent uncertainty is part of the knowledge model, not merely a wording preference at the end of generation.