An approval click is not evidence that a reviewer detected a wrong AI recommendation. Before expanding an AI-assisted workflow, test whether its interface helps people distinguish correct advice from plausible mistakes. Compare presentation variants on matched cases, retain human-only and model-only baselines, and measure acceptance of known-wrong advice with its own denominator. A higher approval rate can mean better assistance, stronger anchoring or simply easier cases.
This article proposes an engineering study, not measured client results or a compliance test prescribed by law. The decision is whether to release a particular review interface for a defined task and operator population. It is not whether humans or AI are generally more reliable.
The control boundary: authority is not decision quality
A functioning approval gate answers who may authorise an action and whether execution waits. It does not answer whether the person understood the evidence. Keep the backend controls in the human-in-the-loop approval architecture. Add an evaluation of the interaction that happens before authorisation; do not replace the gate with a usability score.
For high-risk systems within its applicable scope, the AI Act's consolidated Article 14 addresses awareness of automation bias, interpretation of outputs and the ability to disregard or override them. That is a reason to examine the interface, not proof that a specific screen order satisfies the Act. Counsel must determine classification, roles, current amendments, applicability dates and sector-specific obligations. The consolidation is a documentation aid, not the authentic Official Journal instrument. This is not legal advice.
The Microsoft Research human–AI interaction guidelines support contextual information, efficient dismissal and efficient correction. Their authors explicitly discuss trade-offs; the guidelines do not establish that evidence-first presentation always wins. NIST AI RMF, particularly Appendix C, treats human–AI configurations as contextual and notes the complexity of presenting outputs and explanations to people. It is voluntary risk guidance, not EU legal authority.
Freeze the task before changing the screen
Use a bounded decision such as routing a synthetic service case to the correct support queue. Specify the available facts, permitted actions, acceptable escalation and consequence of a wrong decision. Do not initially combine triage, diagnosis and execution into one success label: a correct diagnosis can still produce an unauthorised action.
Build independently adjudicated cases. Domain reviewers should resolve the reference decision without seeing the tested model's answer. Retain their disagreement and rationale. Cases without a defensible reference belong in an ambiguity stratum, with an escalation rubric, rather than being quietly labelled correct or incorrect. A model cannot grade its own recommendation into ground truth.
Include both correct and deliberately incorrect recommendations. Use realistic mistakes: a plausible route contradicted by one source detail, a missing exclusion or a recommendation based on a stale record. Label injected errors in the study manifest. They reveal susceptibility under controlled exposure; they do not estimate the production model's error frequency. Keep a separate representative case set for operational estimates and report each distribution.
Match case sets on task type, evidence volume, ambiguity and consequence. Freeze evidence, model outputs and model revision before comparing interfaces. If one variant receives shorter answers or more accurate recommendations, the experiment no longer isolates presentation. Record the interface build, policy revision, display language and accessibility settings as part of the treatment.
Four comparisons, with no answer-learning shortcut
The model-only baseline applies the frozen recommendation to the reference rubric without human correction. The human-only arm receives the same task evidence but no AI recommendation. Two assisted arms compare recommendation-first with evidence-first presentation. Both assisted variants need identical evidence, actions and correction permissions; only the intended presentation change should differ.
Randomise reviewers to variants within relevant experience groups where feasible. For a within-reviewer design, counterbalance order and use non-overlapping matched case sets: the same person must not solve a case unaided and then see it again with advice. Rotate case sets across other participants so case difficulty is not permanently confounded with interface. Analyse the dependence created by repeated decisions from the same reviewer and shared cases; a hundred clicks are not a hundred independent reviewers.
Define whether evidence-first merely reorders panels or requires a provisional decision before revealing advice. Those are different treatments. If you require a provisional decision, label the arm accordingly and budget its additional time. Do not add this step to only one arm and attribute the entire effect to visual ordering.
Use a pilot to identify broken tasks and estimate variability, then choose study size against the smallest decision-relevant difference and acceptable uncertainty. There is no universal minimum reviewer count. Small pilots can expose obvious defects but cannot establish the absence of rare harmful acceptance.
Interface sketches: compare access, not decoration
These sketches isolate panel order. The evidence-first variant does not secretly force an extra confirmation. Both variants expose the original evidence, contradicting facts and the same approve, correct and escalate actions. No action is preselected. Keep the execution sandboxed so an intentionally wrong recommendation cannot reach a customer or operating system.
A visible explanation is not necessarily useful evidence. Fluent generated text may restate the mistake. Separate source facts from generated rationale, allow access to the underlying source and make missing evidence visible. If confidence is shown, document what that score means and how it was validated for this task; a model's persuasive wording is not a calibrated probability.
Decision table: measure the failure you intend to fix
| Failure mode | Measure and denominator | Redesign hypothesis | Cost or limitation |
|---|---|---|---|
| Wrong advice accepted | Accepted wrong advice / exposures to known-wrong advice | Move contradicting evidence into the decision view | May increase review time; retest rather than assume benefit |
| Error noticed but not repaired | Correct final decisions / known-wrong advice exposures | Make correction and its downstream effect explicit | Rejection alone is not a correct resolution |
| Useful advice rejected | Correct advice rejected / correct-advice exposures | Clarify capability limits and source support | Rejection may be justified by evidence outside the rubric |
| Assistance harms decisions | Correct final decisions / assigned scorable cases, by arm | Compare assisted with human-only and model-only baselines | Match task mix and show uncertainty |
| Fast clicks hide non-decisions | Time distribution plus unresolved / assigned cases | Improve evidence access and escalation handling | Faster is not safer; timeouts must not disappear |
Define acceptance as adopting the proposed wrong action, not merely opening the recommendation or clicking a generic button. Define correction accuracy against the final reference outcome. Report unresolved and timed-out cases separately, including how they enter the predeclared primary denominator. Excluding difficult unfinished cases after the study inflates apparent quality.
Acceptance of wrong advice and correction accuracy are not necessarily complements: a reviewer can reject one wrong answer and choose another, or escalate without resolving the case. Likewise, rejection of correct advice is a review-cost signal, not automatically harm. The reference rubric must state when escalation is appropriate.
Report raw counts alongside rates, broken down by the predeclared strata. Show decision time for correct outcomes and for all assigned cases; a median over completed approvals alone omits the slow failures. Use an uncertainty method that respects reviewer and case clustering, with statistical support where needed. Do not rank variants by a tiny point-estimate difference with wide uncertainty.
A minimal protocol and result record
Before collecting data, write the task boundary, target roles, case-set revision, adjudication method, variant allocation, primary outcome, exclusion rules, timeout handling and stopping conditions. Name the owner who can halt the study. Choose release criteria before viewing outcomes: acceptable harmful-acceptance risk, permitted loss of correct decisions, review-time capacity and protected critical strata. The values must come from your risk and operating constraints, not from this article.
A restricted study record can use these fields: study_revision; interface_revision; model_revision; case_set_revision; case_id; task_stratum; recommendation_correct; arm; reviewer_pseudonym; assigned_order; final_action; final_correct; unresolved_reason; elapsed_ms; evidence_access_available. Use nullable correctness for ambiguous cases and an explicit adjudication state. An unopened source is not proof that someone ignored it; telemetry shows interaction, not comprehension.
The reporting record should be aggregate: study_revision; arm; task_stratum; reviewers_count; assigned_cases; wrong_advice_exposures; wrong_advice_accepted; correct_advice_exposures; correct_advice_rejected; correct_final_decisions; unresolved_cases; elapsed_time_summary; uncertainty_method. Keep denominators distinct and suppress small or identifying groups. This is a proposed schema, not fabricated experimental output.
Pseudonymised reviewer records are not anonymous. Restrict access, define retention and separate any re-identification key. Seek privacy, employment-law and works-council review before workplace testing or behaviour monitoring. Do not turn the study into a hidden employee ranking. Use synthetic or approved de-identified cases and aggregate reporting by default; even aggregates can identify a tiny team.
Release checklist and failure handling
Check 1 — Reference cases are independently adjudicated, and ambiguity has an explicit treatment. Injected errors and representative production-like cases are distinguishable.
Check 2 — Treatment allocation, case-set rotation and outcome rules are frozen. No reviewer sees the same answer-bearing case across arms. Training uses separate examples.
Check 3 — The operator role can open evidence, correct an action and escalate without administrator privileges. The supplier-instruction acceptance test establishes executable procedures; this experiment then evaluates decision quality under competing presentations.
Check 4 — Results include human-only, model-only and assisted outcomes, missing decisions, uncertainty and critical task strata. The experiment has not silently selected only compliant or fast reviewers.
Check 5 — The release decision names the interface build, supported tasks and residual risks. Reopen it after material changes to model behaviour, evidence access, action semantics, staffing or operating pressure.
Training remains a separate dependency. Role-based AI literacy and access control can establish who is prepared and authorised to review; it cannot compensate for hidden evidence or prove that a qualified person resists misleading advice.
What the experiment cannot establish
An error-enriched study may make reviewers unusually suspicious. A short session may miss fatigue, queue pressure and adaptation to a mostly reliable model. Evidence-first presentation can slow straightforward cases or move attention away from the decisive fact. Recommendation-first may be efficient for well-bounded work. Neither should be declared universally safer.
If both assisted variants perform worse than the human-only baseline on consequential strata, do not choose the less bad screen and expand automation anyway. Investigate the advice, task framing and available evidence; keep the affected scope manual or restricted under the approved operating policy. If results are inconclusive, record that uncertainty rather than converting a pilot into a release certificate.
Start with the decision your team actually owns
Select one consequential review task and one interface change. Produce a frozen case pack, the two comparable screens and a result contract before instrumenting the workflow. The deliverable is an evidence-backed release decision, including reasons to retain the current design or narrow scope.
For a technical review, bring your approval screen, action schema and a small approved synthetic case pack. I can help structure the evaluation protocol, evidence access and release gates with your platform and operations teams. Legal applicability and workplace-study permissions remain with qualified counsel and the responsible organisational functions.
