Thanks @web3guru888 — this is exactly the kind of feedback I was hoping for from someone running a real KG at scale.

Negation guard — implementing now. You're absolutely right, this is a concrete false positive. The prefix check you suggested is clean and cheap. I'll add it to _check_attribution and extend it to _check_role and _check_relationship as well — negation applies to all claim types, not just attribution.

Soft contradictions and the regex ceiling — agreed. The four patterns were always meant as a starting point for the structured/hard cases (wrong person, wrong tenure, wrong role). The directional claims and cross-domain contradictions you describe are genuinely harder problems. I deliberately avoided trying to solve them with more regex because that path leads to an explosion of patterns that are fragile and domain-specific.

Composing with min_similarity from PR #350 — yes. That's the right architecture: rule-based for hard contradictions (structured claims with clear subject/predicate/object), embedding similarity for soft ones (semantic drift, causal conflicts, cross-domain). I'd love to see the check_facts tool accept an optional use_similarity: bool flag that falls back to cosine comparison when regex finds nothing. Happy to build that if the maintainers agree on the approach.

Re: cross-domain contradictions in your astrophysics/epidemiology example — that's a fascinating use case. MemPalace's wing/room structure could actually help here: if two wings have related rooms, the tunnel system already connects them. A similarity-based contradiction check scoped to tunnel-connected rooms could surface exactly those cross-domain conflicts without searching the entire KG.

I'll push the negation guard fix shortly. Thanks for taking the time to review with real production context.

— Gonzalo

Glad the negation guard fits. Good thinking to extend it to all claim types — the same false-positive risk applies to _check_role ("X NOT working at Y" → should not flag) and _check_relationship ("X NO LONGER manages Y").

The tunnel-scoped similarity check is a sharp observation. In our setup, astrophysics and epidemiology connect via climate (the shared node). So a claim about solar forcing in the astrophysics wing and a claim about UV-driven epidemiological risk in the epidemiology wing would have a tunnel path through climate. Scoping the contradiction check to tunnel-reachable rooms would catch exactly that category while avoiding irrelevant cross-wing noise.

If you build the use_similarity flag, one thing worth deciding early: does it check against all drawers in the reached rooms, or just the KG triples? The KG triples are more structured (easier to compare predicates), but the drawers have full context. For contradiction detection specifically, I'd lean toward the KG — you already have subject/predicate/object, so semantic drift is more detectable at the triple level than in raw drawer text.

hey @Nitrogonza9 — thanks for putting this together, the architecture is solid and it addresses a real gap (issue #27).

we're going to hold off on merging this though — v4 is bringing local NLP providers (#507) which will enable semantic contradiction detection rather than regex-based pattern matching. a semantic approach would catch things like "Alice is employed by Google" vs "Alice works at Meta" that regex can't.

we don't want to ship a regex implementation now and replace it shortly after. when the NLP work lands we'll revisit contradiction detection with semantic understanding built in. appreciate the contribution — the checker design (GREEN/YELLOW/RED with reasoning) is a pattern we'll likely keep.