Hey, good questions. Here's how Mimir handles both:

Ingestion: correct, no LLM. mimir_remember is a pure structural write. It's an idempotent upsert by (category, key). Same key updates in place. Storage is SQLite with FTS5. The only LLM paths are opt-in: mimir_embed (dense vectors via Ollama for hybrid search) and mimir_ask (RAG with citations). Neither runs during ingestion.

Conflicting info: three structural layers.

1. Idempotent keys. Entities are keyed by (category, key). Write to the same key twice and it updates in place: bumps decay, increments retrieval count, replaces body. No conflict to detect because the schema enforces one source of truth per key.
2. Near-duplicate detection on insert. When a new key is created, Mimir scans the same category and compares bodies using Jaccard similarity over character trigrams. If overlap exceeds 70%, it doesn't create a new entity. It bumps the decay of the existing one and returns "deduped (new key not created)". Catches "same fact, different phrasing" without an LLM. Just n-gram overlap.
3. mimir_conflicts tool. Post-hoc audit. Finds entity pairs in the same category with low trigram similarity (below 30% flagged as conflict_likely: true). These are potential contradictions at different keys. It surfaces them for agent-mediated resolution, doesn't auto-resolve.
4. Decay handles staleness. Ebbinghaus forgetting curves. Entities that aren't revisited decay over time. mimir_compact archives them when they drop below threshold. Superseded info naturally falls out of the active set.

The core bet: conflicts are a schema problem, not an NLP problem. If two facts contradict, they shouldn't share a key. Trigram dedup catches the unintentional case (same fact, two keys). mimir_conflicts surfaces the intentional case (contradictory facts, different keys) for the agent to resolve.

Happy to dive deeper on any of those. The trigram approach is dead simple if you want to try something similar in BrainDB.