llm

22 beliefs (15 IN, 7 OUT)

• IN 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.
• IN ask-dual-mode-makes-three-llm-calls
  Dual mode makes up to 3 LLM calls (1 TMS synthesis + 1 FTS RAG + 1 merge), short-circuiting to 2 if either retrieval path returns empty.
• IN ask-never-raises-on-llm-failure
  `ask()` catches `TimeoutExpired` and `RuntimeError` from `_invoke_claude()` and returns raw FTS5 search results instead of propagating the exception — the function guarantees a string return.
• IN ask-no-synth-bypasses-llm
  When `no_synth=True`, `ask()` returns raw `api.search()` results without invoking the Claude CLI.
• OUT batch-fault-isolation-is-universal-across-llm-operations
  Both LLM-facing batch operations — derive proposal application (try/except per proposal with error accumulation) and belief review (silent skip on per-batch LLM failure) — isolate faults at the individual item level, preventing any single bad item from aborting the entire batch.
• IN derived-belief-soundness-is-llm-only
  Structural validation ensures justification references exist and are IN, but the logical soundness of the inference from antecedents to derived conclusion is validated only by the proposing LLM — no code-level check verifies that the reasoning step is logically valid.
• OUT llm-belief-operations-span-creation-and-classification
  All LLM-driven belief operations — creation via derive (with safety, completeness, and resource efficiency) and classification via list-negative (with defensive bounding and batch scaling) — share consistent defensive patterns across the complete belief quality lifecycle.
• OUT 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.
• IN llm-driven-mutations-are-safely-bounded
  LLM-driven belief derivation is safely bounded by defense in depth: the derive pipeline validates proposals with fail-soft filtering, Jaccard retraction guards, and environment stripping at the LLM boundary, while the API layer enforces atomic load/save with write-flag gating and dict-only returns at the persistence boundary — malformed or adversarial LLM output cannot corrupt the network.
• OUT 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.
• IN 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.
• OUT llm-integration-is-bounded-fail-soft-and-process-isolated
  LLM integration achieves three independent safety properties across all modules: execution bounds (iteration caps and timeouts), fail-soft error handling (always returns usable results on failure), and process isolation (subprocess invocation with CLAUDECODE environment stripping to prevent recursive entry)
• OUT llm-integration-is-defense-in-depth-across-layers
  All LLM integration achieves defense-in-depth across two independent layers: application-level defensive bounding provides iteration caps, fail-soft error handling, Jaccard retraction guards, and hallucination filtering across all LLM-facing operations, while infrastructure-level process isolation executes all LLM calls through subprocess boundaries with CLAUDECODE environment scrubbing to prevent recursive invocation — ensuring safety at both the semantic and process boundaries.
• OUT llm-integration-is-production-hardened
  LLM integration achieves production-grade robustness across all dimensions: infrastructure-level safety through bounded execution, fail-soft error handling, and process isolation prevents runaway or recursive invocations, while operational-level coverage and fault tolerance ensures both derive (batch) and ask (interactive) paths complete successfully or degrade gracefully under all failure modes.
• IN llm-mutations-are-bounded-end-to-end
  LLM-driven belief derivation is bounded at every stage of the pipeline: input validation (fail-soft filtering, Jaccard retraction guard, environment isolation), atomic persistence (context-managed load/save), and output propagation (deterministic terminating BFS with lifecycle-aware traversal).
• IN llm-prompt-always-via-stdin
  Prompts are passed to LLM subprocesses via `subprocess.run(input=...)`, never as command-line arguments — avoiding shell injection and argument length limits.
• IN llm-resolve-ollama-preserves-inner-colons
  `resolve_model_cmd("ollama:model:tag")` splits on the first colon only, keeping `model:tag` intact as the Ollama model identifier.
• IN llm-subprocess-isolation-prevents-recursion
  All LLM subprocess invocations strip the CLAUDECODE environment variable to prevent recursive Claude Code entry, enforced centrally in invoke_model() and inherited by all LLM-facing modules (ask, derive, review).
• IN llm-thinking-strip-ollama-only
  Thinking-marker stripping (`Thinking...` / `...done thinking.`) is applied only to Ollama model output; Claude and Gemini output passes through unmodified even if it contains the same markers.
• IN no-synth-mode-skips-llm
  When `no_synth=True`, `ask()` returns formatted FTS5 search results without invoking `_invoke_claude()` — the LLM is never contacted.
• IN semantic-contradictions-cluster-before-llm
  The `--semantic` flag on `detect-contradictions` embeds beliefs via sentence-transformers, clusters with KMeans via `list_clusters()`, and sends each cluster to the LLM as a batch — ensuring topically related beliefs are analyzed together instead of being scattered across random batches of 50.
• IN sqlite-only-commands-are-filesystem-llm-or-bulk
  The ~21 SQLite-only CLI commands fall into three categories: filesystem-dependent (hash-sources, check-stale, add-repo), LLM-powered (derive, review-beliefs, detect-contradictions, ask), and bulk import/sync — all requiring either local file access or load-entire-network-modify-save semantics incompatible with PgApi's per-operation transaction model.