Conformal Prediction Sets Belong in the Interface, Not Just the Notebook

TL;DR: Conformal prediction can turn a classifier's scores into a set of plausible labels with a finite-sample marginal coverage guarantee under the method's assumptions. The interface must still decide what to do with one label, several labels, or an empty set. Coverage is not a probability attached to each displayed option, and it does not automatically guarantee accuracy among cases that the product chooses to automate.

A fictional service desk called Northstar routes equipment requests to one of four specialist teams. Its classifier currently displays a single destination, even when two teams are nearly tied. Staff complain that the interface makes uncertainty look like a confident assignment. The product team proposes showing a prediction set instead. This article reviews that proposal as a sequence of interface prototypes, with the statistical promise kept separate from the operational decisions.

The method background comes from Angelopoulos and Bates' introduction, the work on regularized classification sets, and research on conditional coverage limits. All service-desk numbers and prototypes below are illustrative constructions, not benchmark results. Their purpose is to expose decisions a production team must make before putting a statistically meaningful set on a screen.

Prototype A: Four percentages and a bright green winner

The first screen displays scores of 0.45, 0.35, 0.15, and 0.05 and highlights the first team. A user reads the highlight as a recommendation to route immediately. The second team is close enough to deserve attention, but the visual hierarchy makes it feel secondary. The product has converted a ranking into a decision without explaining the cost of choosing incorrectly.

Northstar's problem is not solved by displaying more decimal places. The user needs to know whether the available evidence supports one destination or whether the request should remain open to several possibilities. A set can express that decision boundary more directly than a bar chart, provided the user understands what inclusion means.

The team identifies the intended task: help a dispatcher choose the right specialist while preserving a clear path for ambiguity. It does not promise to infer a unique correct department for requests whose business ownership is genuinely shared. Before calibrating any method, the labeling policy must define whether there is one reference label or whether multiple destinations can be acceptable.

That definition changes evaluation. If historical labels record whichever team happened to receive the ticket, the system may learn administrative habits rather than the team best able to resolve it. A prediction-set guarantee is about the supplied target variable. It cannot repair a target that fails to represent the decision the interface claims to support.

The calibration card behind the screen

For a simple split-conformal construction, a fixed classifier produces scores on a held-out calibration sample. A nonconformity score measures how poorly each example's true label fits the model's output. One common classification choice is one minus the score assigned to that true label. A suitable empirical quantile of those calibration scores determines the inclusion threshold for new labels.

Under exchangeability and the construction's other requirements, the resulting sets have marginal coverage at the chosen level. The finite-sample quantile adjustment matters; it is not simply a casually rounded percentile. With 99 calibration examples and a target error level of 0.10, the relevant order-statistic index in the standard construction is the ceiling of 100 times 0.90, which is 90.

Northstar's prototype uses this elementary construction to make behavior inspectable. It is not a claim that this score produces the smallest or most useful sets for every classifier. The regularized adaptive prediction-set paper studies more sophisticated classification-set construction. The interface team should evaluate the actual selected method rather than treating “conformal” as one fixed display algorithm.

The calibration data remains separate from training and method selection as required by the chosen procedure. If the team repeatedly adjusts the model or score after inspecting calibration failures, it cannot assume the original guarantee survives unchanged. The statistical pipeline needs a versioned record of which artifacts were fixed before calibration and which data established the final threshold.

Prototype B: A set with two destinations

Suppose the illustrative calibrated nonconformity threshold is 0.70. With a score of one minus model probability, labels with a model score of at least 0.30 enter the set. A new request scored 0.45, 0.35, 0.15, and 0.05 therefore produces two destinations. This arithmetic describes the example's construction; it does not establish a real deployment's coverage.

The screen now presents the two included teams at equal visual prominence and asks the dispatcher to inspect the request's equipment type. It retains an “another team” option because the reference label can fall outside the set. A coverage target below one necessarily permits errors, and a user must not be trapped inside the model's candidate list.

The team avoids labeling the set “90 percent confidence in these two teams” without explanation. That phrase can sound like a probability for this particular request. The method's basic guarantee concerns long-run marginal inclusion under its assumptions, not a personalized probability that the current set contains the answer.

Northstar instead uses plain operational language: “Two suggested destinations; review the equipment details before routing.” A short explanation available nearby describes how the suggestions were validated and their limitations. The main screen helps the dispatcher act; the evidence panel provides the statistical detail for users who need it.

Prototype C: One destination does not settle automation

A request with scores 0.80, 0.10, 0.06, and 0.04 yields a singleton under the illustrative threshold. The product manager proposes automatically routing every singleton. This is an additional selection rule, and it changes the question from overall set coverage to the error rate among selected cases.

Marginal coverage does not automatically provide the desired conditional guarantee for singleton cases. Errors can be concentrated in a subset of the population. The team must evaluate the automation policy directly, including which requests produce singleton sets and how often those assignments are wrong. The conditional inference limits paper explains why strong distribution-free conditional promises require care.

Consider a fictional evaluation of 1,000 requests with 900 covered by their sets. If 200 singleton cases include 80 of the 100 misses, overall coverage is still 90 percent, but singleton accuracy is only 60 percent. Those numbers are a deliberately constructed counterexample. They show that a global coverage statement alone cannot justify the proposed automation rule.

Northstar therefore separates a suggestion policy from an automatic-routing policy. The latter needs its own acceptance evidence and cost analysis. A set containing one label may be a useful signal, but the product cannot convert that signal into a stronger guarantee by changing the button color.

Prototype D: No destination survives the threshold

The elementary score construction can produce an empty set. With four scores of 0.28, 0.27, 0.25, and 0.20, none reaches the illustrative 0.30 inclusion threshold. The interface designer initially treats this as a rendering error because a destination card is required by the component schema.

It is instead a meaningful output state that needs a workflow. Northstar routes the request to a general review queue and explains that the system did not identify a suitable suggestion. It does not silently insert the top-ranked label just to satisfy the component. Adding a label changes the procedure and should be evaluated as an explicit modification.

An empty set can be associated with unfamiliar inputs, weak scores, or the particular set-construction rule. It is not automatically proof that the request is outside the training distribution. The product should avoid presenting a diagnostic cause that the method did not establish.

The review queue captures the reason staff eventually chose a destination. That information can guide future model development, but it is not fed back immediately into the current calibration threshold without a controlled update. Otherwise the system's behavior would change continuously while the interface continued to cite an old validation record.

Prototype E: All four teams are plausible

At a more permissive threshold, a difficult request can include every destination. This set may satisfy coverage easily while providing little routing help. A system that always returns all labels can achieve perfect inclusion in a closed-label setting, yet it offers no useful reduction in uncertainty for the dispatcher.

Northstar measures set size and the distribution of set sizes alongside coverage. It also measures the work required to resolve the remaining ambiguity. A two-label set that consistently includes the correct specialist and a closely related team may be manageable. A two-label set containing teams with incompatible intake forms may create more work than a general triage queue.

The interface groups information by the decision that remains. When all teams are included, it can ask for a missing equipment attribute rather than display four equally unhelpful cards. That question is a product intervention, however, and the team must evaluate the full workflow after the new information is collected.

A smaller average set is not automatically better. If the reduction comes from excluding difficult but important requests, operational performance can deteriorate. The acceptance review therefore considers coverage, workload, resolution time, and the consequences of misses together. The set-size metric is informative only in relation to the task it is supposed to simplify.

The staffing calculation the dashboard omitted

The product manager estimates that smaller sets will reduce manual work. The operations lead asks for a staffing calculation. In a fictional day with 1,200 requests, suppose 600 produce singleton suggestions, 420 produce two labels, 120 produce three or four labels, and 60 produce empty sets. Those counts describe workload categories, not proven automation eligibility.

If a trained dispatcher spends an average of 20 seconds reviewing a singleton, 50 seconds on a two-label case, 90 seconds on a broad set, and 120 seconds on an empty set, total review time is 51,000 seconds. That is about 14.2 staff-hours before breaks, queue management, or rework. The arithmetic is 12,000 plus 21,000 plus 10,800 plus 7,200 seconds.

Now suppose a model change reduces broad sets but increases empty sets. The average set size could fall while staff time rises. A metric that treats an empty set as the smallest possible success would be particularly misleading. Northstar's dashboard keeps empty sets separate from useful concise suggestions.

The time estimates must eventually come from observation, and the uncertainty in them should be retained. The example shows how to connect model outputs to an operational question. It does not claim that prediction sets necessarily save labor or that the assumed review times will transfer to another service desk.

Coverage across teams can hide a weak corner

Northstar's aggregate evaluation combines common laptop requests with rare industrial equipment. A high overall coverage can coexist with poor coverage in a small but consequential category. The team examines relevant slices such as equipment family, intake channel, language, and request completeness, while recognizing that small samples produce uncertain estimates.

The purpose of slicing is to detect where the product may fail its operational intent. It is not to pretend that inspecting enough groups creates a formal conditional guarantee. If the organization requires group-specific coverage, it must choose and validate a method designed for that requirement, with enough data and the appropriate assumptions.

For a fictional comparison, 900 common requests with 95 percent coverage contribute 855 covered cases. One hundred rare requests with 45 percent coverage contribute 45. The combined total is 900 of 1,000, or 90 percent. The aggregate meets the nominal target in this constructed sample while the rare category performs badly.

Northstar treats such a result as a reason to revise scope, data collection, or the model. It does not hide the rare group behind the global percentage. A deployment can be narrowed to supported request types while staff handle the rest explicitly. That boundary is often more useful than a broad product claim with a reassuring average.

A changed intake form changes the evidence

The service desk introduces a new intake form that makes one equipment field optional. The resulting requests contain less information than the calibration sample. The model and threshold are unchanged, but the input process has shifted. The original coverage argument cannot simply be carried forward without examining whether its assumptions remain appropriate.

Research on conformal prediction under covariate shift develops weighted methods under specific conditions, including information about the distribution change. It does not establish that any production shift can be repaired by assigning arbitrary weights. Northstar treats this literature as a possible methodological route, not a permission to retain an old guarantee after every workflow change.

The product team logs major changes to intake, label policy, routing destinations, and model preprocessing. Those changes can affect the population or target definition even when the neural network checkpoint stays the same. A validation record should describe the surrounding workflow as well as the model artifact.

During the new form's pilot, staff review a representative sample independently of the model's suggestions. Otherwise the labels collected for evaluation may be influenced by the very interface being assessed. The team wants evidence about correct routing, not just evidence that users accepted the options the model placed in front of them.

The label menu changes from four teams to five

A new specialist team opens. Historical calibration examples were labeled under the four-team organization. Some old cases now belong to the new team, while others remain with their original owners. Adding a fifth output slot is therefore a change in the target space and business policy, not a cosmetic interface update.

Northstar defines how cases should be relabeled under the new ownership rules and collects suitable evidence before presenting a five-team coverage statement. It keeps the old model's scope visible during the transition. A request requiring the new team can enter a designated review path rather than being forced into an outdated four-team set.

The interface also preserves the distinction between a team being absent from the candidate set and a team being unavailable operationally. A specialist on holiday may still be the correct owner, with a different dispatch arrangement. Removing that label from the model's output because nobody is on duty changes the meaning of inclusion.

This separation helps prevent organizational changes from silently corrupting evaluation. The statistical target answers who owns the request under the defined policy. The scheduling system answers who can handle it now. Combining those questions may be appropriate in some products, but it requires a new target and a new acceptance argument.

Error costs belong beside coverage

A misrouted laptop request may cause a short delay. A misrouted request involving specialized equipment may interrupt a critical operation. A single coverage rate treats both misses equally unless the chosen method and evaluation explicitly incorporate their different consequences.

The Conformal Risk Control paper generalizes the framework to expected monotone losses under its stated setup. That is relevant when a product's concern extends beyond binary set inclusion. The team must still define a loss that represents the task and verify that the selected procedure's conditions apply.

Northstar begins with a plain loss table reviewed by operations: delay, repeated intake, specialist interruption, and unresolved request. It avoids assigning precise monetary values where the organization has no evidence. Qualitative severity categories can still guide which cases require mandatory review and where additional data collection has the greatest value.

The product should not claim that a statistical coverage target alone makes a workflow safe or efficient. The target is one component of a decision. The remaining components include label quality, population stability, user behavior, escalation capacity, and the cost of the errors that remain.

The evidence panel users should be able to inspect

Northstar's final prototype includes a compact explanation of what the suggestions mean. It names the supported request population, the model and calibration version, the evaluation period, observed coverage, and the distribution of set sizes. It distinguishes the method's theoretical statement from empirical results on the held-out evaluation sample.

The panel also explains what users can do when the correct destination is missing. That feedback path should not require the dispatcher to accept an incorrect suggestion first. The system records an override as a useful observation while preserving the original set for later analysis.

For internal reviewers, the release record includes the label policy, data split, score definition, quantile rule, and interface decision rules. A screenshot alone cannot establish that the displayed set matches the calibrated procedure. Conversely, a correct notebook cannot establish that the interface preserves the method's meaning after sorting, filtering, or hiding labels.

The final acceptance exercise follows the five prototypes: one suggestion, two suggestions, no suggestion, every suggestion, and a correct label omitted from the set. Staff complete the routing task in each state. The product is ready only when the statistical output and the user's next action form a coherent workflow.

Sorting the cards can quietly change the decision

The visual designer wants to show only the first two suggestions and place the rest behind a disclosure control. That may be reasonable for space, but the interface must preserve the distinction between the complete prediction set and the initially visible subset. If staff act on the first two without opening the disclosure, the practical candidate set has changed even though the backend still returns all labels.

Northstar tests the complete interaction, including how often dispatchers inspect hidden suggestions and whether the correct team appears below the fold. A coverage number calculated on the backend set cannot be used to describe the truncated display. The evidence panel names the object being measured, and the component exposes the full set without requiring an obscure gesture.

The same issue arises if the interface reorders labels according to current staffing availability. Users may infer that the first card has the strongest model support when the ordering actually reflects a queue length. The product can support both signals, but it must label them distinctly. An operationally convenient team and a statistically plausible owner answer different questions.

A follow-up question creates a new prediction problem

For ambiguous requests, Northstar asks the user for a missing equipment model. The enriched input may produce a smaller set. That is a promising workflow, but its evaluation should include the process that chooses the question and the users who answer it. The second-stage population is selected by the first stage and may differ from the original calibration sample.

The team therefore records both inputs and both sets. It evaluates the final routing outcome for all requests entering the workflow, including those abandoned before the follow-up answer. Reporting only cases with completed clarification would hide a potentially important cost of the interface. A smaller final set is useful only if the request reaches that stage and staff can still act correctly.

The follow-up also needs an honest fallback. A user who does not know the equipment model should be able to say so and continue to triage. Forcing a guessed value can make the model appear more decisive while degrading the evidence. The product gains information only when the answer represents something the user actually knows.

A release decision rather than a confidence badge

Northstar approves prediction sets as an aid to dispatchers, with a separate review of any automatic-routing rule. The launch scope names supported equipment categories and retains a general triage path. Staffing estimates include empty and broad sets instead of treating every reduction in average size as progress.

The team monitors observed inclusion and workload while checking for changes in intake and ownership policy. It schedules recalibration as a controlled release step, not an invisible background mutation. When the model or target changes, the displayed evidence changes with it.

This approach gives conformal prediction a practical role without asking it to answer questions outside its guarantee. The method can express uncertainty in a useful form. The interface must preserve that uncertainty, reveal the remaining choices, and support recovery when the correct answer is absent.

The valuable outcome is a dispatcher who can make a better routing decision with a clear understanding of the suggestions. A statistically justified set is an excellent starting point. The product earns trust by making its scope, exceptions, and operational consequences equally explicit.