list-negative-is-defensively-bounded
IN derived (depth 1)
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.
Summary
The pipeline for finding negative beliefs uses three layers of protection against errors. Keywords filter candidates before the LLM ever sees them, any node IDs the LLM invents are caught and thrown out by checking against the real database, and if the LLM response is garbled the system quietly returns an empty result instead of crashing.
Justifications
SL — Three independent defensive measures form a complete safety pipeline for LLM-driven negative classification
Antecedents (all must be IN):
- list-negative-uses-two-stage-classification — `list_negative` uses keyword pre-filtering against a hardcoded `NEGATIVE_TERMS` list (~50 words), then LLM classification via `ask._invoke_claude` to eliminate false positives.
- api-list-negative-filters-hallucinated-ids — `list_negative()` discards any node IDs returned by the LLM that don't exist in the database, preventing hallucinated IDs from appearing in results.
- api-list-negative-graceful-on-malformed-llm — When the LLM returns unparseable output, `list_negative()` returns `count == 0` rather than raising an exception — graceful degradation over failure.
Dependents
These beliefs depend on this one:
- all-belief-inspection-is-non-mutating-and-fault-tolerant — All belief inspection operations — quality review (read-only with fault-tolerant batch handling), staleness checking (conservative non-mutating CI gate), and negative classification (defensively bounded with graceful degradation) — are uniformly non-mutating and fault-tolerant, ensuring observation never perturbs the observed system.
- all-llm-operations-are-defensively-bounded — All three LLM-facing operations — interactive query (ask), batch derivation (derive), and belief classification (list_negative) — apply consistent defensive patterns: bounded execution, fail-soft error handling, hallucination filtering, and graceful degradation on LLM unavailability.
- list-negative-is-bounded-and-batch-scalable — The list-negative classification pipeline is both defensively bounded (two-stage keyword + LLM filtering with hallucination rejection and graceful malformed-output handling) and scalably partitioned (fixed batch size of ~50 candidates per LLM call), ensuring predictable resource usage and bounded LLM costs regardless of belief network size.
- llm-belief-pipeline-is-fully-quality-enforced — The system's complete LLM-driven belief pipeline — both generation (derive with safety, completeness, and coverage) and classification (list_negative with defensive bounding) — achieves fully code-enforced quality constraints at every stage, provided minimum-antecedent validation moves from prompt-only to code-enforced.
- llm-integration-fails-softly-across-modules — 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.