Source units, extraction, and claim lineage

GraphRAG quality is bounded by its source units. A source unit is a stable, citable span of an input document with enough surrounding structure to interpret it. Units that are too large waste context and mix unrelated claims; units that are too small lose definitions, subjects, negation, tables, and temporal qualifiers. Chunking is therefore a semantic and evaluation decision, not merely a character count.

Capture document hierarchy before chunking: title, section path, page, table coordinates, list nesting, speaker, timestamps, and access classification. Use deterministic unit identifiers derived from document version and offsets or a stored idempotency key. Overlap can preserve boundary context, but it also duplicates claims and distorts frequency. Record parent document and neighboring units rather than relying on large overlap to restore all structure.

Entity extraction proposes mentions, types, and normalized names. Relationship extraction proposes typed links with direction and participating mentions. Claim extraction should retain polarity, modality, time, scope, and attribution. “The audit found no evidence that Vendor A accessed records” must not become Vendor A—accessed→records. “Team B may migrate Service C next quarter” is neither a completed migration nor a firm date. Extraction schemas need explicit unknown and not-applicable states.

Use typed structured output and validate it before graph construction. Every entity mention should point to source offsets. Every relationship should cite supporting spans for both endpoints and relation language. Every claim should carry extractor model, prompt or rule version, run identifier, confidence method, and validation outcome. Reject output that references nonexistent offsets or unsupported enumerated types. Do not repair invalid JSON by guessing consequential fields.

Separate mention extraction from entity resolution. A mention “Mercury” in two units does not prove one entity. Create mention nodes or records first, then resolve them with local context, document metadata, known identifiers, and graph constraints. This lets a later resolution fix reconnect claims without re-extracting the source text and avoids baking ambiguous identity into embeddings and communities.

Relationships need an ontology small enough to extract consistently. An unconstrained “related_to” edge creates dense but uninformative graphs. An excessively detailed schema forces the model to hallucinate distinctions. Begin with relations that support query plans and evaluation. Provide definitions, positive and counterexamples, directionality, and allowed endpoint types. Map extractor labels to the governed ontology through a versioned layer rather than letting prompts define permanent vocabulary.

Use multiple passes only for measured needs. A first pass may identify candidate entities; a second can extract relations using those candidates; a verifier can check each proposal against its span. Self-consistency can raise cost without producing independent evidence because the same model and prompt share errors. Human review should sample high-impact, low-confidence, novel-type, and disagreement cases.

Tables, figures, code, and scanned pages require specialized processing. A table cell needs row and column headers. An OCR fragment needs page coordinates and confidence. A diagram relation inferred from layout should be labeled as generated from a visual parse. When a representation cannot preserve enough evidence, retain it for a separate multimodal path rather than inventing a clean text claim.

Evaluate extraction per field and per consequence. Entity mention precision and recall, type accuracy, relation endpoint accuracy, direction, temporal qualifier accuracy, negation, and evidence-span overlap reveal different failures. Slice by document type, language, length, tables, and entity frequency. Also measure graph-level effects: orphan rate, generic-edge rate, degree explosions, duplicate claims, and unsupported edges.

Lineage is the invariant. A graph edge should lead to a validated extraction record, exact source unit, immutable document version, and authorized original artifact. Community reports and final answers should preserve that chain. If one stage cannot emit lineage, its artifact should not support a consequential answer.