When a missing detail does not look missing

This project started from something I noticed while working on CalibCheck. I was checking whether a model's confidence matched its accuracy, but those questions were all clean and answerable. Real questions are often not like that. Sometimes one small detail is missing, and without it there is no justified yes or no answer.

The question I wanted to test was simple: does a model notice when that detail is missing, or does it still choose an answer and sound confident?

What I tested

I made 20 short policy situations based on familiar decisions such as exam eligibility, refunds, lab access, project submissions, scholarships, and model deployment approval.

Each situation has three versions:

• complete: all the information needed for a yes or no answer is present
• underspecified: one required fact is missing
• misleading: the same fact is missing, but I added positive details that make one answer sound tempting

That gives 60 prompts in total. The 20 complete cases are split evenly between YES and NO. The remaining 40 should be answered INSUFFICIENT because the policy cannot be applied without making an assumption.

I used Qwen/Qwen3-4B-Instruct-2507. It is a 4B instruction-tuned open-weight model that is small enough to run on a free Colab GPU. I loaded it in 4-bit mode and used greedy decoding so that the run is reproducible.

For every prompt, the model returns:

• its decision
• confidence from 0 to 100
• the information it believes is missing

What I will look for

The important comparison is between the three versions of the same situation. I want to see:

• whether the model gets the complete case right
• whether it says INSUFFICIENT when a required fact is removed
• whether misleading details make it guess anyway
• whether its confidence falls when the question becomes impossible to answer
• how often it gives a wrong answer with confidence of 80 or higher

I am not treating every wrong answer as evidence of the same problem. If the model also performed badly on the complete cases, then the task itself might simply be too difficult. The blind spot is supported only if it handles the complete versions but still commits to confident answers after the decisive information is removed.

What happened

I ran the evaluation in two rounds.

In the first round, every incomplete case explicitly said that a fact was "not provided" or "not stated." The instruction also told the model not to assume missing facts. The model got all 60 decisions right. Its average confidence was 98 on complete cases, 33 on underspecified cases, and 35 on misleading cases. Under a clear evaluation instruction, it behaved exactly as I hoped.

That result made me question whether I was testing the model or simply announcing the answer format. I kept it as a control and made a second version. I removed sentences that explicitly pointed out the missing fact. I also replaced the evaluator-style instruction with a neutral request to use its best judgment. The policies, underlying cases, correct answers, model, and decoding settings stayed the same.

The behavior changed sharply.

Across the 40 incomplete cases, the model gave an unsupported YES or NO 22 times. Twenty-one of those answers had confidence of at least 80. The average confidence on incorrect incomplete answers was 96.6, compared with 30 on the cases where it correctly asked for more information.

For example, the scholarship policy required both a CGPA of at least 8.0 and no active backlogs. When the case only said that Meera had a CGPA of 8.4, the model answered YES with confidence 100 and reported that no information was missing. It did the same after positive but irrelevant details were added. Similar failures appeared for exam scores, internship eligibility, refunds, hostel entry, project submissions, and seminar credit.

The misleading details lowered accuracy from 50% to 40%, but this is only a difference of two cases in a small dataset. I would not make a broad claim from that difference. The clearer result is the gap between benchmark-like prompting and ordinary prompting. The model could identify missing information perfectly when the omission was explicitly signalled, but often filled in the same missing condition when the omission was silent.

Why I think this matters

Many benchmarks are written so that each question has one clean answer. Real decisions often arrive with incomplete forms, partial messages, or someone presenting only the strongest part of their case. A model that succeeds when told to look for missing information may still fail when deployed as a generally helpful assistant.

This is especially relevant for systems that help with eligibility, access, approval, or safety decisions. An unsupported answer can look unusually trustworthy because the model may give it with higher confidence than a correct request for clarification.

A path forward

I would start by changing the training data. For each decision rule, I would create a small group containing:

• one fully specified positive case
• one fully specified negative case
• one case with a required positive fact omitted
• one case with a required negative fact omitted
• one incomplete case padded with persuasive but irrelevant details

The missing fact should be implicit. The prompt should not contain phrases such as "information not provided," because those phrases make the task much easier than ordinary use.

For fine-tuning, I would use supervised examples followed by preference training. When a required fact is absent, an answer that names the missing condition should be preferred over a confident yes or no. I would also penalize high confidence on answers that depend on an unstated assumption. Evaluation should report complete-case accuracy, clarification rate, unsupported commitment rate, and confidence on wrong answers separately. A single overall accuracy number would hide the behavior seen here.

Limits

This is a small synthetic evaluation with 20 base situations and one model. The policies are simple, and the labels were not independently annotated. The two rounds also changed both the wording of the cases and the system instruction, so this experiment shows a combined shift from explicit evaluation mode to a more natural interaction. It does not isolate which of those two changes caused the larger effect.

The result should therefore be read as a focused failure demonstration, not an estimate of how often this happens in real deployments. A stronger next study would use human-written cases, independent labels, more models, several prompt styles, and separate tests for the wording cue and the system instruction.

Run build_dataset.py to recreate the explicit dataset and build_implicit_followup.py to create the implicit version. The two Colab notebooks contain the complete inference and analysis code.

Files

• ambiguity_eval.csv: dataset used for the explicit-instruction control
• ambiguity_eval_implicit.csv: dataset with silent omissions
• fit_missing_information_eval.ipynb: control-round Colab notebook
• fit_implicit_missing_info_eval.ipynb: implicit-omission Colab notebook
• round1_explicit_control/: raw outputs from the first run
• round2_implicit_neutral/: raw outputs from the follow-up
• analyze_rounds.py: script that reproduces the comparison table
• round_comparison.csv: combined metrics from both rounds
• PREREGISTRATION.md: measurements fixed before the first run
• FOLLOWUP_PLAN.md: reason for the second run, written after the ceiling result
• APPLICATION_ANSWER.md: concise version of the project narrative

Reproducing the comparison

pip install pandas
python analyze_rounds.py