Preserve identity and sources in graph assertions

Learning objective

Model typed entities, relationships, and provenance in a knowledge graph.

Core idea

A knowledge graph makes relationships explicit enough to traverse. A supplier owns a facility; the facility produces a component; the component appears in a product. These are different relationships between different types of entity. A graph can connect them across documents without relying on their descriptions being semantically similar.

The design challenge is preserving what each connection means. Two organizations with the same display name must not become one entity. A proposed acquisition must not become completed ownership. A relationship extracted from a report must remain attributable to that report. Design identity, types, and provenance together before optimizing retrieval.

NVIDIA’s Context-Aware RAG implementation provides a concrete reference: graph_ingestion configures entity extraction, while its Neo4j storage separates Document, Chunk, and extracted entities. These are useful implementation mechanisms, but a production domain model still needs your business definitions.

How it works

Define identities and permitted relationships

Begin with the questions the assistant must answer. For a supplier-impact assistant, define application node types such as Supplier, Facility, Component, and Product. Define directed predicates such as OPERATES, PRODUCES, and CONTAINS, including the permitted source and target types. These names are an example application vocabulary, not NVIDIA configuration enum values.

Give each entity an identifier derived from an authoritative business record where possible. Store names as attributes and aliases. A spelling change should update an alias, while two distinct supplier registrations remain distinct entities even if their names match. Merging on a display name changes every path that passes through that node.

A predicate’s direction is part of its meaning. Facility PRODUCES Component does not mean that a component operates the facility. Similarly, Supplier OPERATES Facility and Supplier OWNS Facility are different assertions. Define both only if the source material supports that distinction and the questions need it.

NVIDIA exposes node_types and relationship_types under the ingestion function’s params. Its documented default node types are Person, Vehicle, Location, and Object, reflecting its video-oriented vocabulary. Its extraction base passes the lists to LangChain’s LLMGraphTransformer, imported from langchain_experimental, as allowed_nodes and allowed_relationships. The documented default for disable_entity_description is true; in that mode, the implementation clears both lists. Setting the lists alone therefore does not establish enforcement. Set disable_entity_description: false to pass them through on the normal path; the fallback described in 1.7.2 can still remove them.

Separate a fact from its supporting text

Provenance answers a different question from identity: where did this assertion come from? NVIDIA’s Neo4j implementation stores chunk text and metadata on Chunk, connects a chunk to its Document using PART_OF, and connects chunks to extracted entities using HAS_ENTITY. The ingestion base uses a chunk hash when creating those entity links.

This structure lets you retrieve the text around an entity. It does not, by itself, identify the exact sentence supporting every relationship between two entities. A chunk might mention two suppliers without asserting ownership between them. Preserve assertion-level support when your answers must justify a particular edge.

For example, define an application assertion record with subject_id, predicate, object_id, source_document_id, source_revision, and source_span. These are proposed application fields. Keep that record beside the business edge, or represent the assertion as a node linked to its endpoints and source. The span identifies the supporting passage; the revision prevents a citation from silently pointing into changed text.

A chunk links to the entities it mentions; an assertion node links one edge’s endpoints to its source.

Keep extraction metadata distinct from business time. An application field such as extracted_at says when processing happened; valid_from and valid_to describe when the business relationship holds. A report ingested today can describe a facility operated by another company last year. Treating ingestion time as business validity produces incorrect temporal paths.

Preserve disagreements without corrupting identity

Two documents can disagree about the same relationship. Keep their assertions independently attributable until a domain owner resolves the conflict. Do not create a second supplier merely because a source disputes ownership, and do not overwrite one source with the last extraction to finish.

Choose the assertion representation based on the questions. A direct edge with source properties is compact when one assertion has one support record. An assertion node handles multiple supporting documents, conflicting claims, and different validity periods more explicitly, at the cost of more nodes and joins. Your ingestion adapter owns that representation; the extraction model proposes content rather than deciding corporate identity.

Key distinctions and trade-offs

The following choices change what a traversal can safely mean:

A restrictive vocabulary improves consistency but can discard important relationships outside the schema. An unrestricted vocabulary captures more candidate content but creates synonymous predicates that fragment traversal. Assign vocabulary changes to the domain data owner, with extraction validation handled in 1.7.2.

Architecture / decision scenario

A manufacturing procurement assistant must identify products exposed to a supplier shutdown. It processes 12,000 reports, including two suppliers named Meridian with different registration identifiers. Procurement requires each reported dependency to cite the report revision and passage; it accepts a 24-hour ingestion delay.

The tempting design merges matching names and stores only generic RELATED_TO edges. It is cheaper to ingest, but merges the two suppliers and cannot distinguish facility operation from component production. A path through the wrong Meridian would incorrectly flag products for a recall investigation.

The procurement data owner chooses canonical supplier identifiers and typed endpoints. The platform team retains Document and Chunk context using PART_OF and HAS_ENTITY, then adds application assertion records for exact source spans and validity. Extraction results with unresolved identity remain outside the published dependency graph. The daily processing window makes that resolution practical.

A later report changes the facility operator. The team closes the previous assertion’s validity period and records the replacement with its own source. Historical questions retain the previous path; today’s impact analysis selects the valid assertions. Retrieval tuning cannot repair a graph that merged identities or discarded this history.

Common exam traps

• Treating entity names as globally unique identifiers.
• Interpreting every relationship as symmetric or transitive.
• Confusing a chunk mentioning two entities with support for an edge between them.
• Assuming node_types enforces types under the default disable_entity_description: true.
• Replacing conflicting assertions without retaining their sources.

What to remember

Model entities by stable identity, relationships by explicit meaning, and assertions by attributable support. NVIDIA’s Chunk, Document, PART_OF, and HAS_ENTITY provide source context; assertion-level provenance and business validity make that context usable for defensible relational answers.

Knowledge check

References

• NVIDIA, Context-Aware RAG configuration
• NVIDIA, Graph ingestion base implementation
• NVIDIA, Neo4j storage implementation