llm-integration-fails-softly-across-modules
OUT derived (depth 2)
All LLM-facing modules apply consistent fail-soft error handling: the ask module always returns a string even when the LLM is unavailable, and the derive pipeline accumulates per-proposal errors rather than raising exceptions — no LLM failure path crashes the system.
Summary
When the LLM is down or returns garbage, every part of the system that talks to it degrades gracefully instead of crashing — questions still get answers, batch operations skip bad items instead of aborting, and invalid output is quietly filtered out. This claim is currently retracted, meaning at least one of those guarantees no longer holds.
Justifications
SL — Cross-module consistency — both LLM integration points (ask and derive) apply fail-soft patterns, establishing a system-wide invariant for LLM error handling
Antecedents (all must be IN):
- ask-always-returns-string — `ask()` returns a string on every code path — LLM response, raw search results, or fallback; it never raises an exception to the caller.
- derive-fail-soft-validation — `validate_proposals` filters invalid proposals into a skipped list rather than raising; `apply_proposals` catches per-item exceptions so one bad proposal never blocks others
SL
Antecedents (all must be IN):
- ask-always-returns-string — `ask()` returns a string on every code path — LLM response, raw search results, or fallback; it never raises an exception to the caller.
- derive-fail-soft-validation — `validate_proposals` filters invalid proposals into a skipped list rather than raising; `apply_proposals` catches per-item exceptions so one bad proposal never blocks others
- list-negative-is-defensively-bounded — The negative belief listing pipeline applies defense-in-depth: keyword pre-filtering narrows candidates before LLM classification, hallucinated node IDs are discarded against the actual network, and malformed LLM output falls back gracefully to zero count rather than raising.
- review-is-read-only-and-fault-tolerant — The review module operates entirely on in-memory snapshots with no storage dependency, handles missing antecedent references with placeholder text rather than exceptions, and silently skips failed LLM batches — achieving fault-tolerant read-only operation across all failure modes.
Dependents
These beliefs depend on this one:
- llm-fault-tolerance-is-multi-granular — LLM fault tolerance operates at two independent granularities: module-level fail-soft handling ensures entire operations degrade gracefully when the LLM is unavailable, while item-level batch fault isolation ensures individual failures within derive and review batches are contained without affecting other items in the same batch.
- self-correction-is-resilient-to-llm-unavailability — The system's core self-correction mechanisms — contradiction resolution through dependency-directed backtracking and staleness detection through source hash comparison — require no external dependencies and execute on stdlib alone, while all LLM-facing operations apply consistent fail-soft error handling — LLM unavailability degrades knowledge expansion but never compromises correction integrity.