Across 10+ knowledge graph systems studied, almost nobody has solved knowledge evolution well. This is the biggest unsolved problem in the space. Most systems are append-only — they grow but never prune, merge, or update. The few that attempt evolution either go too far (StixDB’s auto-decay with 48-hour half-life actively destroys knowledge) or not far enough (Pal’s linter agent is aspirational code that depends on LLM choosing to act).
Our own /connect skill is the closest thing to systematic maintenance across the systems studied, but it only adds links — it doesn’t prune outdated insights, merge near-duplicates, or detect contradictions. This means every knowledge graph, including ours, accumulates noise over time. Nodes that were accurate when written may become outdated or contradicted by newer insights, but nothing in the system surfaces this.
The contradiction detection problem is particularly important: two insights that directly contradict each other are both invisible to the graph unless explicitly linked. Per our design decision, Evolving summaries beat append-only memory — rewrite profiles, don't accumulate facts captures one evolution strategy — rewriting profiles instead of appending — but this only works for summaries, not for atomic insights. The Context layers must be living systems, not static artifacts insight articulates the principle (context layers need self-updating feedback loops) but no system we studied has actually implemented this for a curated graph. The Verification is a Red Queen race — optimizing against a fixed eval contaminates it pattern applies here too: any automated quality check on a graph will degrade as the graph learns to pass it.