# Beyond Hallucination: Consistency and Sensitivity
# Book: Hallucination From First Principles
# Chapter URL: https://programmer.ie/books/hallucination-from-first-principles/09-chapter/
# Prose fingerprint (sha256, normalized): 60fcfa79d766ac577a1744d46afb465b6453e4f9fde295dffe5b44532acb949f
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Chapter 8 ended with a rule:
If a downstream decision depends on a distinction, do not discard that distinction before the decision is made.
That rule breaks the idea of one universal hallucination score.
A response can be well contained and still reverse a relation. It can preserve every relation and still ignore the decisive facts of the problem. It can be correct once and unstable under a harmless rephrasing. It can be perfectly repeatable and consistently wrong.
Consider two strategically opposite situations.
DECLINE 18 months of runway losing money shrinking demand high competitive pressure GROWTH strong margins large reserves rapidly expanding demand low immediate survival pressure Now suppose both receive essentially the same advice:
focus on innovation improve operational efficiency listen to customers use data-driven decision making build capabilities Nothing is necessarily hallucinated. Nothing may contradict the prompt. Every sentence may be defensible in isolation.
But the decisive context changed and the recommendation barely did.
That gives us a different reliability question:
Does this output depend on the right things?
Two families of measurement become especially important:
CONSISTENCY / CONSTRAINT FIDELITY Does the system preserve what should remain stable? SENSITIVITY / COUNTERFACTUAL RESPONSIVENESS Does the system change appropriately when something important changes? These are dual requirements.
A reliable system should be invariant to irrelevant variation and responsive to relevant variation.
Most static benchmarks inspect one input and one output at a time. Consistency and sensitivity instead require us to study relationships among controlled families of executions.
The evaluation unit changes from:
one response to:
base scenario + controlled transformations + expected response relations + repeated executions where needed That is the architectural shift of this chapter.
1. Reliability is a property of transformations, not only points Containment asks one useful question:
Did the claim representation extend beyond the configured evidence geometry? Chapter 8 showed why that question cannot determine whether every truth-bearing relationship is correct.
Consistency and sensitivity add a different kind of observation. They do not primarily inspect a response in isolation. They inspect how behavior changes under a declared transformation.
Let:
$$ x' = T(x) $$where $T$ changes some declared aspect of the input.
The transformation must also declare what relation should hold between the resulting behaviors.
Call that expected relation:
$$ R_T. $$Examples:
PARAPHRASE input meaning unchanged → decision should remain equivalent BUDGET COLLAPSE $10,000,000 → $100,000 → plan should become cheaper, narrower, or infeasible EVIDENCE REMOVAL remove the only decisive support → confidence/support state should weaken LEGAL FACT REVERSAL change a legally controlling fact → legal conclusion may need to change The common object is therefore not merely sensitivity.
It is transformation fidelity:
Did the system satisfy the correct response relation under the declared transformation?
Consistency and sensitivity are special cases of that larger idea.
2. A generative model produces a distribution, not one point For a deterministic system we can write:
$$ y=f(x). $$But a language model is usually better represented as:
$$ Y_x\sim P_\theta(Y\mid x). $$After a controlled transformation:
$$ Y_{T(x)}\sim P_\theta(Y\mid T(x)). $$One sampled pair:
y and y' may differ because of decoding randomness rather than because the model responded to the perturbation.
So the deeper question is:
Did the response distribution move in the expected direction by more than ordinary within-condition sampling variation?
For deterministic decoding, one execution per condition may be enough for a basic test.
For stochastic generation, repeated samples can separate:
within-condition variation from:
between-condition effect. This distinction is foundational.
Repeatability is not contextual sensitivity.
A model can produce slightly different prose on every sample while its decision never moves. Conversely, it can show substantial sampling variation while its decision distribution still shifts correctly when the underlying problem changes.
3. Consistency is a family of constraint-fidelity measurements The word consistency is dangerously overloaded.
For this book, the broad definition is:
Consistency measures whether a declared constraint that should remain stable is actually preserved.
That produces several distinct measurement contracts.
Internal consistency One response against itself.
The trial showed no mortality benefit. ... The mortality benefit was statistically significant. Reference consistency Response against supplied evidence, state, or another authoritative reference.
Evidence: A acquired B. Claim: B acquired A. This can overlap with factual faithfulness because the reference is the same. The measurement question is nevertheless specific: was the supplied constraint preserved?
Transformation consistency Response under a should-not-change transformation.
original problem ↓ paraphrase same underlying problem ↓ core decision should remain equivalent Trajectory consistency Facts, commitments, observations, plans, and claimed capabilities across multiple turns or agent steps.
For an agent:
step 1: "I will query the SQL database." step 2: SQL tool executes successfully. step 3: "I do not have database access, so I estimated the value." That is not merely a badly worded answer. It is a trajectory-level contradiction between intention, runtime state, and later narration.
Agentic systems therefore need consistency over objects such as:
world state plan commitments tool availability tool results entity identities intermediate facts completed actions Each form of consistency needs its own measurement unit and oracle.
And none supplies truth by itself.
A model can answer:
Paris is the capital of Germany. on every sample, under every paraphrase, with perfect internal coherence.
That is consistent.
It is still wrong.
4. Sensitivity is not instability A naive definition says:
If the output changes when the input changes, the system is sensitive.
That is too weak.
Suppose we paraphrase:
What was Company A's 2025 revenue? as:
How much revenue did Company A report in 2025? and the answer changes from:
$4.2 billion to:
$7.9 billion. The model is responsive to something that should not matter.
That is brittleness.
Now change a decisive constraint:
budget = $10,000,000 to:
budget = $100,000 —a 100× reduction.
If the implementation plan remains functionally unchanged, the model is insufficiently responsive to something that should matter.
Reliable behavior requires selective responsiveness:
irrelevant or meaning-preserving change → preserve the required decision or structure material decision-relevant intervention → change the required output component in the expected direction This gives us the central principle:
Reliability is not invariance. Reliability is knowing what to be invariant to—and what not to be invariant to.
5. One formalism unifies invariance and responsiveness For a deterministic system, let:
$$ y=f(x), \qquad y'=f(T(x)). $$For a stochastic system we instead compare samples or structured summaries from:
$$ P_\theta(Y\mid x) \quad\text{and}\quad P_\theta(Y\mid T(x)). $$Every transformation carries an expected response relation $R_T$.
Define a relation evaluator:
$$ F_T(x) Q\big(Y_x,Y_{T(x)};R_T\big), $$
where $Q$ returns a typed state or score indicating whether the required relation was satisfied.
Invariance If the transformation should not matter, the expected output transformation is identity:
$$ f(T(x))\approx f(x). $$For a normalized distance $d$:
$$ C_T(x)=1-d(y,y') $$can be a convenient baseline when semantic equivalence is the target.
Equivariance / directional responsiveness Often the correct behavior is not invariance but a predictable change.
Conceptually:
$$ f(T(x))\approx G_T(f(x)), $$where $G_T$ describes the expected transformation in output space.
For example:
runway collapses → cash preservation priority rises → discretionary investment falls → planning horizon shortens The output does not need to become maximally different.
It needs to change in the right way.
This is why raw divergence:
$$ d(y,y') $$is only a diagnostic.
The real target is fidelity to $R_T$.
6. The perturbation contract is part of the measurement A sensitivity score without a perturbation contract is almost meaningless.
A stronger contract is:
perturbation_contract = { "name": "runway_collapse", "transformation_type": "decision_relevant_intervention", "base_variable": "cash_runway_months", "transformation": "18 -> 3", "protected_invariants": [ "company_identity", "industry", "market_state", ], "expected_relation": "strategy_becomes_survival_oriented", "required_changes": [ "cash_preservation_priority_increases", "optional_investment_decreases", "time_horizon_shortens", ], "oracle": { "type": "structured_rubric", "version": None, }, "measurement": { "unit": "recommended_strategy", "paired": True, "samples_per_condition": 3, }, } The phrase decision-relevant intervention is deliberate.
Changing a value inside a prompt does not by itself establish a causal relationship in the real world. It creates a controlled counterfactual scenario for evaluation.
The test must declare:
what changed what must stay fixed what output component should change what direction the change should take how that relation will be judged The oracle is therefore part of the measurement contract.
7. The oracle-generation bottleneck Who writes the expected relation?
That question matters.
For some tasks, the oracle can be exact.
Level A — programmatic oracle input arithmetic changes → exact numeric output known Level B — structured deterministic oracle risk category HIGH → LOW ranking A > B → B > A unit test should now pass / fail Level C — rubric-based oracle cash preservation priority should increase materially A human, domain model, or evaluator may judge this relation.
Level D — open-ended judgment strategy should become more appropriate This is the weakest form because the expected relation itself is underspecified.
A frontier model can help draft perturbation contracts, but an LLM-generated oracle inherits its own failure modes:
sycophancy shared default assumptions missing domain constraints ambiguous rubrics hallucinated expected effects So:
A perturbation test is only as trustworthy as the oracle that defines what should have changed.
Where possible, prefer executable or structured relations over free-form judge preferences.
8. Perturbations themselves need validation Counterfactual generation can fail before the model under test ever runs.
A perturbation might:
change two decisive variables accidentally break scenario consistency fail to rename one entity occurrence remove evidence that was not actually decisive introduce an unintended demographic cue make the transformed scenario impossible So the test suite should validate:
transformation applied as declared protected invariants preserved scenario remains coherent oracle relation remains valid no hidden second intervention introduced Define:
$$ \operatorname{PerturbationValidityRate} \frac{N_{valid}}{N_{attempted}}. $$
And add a state:
INVALID_TEST This is not the same as:
UNAVAILABLE NOT_MEASURED FAIL The evaluator should not blame the model for a broken experiment.
9. A useful transformation ladder A repeatable suite benefits from increasing oracle and reasoning difficulty.
Level Transformation family Expected relation 1 formatting / paraphrase core answer invariant 2 consistent fictional rename / evidence reorder semantics and decision invariant 3 single decisive variable change declared output component changes directionally 4 constraint or outcome reversal decision/ranking often reverses 5 decisive evidence removal / contradiction injection support, confidence, or action changes The point is not that every application needs every level.
The point is that transformation difficulty should be declared rather than hidden.
This mirrors the benchmark and adversarial-difficulty discipline from Chapters 6 and 7.
10. The response surface is defined by transformation families Static evaluation sees:
x → y Dynamic evaluation examines a controlled family:
graph TD X[base input x] --> R[response] TP["T_paraphrase(x)"] --> RP[response should stay] TF["T_format(x)"] --> RF[response should stay] TB["T_budget(x)"] --> RB[response should move] TR["T_runway(x)"] --> RR[response should move] R -.- RP R -.- RF R -.- RB R -.- RR Natural-language inputs do not have one universally meaningful Euclidean neighbourhood.
So the local response surface is defined relative to a declared transformation family, protected invariants, and expected response relations—not merely by textual distance.
Contrast sets provide a local view of a model’s decision boundary through small meaningful perturbations.[1]
Counterfactual code evaluation similarly asks whether small but decisive specification changes produce the required behaviour.[6]
A system’s reliability is partly a property of the shape of its response surface around the input, not merely the quality of one sampled point.
That surface can be:
flat where it should move jagged where it should remain stable or selectively responsive The third state is the target.
11. Selective responsiveness needs two measurements Do not force should-change and should-not-change behaviour into one undifferentiated score.
Let $\mathcal{T}_I$ be the set of valid invariance transformations and $\mathcal{T}_R$ the set of valid response-changing transformations.
A benchmark may summarise invariance as:
$$ C \frac{1}{|\mathcal{T}I|} \sum{T\in\mathcal{T}_I}Q_T^{inv}, $$
and responsiveness as:
$$ S \frac{1}{|\mathcal{T}R|} \sum{T\in\mathcal{T}_R}Q_T^{rel}. $$
But production should retain the per-transformation results.
The resulting diagnostic is:
High responsiveness to decisive change Low responsiveness to decisive change High invariance to irrelevant change Selectively responsive Context-insensitive / generic Low invariance to irrelevant change Brittle but responsive Brittle and generic A third failure deserves a name:
Accidental responsiveness The answer changes after a decisive perturbation, but not in the expected direction.
For example:
budget falls 100× → proposed spend increases Raw output divergence is high.
Relation fidelity is zero.
That is why:
answer changed
is not enough to pass a sensitivity test.
12. Measure paired effects against sampling noise Every transformed example belongs to a specific base example:
$$ x_i\leftrightarrow T(x_i). $$Preserve that pairing.
Suppose a structured extractor $g(Y)$ maps a response to the decision variable we care about:
recommended spend risk level ranking selected action confidence state For one prompt family, estimate:
$$ \Delta_i \mathbb{E}[g(Y_{T(x_i)})] \mathbb{E}[g(Y_{x_i})]. $$
Then ask two questions.
Direction Did $\Delta_i$ have the sign or relation required by $R_T$?
Magnitude relative to noise Was the between-condition shift larger than ordinary within-condition variation?
A practical experiment can sample $k$ responses per condition and report:
paired effect confidence interval direction-correct rate within-condition variance between-condition shift Do not pool generations as if they were independent examples.
When bootstrapping, resample base prompt families, preserving their transformations and repeated generations as a group.
This is the same dependency discipline Chapter 6 demanded for source-grouped evaluation.
13. A response-relation matrix becomes the evaluation artifact Instead of one sensitivity score, record the suite.
Transformation Should change? Expected component Oracle strength Result paraphrase no core decision structured PASS / FAIL formatting no semantic decision structured PASS / FAIL fictional rename no relation/decision structured PASS / FAIL budget collapse yes plan scale / feasibility rubric or programmatic PASS / FAIL runway collapse yes survival priority rubric PASS / FAIL deadline compression yes scope / feasibility structured PASS / FAIL evidence removal yes support / confidence structured PASS / FAIL This response-relation matrix is the dynamic equivalent of the detector matrices in earlier chapters.
It tells us not merely whether the model is sensitive, but which kinds of transformation it understands and which it ignores.
14. Existing benchmarks fit different cells of the framework Recent work already measures several pieces of this problem.
Work This chapter’s interpretation SCORE primarily should-not-change robustness under paraphrases and answer-choice reorderings LogiConBench internal/logical constraint consistency ConfRAG reference consistency when retrieved evidence conflicts Legal relevance-sensitive evaluation explicit should-change + should-not-change counterfactuals CTF-Code decisive specification changes that should alter generated solutions SCORE reports accuracy fluctuations of up to 10% under prompt paraphrases on MMLU-Pro and up to 6.1% under answer-choice reordering on AGIEval.[2]
LogiConBench releases a 280,000-example logical-consistency corpus, with the hardest Enumerative task remaining difficult for the evaluated frontier models.[3]
ConfRAG contains 1,814 questions over heterogeneous web references, with explicit contradictions in 57.2% of questions.[4]
The 2026 legal work makes the duality especially explicit: trustworthy behavior requires stability under legally irrelevant changes and responsiveness when legally material facts change.[5]
No single benchmark covers the whole response-relation matrix.
That is exactly why consistency and sensitivity must be specified by contract rather than treated as one universal property.
15. Our use of sensitivity is deliberately narrower than some prior work Errica and colleagues also use the terms sensitivity and consistency, but for a different setting: text classification under prompt rephrasings. In their formulation, sensitivity measures prediction changes across prompt rephrasings, while consistency measures variation across rephrasings for examples of the same class.[7]
That work is relevant to the broader robustness problem.
This chapter uses counterfactual sensitivity more specifically for:
responsiveness to decision-relevant changes under an expected output relation.
So:
prompt-rephrasing sensitivity and:
counterfactual decision sensitivity should not be treated as identical measurements.
The shared principle is controlled variation.
The contracts differ.
16. The formalism predicts a failure mode Return to the safe-looking strategic answers from the opening.
Suppose materially different contexts:
$$ x_1,x_2,\ldots,x_n $$have perturbation contracts that require materially different decisions.
Let $g(Y)$ extract the recommendation or decision class.
If:
$$ g(Y_{x_1}) \approx g(Y_{x_2}) \approx\cdots\approx g(Y_{x_n}) $$while the expected relations require those decisions to differ, the transformation-fidelity machinery has caught something the earlier axes cannot.
Two cases must be separated.
Legitimate convergence Different scenarios genuinely imply the same action. Low output diversity is not itself a failure.
The failure the oracle names The oracle says decisive context should change the action, and it does not.
Containment does not see this, because nothing leaves the evidence geometry.
Constraint checks do not see it, because nothing contradicts the prompt.
The perturbation relation sees it, because the answer failed to move when the decision-relevant variable moved.
A response can therefore satisfy every static check and still be insufficiently responsive to the facts that should have determined it.
The formalism in this chapter predicts that failure mode without yet naming it. The next chapter examines it directly.
17. From three numbers to typed measurement records A shorthand such as:
$$ (H,C,S) $$is useful for a sketch.
But it visually suggests three homogeneous scalar coordinates.
They are not.
A more faithful abstraction is:
$$ \mathcal{R}(x) {R_H,R_C,R_S}, $$
where each $R_i$ is a typed measurement record with its own contract, output space, uncertainty, and blind spots.
For example:
reliability_record = { "containment": { "energy": 0.18, "state": "LOW_RISK", }, "constraint_fidelity": { "internal_consistency": "PASS", "reference_consistency": "PASS", "trajectory_consistency": "NOT_MEASURED", }, "transformation_fidelity": { "paraphrase_invariance": "PASS", "budget_change": "FAIL", "runway_change": "FAIL", "evidence_removal": "UNCERTAIN", }, } The state vocabulary now includes:
PASS FAIL UNCERTAIN NOT_APPLICABLE NOT_MEASURED UNAVAILABLE INVALID_TEST And:
NOT_MEASURED ≠ PASS UNCERTAIN ≠ FAIL NOT_APPLICABLE ≠ UNAVAILABLE INVALID_TEST ≠ model failure Summary scores may be useful for ranking, dashboards, or triage.
Diagnosis and policy should retain the typed record.
Chapter 12 will define how policy acts on that record. Until then, the measurements remain evidence, not authorization.
18. Do not assume the axes are orthogonal Earlier internal exploration described containment, consistency, and sensitivity as complementary but potentially correlated signals.
They target different properties, but their observed scores may correlate because one upstream failure can affect several axes.
Work one case through. A retrieval bug drops the one passage that carries the decisive fact, and returns four topically-related distractors instead.
containment (H) the claim now has less real support in the evidence set, and the distractors broaden the subspace → energy rises reference consistency (C) the claim can no longer be checked against the missing passage → the reference-consistency check returns UNCERTAIN or FAIL context sensitivity (S) the model, seeing weaker evidence, falls back to a generic answer → the counterfactual-inversion test now fails too One bug, three axes moving together. If you sampled a batch of requests during that outage and computed all three, H, C, and S would show a strong positive correlation — not because they measure the same property, but because they share an upstream cause. A dependence study that ran only on healthy traffic would miss it, and a policy that treated the three as independent evidence would triple-count one failure.
The right empirical question is:
Does each measurement add useful information where its contract says it should?
A minimum dependence study should:
run the measurements on the same prompt families; report Pearson/Spearman relationships where appropriate; compare single-axis and combined models; preserve failure-mechanism slices; measure incremental value inside the slice each axis is intended to observe. For example:
OUT-OF-SPAN INVENTION H vs H + C vs H + S RELATION INVERSION H vs H + C CONTEXT-INSENSITIVE RECOMMENDATION H + C vs H + C + S Global incremental AUC can be useful.
Conditional utility by failure mechanism is stronger evidence that a measurement is doing the job its contract claims.
The axes are complementary until experiments show how dependent they really are.
19. Production reality: response-surface evaluation is expensive A five-perturbation suite plus the original prompt can multiply generation cost by roughly six before repeated samples are added.
Running that synchronously on every request is often unnecessary and sometimes impossible under latency or budget constraints.
A practical architecture can separate cheap online sensors from expensive dynamic evaluation.
Synchronous Use low-cost checks that are already available in the request path:
runtime assertions structured constraints retrieval/evidence checks containment critical deterministic verification Shadow evaluation Run perturbation suites asynchronously on sampled traffic without blocking the user response.
Template / workload evaluation Cluster recurring prompt or task families and test representative scenarios deeply rather than perturbing every individual request.
Risk-triggered evaluation Run expensive counterfactual tests for:
high-stakes actions novel task families low-confidence cases policy-critical recommendations model/version changes Offline regression Keep a fixed response-relation suite for every model, prompt, retriever, or policy revision.
The response surface is therefore often a system evaluation artifact, not a per-token production gate.
That distinction matters for cost, latency, and reproducibility.
20. The experiment we still owe The chapter now has an executable method, but our earlier internal exploration contains a proposed perturbation pipeline rather than a completed numerical experiment.
We should not invent measurements to make the chapter appear more empirical than it currently is.
The next book-owned experiment is therefore explicit.
Prompt families Construct paired scenarios such as:
18 months runway ↔ 3 months runway $10M budget ↔ $100k budget growth ↔ decline 1 year deadline ↔ 1 week deadline support present ↔ decisive evidence removed Add should-not-change controls:
paraphrase formatting consistent fictional rename independent evidence reorder Sampling For each condition:
k repeated generations fixed model version fixed decoding profile record random seed where supported Measurement Report:
perturbation validity rate invariance pass rate relation-aware responsiveness pass rate direction-correct rate paired effect with confidence interval within-condition variation failure slices by transformation type Minimum interpretation The useful four-way diagnosis is:
Invariance Responsiveness Interpretation high high selectively responsive high low context-insensitive / generic low high brittle but responsive low low brittle and generic Until that experiment is run, this chapter establishes the measurement architecture and protocol, not a claimed sensitivity benchmark result for our own system.
That boundary is intentional.
21. What Chapter 9 adds We can now describe the reliability stack more precisely.
Containment What semantic material appeared? Did the claim extend beyond the evidence representation? Constraint fidelity Which relations, facts, states, and commitments should remain stable? Did the system preserve them? Transformation fidelity Which input changes should not matter? Which input changes should matter? Did behavior satisfy the corresponding expected relation? These questions catch different failure patterns.
Observed pattern Interpretation low containment risk + good constraint fidelity + good transformation fidelity candidate behaves well on these observed axes low containment risk + poor constraint fidelity in-span structural/reference failure high containment risk + good responsiveness adaptive but unsupported output low containment risk + good constraint fidelity + poor responsiveness safe-looking but context-insensitive output poor invariance + high raw divergence brittle system large change in wrong direction accidental responsiveness This is the first mature form of the diagnostic reliability record.
It is not complete.
We still need:
attribution provenance epistemic adequacy verification state policy But the architecture has crossed an important boundary.
We no longer evaluate the model only as a text generator.
We evaluate it as a stochastic response function under controlled transformations.
What you should now be able to answer After this chapter, you should be able to explain:
Why a response can be perfectly repeatable and still wrong. The difference between invariance and equivariance, and why one formalism covers both. Why a perturbation is not usable as a measurement until the perturbation itself is validated. How to tell a real paired effect from sampling noise. What the four cells of the invariance-by-responsiveness diagnosis mean. Why the evaluation unit moves from one response to a controlled family of executions. Why this book’s use of sensitivity is narrower than some prior work, and what the narrow sense is. What this chapter establishes, and what it explicitly does not establish about our own system. Exercises Exercise 1 — Write a perturbation contract Take one task you care about. Following the contract in Section 6, list three transformations that must not change the decision and three that must. For each, state the expected relation — invariance, or the direction the decision should move — and the oracle level from Section 7 you would need to check it.
Exercise 2 — Separate an invariance failure from noise Pick one should-not-change transformation. Generate several responses for the original input and several for the perturbed input at a fixed model version and decoding profile. Extract one structured decision per response. Report the paired effect with a confidence interval and the within-condition variation. Decide whether any observed movement exceeds sampling noise.
Exercise 3 — Run the four-way diagnosis Build five should-not-change pairs and five should-change pairs for the same task. Compute the invariance pass rate and the responsiveness pass rate. Place the system in one cell of the Section 20 table. State which failure you would fix first, and why.
Exercise 4 — Validate an oracle before trusting it Take the should-change set from Exercise 3. Before running the model, have two independent labelers mark the expected direction for each pair. Record the agreement rate. If the oracle disagrees with itself, the sensitivity numbers built on it are not yet interpretable.
Research roots Matt Gardner et al., “Evaluating Models’ Local Decision Boundaries via Contrast Sets,” Findings of EMNLP 2020, pp. 1307–1323. Introduces contrast sets built from small, meaningful perturbations that expose failures hidden by standard in-distribution test sets. https://aclanthology.org/2020.findings-emnlp.117/
Grigor Nalbandyan, Rima Shahbazyan and Evelina Bakhturina, “SCORE: Systematic COnsistency and Robustness Evaluation for Large Language Models,” NAACL 2025 Industry Track. Reports substantial accuracy variation under prompt paraphrasing and answer-choice reordering and proposes repeated evaluation across controlled setups. https://aclanthology.org/2025.naacl-industry.39/
Zheng Chen et al., “LogiConBench: Benchmarking Logical Consistencies of LLMs,” ICLR 2026. Generates scalable logical graphs with explicit reasoning paths and reports substantial remaining difficulty for frontier models on exact logical-consistency tasks. https://proceedings.iclr.cc/paper_files/paper/2026/hash/01db36a646c07c64dd39a92b4eceb417-Abstract-Conference.html
Yizhen Yuan, Rui Kong, Dongze Li, Yuanchun Li and Yunxin Liu, “Benchmarking LLM’s Capability in Reasoning over Conflicting Web References,” ACL 2026, pp. 303–322. Introduces ConfRAG with 1,814 questions over heterogeneous web references; 57.2% contain explicit contradictions. https://aclanthology.org/2026.acl-long.11/
Linze Chen, Yufan Cai, Zhe Hou and Jin Song Dong, “Which Changes Matter? Towards Trustworthy Legal AI via Relevance-Sensitive Evaluation and Solver-Grounded Reasoning,” 2026. Frames trustworthy behavior as sensitivity to legally material changes combined with invariance to irrelevant changes. https://arxiv.org/abs/2605.26530
Xianzhen Luo et al., “Success is in the Details: Evaluate and Enhance Details Sensitivity of Code LLMs through Counterfactuals,” 2025. Introduces CTF-Code using minimal counterfactual specification changes and reports substantial performance degradation under detail-sensitive variants. https://arxiv.org/abs/2505.14597
Federico Errica, Davide Sanvito, Giuseppe Siracusano and Roberto Bifulco, “What Did I Do Wrong? Quantifying LLMs’ Sensitivity and Consistency to Prompt Engineering,” NAACL 2025, pp. 1543–1558. Defines sensitivity and consistency for classification robustness across prompt rephrasings; this chapter distinguishes that use from decision-relevant counterfactual responsiveness. https://aclanthology.org/2025.naacl-long.73/
Next: The Safe but Useless Model We now have a method for detecting a failure ordinary hallucination checks miss.
An answer can be:
well contained structurally consistent factually unobjectionable stable under harmless paraphrase and still be wrong for the situation because it barely depends on the situation at all.
Chapter 10 takes that failure seriously.
The next question is not:
Did the model make something up?
It is:
Did the model actually respond to the problem it was given, or did it collapse to the same safe high-probability answer it would have produced anyway?
That is the safe but useless model.