{ "schema_version": 1, "builder_plan": { "scenario": "Tool errors or unavailable services cause your agent to abandon recoverable tasks.", "change": "Inject repeatable tool failures and change only the recovery policy.", "baseline": "Your current retry and fallback behavior under the same injected failures.", "steps": [ "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.", "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.", "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.", "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test." ], "measure": "Recovered tasks, duplicate side effects, retries, time to recovery, and total cost.", "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation." }, "builder_review": null, "arxiv_id": "2610.25739", "title": "How Much Does One Wrong Answer Cost? Error Propagation in Constraint Pruning with Noisy LLM Oracles", "summary": "The method does not replace constraint pruning itself; it replaces the assumption that a correct oracle makes query order irrelevant, prescribing query orders (notably pivot orders for entity resolution) that bound how far one wrong LLM answer propagates. It costs nothing in extra queries or infrastructure, only deliberate ordering of the same yes/no questions, with pivot ordering being simple to implement. It can fail when error independence or small-epsilon assumptions break down (correlated oracle errors, systematic biases toward certain record pairs), since the guarantees are first-order in epsilon and the common most-similar-first ordering is provably the worst in one dimension.", "rationale": "The reader already using LLM-based entity resolution or ranking with transitivity pruning can adopt pivot query ordering at zero infrastructure cost, but should validate error behavior on their own data since the analysis assumes small independent per-answer error.", "technique": "Error-aware constraint pruning for noisy LLM oracles", "family": "recuperacao_de_falha", "recommendation": "testar", "published": "2026-10-19", "as_of": "2026-10-25", "editorial_status": "indexed", "source_url": "https://arxiv.org/abs/2610.25739", "independent_implementations": 0, "total_implementations": 0, "stars": 0, "citations": 0, "claims": [ { "claim_id": "claim-01", "statement": "The method does not replace constraint pruning itself; it replaces the assumption that a correct oracle makes query order irrelevant, prescribing query orders (notably pivot orders for entity resolution) that bound how far one wrong LLM answer propagates. It costs nothing in extra queries or infrastructure, only deliberate ordering of the same yes/no questions, with pivot ordering being simple to implement. It can fail when error independence or small-epsilon assumptions break down (correlated oracle errors, systematic biases toward certain record pairs), since the guarantees are first-order in epsilon and the common most-similar-first ordering is provably the worst in one dimension.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2610.25739", "source_page": null, "source_excerpt": "" }, { "claim_id": "claim-02", "statement": "For entity resolution, pivot orders amplify errors by less than a factor of 2 and are optimal, while random orders cost order m^(1/3) extra corrupted facts; random-order pruning under implication rules adds no first-order risk.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2610.25739", "source_page": null, "source_excerpt": "" } ], "exposure_map": [ { "dimension": "quality", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compute", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "latency", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "operations", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compatibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "security", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "data_and_training", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "reproducibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" } ], "risks": [], "minimum_test": [], "open_questions": [], "independent_tests": [], "lab_reproductions": [], "report_available": false, "validation_tier": "unknown", "evidence_tier": "unknown", "infrastructure_basis": "unknown", "equations": [], "equations_status": "not_fetched", "core_kind": "", "equations_fetched_at": "", "equations_source_url": "", "equations_source_sha256": "", "exposures_reviewed_at": "", "exposures_source_sha256": "" }