The Answer Is Optional: An Abstention Contract for AI

A procurement assistant reads an invoice, finds a plausible purchase order, and drafts an approval. The supplier name and amount match, but the currency is missing and two purchase orders share the same reference fragment. The model can still produce a fluent answer. The useful question is whether the system should let it.

That is the reader decision in this guide: for this claim or action, should the AI answer, seek more evidence, defer to a qualified reviewer, or refuse? The answer cannot come from a generic confidence badge or a prompt that says “say I do not know.” It requires an operating contract that connects evidence, consequence, measured performance, and fallback capacity.

The central rule is: abstention is a system decision, not a style of generated prose. A low score is one signal. The enforceable outcome belongs outside the model, is tested on representative cases, and expires when the model, task, population, evidence path, or cost of error changes.

Abstention is a service behavior, not a sentence style

A model can write “I am uncertain” before a wrong answer, or state a wrong answer with complete confidence. It can refuse a harmless request for policy reasons while confidently inventing a document fact. These are different mechanisms:

• epistemic abstention: available evidence or validated competence is insufficient;
• policy refusal: the request or output is prohibited regardless of confidence;
• operational deferral: the task may be valid, but authority, time, capacity, or a required reviewer is unavailable;
• clarification: a missing field or ambiguous intent can be resolved through a bounded question.

Do not combine them into one “failure” label. Each disposition needs a reason code, user message, safe next step, owner, and measurement. A system that withholds an answer but silently drops the work has not failed safely; it has moved the failure downstream.

This is also why human approval design matters. Deferral is useful only when the person receives the evidence, ambiguity, consequence, and available alternatives—and has the authority and time to decide.

What the evidence establishes—and where design judgment begins

The NIST AI RMF Core says knowledge limits and human oversight should be documented, evaluations should resemble deployment conditions, limits on generalization should be recorded, and systems should fail safely when pushed beyond their knowledge limits. It does not give one universal confidence threshold.

For generative systems, NIST AI 600-1, published in July 2024, defines confabulation as confidently presented erroneous content and recommends empirically validating capability claims, checking sources and citations, and handling errors. Fluency therefore cannot serve as a correctness signal.

Research gives narrower tools. The 2017 selective-classification paper frames a reject option as a trade between coverage—the share of cases answered—and risk on the answered subset. The 2019 SelectiveNet paper trains prediction and rejection jointly and reports improved risk–coverage trade-offs on its studied classification and regression datasets. These papers establish methods in specified experimental settings, not a guarantee for every language-model workflow.

ZharfAI's analysis is to turn that idea into an application-level contract. The decision unit is not “the whole chat.” It is one typed claim, recommendation, extraction, or action under a named consequence and evidence requirement.

Define four dispositions before choosing a score

Start with outcomes that the product can actually execute:

Define these per claim type. An assistant may answer where an invoice was received, seek evidence for the currency, defer a tolerance exception, and refuse to create a fictitious approval record—all in one workflow.

Record the minimum contract: task and population, evidence required, acceptable error by consequence, answer authority, deferral destination, maximum wait, privacy boundary, expiry, and owner. If no safe fallback exists, reducing coverage is not automatically safe; the product may be unfit for that use.

Treat confidence as evidence, not truth

A useful score orders cases so errors concentrate at one end. A calibrated probability makes a stronger claim: among comparable cases assigned 0.8, roughly 80 percent should be correct under the evaluated conditions. Ranking and calibration are not the same.

The 2017 calibration study by Guo and colleagues found poor calibration in the modern neural classifiers it tested and showed that temperature scaling often improved those studied settings. It did not establish that one calibration method turns token probabilities, verbal confidence, or a vendor score into a universal probability of factual correctness.

For a generative workflow, build signals around the decision:

• evidence presence, freshness, authority, contradiction, and citation support;
• input completeness, schema validity, language, population, and distance from evaluated cases;
• agreement across deterministic checks, retrieval, model samples, or independent models;
• model or classifier score calibrated on the exact task and version;
• tool success, policy status, authorization, and postcondition checks;
• explicit high-consequence triggers that force deferral regardless of score.

Do not average unrelated signals into an unexplained green number. A valid signature cannot compensate for missing evidence; high semantic similarity cannot override tenant authorization. Keep vetoes, requirements, and ranking signals distinct.

Measure risk, coverage, and fallback load together

Let coverage be the fraction of eligible cases the system answers automatically. Selective risk is the error or loss on those answered cases. As the answer threshold becomes stricter, coverage often falls and measured risk may fall—but the rejected work does not disappear.

For each threshold, report:

• answered volume and selective risk with confidence intervals;
• error severity, not only average accuracy;
• coverage and risk by language, customer, source quality, consequence, and other relevant slices;
• false abstentions: cases a safe system could have answered;
• false answers: cases that should have been withheld;
• seek-evidence success, extra latency, and abandonment;
• deferral volume, queue age, reviewer agreement, overturn rate, and deadline breaches;
• refusal accuracy and appeal outcomes.

The practical objective is not “minimum error” or “maximum automation.” It is expected harm and service cost across all outcomes. A threshold that halves model errors but sends 40 percent of traffic to a team that can review 5 percent creates a queue, encourages rubber-stamping, and may be worse than answering less consequential cases through a narrower contract.

Build the policy outside the model

Use an explicit state machine:

1. Classify the decision. Identify claim type, consequence, affected party, required authority, and deadline.
2. Assemble evidence. Retrieve only approved sources and record versions, dates, access scope, and contradictions.
3. Run deterministic gates. Check required fields, permissions, policy, arithmetic, invariants, and prohibited uses.
4. Compute validated signals. Use only scores whose task, population, version, and calibration record are known.
5. Choose a disposition. Apply vetoes first, then seek-evidence rules, consequence-specific thresholds, and fallback availability.
6. Execute safely. Answer with provenance, ask one bounded question, create a review packet, or refuse without performing the side effect.
7. Verify the postcondition. Confirm what was delivered, queued, denied, or committed; preserve the reason and evidence.

The prompt may help phrase the message, but it must not change the threshold, invent a reason code, reopen a forbidden path, or mark its own answer as verified. Keep policy version and evidence in the audit event.

Test the places where answers should not exist

Ordinary test sets over-reward answering because every example often has a label or expected response. The SQuAD 2.0 paper made this weakness visible for extractive question answering by adding more than 50,000 adversarial unanswerable questions that resembled answerable ones. Its lesson is broader but bounded: evaluation needs plausible cases where the correct behavior is not to extract an answer.

Create negative and boundary families for the real workflow:

• required evidence absent, stale, inaccessible, or outside the authorized scope;
• two authoritative sources conflict;
• the request uses a supported form but an unsupported population or purpose;
• a familiar identifier points to several entities;
• a retrieved document contains a plausible distractor or instruction;
• the answer exists but the system lacks action authority;
• reviewer capacity is exhausted or the deadline has already passed;
• a policy forbids the use even when the fact is known.

Include multilingual and distribution-shift cases. Measure whether abstention generalizes beyond the examples that taught it. The broader frontier-model evaluation guide explains why vendor benchmarks must be replaced by use-specific, failure-aware evidence.

Use statistical guarantees only for the claim they support

Conformal methods can produce prediction sets or tune decisions with finite-sample guarantees under stated assumptions. Google's 2024 Conformal Risk Control paper extends conformal prediction to control the expected value of a monotone loss and demonstrates examples in computer vision and natural-language processing.

That is not an instance-wise certificate that a generated paragraph is true. A guarantee depends on the loss, calibration data, exchangeability or other stated conditions, sample size, and implementation. Marginal coverage can hide poor performance for a small high-risk group. Distribution shift, adaptive querying, reused calibration data, or changing labels can break the intended claim.

Use conformal or other statistical controls where the output and loss can be specified—classification sets, extraction fields, bounded retrieval claims, or a calibrated risk score. Keep the guarantee text next to its assumptions, slices, version, and expiry. For open-ended synthesis, combine claim decomposition, evidence checks, constrained outputs, and targeted human review rather than attaching a mathematical label to the entire paragraph.

Worked example: a multilingual invoice exception

Consider an assistant that proposes whether an invoice matches an approved purchase order. The auto-answer contract covers one currency, one legal entity, exact supplier identity, amount within a documented tolerance, an unexpired order, and no duplicate invoice signal. The final posting remains in a controlled accounting service.

For a Persian invoice, OCR extracts an amount and supplier but leaves currency unresolved. Retrieval finds two open orders with similar references. The model's preferred match score is high because names and amounts align. Deterministic gates still find two missing requirements: unique order identity and currency.

The system chooses seek evidence. It queries the approved vendor master and purchase-order record using the supplier identifier, not a general web search. If one order and currency resolve, it recalculates the match and may answer. If ambiguity remains, it chooses defer and sends the accountant the original invoice, both candidate orders, extracted fields, failed gates, model version, and deadline. If the requester asks it to fabricate the missing currency, it refuses. No generated explanation can override those states.

This example also depends on retrieval knowledge quality: abstention cannot be better than the system's ability to identify authoritative, current, access-controlled evidence.

Make the fallback a real product surface

For each deferral class, name the receiving role, queue, service level, evidence packet, decision options, and continuity path. Limit the number of cases a reviewer can see without fatigue. Sample both answered and deferred work so the team can detect threshold gaming and automation bias.

The joint FDA, Health Canada, and MHRA transparency principles for machine-learning-enabled medical devices are sector-specific, not a general legal rule. Their useful design lesson is that intended use, workflow role, performance, known limitations, confidence intervals, data gaps, and conditions misaligned with validation should be communicated to the people making decisions.

Apply that lesson proportionately: show why work was withheld, what is missing, which action is still safe, and when the user should expect resolution. Do not display raw probability to create false precision. Do not make “contact support” the fallback for a time-critical decision unless support owns that decision and can meet the deadline.

Recalibrate when the contract changes

Thresholds are versioned release artifacts. Re-evaluate them when the model, prompt, retrieval corpus, OCR, tool, language mix, policy, user interface, action authority, reviewer team, or error cost changes. A stable overall abstention rate can hide a failing slice; a rising rate can reflect a safer discovery of unsupported traffic.

Connect the policy to post-deployment monitoring. Watch score distributions, risk–coverage curves, missing-evidence reasons, reviewer overturns, delayed outcomes, queue capacity, and incidents. Replay a fixed guard set and sample fresh production cases. When outcome truth is delayed, keep provisional and mature measurements separate.

If the answered subset no longer meets the approved risk, constrain or suspend that claim type while investigating. Do not lower the threshold merely to clear the review queue. Repair capacity, evidence, or scope first; any threshold change needs the same evaluation and approval as a model change.

The abstention release gate

Before enabling an AI answer or action, require affirmative answers:

• Is the decision unit a typed claim or action with a named consequence and owner?
• Are answer, seek-evidence, defer, and refuse outcomes distinct and executable?
• Are mandatory evidence, authorization, policy, and postcondition gates enforced outside the model?
• Is every confidence signal defined, versioned, and validated for this task and population?
• Do risk–coverage results include severity, uncertainty, relevant slices, and out-of-domain cases?
• Can the fallback absorb expected and stressed volume without unsafe delay or rubber-stamping?
• Does the user receive the reason, missing evidence, safe next step, and service expectation?
• Are statistical guarantees stated only with their loss, assumptions, data, scope, and expiry?
• Are answered, deferred, and refused cases sampled for outcome review and appeal?
• Will any material model, data, policy, authority, population, or capacity change trigger re-evaluation?

The goal is not to make an AI sound humbler. It is to make unsupported authority unavailable. A dependable system earns the right to answer only for the portion of work where evidence, evaluation, consequence, and operations agree. Everywhere else, a well-designed pause is part of the product.

Source notes — reviewed August 22, 2026

• NIST AI Risk Management Framework Core — January 2023 voluntary framework outcomes on knowledge limits, deployment-relevant evaluation, uncertainty, human oversight, generalization limits, and safe failure.
• NIST AI 600-1: Generative AI Profile — July 2024 cross-sectoral profile defining confabulation risk and recommending empirical capability validation, source checks, and error handling.
• Selective Classification for Deep Neural Networks — NeurIPS 2017 paper on setting a desired selective risk by trading prediction coverage for rejection in its studied setting.
• On Calibration of Modern Neural Networks — ICML 2017 study of calibration and post-processing methods on specified image and document classifiers.
• SelectiveNet: A Deep Neural Network with an Integrated Reject Option — ICML 2019 research integrating prediction and rejection under a target coverage constraint.
• Know What You Don't Know: Unanswerable Questions for SQuAD — ACL 2018 paper introducing plausible unanswerable questions to evaluate whether extractive systems abstain.
• Conformal Risk Control — ICLR 2024 paper controlling expected monotone loss under the method's stated assumptions, with vision and NLP examples.
• Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles — June 2024 joint FDA, Health Canada, and MHRA principles on intended use, workflow, performance, limitations, data gaps, confidence intervals, and lifecycle communication.