Beyond Hallucination: Consistency and Sensitivity

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:

The transformation must also declare what relation should hold between the resulting behaviors.

Call that expected relation:

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
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:

Define a relation evaluator:

Invariance

If the transformation should not matter, the expected output transformation is identity:

Equivariance / directional responsiveness

Often the correct behavior is not invariance but a predictable change.

Conceptually:

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:

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:

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.

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:

The resulting diagnostic is:

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:

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:

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.

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.

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:

Let $g(Y)$ extract the recommendation or decision class.

If:

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:

But it visually suggests three homogeneous scalar coordinates.

They are not.

A more faithful abstraction is:

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:

1. run the measurements on the same prompt families;
2. report Pearson/Spearman relationships where appropriate;
3. compare single-axis and combined models;
4. preserve failure-mechanism slices;
5. 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:

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.

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:

1. Why a response can be perfectly repeatable and still wrong.
2. The difference between invariance and equivariance, and why one formalism covers both.
3. Why a perturbation is not usable as a measurement until the perturbation itself is validated.
4. How to tell a real paired effect from sampling noise.
5. What the four cells of the invariance-by-responsiveness diagnosis mean.
6. Why the evaluation unit moves from one response to a controlled family of executions.
7. Why this book’s use of sensitivity is narrower than some prior work, and what the narrow sense is.
8. 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

1. 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/

2. 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/

3. 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

4. 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/

5. 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

6. 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

7. 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.