Trust Calibration in Human-AI Systems

Trust calibration is the alignment between how much a user relies on an AI system's output and how reliable that output actually is for the task, context, and version in front of them. The construct is necessary for safe and productive human-AI work, but it is also local, evidence-dependent, and brittle under capability drift — calibration is best understood as situated appropriate reliance under uncertainty, not as a stable user attitude that interface design can install. This article surveys the construct, its measurement pathologies, the empirical record from automation studies through current software-engineering work, and the design interventions whose effects depend heavily on conditions.

Coverage note: verified through May 2026.

1. Definition: from "trust in AI" to appropriate reliance

The standard formulation of trust calibration treats it as the degree to which a user's expressed confidence in an AI output matches the AI's actual reliability. That definition is operationally useful but conceptually thin in three ways, and the deeper literature on human-automation interaction has spent two decades pushing past it.

First, expressed confidence is only one of several quantities a designer or researcher might mean by "trust." Lee and See's 2004 Human Factors review anchors the field by defining trust in automation as an attitude that an agent will help achieve an individual's goals in a situation characterized by uncertainty and vulnerability — but the operational target is appropriate reliance, not maximal trust. A user who trusts a perfectly reliable system can still fail to rely on it; a user who reports low trust can still defer to its suggestions when verification is expensive. The construct that matters at the moment of action is the reliance behavior, of which expressed confidence is a noisy, sometimes misleading proxy.

Second, the binary "accept or reject" frame hides what people actually do with AI outputs in real workflows. They accept, reject, edit, ask for justification, run tests, consult a second system, escalate to a colleague, defer the decision, or change the task. This middle space is where the verification economy lives: how cheaply can a user check the output, who pays the cost, what evidence makes it usable. Any account of calibration that omits verification cost will overestimate the role of static UI cues.

Third, "AI reliability" is not a scalar. For frontier generative systems, reliability is a jagged surface over task type, prompt phrasing, retrieval state, system instructions, model version, tool affordances, and whether the user can notice an error post hoc. The same chat assistant may be 95% accurate at boilerplate test scaffolding in a familiar repository and well below 50% accurate at security-sensitive refactors three commits later. Talking about whether a user "trusts Claude" or "trusts Copilot" at the product level is usually too coarse to be calibrated against anything stable.

A more defensible operational definition follows from these three points: trust calibration is the match between a user's enacted reliance on an AI output — accept, reject, verify, or escalate — and the AI's empirically observed reliability for the specific task slice, context, and system version that produced the output. Cross-references: Appropriate Reliance, Automation Bias, Algorithm Aversion, Human-AI Teaming.

2. The over-reliance / disuse spectrum

The classic frame for miscalibration places two failure modes at opposite ends of a single axis:

Behavior	AI is correct	AI is incorrect
User accepts	Appropriate acceptance	Over-reliance (false acceptance)
User rejects	Disuse / underreliance (false rejection)	Appropriate rejection

Over-reliance and disuse are both well documented in the automation-bias and algorithm-aversion literatures. Parasuraman and Riley's 1997 framework introduced the use / misuse / disuse / abuse vocabulary that still organizes most of this work, and meta-analyses since have shown both modes are real, context-sensitive, and costly.

The matrix is a useful spine, but it understates the structure of real decisions in two ways. Severity asymmetry: false acceptance of a wrong medical recommendation, a wrong legal citation, or a wrong production database migration is not symmetric with false rejection of a correct one. Verification cost: the cells implicitly assume a binary decision with cheap ground truth. In coding, ground truth is sometimes cheap (the test passes or fails) and sometimes expensive (the architectural choice ages well or doesn't). The four-cell matrix should therefore be read as a starting point that needs to be augmented with cost, severity, and reversibility before it scores a workflow.

3. Measurement: five quantities that get confused

Most of the quality problems in the trust-calibration literature trace to confusion among five distinct measurable quantities. A wiki entry that conflates them — or cites studies that do — will overclaim. Any specific study should be readable as targeting one or two of these:

#	Quantity	Typical measure	Common confusion
1	AI reliability	Accuracy, F1, defect rate, slice-level eval	Treated as a single number; "the model is 87% accurate" hides slice variance
2	Model confidence calibration	Brier score, ECE between AI-reported probability and AI correctness	Conflated with user calibration; a calibrated model does not guarantee a calibrated user
3	User self-reported trust	Likert items, Trust in Automation Scale	Treated as a behavioral predictor; survey trust often diverges from acceptance behavior
4	User confidence in a specific output	Forecasted probability the AI is correct, item-level	The right calibration target — but expensively elicited and rarely instrumented in field studies
5	Behavioral reliance	Accept / reject / verify / edit rates conditional on AI correctness	Where most of the actionable signal lives; underreported because it requires logging

A sixth quantity sometimes folded in — team accuracy — is downstream of all of these and is worth keeping separate. A team can become more accurate because the AI is strong, even if the human is poorly calibrated; conversely, a calibrated user can perform poorly when paired with a weak model. Bansal, Wu, Zhou, Fok, Nushi, Kamar, Ribeiro, and Weld's CHI 2021 study is widely (and incorrectly) cited as evidence about user trust calibration when its primary contribution is to show that adding explanations to AI advice can increase team accuracy without improving complementarity — that is, users became more accepting of AI recommendations whether the recommendations were correct or not. The team got better; the calibration did not.

This decomposition motivates the article's central methodological commitment: whenever a study or claim is invoked, the underlying measurement target should be named explicitly. "Trust improved" is not a complete claim. "Self-reported trust improved while behavioral over-reliance also increased" is.

4. Theoretical anchor: Lee and See's framework, and what it does not cover

Lee and See 2004 remains the right starting point because of three commitments that survive the transition from rule-based automation to generative AI. The framework treats trust as dynamic (it updates as evidence accumulates), contextual (calibrated to a specific automation in a specific situation), and appropriate rather than maximal (the design target is matching reliance to capability, not increasing reliance). It explicitly distinguishes the affective, cognitive, and analytic bases of trust, and it predates but anticipates much of the human-AI decision-making literature.

What the framework does not cover, and what frontier AI systems make load-bearing, is the rate of change. Classical automation typically had documented operating envelopes — a TCAS, an autopilot mode, a cruise control — within which reliability claims were stable enough that operators could form mental models from training and experience. Generative AI systems do not generally come with operating envelopes. Their behavior depends on prompt phrasing, retrieval results, system instructions, tool calls, version updates, and product UI changes that ship without notice. The gap between what users perceive about a model and what the model does is not a one-time training problem but a continuously regenerating one.

This is the move the field is currently making: from a single user-attitude framing toward a maintenance framing in which calibration is the output of an ongoing loop between reliability evidence (versioned evals, slice-level benchmarks, audit trails), decision interfaces (confidence, explanation, friction), and feedback (test outcomes, review, deployment telemetry). When any of those three is missing or stale, calibration decays.

5. Evidence by domain

The empirical record on trust calibration is uneven across domains. Treating it as a single literature obscures more than it reveals. The strongest evidence sits in classic decision-support and lab-based human-AI decision studies; the software-engineering evidence is much thinner than its prominence in current practitioner discourse would suggest.

5.1 Classic decision-support and automation

The automation-bias literature established the basic phenomena. Operators monitoring automated systems show characteristic errors of commission (accepting an automated cue that contradicts other available evidence) and omission (failing to notice a problem the automation missed). Mosier and Skitka's work in aviation, and subsequent meta-analyses in clinical decision support and process control, document these effects across decades. The takeaway that survives into the AI era is not that humans are uniformly biased toward automation; it is that reliance is sensitive to perceived authority of the automation, attentional load, time pressure, accountability structure, and the legibility of the underlying evidence.

5.2 Human-AI decision-making in lab settings

The CHI / CSCW / FAccT human-AI decision-making literature from roughly 2018 onward has produced the densest evidence on calibration interventions, almost all of it in controlled lab tasks (image classification, deceptive review detection, recidivism risk, nutrition decisions, sentiment).

Bansal et al. (CHI 2021) tested whether explanations help human-AI teams achieve complementary performance — outperforming both AI alone and human alone. Across two studies and two domains, they found AI assistance improved team accuracy, but explanations did not increase the complementarity benefit. Instead, explanations increased the rate at which users accepted AI recommendations regardless of correctness. The result is one of the cleanest demonstrations that explanation presence is not a calibration intervention.

Vasconcelos, Jörke, Grunde-McLaughlin, Gerstenberg, Bernstein, and Krishna's CSCW 2023 work partially complicates the Bansal picture: across five experiments, explanations did reduce over-reliance when explanation engagement cost was lower than the value of avoiding an incorrect AI suggestion. Their cost-benefit framing reframes over-reliance not as a cognitive bias but as a rational response to verification cost — users skip explanations and defer to the AI when checking is expensive relative to the expected gain from catching an error. This makes the design implication conditional: explanations help when they reduce the marginal cost of verification or increase its marginal benefit.

Buçinca, Malaya, and Gajos's 2021 study of cognitive forcing functions tested interventions that interrupt the user before an AI recommendation is shown — making the user commit to a tentative answer, or wait, or update incrementally. These deliberate-friction designs reduced over-reliance more reliably than passive XAI techniques (e.g., feature highlights), but participants liked them less, and the benefit was moderated by need for cognition. This finding is among the cleaner pieces of evidence that calibration improvements often come at adoption and satisfaction cost.

Zhang, Liao, and Bellamy's FAT* 2020 study tested whether confidence scores improve trust calibration. Their result is mixed: confidence displays helped users distinguish high- from low-confidence AI outputs, but did not consistently improve joint decision accuracy. Calibration of belief did not translate cleanly into calibration of action.

Schoeffer, De-Arteaga, and Kuehl's CHI 2024 paper on explanations and fairness found that feature explanations changed reliance behavior without helping users distinguish correct from incorrect recommendations — and in some conditions, the reliance shifts were patterned along sensitive attribute lines, raising fairness concerns separate from accuracy.

Ma, Lei, Xu, You, and Yang's CHI 2024 work on human self-confidence calibration is a useful pivot. Rather than asking whether users trust the AI appropriately, it asks whether users know when they themselves are likely wrong — and shows interventions that help users calibrate their self-confidence indirectly improve appropriate reliance, because well-calibrated users defer to AI when their own confidence is low and override when it is high. This reframes the problem: in many decisions, the bottleneck is not how the AI presents itself but whether the user has any meaningful read on their own competence in the slice.

The honest aggregate read of this literature: explanations and confidence displays are not generic calibration aids; they have measurable effects on reliance behavior that are sensitive to task, cost, and incentive structure, and that can either help or hurt calibration depending on those conditions. Friction-based interventions have somewhat stronger and more consistent calibration effects but trade against speed and satisfaction.

5.3 Software engineering: thin and unsettled

The software-engineering evidence is the one most often invoked in current practitioner writing on trust calibration, and it is the evidence the field should be most cautious about. Three caveats:

First, most published studies measure productivity, code quality, defect rates, security implications, or perceived usefulness — not calibration in the strict sense (forecasted user confidence vs. verified output correctness). The early Copilot productivity RCT and observational studies established that AI code assistance changes how developers work and can increase task throughput on certain tasks, but they did not directly test whether developer confidence in AI-generated code tracks its actual correctness.

Second, the qualitative and design-probe work on developer trust — Wang, Cheng, Ford, and Zimmermann's FAccT 2024 study of trust in AI-powered code generation tools is a representative example — captures how developers reason about AI assistants (provenance concerns, calibration to task type, oscillation between automation and skepticism, organizational policy effects). This work is valuable for design, but it is interview- and probe-based and does not produce calibration estimates.

Third, the closest things to direct calibration evidence in coding work are emerging but limited. Mozannar, Bansal, Fourney, and Horvitz's CHI 2024 work on Copilot programmer interactions develops a vocabulary for the cost of programmer-AI interaction (the time and cognitive load of evaluating, verifying, accepting, or modifying suggestions) — useful framing but not a calibration study. The widely-discussed METR early-2025 RCT on experienced open-source developers using Cursor/Claude-style tools found a perception-performance mismatch — developers expected speedups while measured task completion time increased in that population. This is a real and important finding, but it is also small, task-local (real maintenance work in mature open-source repos), specific to a particular cohort of expert developers, and aging fast given how quickly the underlying tools change.

Anthropic's 2026 Claude Code autonomy analysis is sometimes cited in calibration discussions; it is best read as vendor telemetry showing patterns in autonomous coding sessions (longer sessions, clarification frequency, oversight-infrastructure use). It is useful as descriptive data, not as independent calibration evidence — and the underlying tool changed materially within the analysis window.

Recent ICSE 2025 work on calibration of code-generation models addresses model-side confidence calibration: whether an LLM's stated probability of correctness for a generated snippet matches actual correctness. This is a necessary input to user calibration but not the same thing — even a perfectly calibrated model can produce poorly calibrated users if the confidence signal is hidden, mislabeled, or inactionable.

The defensible aggregate claim, as of May 2026: direct trust-calibration evidence in professional software engineering is qualitative, perception-focused, or task-local; productivity and correctness studies provide adjacent but distinct evidence; and the field lacks published longitudinal, instrumented field studies that link forecasted confidence, accept/reject behavior, verification, and defect outcomes across model versions.

6. Design interventions and their boundary conditions

The interventions most often proposed for improving trust calibration — confidence visualizations, explanation interfaces, uncertainty quantification, and deliberate friction — should be presented as conditional mechanisms, not best practices. The following table summarizes the evidence-supported boundary conditions. Each row should be read as "this intervention helps when X and fails when Y."

Intervention	Works when	Fails when	Best evidence
Confidence visualizations	Underlying model confidence is itself calibrated; users understand the scale; confidence maps to a task-relevant action threshold	Confidence is poorly calibrated or hidden post hoc; users treat the number as authoritative without understanding its derivation; UI reduces verification because output now "feels checked"	Zhang et al. 2020
Explanation interfaces	Explanations reduce the marginal cost of verification or increase its marginal benefit; users have time and incentive to engage	Explanations make outputs feel more coherent and increase acceptance regardless of correctness; explanations introduce reliance shifts patterned along sensitive attributes	Bansal et al. 2021; Vasconcelos et al. 2023; Schoeffer et al. 2024
Uncertainty quantification	Uncertainty maps to a clear action (e.g., "below threshold → run extra test"); users can act on it without retraining; visualization is ordinal and behaviorally meaningful	Uncertainty is conveyed as raw numbers without action mapping; users develop fatigue and ignore the cue; uncertainty is itself uncalibrated against actual error rates	Decision-support meta-analyses
Deliberate friction / cognitive forcing	Friction is proportional to risk and reversibility; high-stakes actions get more friction; users have authority and time to act on what the friction surfaces	Friction is uniform and ritualized into clicking-through; users disable safeguards or stop using the tool; friction is borne unevenly across user populations	Buçinca, Malaya, Gajos 2021
Versioned reliability evidence	System exposes slice-level reliability that updates with model changes; users can map their task to a slice; evidence is delivered in workflow rather than buried in docs	Evidence is presented as a global accuracy number; users cannot find the slice that matches their task; evidence is stale or vendor-curated without independent audit	Limited direct evidence; mostly architectural argument
User self-confidence calibration	Task structure allows users to predict their own correctness; feedback closes the loop on user predictions	Users have no meaningful read on their own competence in the slice; self-prediction is itself uncalibrated; feedback is too delayed to support learning	Ma et al. 2024
Feedback loops on outcomes	Feedback is fast, attributable to specific AI suggestions, and credible; outcomes are observable post hoc	Outcomes are delayed (security, maintainability, architectural fit); attribution is contested; feedback is filtered or selectively presented	Argued from Lee & See 2004; limited direct AI evidence

Several second-order patterns recur across rows. Interventions can correct for over-reliance while inducing disuse — sufficiently strong warnings or friction can drive users to abandon a system that, on net, would have improved decisions. Interventions can improve average outcomes while degrading edge cases — an explanation interface that helps experts may impose cognitive cost on novices, and a confidence threshold that improves aggregate accuracy may hide degradation in rare or adversarial slices. Interventions can produce procedural compliance without epistemic engagement — users develop the appearance of careful checking (reading explanations, hovering on confidence labels) while still accepting the AI's output, particularly when verification is expensive or accountability is diffuse.

The implication is that a calibration intervention should not be evaluated on the dimension it nominally addresses, but on whether it shifts the full joint distribution of (acceptance, verification, correctness, severity) in the desired direction across the populations and task slices the system serves.

7. Second-order effects and equity

Once "trust calibration" becomes an operational metric inside an organization, the metric itself can be optimized in ways that look like calibration but aren't. A team can drive measured acceptance / rejection rates toward target values while hiding severe error pockets in rare slices, adversarial prompts, or marginalized user populations. A confidence display can make a system appear calibrated in aggregate while concealing slice-level miscalibration that disproportionately affects groups with less training data.

The equity dimension is under-discussed in current calibration writing and deserves explicit treatment. Most documented intervention effects — confidence visualizations, explanations, friction — are moderated by user expertise, domain knowledge, need for cognition, language, accessibility, and organizational role. Interventions that improve calibration for the median expert user can simultaneously increase cognitive load, error rates, or abandonment for novices, non-native speakers, or users without time to engage. An honest design specification should report these moderation effects, not only the average treatment effect.

A related concern is accountability laundering. Many AI-augmented workflows are described as "human-in-the-loop" on the strength of a user click somewhere in the chain. If the user lacked the time, evidence, or authority to actually verify the AI's output — common in high-volume settings, claims processing, content moderation, code review at scale — then the human-in-the-loop framing is procedural cover rather than calibration. The calibration question for such systems is not "did the user accept appropriately?" but "did the user have the conditions to calibrate at all?" Cross-reference: Human Oversight, Accountability in Automated Decision Systems.

The harms of miscalibration are not borne evenly. Over-reliance pushes errors downstream — to patients, customers, defendants, users who never opted into the AI system, and junior or downstream engineers who inherit AI-generated artifacts. Disuse can also harm people, by preserving slower or less accurate human-only workflows that are themselves badly calibrated against the actual base rates of decisions. Calibration is therefore not a neutral design property; it is a distributive one.

8. The nonstationarity problem: capability drift

The deepest open question for trust calibration in modern AI systems is whether stable user calibration is achievable when the AI's capability surface changes faster than the user receives reliable feedback. This is the nonstationarity problem, and it has no settled answer.

Three sources of drift compound:

1. Model drift. Frontier model versions ship at intervals that are short relative to the time it takes a user to develop a calibrated mental model from naturalistic feedback. A user who has spent six months learning where the previous model fails may need to relearn most of that map within weeks of an update. Vendors do not generally publish slice-level reliability deltas between model versions, and benchmark comparisons are typically aggregate.
2. Product drift. Even when the underlying model is stable, the system instructions, retrieval pipeline, tool integrations, safety filters, and UI affordances around it change. The same prompt to "Claude" in two different products on two different days can route through different system prompts, different tool stacks, and different verification scaffolding.
3. Workflow drift. As users adapt to AI assistance, the tasks they delegate also change — typically toward longer, more autonomous, less inspectable units of work. Calibration formed on autocomplete-style suggestions does not transfer to agent-style multi-step tasks.

Two architectural responses are visible in current systems, neither clearly sufficient:

Maintenance-style calibration, in which the system exposes versioned reliability evidence (slice-level evals, changelog deltas, audit trails) and the user's calibration is treated as a continuously regenerating output of that pipeline. This is closer to how reliability engineering treats systems whose components change over time. It is consistent with Lee and See's dynamic-trust framing but requires evidence infrastructure that most products do not currently expose.

Localized calibration, in which users abandon any pretense of calibration to "the model" or "the product" and instead develop calibration against tightly bounded task slices ("this assistant is reliable for boilerplate test scaffolding in this repo when CI passes"). This is empirically how experienced users seem to operate, and it has the advantage of being achievable. It has the disadvantage of being non-transferable — calibration earned in one slice does not generalize, and users typically cannot audit which slices generalize and which do not.

A third response — abandoning calibration as a user-side problem and treating it as a governance and evaluation problem — is sometimes proposed and is partially correct: when reliability changes faster than users can track, the answer cannot be "users should try harder." But governance does not eliminate the calibration question; it shifts where the calibration happens. If the user still has to decide whether to accept an output, the system still needs a calibration story; the story is now told by the evidence infrastructure rather than by the user's mental model.

The honest read is that achievable calibration is local, versioned, and slice-bound; calibration to a product or vendor at the level of "I trust Claude" is probably not achievable in any rigorous sense given current rates of change. Users who report such global calibration are usually reporting a generalized affective stance — useful for adoption decisions, not for individual outputs.

9. When calibration is the wrong frame

Trust calibration is the right frame for many decisions, but not all. Three cases where it is the wrong frame are worth naming explicitly, because invoking calibration in these contexts produces the appearance of rigor without the substance.

When the task does not have a verifiable ground truth at action time. Code that compiles and passes tests has reasonable short-term ground truth; code that ages well in a system over five years does not. Architectural recommendations, security choices, hiring decisions, and most strategic outputs share this property. Calibration in such cases is calibration against a proxy (does the test pass, does the explanation feel coherent), and optimizing against a proxy that is decoupled from outcomes is a known failure mode. The alternative is not better calibration; it is structural — code review, second-pair-of-eyes processes, post-deployment monitoring, reversibility. Cross-reference: Outcome Verification Cost.

When verification cost dominates decision cost. In high-volume settings — content moderation, claims processing, inbox triage — the per-decision verification budget is so small that no realistic UI intervention can produce calibration. The honest framing in such settings is not "calibrate the user" but "set the system's risk threshold to a level where uncalibrated routine acceptance is acceptable, and route the rest to a higher-cost path."

When the AI's reliability is fundamentally unobservable to the user. In some agentic workflows, the user does not see the intermediate tool calls, retrieved documents, or chain-of-thought that produced an output. Calibration against the surface output without visibility into the process is calibration against a presentation, not a system. This case is increasingly common in production agent systems and deserves more attention than it currently receives. Cross-reference: Agentic AI Oversight, Process Visibility.

In each of these cases, the right move is structural rather than perceptual: change what the user can see, what verification costs, or what the AI can do unilaterally. UI cues are secondary unless they live inside an evidence-producing system.

10. What the field needs next

The decisive missing evidence for the software-engineering case — and by extension for the broader claim that trust calibration is improvable in fast-changing AI workflows — is longitudinal, instrumented field study that links four quantities across model and tool changes:

• The user's predicted probability that a specific AI output is correct (item-level confidence forecast).
• The user's actual reliance behavior on that output (accept, reject, edit, verify, escalate).
• Verification effort actually expended.
• Outcome correctness, ideally with severity weighting.

Cross-sections are not enough; the longitudinal piece is what tests whether calibration survives capability drift. The cheapest version of such a study is a coding-field RCT in a real maintenance environment, randomizing across normal AI assistance, calibrated confidence/evidence displays, deliberate friction, and outcome feedback, and running across at least one model or product update. Calibration error between forecasted user confidence and verified correctness, plus false-acceptance and false-rejection rates by severity, would be the primary metrics; task time, review burden, satisfaction, and post-update drift the secondary. As of May 2026, no published study at this resolution exists for production coding work; the METR RCT is the nearest neighbor but does not capture item-level confidence forecasts against verified correctness.

Even such a study would not settle the general question. It would settle a local regime — a particular tool, model version, task mix, team culture, and verification infrastructure. The general claim ("trust calibration is achievable in fast-changing generative AI") is probably not the kind of claim that admits a clean empirical resolution. The more tractable claims are slice-by-slice and version-by-version, and that is the level at which the field should be pitched.

11. Net read

Trust calibration is a necessary concept for any safety-conscious account of human-AI systems, but the construct does not bear the weight current discourse places on it. The defensible position is:

1. Calibration is appropriate reliance, not maximal trust — and the operational target is reliance behavior under verification cost, not self-reported confidence.
2. The five quantities — AI reliability, model confidence calibration, user self-reported trust, user item-level confidence, behavioral reliance — must be kept distinct. Most overclaims in the literature trace to merging them.
3. Lee and See's 2004 framework is still the right anchor, especially its insistence on dynamic, contextual, appropriate trust — but its assumption of stable operating envelopes does not hold for frontier generative AI and must be supplemented with maintenance-style calibration architectures.
4. The strongest empirical findings are conditional, not universal. Explanations and confidence displays are not generic aids; they have measurable effects that depend on cost, incentive, and task structure. Friction is more reliably calibration-improving but trades against adoption.
5. The software-engineering evidence is thinner than its rhetorical prominence suggests. Productivity, perceived usefulness, and defect-rate studies are not direct calibration evidence; the few direct calibration studies are small, task-local, and aging fast.
6. Capability drift is the unsolved problem, not an inconvenient footnote. Achievable calibration is local and versioned; global calibration to a product or vendor is probably not achievable in a rigorous sense given current rates of change.
7. Calibration is a distributive property, not a neutral one. Its failures fall unevenly across user populations and downstream third parties, and design specifications should report moderation effects rather than only average treatment effects.

The wiki entry's main warning to a practitioner: be skeptical of any calibration claim that does not name the measurement target, the task slice, the system version, the verification cost, and the population for whom it holds. Be more skeptical of any intervention recommendation that does not name the boundary conditions under which it works and the failure modes it can introduce. Calibration is real, but it is a property of (system, task, user, version, evidence infrastructure) tuples — not a property of users or models alone.

Companion entries

Core theory:

• Appropriate Reliance
• Automation Bias
• Algorithm Aversion
• Lee and See Trust in Automation Framework
• Human-AI Teaming

Measurement:

• Behavioral Reliance vs Self-Reported Trust
• Model Confidence Calibration
• Complementary Team Performance
• Verification Cost in Human-AI Decisions

Design interventions:

• Explanation Interfaces
• Uncertainty Quantification in Decision Support
• Cognitive Forcing Functions
• Confidence Visualizations
• Versioned Reliability Evidence

Software engineering:

• AI Pair Programming
• Copilot and Coding Agent Studies
• Perception-Performance Mismatch in Developer Tools
• Agentic AI Oversight

Counterarguments and limits:

• Capability Drift and Nonstationary AI
• Accountability Laundering
• Equity Effects of Calibration Interventions
• When Calibration Is the Wrong Frame
• Outcome Verification Cost

Adjacent governance:

• Human Oversight
• Evaluation Drift
• Slice-Level Reliability Evaluation
• Audit Trails for AI Systems