A framework by Matthaios Mantzios

Room to Disagree

A framework for designing and testing the interfaces through which humans oversee AI systems.

Oversight is real when the person reviewing has room to disagree: the information to form a view, and a path to act on it that costs no more than agreeing.

At a glance

Covers
five capabilities of Article 14(4)
Built on
four decades of automation-bias research
The test
the seeded-error audit
For
any interface where a person reviews AI output
v1.0 ·August 26, 2026 ·CC BY 4.0 ·DOI 10.5281/zenodo.22079130

Why this exists

The AI Act relies on human oversight as its central safeguard. Article 14 requires that high-risk AI systems can be effectively overseen by natural persons, and it places the interface inside the obligation: systems must be designed “including with appropriate human-machine interface tools” so that oversight is possible. The Act even names the failure to design against — automation bias, the documented human tendency to over-rely on machine output.

What the Act does not say is what an interface that achieves this looks like. Legal scholars have called the requirement a loose collection of items with no clear standard of meaningful oversight. The harmonised standards are still in draft. Compliance platforms answer with logging and documentation, which record that a review happened without asking whether the reviewer could have caught anything. A recent survey of analyst oversight put the gap in one sentence: human oversight is the most proposed and least evaluated component of responsible AI.

In practice, I keep seeing the same interface. Accepting the system’s output takes one click. Rejecting it opens a justification form. Confidence is displayed as certainty. The queue is sized so that genuine scrutiny of each item is arithmetically impossible. Each of these is a design decision, each one pushes the human towards agreement, and together they produce what critics have rightly called oversight theatre: a warm body in the loop, signing.

The reviewer in that interface has no room to disagree. Not because they lack the will, and not because they lack the training. Because the arrangement has priced disagreement higher than agreement, and people respond to prices.

The transparency side of the same problem — what Article 50 now requires of the moment a product tells someone it is a machine — is covered in a companion article.

In this framework you will find five capabilities an oversight interface must support, the design criteria behind each one, and a test that measures whether the oversight you have documented is oversight that actually happens. The capabilities come from the statute’s own text. The criteria come from four decades of published research on automation bias and human supervisory control. The test is one you can run before a regulator runs it for you.

The framework on one poster

Poster titled Room to Disagree, a framework for AI oversight interfaces, version 1.0 under CC BY 4.0. Five numbered cards run across it, each with a mark, a name, an Article 14(4) reference and its criteria. One, Understand, Article 14(4)(a): grasp what the system can and cannot do at the point it matters — limitations shown beside the output in the operator’s language; scope of competence visible. Two, Monitor, Article 14(4)(a): notice when something is off — anomalies and drift surface in the field of attention rather than in a log; uncertainty displayed as uncertainty rather than a flat verdict; base rates travel with the output. Three, Resist, Article 14(4)(b): the interface works against automation bias instead of manufacturing it — friction symmetry, meaning rejecting costs no more effort than accepting; no pre-selected approval, auto-advance or batch accept; queue volume permits genuine scrutiny per item. Four, Interpret, Article 14(4)(c): make sense of the output well enough to judge it — the explanation gives the evidence needed to disagree rather than persuasion; output framed as input to a human decision; interpretation aids reachable without leaving the decision. Five, Intervene, Article 14(4)(d) to (e): act on that judgement — override and reversal reachable per case without penalty; declining to use the system is an available path; a real stop control known to the operator. A band runs underneath all five, headed the base condition: the oversight interface must itself be accessible, because a person assigned to oversight may have a disability and if the interface fails them the oversight obligation fails with it. WCAG 2.2 AA conformance for the review surface is the floor.
The five capabilities, and the condition all five stand on. Download the poster (PNG)

Start with your question

The claim

Human oversight of an AI system is a measurable property of the interface and the conditions under which a person uses it. It is demonstrated when operators, working through that interface under realistic load, can detect and reject outputs that deserve rejection. If this cannot be demonstrated, the oversight exists on paper only.

Scope

The framework applies wherever a person is asked to review, approve, or act on what an AI system proposes. The statutory case is the high-risk AI system under Article 14, where the obligations are binding and dated. The general case is every review surface in modern software: the suggested reply, the generated code diff, the flagged transaction, the drafted decision awaiting approval. The criteria are the same in both cases; only the consequences of failure differ.

The five capabilities

Article 14(4) lists what a person assigned to oversight must be enabled to do. The framework turns each item into interface criteria. The taxonomy is the legislator’s; the operationalisation is mine. Pick a capability to see its criteria and its example.

Article 14(4)(a)

Understand

Grasp what the system can and cannot do, at the point it matters.

The statute

overseers must be enabled “to properly understand the relevant capacities and limitations of the high-risk AI system”

The framework’s criteria

  • Capabilities and known limitations are disclosed in context, beside the output, in language the operator uses. A limitation stated only in a manual or a training deck does not count.
  • The system’s scope of competence is visible: what classes of input it was built for, and what it will still confidently process anyway.
Two versions of the same claims review screen for claim 8841. The left panel is marked Avoid. Three rows headed what this model is for, known limitations, and cases it was not validated on are all empty, marked with a dash. Below them a link reads model documentation, with a note that it opens the vendor portal in a new tab. The right panel is marked Aim for. It states that the model is built for household water damage under five thousand euros, and that this claim at two thousand three hundred and forty euros is in scope. A bordered panel headed outside what this model was validated on explains that the policy includes a home-office extension, that the model was not validated on mixed residential and commercial claims, and that it will still produce a recommendation for this case. A short list headed what this system cannot do notes that it cannot judge whether the damage cause is disputed, and cannot see documents added after 06:10 this morning.
A limitation stated only in a manual does not count. View full size

Article 14(4)(a)

Monitor

Notice when something is off.

The statute

“duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance”

The framework’s criteria

  • Anomalies, drift and unexpected behaviour surface in the operator’s field of attention rather than in a log nobody reads.
  • Uncertainty is displayed as uncertainty. A probabilistic output rendered as a flat verdict removes the single most useful signal an overseer has.
  • Base rates and context travel with the output, so a plausible-looking result can be judged against what is normal.
Two versions of the same claims review screen, both recommending approval of claim 8841 at two thousand three hundred and forty euros. The left panel is marked Avoid. It shows Confidence 94 per cent as a single large figure with a filled progress bar, and three empty rows where the model version, the date the data was last refreshed, and comparable outcomes would be. System status is a link reading view activity log. The right panel is marked Aim for. It replaces the single figure with an estimate of 74 per cent shown as a range from 61 to 83 on a marked bar, and notes that comparable claims this quarter settled 61 per cent of the time. The same three rows are filled in: model version 4.7, changed six days ago; data refreshed this morning at 06:10; 184 comparable cases in the last 90 days. A bordered alert reads drift detected in this queue, water-damage claim values are 18 per cent above the validation baseline, 327 cases affected.
The same claim, the same model, the same number underneath. View full size

Article 14(4)(b)

Resist

The interface works against automation bias instead of manufacturing it.

The statute

“to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)”

The framework’s criteria

  • Friction symmetry. Rejecting an output costs no more effort than accepting it. One-click accept beside a mandatory justification form is theatre by construction, and it is the most common defect I encounter in review surfaces.
  • Defaults do not lean towards acceptance. Pre-selected approval, auto-advance on accept, and batch-accept controls are all design decisions with a documented behavioural cost.
  • Vigilance load is managed. Queue volumes and pacing that make genuine scrutiny arithmetically impossible are an interface defect, wherever they are configured.

An honest cost, from the research this rests on: designs that reduce over-reliance tend to be liked less. Effective resistance has a satisfaction price, and pretending otherwise would be marketing.

Two versions of the same claims review screen side by side, both showing claim 8841, water damage, policy held six years, and the same system recommendation to approve a settlement of two thousand three hundred and forty euros. The left panel is marked Avoid. It prints Confidence 94 per cent as a flat figure, gives a single filled Approve button with Reject demoted to a small text link, and shows that rejecting opens a reason code, a required written justification, and routing to a second reviewer before it takes effect. Below that, auto-advance to the next case after approval, and a target of sixty cases per hour. The right panel is marked Aim for. It replaces the confidence figure with the statement that similar past claims split sixty-one to thirty-nine and the model is not confident here. Agree and Disagree appear as two controls of identical size, neither pre-selected, each labelled one action. A panel headed what this rests on lists the evidence a reviewer would need in order to disagree: undated damage photographs, a policy exclusion the assessor did not rule out, and two comparable claims declined last quarter, with the full assessor file openable without leaving the case. No auto-advance and no throughput target.
The same case, twice. Only the interface changes. View full size
Six phone screens showing the same claims review case, claim 8841 at two thousand three hundred and forty euros. The first, marked accept in one tap, shows a full-width Approve button with a numbered marker, and Reject as a small text link below it. The second, marked aim for, one tap either way, shows Agree and Disagree as two equal buttons each labelled one tap. The remaining four are marked reject: four taps, two screens, one sheet, and are numbered in sequence. Tap one is the Reject link. Tap two opens a bottom sheet listing four required reason codes. Tap three is a new screen carrying the chosen reason and a required written justification field, with an on-screen keyboard covering the field it asked the reviewer to fill. Tap four is a confirmation screen stating that the rejection goes to a second reviewer before it takes effect, with a submit button.
A small screen forces one primary action, and everything else moves behind it. View full size

Twelve claims, six in each of two interfaces. Two of each six are wrong in the same two ways. Nothing is highlighted in either. Send back the ones that should not be approved.

Your own detection rate, in both interfaces. Twelve cases and one person is not a study — that is the point the results make.

Article 14(4)(c)

Interpret

Make sense of the output well enough to judge it.

The statute

“to correctly interpret the high-risk AI system’s output, taking into account, for example, the interpretation tools and methods available”

The framework’s criteria

  • The explanation offered is sufficient for the decision at hand. An explanation that merely makes the output feel reasonable serves persuasion; the operator needs the evidence that would let them disagree.
  • Output is framed as evidence for a decision the human makes, and the interface language holds that framing consistently.
  • Interpretation aids live in the flow of the decision, reachable without leaving it.
Two versions of the same claims review screen for claim 8841. The left panel is marked Avoid. A block headed why this recommendation gives four fluent assertions in prose: the policy is in good standing, the reported damage is consistent with the stated cause, the claimant has no prior claims of this type, and the proposed settlement is within the normal range. Underneath, a question asks whether the explanation was helpful, with Yes and No buttons. The right panel is marked Aim for. A block headed what this rests on, and where it came from lists the same four claims as rows, each with its source and its status: policy in force, from the policy record, verified; damage consistent with cause, from the assessor note, not stated; no prior claims, from claims history, verified; settlement in normal range, from 184 comparable cases, verified. A bordered note headed what would change this explains that if the assessor had ruled out gradual seepage, confidence would rise, and if they had confirmed it, the claim would be declined.
An explanation you cannot check is a justification, not evidence. View full size

Article 14(4)(d)–(e)

Intervene

Act on that judgement.

The statute

“to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output”, and to intervene or interrupt “through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state”

The framework’s criteria

  • Override and reversal are reachable, per case, without penalty built into the flow.
  • Declining to use the system for a given case is an available path, as the Act requires.
  • The stop control is real, known to the operator, and its consequences are understood.
Two versions of the same claims review screen, shown after the decision has been applied: claim 8841 approved and settled at two thousand three hundred and forty euros, payment scheduled. The left panel is marked Avoid. It states that the decision has taken effect and offers a box headed disagree with this outcome, with an optional free-text field, and a note that feedback is recorded and reviewed monthly. Two buttons are shown greyed out and unavailable: reverse decision, requiring an administrator, and stop AI processing, not available to your role. The right panel is marked Aim for. It states that payment is scheduled for nine the next morning and is reversible until then. Reverse this decision and decide without the system appear as two controls of equal size, each labelled one action. A panel headed if you reverse explains that payment is cancelled before it leaves and that the claim returns to the reviewer rather than to the queue. A bordered panel headed stop the system for this queue explains that it pauses new recommendations, holds already-decided cases unpaid for review, that the reviewer can do this, and that it is logged.
Disagreement that changes nothing is a comment, not oversight. View full size

The base condition

The oversight interface must itself be accessible. A person assigned to oversight may have a disability; if the interface fails them, the oversight obligation fails with it. Web Content Accessibility Guidelines conformance for the oversight surface is a floor here, and early academic work now argues that accessible, plain-language interfaces are enabling infrastructure for meaningful oversight. I have spent most of my career on that floor, and I can report that review surfaces are where it is thinnest.

Two versions of the same claims review card, each followed by what a screen reader announces. The left panel is marked Avoid. The announcements read: button; button; graphic; 94 per cent, with no indication of what the number describes. A note records that the drift alert is never announced because it is a coloured panel with no role and no live region, and that focus jumps to the top of the page after a decision. Each failing line carries a solid heavy marker bar. A bordered verdict reads: the person assigned oversight cannot perform it. The right panel is marked Aim for. The announcements read: system recommendation, approve, settle at 2,340 euros; estimated 74 per cent, range 61 to 83, comparable claims settled 61 per cent of the time; alert, drift detected in this queue, 327 cases affected; Agree, button, one action, and Disagree, button, one action. A note records that after a decision focus moves to the next case heading. Each passing line carries a hollow outlined marker bar. A bordered verdict reads: every check in the framework is performable.
If the interface fails the person assigned oversight, the obligation fails with it.

How to use it

A worked assessment of a single claims review screen against the framework's criteria. On the left, the screen under assessment: the system recommends approving claim 8841 at two thousand three hundred and forty euros, with Confidence 94 per cent, a filled Approve button, Reject as a small link, a rejection panel requiring a reason code and a written justification and routing to a second reviewer, auto-advance on approval, and a target of sixty cases per hour. Six numbered markers point at the elements assessed. On the right, what the criteria find, each finding carrying its capability and article reference. One, Understand, Article 14(4)(a): no statement of what the model is for, what it was validated on, or what it cannot do. Two, Monitor, Article 14(4)(a): a single confidence figure rendered as a verdict, with no range, base rate, model version, data freshness or drift signal. Three, Resist, Article 14(4)(b): friction symmetry fails, approving is one action and rejecting is four, and this is the finding that makes the approval rate uninterpretable. Four, Interpret, Article 14(4)(c): nothing the reviewer could use to disagree with something specific. Five, Resist: auto-advance on accept, a default leaning toward acceptance. Six, Resist: a throughput target of sixty an hour against a queue of 210. Below, the profile this screen produces: Understand nought of three, Monitor nought of four, Resist nought of four, Interpret nought of three, and Intervene and the surface itself both marked not assessable from this screen. A closing panel headed what to fix first, and what this does not tell you names finding three, and states that two capabilities cannot be scored from this screen at all and that no criteria review of any kind demonstrates oversight — only a seeded-error audit does.
One screen, read against the criteria. The profile is the output; the audit is the evidence.

The test: the seeded-error audit

Criteria describe an interface. Oversight is demonstrated by behaviour, so the framework’s outcome measure is behavioural.

Insert known-wrong outputs — errors of the kinds the system genuinely produces — into the operators’ real queue, at realistic frequency, without announcement. Measure whether operators, working through this interface under this load, detect and reject them. Detection rate on seeded errors is the vital sign of an oversight arrangement. An interface through which seeded errors sail is documented theatre, whatever the process diagram says.

The full protocol, the three rules that keep the test honest, and the ethics ground rules

What this framework does not claim

  • It does not offer legal advice, and passing the seeded-error audit is not a presumption of conformity with anything. It produces evidence of a kind regulators have said they will look for; how that evidence weighs is a question for lawyers and, eventually, courts.
  • It does not claim automated or checklist evaluation is sufficient. The criteria find defects; only the behavioural test demonstrates oversight.
  • It does not replace the organisational frameworks. Governance models, risk management systems and the coming harmonised standards operate at the level of the organisation and the process. This framework operates at the interface, and it composes with all of them.
  • It does not cover what happens after control is lost. Containment, investigation, redress and organisational learning are essential and they sit outside these five capabilities, because Article 14(4) stops at intervention and because recovery after harm is not evidence that oversight worked.
  • It does not assume oversight is always the right control. Some decisions should not be delegated to AI at all, and some low-stakes automation is degraded by mandatory review. The framework measures whether oversight works where oversight is the chosen safeguard.
  • It does not justify accessibility by what compliance or machines gain from it. Accessibility is an obligation on its own terms; here it is also a precondition for oversight.

Applications registry

No applications recorded yet. If you have applied Room to Disagree — in a product, an audit, a paper or a standard — you are invited to submit it for the registry: matthaios@uxellence.gr.

Cite as

Mantzios, M. (2026). Room to Disagree (v1.0). UXellence. uxellence.gr/room-to-disagree. DOI: 10.5281/zenodo.22079130.

Reference material

Relationship to other work

The critique this framework answers is well established, and credit belongs where it originated: Ben Green’s demonstration that oversight policies lack empirical support, the “warm body in the loop” analysis, and the legal scholarship on Article 14’s vagueness from Enqvist, Fink, Laux and others. The scientific ground under the criteria belongs to its authors too: the automation bias literature from Parasuraman, Skitka and Mosier onward; Buçinca, Malaya and Gajos on cognitive forcing functions, the interface interventions that measurably reduce over-reliance; Langer, Baum and Schlicker’s signal-detection account of oversight effectiveness; Alon-Barkat and Busuioc’s experiments on automation bias in public-sector decisions; and Alfrink and colleagues on contestable AI by design, which covers the adjacent question of how decision subjects, rather than operators, challenge a system.

A third neighbour arrived while this framework was being finalised. Hardy’s Oversight-to-Control framework, published as a preprint in July 2026, models oversight as a chain of six functions — observe, detect, interpret, challenge and decide, intervene, recover and learn — and tests it against eight governance instruments and nineteen documented cases. Its findings are useful to anyone working on this problem: intervention is explicit in every prescriptive instrument examined and demonstrably present in almost none of the cases, interpretation was never fully present in any assessable case, and workload and time were the least specified of all the conditions that make review possible. It operates at the level of the institutional arrangement, it is retrospective, and it closes by calling for prospective evaluation of whether reviewers can recognise the need to override, act within the real decision window, and trigger recovery. That call is a second, independent statement of the gap this framework was built to fill.

One finding in it deserves stating rather than avoiding. In Hardy’s corpus, automation bias was not the leading failure mechanism; missing escalation, inadequate validation and organisational governance failure appeared more often. The corpus is drawn from public records of institutional failure, which will under-represent interface defects that never produce a case file, and the author is careful to say the counts are not prevalence estimates. Still, it is a reasonable corrective to any reading of this framework that treats the interface as the only place oversight goes wrong. It is not. It is the place a design team can do something about.

Two standards are arriving in the same territory and this framework is built to sit under them, never beside them. prEN 18229-3, the draft European harmonised standard for Article 14 — read in full at the Enquiry stage through the national standardisation platform — organises oversight around the reaction timeframe, specifies interface requirements for review, notification and continuous-monitoring surfaces, and requires providers to verify at design time that designated persons can identify incorrect or hazardous outputs, naming tests with intentionally flawed outputs as an example method. ISO/IEC 42105 provides organisational guidance across the AI lifecycle. This framework composes with both and adds what neither contains: friction symmetry as a design criterion, the accessibility of the oversight interface itself as a base condition, and in-service behavioural evidence — the seeded-error audit runs in the live queue, on the deployer’s side of Article 26, after design-time verification has passed. The standard verifies the design; the audit verifies the deployment. The framework’s vocabulary follows the standard’s — the designated person, the reaction timeframe — and any overlap is resolved in the standard’s favour.

The contribution here is therefore narrower and more practical than any neighbour: interface-level criteria a design team can apply this sprint, and a behavioural test an auditor can run this quarter, mapped to the statute a European product must satisfy by December 2027.

References
  • Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 14, 26, 27, 50, 113 — EUR-Lex, consolidated version of 27 July 2026.
  • Regulation (EU) 2026/1744 (Digital Omnibus on AI), OJ L, 24 July 2026.
  • European Commission, Guidelines on transparency obligations for providers and deployers of AI systems, 20 July 2026.
  • Green, B. (2022). The flaws of policies requiring human oversight of government algorithms. Computer Law & Security Review, 45, 105681.
  • Langer, M., Lazar, S., & Baum, K. (2025). On the complexities of testing for compliance with human oversight requirements in AI regulation.
  • Langer, M., Baum, K., & Schlicker, N. (2024). Effective human oversight of AI-based systems: a signal detection perspective. Minds and Machines.
  • Sterz, S., et al. (2024). On the quest for effectiveness in human oversight. FAccT ’24.
  • Buçinca, Z., Malaya, P., & Gajos, K. Z. (2021). To trust or to think: cognitive forcing functions can reduce overreliance on AI. CSCW.
  • Alon-Barkat, S., & Busuioc, M. (2023). Human–AI interactions in public sector decision-making: “automation bias” and “selective adherence” to algorithmic advice. Journal of Public Administration Research and Theory.
  • Parasuraman, R., & Manzey, D. H. (2010). Complacency and bias in human use of automation. Human Factors, 52(3).
  • Alfrink, K., Keller, I., Kortuem, G., & Doorn, N. (2023). Contestable AI by design: towards a framework. Minds and Machines.
  • Schwemer, S. F., & Koivisto, I. (2025). A warm body in the loop. Verfassungsblog.
  • Hardy, K. (2026). From human oversight to effective control: a socio-technical safety-control framework for high-risk AI systems. Research Square preprint, 10 July 2026. DOI 10.21203/rs.3.rs-10151972/v1.
  • prEN 18229-3 (draft), AI trustworthiness framework — human oversight. CEN-CENELEC JTC 21, at Enquiry.
  • ISO/IEC FDIS 42105, Information technology — Artificial intelligence — Guidance for human oversight of AI systems.
  • ECAC/TSA Threat Image Projection documentation; Panko, R. R., spreadsheet inspection experiments (seeded errors).
  • Prior-use note: “demonstrable human oversight” appears as a descriptive phrase in compliance commentary, and this framework was drafted under the working title Demonstrable Oversight before being renamed. The framework, its criteria and its test are claimed here; no generic phrase is.

Changelog

v1.0 — initial publication. Renamed from the working title Demonstrable Oversight before first publication; no version was released under that name. No structural revisions planned for eighteen months from publication; corrections are recorded on the canonical page with credit.

Notes and additions since publication

The framework text is fixed at v1.0 and will not be revised structurally before February 2028. Findings that would change a future version are recorded here as they arrive, dated and credited, so that the framework is visibly answerable to work published after it. None of the entries below corrects an error in v1.0; each one enlarges it.

27 August 2026 — The field’s consensus framework, and where this one attaches to it

Keeping an Eye on AI (Gaube et al., 2026, arXiv 2605.16278) is the output of Dagstuhl Seminar 25272 and carries twenty authors. It sets out an oversight architecture of two layers — the task layer being overseen and the oversight layer doing the overseeing — a process model of the information flow between them, preconditions for monitoring and intervention, and a documentation template applied to four worked domains. It was published in April 2026 and is not cited in v1.0 of this framework. That is an omission rather than a judgement, and it is recorded here rather than quietly corrected.

The two are complementary in a specific way. Gaube et al. conceptualise monitoring as a signal detection task: overseers attend to cues, accumulate evidence, and intervene when the evidence warrants it. Signal detection requires ground truth — a hit rate cannot be computed without knowing which items carried signal — and their framework does not supply a way to obtain it in a live deployment. The seeded-error audit is one: planted errors are known signal, and detection rate is the hit rate. Their architecture is the model; this contributes an instrument for it, grounded in the same signal-detection account already cited here through Langer, Baum and Schlicker.

Two things in this framework remain absent from theirs, verified by full-text search: the accessibility of the oversight surface as a condition of the obligation, and cost parity between accepting and rejecting an output. Neither is a criticism of a paper working at a different level.

Gaube, S., Langer, M., Miller, T., et al. (2026). Keeping an Eye on AI: A Framework for Effective Human Oversight of AI Systems. arXiv:2605.16278. CC BY-SA 4.0.

27 August 2026 — Over-reliance is one of two failure directions

Faas, Kerstan, Uth, Langer and Feit ran four co-design workshops with domain experts overseeing an AI grading system. Their most prevalent finding across all groups was that participants were drawn to performing the AI’s task themselves rather than overseeing it — re-checking every item, finding it inefficient, and reporting that they felt useless and bored.

That is under-reliance and role confusion, and it is the opposite of the mechanism Resist is built around. Their conditions removed the pressures that produce automation bias: no throughput target, no queue depth, and participants who had not used AI support for the task before. The two findings are compatible. But Resist follows Article 14(4)(b), which names automation bias, and a reader could take the framework to mean that over-reliance is the only way oversight fails. It is one of two, and the interface can produce either.

Faas, C., Kerstan, S., Uth, R., Langer, M., & Feit, A. M. (2025). Design Considerations for Human Oversight of AI: Insights from Co-Design Workshops and Work Design Theory. arXiv:2510.19512.

27 August 2026 — Removing the per-item decision, as an alternative to cost parity

In the same study, two groups designing their ideal oversight interface removed the per-item accept and reject decision entirely, leaving only a control to finish the task. One group separated detecting errors from fixing them.

Friction symmetry equalises the cost of the two paths. This is a third option: remove the per-item confirmation, so that there is nothing to rubber-stamp and the reviewer’s job becomes finding problems rather than confirming each item. Where the reaction timeframe permits it, it is a stronger intervention than making rejection cheaper, and the framework does not currently name it.

Credit: Faas et al. 2025, workshop groups CS2 and Psy2.

27 August 2026 — The cost of disagreeing is not only interaction cost

Friction symmetry counts actions. Two sources point at a cost that actions do not capture.

Faas et al. report participants feeling bad about themselves when reducing a student’s marks — one observed that had they not intervened, the student would have kept the points, and “I screwed them up.” Separately, an analysis of what makes disagreement possible names blame asymmetry: where deferring to the system and being wrong is attributed to the system, while overriding and being wrong is attributed to the reviewer, no rational reviewer overrides.

These are the same phenomenon from opposite directions, and both operate even where the workflow is perfectly symmetric. A future version should carry a criterion under Resist covering the psychological and liability cost of disagreeing, distinct from its interaction cost.

This also touches the one condition for effective oversight the framework does not operationalise. Sterz et al. name four: causal power, epistemic access, self-control and fitting intentions. The framework covers the first three and is silent on whether the reviewer is motivated to do the job properly, which Faas et al. address directly.

27 August 2026 — Automation bias ranked fourth in a corpus of documented failures

Hardy’s Oversight-to-Control analysis coded nineteen public incident and deployment cases. Automation bias appeared in four of them and was not the leading failure mechanism; missing escalation or recourse, inadequate validation, and organisational governance failure appeared more often.

The corpus is drawn from public records of institutional failure, which will under-represent interface defects that never generate a case file, and the author states the counts are not prevalence estimates. It is recorded here because it is a reasonable corrective to any reading of this framework that treats the interface as the only place oversight goes wrong. It is not. It is the place a design team can do something about.

Hardy, K. (2026). Research Square preprint, DOI 10.21203/rs.3.rs-10151972/v1.

Licence

Creative Commons Attribution 4.0 International (CC BY 4.0). You may share and adapt this work, including commercially, with attribution to Matthaios Mantzios and a link to the canonical page.