batch-fault-isolation-is-universal-across-llm-operations
OUT derived (depth 1)
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.
Summary
When the system processes batches of LLM work — either applying derived proposals or reviewing beliefs — each item is handled independently so that a single failure does not take down the rest of the batch. However, this claim is currently retracted because while derive operations do properly isolate errors per proposal, the review path silently drops failed batches without signaling the failure to callers, which is not true fault isolation but rather silent data loss.
Justifications
SL — Both batch processing paths independently implement per-item error isolation, establishing it as a cross-cutting system pattern
Antecedents (all must be IN):
- derive-apply-isolates-per-proposal-errors — `apply_proposals` wraps each `api.add_node()` call in try/except and accumulates `(proposal, error_string)` tuples, so one malformed proposal does not abort the batch.
- review-batch-failure-is-silent-skip — When an LLM call fails for a review batch, the error is logged to stderr but the batch is skipped with no indication in the returned results; callers cannot distinguish "skipped due to error" from "no problems found."
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.