Skip to content

Created 2026-09-01. TTL: 90 days (expires 2026-11-30). Answers the Context Embedding Research Brief.

Context Embedding in Claims: Verdict and Design Mapping

The RAG technique is real, measured, and cheap, and it transfers to Indra, but to two different places than the analogy suggests. Contextual retrieval improves candidate generation (it is a recall technique), while Agus's proposal targets match judgment (a precision decision). Both applications are supported: contextual embeddings for the future pgvector candidate search, and contextual evidence for an LLM judge at the evidence/critical-mass stage. The judge must be confined to evidence links and promotion input; it never mints member links directly, or invariant 3 (identity from member links only) dies quietly.

Confidence: high on the RAG mechanics (primary source, published numbers); medium on the entity-matching transfer (a converging 2024-2026 literature, little published production evidence).

Q1. Mechanics of contextual retrieval in RAG

Anthropic's contextual retrieval is the canonical form (Anthropic, Sept 2024):

  • A small model (Claude Haiku) receives the whole document plus one chunk and writes 50-100 tokens of situating context ("this chunk is from an SEC filing on ACME's Q2 2023 performance; the previous quarter's revenue was..."). The context is prepended to the chunk before both embedding and BM25 indexing.
  • Cost with prompt caching (the document stays cached across its chunks): about $1.02 per million document tokens.
  • Measured retrieval failure-rate reduction: 35% from contextual embeddings alone (5.7% to 3.7%), 49% adding contextual BM25 (to 2.9%), 67% adding reranking (to 1.9%).
  • Stated limitation: below roughly 200K tokens of corpus, skip retrieval entirely and put the corpus in the prompt.

Variants, and why they matter less here (futureagi overview, Reconstructing Context, arXiv 2504.19754):

  • Late chunking embeds the whole document first and pools per-chunk vectors: cheaper, no generation step, but context is implicit in the vector and cannot be shown to an LLM judge. Wrong fit: Indra wants the context as text evidence, not only as embedding geometry.
  • RAPTOR builds a recursive summary tree: useful for multi-hop question answering, not for per-claim provenance.
  • Parent-document retrieval returns the parent when a child chunk hits: the child chunks stay context-poor "semantic islands", which is exactly the failure the explicit summary avoids.

The explicit generated-summary variant is the right analog: it produces an artifact (text) that serves both embedding enrichment and judge input.

Q2. Transfer to entity matching

The entity-resolution field is moving the same direction: exact and probabilistic matching for the cheap bulk, LLM judgment with retrieved context for the ambiguous residue (The Rise of Semantic Entity Resolution, TDS, Tilores: Can LLMs be used for Entity Resolution?). Relevant findings:

  • RAG-style entity matching with blocking first (only ambiguous pairs reach the LLM) is the standard cost control (Cost-Efficient RAG for Entity Matching, arXiv 2602.05708). This maps one-to-one onto Indra's tiers: identifying claims short-circuit, and only the non-identifying evidence band would ever reach a judge.
  • Clustering candidates in one prompt instead of pairwise calls cuts LLM calls up to 5x at comparable accuracy (In-context Clustering-based ER, SIGMOD 2026). Relevant later, when one partial has several candidate entities: one judge call over the whole candidate set, not N pairwise calls.
  • LLM self-explanations for match decisions are not reliably faithful (arXiv 2606.01210): store the judge's verdict and its cited context as provenance, but do not treat its stated reasoning as ground truth.

Net: the literature supports an LLM judge that consumes claim text plus situating context and outputs a membership verdict with confidence, at the ambiguous stage only.

Q3. Where summaries are generated

  • Two levels, matching the composition model: one summary per Source (generated once at ingestion, cached forever since sources are immutable) and one per Event (generated at composition, keyed by the set of source ids). The event summary is the situating context; the source summary is its input and also serves sources reused across events.
  • Storage: SourceSummary and EventSummary rows keyed by (source_id | event_id, summarizer_version). Nothing attaches to Claim; claims already reach their context through lineage (claim, partial, event, sources). Re-runnable by version bump, consistent with the append-only principle.
  • Cost: at contextual-retrieval prices (about $1 per million tokens with caching, small model via OpenRouter), Helmi's ingest volume makes this a rounding error. Generate eagerly at ingestion; lazy generation saves nothing and adds a failure mode at match time.
  • Principle amendment required: the README states the core is deterministic and only extraction touches an LLM. Summarization becomes a second LLM stage. Amend the principle to "ingestion, composition, parsing, and normalization are deterministic; summarization and extraction are the LLM stages, both versioned and re-runnable" rather than hiding the summary step inside extraction.

Q4. Risks and guardrails

  1. Invariant erosion is the real risk. A judge that can create member links converts one hallucinated summary into identity poisoning. Guardrail: judge output may only create or strengthen evidence links and feed the critical-mass consistency input. Member links still come only from identifying exact matches or promotion.
  2. Context skew: a bad event summary biases every claim from that event the same way. Mitigation: summaries are versioned; the judge receives raw claim text alongside the summary, never the summary alone.
  3. Eval before trust: build a scored dataset of judge decisions (Langfuse, anonymized per the standing rule) before the judge influences promotion. The extraction-metrics deliverable already planned should add two numbers: how often the ambiguous band occurs, and judge agreement with human labels on a sample.
  4. Not v1 scope. This slots into matching/resolution, which is deliberately last. What v1 should do now is cheap: store source and event summaries from the start so the corpus is context-rich when matching is built. Backfill is possible (stages re-run), but eager generation costs near nothing.

Recommendation

Adopt, scoped: add SourceSummary and EventSummary to v1 ingestion/composition (eager, versioned, small model via OpenRouter); amend the deterministic-core principle; defer the LLM judge to the entity-resolution phase, gated on the eval dataset.

Decision (Agus, 2026-09-01): the resolution judge

The judge lives in the entity-resolution phase only. Trigger: a new evidence link lands on an entity. The judge then tries to resolve that entity's existing evidence relationships: it compares what is known for sure about the entity (member claims plus their situating context) against the claims and context of each evidence partial, and returns one verdict per evidence link:

  • promote: the evidence partial belongs; the applier runs the standard evidence-to-member promotion transaction.
  • supersede: the link is judged unrelated; the applier supersedes it (superseded_reason: judged_unrelated). Never a delete.
  • inconclusive: leave the link active and wait for more evidence.

Guardrails: every verdict is recorded with model and prompt version and the inputs it saw; the judge runs in shadow mode (verdicts logged, not applied) until it clears the eval dataset; the raw claim text always accompanies the summaries in its input.