Why Didn't It Check? Unsupported Final Claims and Their Repair in Two Tool-Equipped Language Models

Justin Bronder

cs.AIAug 27, 2026

Why Didn't It Check? Unsupported Final Claims and Their Repair in Two Tool-Equipped Language Models

Authors: Justin Bronder

Organizations: Independent Researcher

Abstract

A language model with access to tools can commit to a final claim unsupported by the evidence it has seen, even when a single available tool call would resolve the uncertainty and its instructions explicitly forbid assumptions and guesses. We separate this failure into two precisely defined quantities: occurrence, how often the model makes an unsupported claim on its own, measured from the visible evidence and final claim without using the hidden correct answer; and conditional repair, how often those same naturally occurring unsupported claims are repaired when the missing evidence is supplied. On one fixed Qwen3-32B setup, 33 of 512 first responses to 256 new prompt templates ended with an unsupported established claim. We replayed each case from an exact copy of the state in which the claim occurred; within each matched replay, the alternative tool responses had the same structure and length and differed only in a one-character response code. Resolving evidence repaired 33 of 33 claims; a matched response carrying no useful information repaired 0 of 33. When the evidence supported the original answer, the model preserved 33 of 33, with no observed harm. In a separate experiment, on 64 cases where evidence was needed, an automatic checking rule added 21 evidence calls, corrected all 10 wrong unsupported claims, preserved the 11 that were correct by accident, and never changed a correct answer into a wrong one. On a fixed Gemma 4 setup using the same sampling settings, the model called the tool in all 512 first responses and never made an unsupported final claim, so conditional repair could not be measured for that setup. These results describe two local fixed model setups on two synthetic task families. They do not show how common this failure is in real-world deployments, nor that it reflects a general mechanism shared across models.

Figures & tables

Fixed setup	Tool calls	Final answers without a call	Hit output limit	Unsupported final claims	Exact 95% frequency bounds	Repair test
Qwen3-32B / llama.cpp	469/512	39/512	4/512	33/512	[0.0475, 0.0852]	Measured on 33 cases
Gemma 4 31B-it QAT-Q4_0 / llama.cpp	512/512	0/512	0/512	0/512	upper 0.0058	Could not be measured because there were no cases

Table 1

Experiment	Cases examined	Unsupported claims selected	Resolving evidence	No-information response	Harm from supporting evidence	What it contributes
Automatic checking	64 NEEDED first responses	21	21/21 gained support; all 10 wrong answers corrected	Not isolated	0 observed	Practical benefit, but evidence and extra turn are combined
Extra-turn exploratory follow-up	21 previously selected claims	21	All 10 wrong answers corrected by decisive evidence	0/21 final answers changed	Not tested	Supporting evidence only because cases were reused
First new matched replay	64 first responses	4	4/4	0/4	0/4	First prespecified evidence/no-information comparison, but small
Larger 256-response replay	256 first responses	14	14/14	0/14	0/14	More cases, but one code still had a fixed meaning
Final 512-response code-remapping experiment	512 first responses	33	33/33	0/33	0/33	Primary repair result and test against a fixed-code shortcut

Table 2

Component	Qwen setup	Gemma setup
Profile	qwen3-32b	gemma4-31b-it-qat-q4_0
Checkpoint SHA-256	3291abe70f16ee9682de7bfae08db5373ea9d6497e614aaad63340ad421d6312	179cfb99212709597eae5929112cfca677e1bbf566178b479ae1da0c4772874b
Checkpoint bytes	20,201,240,160	17,651,001,568
Prompt and tool format	Qwen ChatML/Hermes tool syntax	Fixed Gemma reasoning and function-call syntax
Reasoning format	Native Qwen reasoning envelope	Gemma reasoning enabled
Sampler	temperature 0.6, top-k 20, top-p 0.95	temperature 0.6, top-k 20, top-p 0.95

Table 3

Experiment	Experiment or prompt-bank identifier	Manifest / analysis SHA-256	Key commits
Cost-bearing auto-fire	vcw-neutral-cost-bearing-autofire-v1:99a8521256710c6e1131b15a57cbeb92d90d3e12f9e1b0fe6be4dd9db115deec	bank manifest ef57f0f18db064a6e8f9fc58e4e6e3c3beb321cc3e6cf3e22d56d9403559e93a ; analysis fb7ab30c4c48751a44db8651e0fe4ffeb05def2e05fd951b3ef1b165512c4c34	freeze 69e0f805 ; live source 0b37f30c
Qwen counterbalanced-512	60001508d04309f08bc9abfdecc1368ef9a933bf4128c2bb198569adff9a04e3	manifest 31352fa50427fb9af98c88501faeb6f485d1f5807c7ab527cf4986197c509d66 ; analysis 18f26fba2e09ad3aa23101722378f0aff2443f344f7b3a519342f8c626ec0622	contract 3179dc3 ; realized 202a2b4 ; raw 879a6f4 ; result 653233a ; merge b2b8ff5
Gemma counterbalanced-512	1c161665fcbaf6ba1676997d89e7dccc4560cb63c61b9dfdba4a72509195221d	manifest 479861230e6708790814567d9d46138d1acb3b5654616f8a078bc641c1ed8bc6 ; analysis/replay ff8ea5136da3c6f45d819e994786085873710b284e5c1059697af282304dd76b	route ba7b8c8 ; packet 0d45590 ; raw e647c62 ; result 5a0b7ef ; merge e186852

Table 4

Observed result	What it shows	What it does not show
Qwen produced 33 unsupported final claims in 512 first responses	The observed frequency in that exact setup, on that fixed artificial schedule	Frequency in deployments, a stable rate for the prompts, or a Qwen-family rate
Disqualifying evidence repaired 33/33 claims and the matched no-information response repaired 0/33	Within these selected matched cases, the resolving response content caused retraction relative to the no-information response	General self-correction, use of arbitrary evidence, or a universal repair rate of 100%
A , B , and C exchanged supporting and disqualifying meanings without changing the direction of the result	A simple fixed rule tied to one literal response character cannot explain these cases	General semantic understanding or invariance under other code systems and prompts
Automatic checking changed 10 wrong answers to correct with 21 added evidence calls	Improved accuracy and evidential support in the fixed 64-case NEEDED experiment	Deployment utility, acceptable latency, or the cost of unnecessary checks in ordinary traffic
Gemma called the tool in 512/512 first responses and produced 0/512 unsupported final claims	Zero observed failures in that fixed Gemma setup under the Qwen-matched sampling settings	Model-wide discipline, an effect caused only by the checkpoint, or a repair effect of zero
One raw trace stated the rule for unknown values and then violated it	A concrete contradiction between the archived explanation and final answer	A hidden reasoning mechanism or a general behavioral tendency

Table 5

Appendix figures & tables2 assets

Supplementary material from the paper’s appendix.

Appendix

Condition	Injected tool response	Resulting final claim
Disqualifying evidence (Q)	{"record":"Emma","field":"checksum_matches","value_code":"B"} where B meant YES	{"candidate":null,"status":"not_established"}
Supporting evidence (D)	{"record":"Emma","field":"checksum_matches","value_code":"A"} where A meant NO	{"candidate":"Lucas","status":"established"}
No-information response (U)	{"record":"Emma","field":"checksum_matches","value_code":"U"} where U supplied no value	{"candidate":"Lucas","status":"established"}

Appendix

Table 6

Quantity	Observed	Lower	Upper
Qwen unsupported-claim occurrence	33/512	0.0475	0.0852
Gemma unsupported-claim occurrence	0/512		0.0058
Repair after disqualifying evidence	33/33	0.9132
Change after no-information response	0/33		0.0868
Harm after supporting evidence	0/33		0.0868
Repair after counting each prompt template once	31/31	0.9079

Appendix

Table 7

LLM Reliability

Large language model reliability studies whether outputs remain correct, calibrated, robust, and controllable across prompts, contexts, and deployment conditions.

See all 802 papers

Oct 1, 2026

Keyword Harnesses Fail Open: A Cheap Diagnostic Ladder for Tool-Use Claims in Small Language Models

Keyword-matching benchmarks can credit small models for tool use they never perform. We document such a false positive in a matched-architecture pair of Spanish security language models and propose a ladder of strict, cheap diagnostics. A 661.6M parameter model (approx. 65% code/technical text; no dedicated SFT) and a 1,109M model (web-heavy multi-phase curriculum; 6B-token tool-SFT) share decoder, tokenizer, and special tokens, scoring almost identically on lenient tool-use metrics (B4: 0.660 vs. 0.650). Verbatim-reproduction checks on training examples separate them completely: the 600M emits valid tool calls with generalized arguments on 6/6 examples; the 1B does so on 0/6 across checkpoints. A first-token probe localizes the 1B's failure to a missing prior (prob.

10^{-4}

10^{-5}

on <|tool_call|>), which was erased by its web-heavy training phase. A targeted SFT recipe (diverse corpus, 5x higher learning rate, 2,202 steps, ~3.3 GPU-hours) repairs the 1B using three orders of magnitude fewer tokens than the failed phase. On all 269 corpus rows, valid emission rises from 0.100 to 0.959 (600M: 0.926). On 238 unseen prompts, the repaired 1B passes 0.536 vs. the 600M's 0.428 (

p = 0.004

). Embedding-drift checks show the repair did not move the trigger token's tied embedding (97.7% of the bf16 table remains bit-identical), meaning changes live in the surrounding network. Both models over-trigger, rarely answering negative prompts without a call (0.09 for 600M, 0.17 for repaired 1B). Factorial analyses confirm all repair configurations install the format, though suppression benefits from a diverse corpus remain a hypothesis due to seed sensitivity. This cheap diagnostic ladder costs minutes of CPU time and should gate tool-use claims on small models.

Juan S. Santillana

Independent Researcher

Supervised Fine-Tuning Tool-Use Evaluation Language Model Generation Evaluation Small Language Models LLM Reliability LLM Tool Use

Ask PDF

Sep 13, 2026

Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return

Tool-augmented language models are evaluated on whether they reach the right answer, not on whether they report honestly when a tool fails to supply one. We isolate this post-failure decision with a benchmark of 1,024 items spanning 16 internal-system domains and eight tool-failure types, in which a tool call is enforced and the returned payload is guaranteed to be unusable. Under a deployment-style system prompt, 14.10% of responses are dishonest: the model either asserts a value the payload cannot support or declines while citing a fabricated policy or capability limit. The rate is governed almost entirely by whether the failure is signalled. When the tool returns status:error, dishonesty is absent (0.0%); when it returns status:ok with a redacted, corrupted, stale, malformed, empty or truncated value, dishonesty reaches 45.3%. The behaviour is not an artefact of our prompts: it appears under a neutral prompt (10.17%) and under the shipped prompt of every production agent framework we evaluate, reaching 24.67% under CrewAI's, and none of the nine frameworks we audit specifies what the model should do when a tool fails. Comparing prompt-level defences, we find that the operative variable is not deference to tool output but the absence of a named failure state. Appending a single sentence that requires the model to emit retrieval_status: OK or FAILED before answering reduces dishonesty from 14.10% to 0.87%, with one item of 688 worsening against 92 improving, and transfers unchanged into three foreign agent scaffolds. The emitted flag is faithful in 99.7-99.9% of declarations, giving a runtime detector that needs only a regular expression.

Arham Sethi, Arsen Kenzhebayev, Saanvi Paturi +3

The Shishukunj International School · Haileybury Astana · UWCSEA East Campus +2

Tool-Augmented Language Model Agents Deception in Language Models LLM Agent Evaluation Tool-Using Agents Tool-Using Language Agents Error Feedback

Ask PDF

Aug 29, 2026

Detecting and Repairing Hallucinations in Retrieval-Augmented Generation

Language models increasingly answer questions by consulting retrieved documents rather than memory alone, a design now common in search assistants and enterprise knowledge tools. Grounding a model in retrieved text reduces unsupported statements but does not eliminate them, and a reader cannot tell a grounded sentence from an invented one. Most research on this problem stops at detection, yet flagging a faulty answer changes nothing for the person reading it, and little is known about which action should follow. Using RAGTruth, a benchmark whose unsupported passages are annotated by hand, we split each flagged answer into individual factual claims, check each against the retrieved source, and compare leaving the answer untouched with three repair strategies of increasing richness: deleting an unsupported claim, replacing it with source text, and rewriting it. Three language models from different families judge the 916 repaired answers. Every strategy reduces the proportion of answers judged to contain unsupported content, and all three judges agree on the ordering. Deletion achieves the largest reduction while retaining least of the original answer, at 64.3% of the text, whereas rewriting retains 80.1% and reduces least. Repair is not confined to faulty answers: 83.5% of answers annotated clean are edited too. The strategies occupy different points on a grounding preservation trade-off rather than forming a quality ranking, and choosing between them needs evidence about answer usefulness that automatic metrics cannot supply.

Sai Krishna Reddy Mulakkayala, Niki van Stein, Aske Plaat

LIACS, Leiden University, Leiden, The Netherlands

Hallucination in RAG LLM Hallucination Mitigation Retrieval-Augmented Generation RAG Evaluation

Ask PDF

Abstract

LLM Reliability

Explore similar work

Keyword Harnesses Fail Open: A Cheap Diagnostic Ladder for Tool-Use Claims in Small Language Models

Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return

Detecting and Repairing Hallucinations in Retrieval-Augmented Generation