Self-Healing Knowledge Graphs: Graphs That Fix Themselves

Provenance is not truth. A triple can be perfectly traced to a published source and still be wrong — contradicted by a later signal, inconsistent with the schema, or hallucinated by the model that extracted it. The industry has spent years building better provenance; the harder problem is what to do when provenance says the fact is sourced but the fact is still garbage. The sharpest 2026 statement of this is TGComplete, which finds that most gold-correct edges have no supporting passage even under exhaustive retrieval — so textual verification measures provenance, not correctness (Kang et al., 2026, arXiv:2606.15833).

This is article #3 in the Autonomous Knowledge Graphs series, and it is a guardrail. Where #1 builds the lead and account graph and #2 reasons over it, this article keeps it accurate over time. It obeys the same fleet constraints — LangGraph control, Cloudflare data, LangSmith observability, DeepSeek-only egress, a ≥ 0.80 eval bar, grounding-first provenance, draft-first approval — and runs as a background sweep over the stored graph.

Loading diagram…

The Two Conflated Lineages

Most "error correction" systems are answer-side filters and graph-side verifiers, not graph repairers. KGHaluBench classifies model responses as aligned, hallucinated, or abstained by cross-checking against a static graph (Robertson et al., 2026, arXiv:2602.19643); FactCheck benchmarks LLMs for validating KG facts via internal knowledge, RAG evidence, and multi-model consensus (Shami et al., 2026, arXiv:2602.10748); and SHARP is a training-free agent that verifies triples with schema-aware planning plus external evidence — surfacing contradictions without itself rewriting the graph (Ma et al., 2026, arXiv:2604.04190). All three tell you a fact is wrong; none repairs the store, so the same wrong fact keeps triggering errors. On the other side are systems that actually modify the stored graph: Better Later Than Sooner applies a post-extraction stage that detects and repairs facts violating ontology or commonsense constraints (Loconte et al., 2026, arXiv:2605.29168). The distinction matters: detection and answer-side fixes are cheap but leave the store polluted; graph-side repair compounds its benefit over every future query. This design pairs SHARP-style verification with an explicit repair-and-reinstate step.

Reference Architecture: Detect → Repair → Verify-or-Abstain

The design anchors on a three-stage loop in LangGraph that sweeps the stored lead/account graph at configurable intervals. Detect identifies candidate issues; Repair applies invalidation-first corrections; Verify-or-abstain decides whether the repaired triple is committed, quarantined, or left invalidated. The gate is the load-bearing part: no repair is final until it clears a confidence threshold and has a retrievable evidence span — mirroring SHARP, where the agent must return a source for every verification step.

Detection Signals: Three Classes

Detection is deliberately bounded to 3 classes — unbounded anomaly detection drives false-positive rates high:

1. Schema/type violations — e.g. a triple asserting hasType → Customer when the ontology declares the range Account. Caught with shape checks against the maintained schema; the multi-LLM consensus of Clinical KG construction validates types at build time (Das et al., 2026, arXiv:2601.01844), and this loop checks post-hoc.
2. Contradictory edges on the same subject + relation — two foundedIn values for one company. The pass groups triples by subject+predicate and flags any group whose object values differ while both clear the confidence floor.
3. Low-provenance edges — extraction confidence below 0.6 and no source passage retrievable above a 0.5 cosine threshold. This catches "out of thin air" hallucinations.

Repair: Invalidation Is Not Deletion

Every detected violation is handled by stamping invalid_at with the current timestamp. No destructive delete occurs; the triple stays in the graph but is non-queryable by default, and a future sweep may reprieve it. A repair lands only if it clears two conditions: a 0.6 confidence gate (a DeepSeek ranker scores the triple, the violation type, and the proposed fix) and a retrievable evidence span supporting the new state. If no evidence span is found, no repair is attempted — the triple is simply kept invalidated and revisited on the next sweep. When a repair is proposed, the fleet's ≥ 0.80 verification bar governs whether it is reinstated or sent to quarantine, so the 0.6–0.8 deadband is exactly where borderline repairs wait for a human — an intentional safety net.

The Gate: Verify-or-Abstain

Verification maps to the same tripartite outcome KGHaluBench uses:

• Aligned (pass) — the repaired triple plus its evidence span clears 0.80 on a judge prompt; the invalid_at stamp is removed and the triple is reinstated.
• Hallucinated (fail) — the judge finds inconsistency with the evidence or with other active triples; the triple stays invalidated until a later sweep revisits it.
• Abstained (quarantine) — the judge cannot reach the threshold; the triple moves to a quarantine store flagged for review, with metadata preserved for audit.

The gate runs after every repair, and on a sample of unchanged triples each sweep to catch what detection missed — a continuous validator that both corrects and re-validates.

Provenance ≠ Correctness

The corpus repeatedly shows provenance is necessary but insufficient. TGComplete makes the point quantitatively — verifiability tracks provenance, not truth — and argues for verify-or-abstain over recall-maximizing completion (Kang et al., 2026). SHARP's schema-aware planning reveals contradictions pure provenance tracking misses, and Better Later Than Sooner catches ontology violations after extraction. The design's separation of detection (cheap, deterministic rules) from verification (an expensive judge with evidence) mirrors this: the lower 0.6 repair gate maximizes recall by attempting repairs, while the 0.80 verification gate controls precision by catching the mistakes.

Failure Modes

1. Over-aggressive detection. Schema rules can fire on harmless typos, forcing re-verification against an evidence span that may not exist — inflating quarantine load.
2. Gate too conservative. A 0.6 repair gate leaves true positives just below it (a 0.59) unrepaired; the loop abstains when it could act.
3. Evidence-span staleness. The corpus may have changed since extraction while the evidence index lags, so the judge can reject a correct repair whose passage now reads differently.
4. Cross-class gluing. A triple that is both a type violation and a contradiction may have only one issue repaired, leaving the other for the next sweep.

These argue for monitoring, adjustable thresholds, and a human-review queue — repair rates, gate pass rates, and quarantine growth per source are tracked in LangSmith.

Numbered Limitations

1. Detection scope. Only 3 classes are implemented; numeric contradictions, temporal decay, and cardinality violations are not detected, and adding them increases latency.
2. Static thresholds. The 0.6 repair gate and 0.80 verification gate are fixed; per-predicate dynamic thresholds are not implemented.
3. Evidence-retrieval bottleneck. Each repair needs an evidence-span search, so a full re-scan of a large graph per candidate is prohibitive — the sweep operates on a bounded sample per run rather than the whole graph.
4. Model dependency. The loop runs on DeepSeek only; if calibration drifts, both the confidence gate and the judge degrade together, and no cross-model validation is performed.
5. No temporal recovery. Invalidation stamps handle point-in-time corrections; a fact corrected now but re-acquired later through another channel may be duplicated.
6. Quarantine growth. Without an effective human-review feedback loop, quarantine accumulates; the design assumes a data steward works the queue.

Decision Table: Invalidate vs Delete vs Quarantine

Condition	Action	Why
Repair clears 0.6 + evidence + verification ≥ 0.80	Invalidate-then-reinstate	passes the second gate; safe for high-stakes use
Repair clears 0.6 + evidence, verification 0.6–0.79	Quarantine	preserved but not exposed; routed to human audit
Confidence < 0.6 OR no evidence	Invalidate (no repair)	no new error introduced; deferred to next sweep
Exact duplicate of a confirmed live triple	Delete	the only case where erasure is safe — identity is certain

Invalidation is the default for all detected issues; deletion is reserved for ID-confirmed duplicates; quarantine holds the ambiguous high-confidence repairs that cannot clear the gate.

Conclusion

Self-healing is not a one-time engineering feat but a commitment to continuous maintenance. The 2026 corpus — from SHARP's schema-aware verification to KGHaluBench's abstain framework and TGComplete's provenance-vs-truth result — points to a future where graphs are never fully clean but always getting cleaner. The measure of a healthy graph is not its initial quality but the rate at which it recovers from its own errors. The practical takeaway: invest in verification as heavily as in detection, make invalidation the default, and keep a human on the quarantine queue — the canary for systematic extraction failures no automated loop can yet correct.

Frequently Asked Questions

What is a self-healing knowledge graph? It runs a background loop that detects errors in the stored graph, repairs them, and verifies the repair against evidence — fixing the graph itself rather than only patching a downstream answer. The 2026 canonical scaffold is detect, repair, then inconsistency-tolerant reasoning.

Why is repairing the graph different from repairing the answer? Answer-side filters patch one response without touching the store, so the same wrong fact keeps triggering errors. Repairing the stored graph compounds its benefit across all future queries.

What does "provenance is not truth" mean for KG repair? A triple can be traced to a source and still be wrong. TGComplete shows most gold-correct edges have no supporting passage even under exhaustive retrieval, so textual verification measures provenance, not correctness — the safe response is verify-or-abstain.

Does the loop ever delete data? No, except exact duplicates confirmed by ID. Every detected issue is handled by stamping invalid_at, so the triple becomes non-queryable but stays for audit and possible reinstatement.

How does the loop avoid making things worse? A repair lands only if it clears a 0.6 confidence gate AND has a retrievable evidence span; a final 0.80 verification gate decides reinstate vs keep-invalidated vs quarantine. The deadband between the gates is where borderline cases wait for a person.

Autonomous Knowledge Graphs — the series

1. Autonomous Knowledge Graph Construction: Graphs That Build Themselves (autonomy: high)
2. Reasoning Over the Graph: From GraphRAG to Planning Agents (autonomy: high)
3. Self-Healing Knowledge Graphs: Graphs That Fix Themselves (this article — guardrail)
4. The Graph as Agent Memory (autonomy: medium)
5. Closing the Loop: Evaluation, Debate, and Discovery (guardrail)

A companion thread to The Autonomous Sales Fleet. Next: #4 The Graph as Agent Memory.

References

• Yongqi Kang, Yu Fu, Yong Zhao. When Correct Edges Cannot Be Verified: A Provenance Gap in Incomplete KGQA and a Provenance-Favoring Completion Policy (TGComplete). 2026. arXiv:2606.15833. https://arxiv.org/abs/2606.15833
• Xinyan Ma et al. Schema-Aware Planning and Hybrid Knowledge Toolset for Reliable Knowledge Graph Triple Verification (SHARP). 2026. arXiv:2604.04190. https://arxiv.org/abs/2604.04190
• Lorenzo Loconte, Timothy Hospedales, Cristina Cornelio. Better Later Than Sooner: Neuro-Symbolic Knowledge Graph Construction via Ontology-grounded Post-extraction Correction. 2026. arXiv:2605.29168. https://arxiv.org/abs/2605.29168
• Alex Robertson et al. KGHaluBench: A Knowledge Graph-Based Hallucination Benchmark for Evaluating the Breadth and Depth of LLM Knowledge. 2026. arXiv:2602.19643. https://arxiv.org/abs/2602.19643
• Farzad Shami, Stefano Marchesin, Gianmaria Silvello. Benchmarking Large Language Models for Knowledge Graph Validation (FactCheck). 2026. arXiv:2602.10748. https://arxiv.org/abs/2602.10748
• Udiptaman Das, Krishnasai B. Atmakuri, Duy Ho, Chi Lee, Yugyung Lee. Clinical Knowledge Graph Construction and Evaluation with Multi-LLMs via Retrieval-Augmented Generation. 2026. arXiv:2601.01844. https://arxiv.org/abs/2601.01844