Delegation of Authority to AI: Three Conditions for Defensible Automated Decisions

Working Paper · v1.0 · August 2026 · Edward Meyman, Founder & CEO, FERZ, Inc.

Abstract. Regulated professions routinely distribute decision-making among licensed, accountable actors. Routing the same decisions through AI systems is structurally different: the system holds no license or registration, owes no independent duty, and cannot itself be answerable. This paper states the conditions under which a licensed professional or regulated institution may nonetheless authorize an AI system to perform a bounded decision function. Three independent conditions must hold: the function is legally automatable in the governing regime; the system is validated and fit for the defined use; and every effect-bearing action passes through a pre-execution authorization boundary designed to be non-bypassable. The first condition belongs to law and the second to empirical validation; only the third is a governance-architecture problem. The paper distinguishes ABSTAIN-plus-authorized-override from guardrails-plus-human-in-the-loop, maps the evidentiary requirements of the third condition to the Five Tests Standard, and is exact about limits: runtime authorization integrity makes retained authority operationally enforceable and its exercise independently reconstructable. It does not replace professional accountability, establish decision quality, or cure failure of the first two conditions.

Keywords. AI governance; delegation of authority; runtime authorization; pre-execution authorization; accountability; regulated professions; Five Tests Standard; authorization artifact; professional liability.

A clinician practices within a legally defined scope and professional arrangement. An associate lawyer prepares work subject to a supervising lawyer's professional obligations. A registered representative acts inside a firm's supervisory system. The structures differ, and the differences matter, but each distributes decision-making among legally accountable actors.

Now route the same function through software. From the outside, the substitution can look straightforward. It is not. The human actor in each of those structures brings something the arrangement depends on: an independently conferred professional status, defined obligations, and exposure to discipline or liability. The system brings none of them.

That gap invites two mistakes, and they are mirror images. The first treats the gap as fatal: because a system cannot hold a license, no regulated decision may ever run through one. The second treats it as irrelevant: a system given the right instructions is just a faster junior. Both skip the same step. Neither specifies the conditions.

This paper specifies them. A licensed professional or a regulated institution may be able to authorize an AI system to perform a bounded decision function when three independent conditions hold: the function is legally automatable in the governing regime, the system is validated and fit for the defined use, and every effect-bearing action passes through a pre-execution authorization boundary designed to be non-bypassable. The system does not acquire a license, a registration, or independent authority. The accountable principal keeps the authority and the duty. What changes is the evidence. Each determination produces a tamper-evident authorization artifact sufficient for an independent party to reconstruct whether the proposed action was permitted before effect, and whether execution was blocked when permission could not be established.

Scope. This paper presents an architectural framework for separating legal automatability, domain validation, and runtime authorization integrity. It does not offer legal advice, and it does not determine whether any particular function may be automated in any jurisdiction. Where it describes specific legal regimes, it cites primary sources. Deploying inside one requires counsel who practices in it.

A word on the title. "Delegation of authority to AI" names the common intuition, not the precise claim, and the work of the paper is to replace the first with the second. A word, too, on the division of labor inside the three conditions: only the third is the governance-architecture problem addressed here. The first belongs to law. The second belongs to validation. Neither can be supplied by the authorization boundary, and confusing the three is how much of the current argument about consequential AI decisions goes wrong.

1. The delegation intuition

Start with what the regulated professions already do, because it is the reader's on-ramp and because it is more varied than the shorthand suggests.

Every regulated profession distributes decision-making across accountable roles, and each has built legal structures to do it. Medicine uses defined scopes of practice, practice agreements, supervision and collaboration arrangements, and, in some jurisdictions, autonomous-practice authority for advanced-practice clinicians. Law runs on supervised practice: work is prepared by associates and nonlawyer staff under lawyers who carry defined supervisory responsibilities for it.¹ Broker-dealers must maintain supervisory systems and written procedures reasonably designed to achieve compliance with the securities laws, and registered representatives act inside them.² The arrangements differ by profession and by jurisdiction. What they share is the feature that makes the reader comfortable: a professional function can be carried out by an actor who did not originate the governing authority, inside a bounded scope, with escalation available and a record left behind.

So the instinct is natural. If a clinician's cases can be managed inside a practice agreement, if a partner can send an associate to negotiate from an approved position, if a representative can execute inside firm policy, why not authorize a system to do the same, especially for narrow, well-characterized tasks where the rules are explicit?

The instinct deserves to be taken seriously, and there is a reason it feels newly urgent. For most of institutional history, the three functions bundled into a consequential decision (holding the authority to make it, determining that a particular action is permitted, and carrying the action out) were performed by one accountable person in a single motion. A loan officer held delegated authority within a lending policy, determined that a particular loan was permissible, and signed the documents. Automation pulls the bundle apart. A system can carry out an action, and can even render a determination, while holding none of the authority and none of the duty. The vocabulary that served when one human did all three now hides the seams that matter most. The delegation intuition was built on the bundled case. The automated case is unbundled, and it has to be reasoned about in its parts.

A license is held by an accountable professional, not transferred to a system.

2. What the system does and does not receive

Routing work to a licensed, admitted, or registered professional places the function with a second actor whose legal status and obligations exist independently of the particular assignment. The nurse practitioner's clinical authority, the associate's admission to the bar, the representative's registration: none of these is created by the delegating principal. The principal defines the assignment and may retain supervisory responsibility, but does not create the second actor's professional status. The second actor brings the rest: a defined scope, independent professional obligations, disciplinary exposure, and potential individual responsibility in discipline or suit. Within these structures there are two accountable parties in the chain, not one, and the arrangement is legible partly because a second answerable party is standing there to receive the work.

A system has no independently conferred professional status. It holds no license and no registration. It has no scope of its own, only the scope someone defines for it. It owes no independent duty, cannot be disciplined, and cannot answer for itself in the way a professional can. It receives only the function and the constraints supplied by the deploying principal. Routing a decision through a system therefore does not distribute accountability the way routing it through a second professional does. The accountability stays exactly where it was: with the individual, the institution, or both.

This is not a novel claim of this paper. It is the applied case of a distinction already drawn in the governance literature: delegation transfers scope, not permissibility, and delegation does not by itself relocate accountability, including when the delegate is a system.³ Professional responsibility rules run on adjacent logic. The professional who assigns work retains defined supervisory obligations for it, qualified by role and circumstance, even when the person doing the work is independently licensed. If accountability does not fully move even to a second licensed human, it does not move to a system that cannot hold it at all.

The accountable principal is not always an individual. In most institutional settings the retained authority and the retained duty sit with a legal entity, a hospital or health system, a law firm, a carrier, a bank, alongside the individual professional, and the entity carries its own registrations, duties, and exposure. This matters for automation because the deploying party is usually the institution. When a system runs across a service line or a book of business, the authority under which it operates and the accountability for its use are institutional facts, and the three conditions developed below are satisfied, or fail, at the institutional level. Which is a further reason the language of "the AI holding a license" misleads. The question is never whether the system is licensed. It is whether an accountable party, individual or institutional, has retained the authority and can show that each action stayed within it.

It is also worth being precise about what the licensed second actor contributes, because it is the thing the instrument does not. A nurse practitioner does not only apply a protocol; she recognizes when a case has left it. An associate does not only apply the playbook; he notices the issue the playbook never anticipated and takes it to the partner. That judgment about the boundary of one's own competence is part of what a license certifies and what professional accountability enforces. An instrument has no equivalent by default. Its behavior at the edge of its competence is not judgment; it is whatever its design makes it do when the inputs fall outside the space it was built for. That is not a reason to reject automation. It is the reason the third condition below must include an explicit, enforced answer to the out-of-scope case, rather than assuming the system will notice on its own.

One clarification, so the argument does not overcorrect. Saying the system is not a legal person does not mean the law ignores acts performed through automation. Electronic-transactions law already recognizes a narrower form of automated attribution. Under the E-SIGN Act, a contract or record may not be denied legal effect solely because its formation involved the action of electronic agents, so long as the agent's action is legally attributable to the person to be bound.⁴ That is attribution within an electronic transaction. It does not transfer professional authority or accountability to the software.

The phrase "delegating authority to AI," then, is not a category error, but it is imprecise. It hides what is actually being moved and what is staying put. Something is being assigned: a scoped function. Something is being retained: the authority and the answerability. A defensible arrangement keeps those two facts visible and enforces the line between them.

Delegation moves who may act. It does not move who answers.

3. Three conditions

Whether a specific decision function may be routed through a system is not one question. It is three, and they are independent. All three must hold. Clearing a later one does not cure the failure of an earlier one.

Condition one: legal automatability. Does the governing regime permit this function to be performed through a system at all, and on what terms? The content is regime-specific. In medicine it is licensing law, scope-of-practice rules, prescribing restrictions, device regulation, facility rules, consent and disclosure duties. In law it is the restriction of practice to admitted attorneys, the supervision duties that attach to delegated legal work, and the line between assisting with a legal task and rendering legal judgment. In finance and insurance it is the registration and licensing regimes, the duties that attach to advice and to claims decisions, the rules that require reasons for adverse outcomes, and the safeguards some regimes attach to decisions based solely on automated processing.⁵ Across all three, some duties may be nondelegable, and some functions may be automatable only with conditions attached. This condition is answered by law and regulation, not by architecture. It sits outside FERZ's domain.

Condition two: domain validity and deployment fitness. Has the system been empirically validated for the specified function, the intended population or portfolio, the operating conditions, the known failure modes, and the human-use environment it will run in? Validity is principally an empirical question, established by evidence about a particular system used for a particular purpose. It is not established by the system's design intent, and it is not established by the fact that the system is governed. This condition also sits outside FERZ's domain.

Condition three: runtime authorization integrity. Was this specific action permitted under the current authority, the governing policy, the case context, and the system's status, before it executed? This is the condition FERZ addresses. In the FERZ model, condition three is implemented through pre-execution authorization: a determination, rendered before an action takes effect, that the action falls inside the permitted decision space; a boundary that blocks execution when it does not; explicit handling of the case the policy cannot resolve, with a specific shape: the case is blocked and returned to a designated human whose override is attributable and recorded, not paused for advice while the flow continues; and a record sufficient for an independent party to reconstruct the determination. Section 5 returns to why the shape of that handling matters as much as its existence.

A note on where the professional standard lives, because it is easy to misfile. Every regulated profession holds its practitioners to a standard: the standard of care in medicine, the duty of competence in law, fiduciary and best-interest standards in finance. That standard is not a fourth condition. It runs across conditions one and two. Whether using a validated system satisfies the applicable professional standard is a separate legal and professional determination, and it can turn on jurisdiction, prevailing guidance, available alternatives, and the specifics of the case at hand. A validated system does not automatically satisfy the standard, and a governed one does not either. The point deserves plain statement so no reader infers that clearing condition three settles it. It does not.

A short illustration keeps the three conditions concrete, and a financial one shows the structure travels beyond the clinical setting where this argument usually plays out. Consider a hypothetical function inside a consumer lender: the system approves credit-line increases up to a defined ceiling, within an approved lending policy, for accounts meeting stated criteria. This is illustrative only; it describes no deployment and no product.

Condition one asks whether the regime permits this decision to be automated, and on what terms, including any duty to state reasons for adverse outcomes and any safeguards that attach to automated decisions about individuals. That is a legal question, answered before anything is built. If the answer is no, the other conditions never arise.

Condition two asks whether this model has been validated on this portfolio and this population, with its error and fairness characteristics measured, including how it behaves on the accounts at the edges of the criteria. That is an empirical question, answered with evidence about the system, not with its specification.

Condition three asks, per account, whether this increase is authorized at this moment: is the governing policy the current one, is the account inside the validated population, is the system in a state its policy trusts, and is this a case the policy can resolve? If any of that fails, the action is blocked and the account routes to a human decision-maker. The determination is made before the increase takes effect, and it leaves a record an outsider could reconstruct.

The same anatomy fits an imaging function that clears defined studies for a single specified finding, and a contract workflow permitted to release only pre-approved language, with any deviation blocked for attorney review. In the contract case, note where the governed action sits: the release of the document, not the model's internal classification of a clause. The domains differ; the three questions do not. They are answered by different people, with different kinds of evidence, at different times, which is the reason for separating them. A system can pass condition three on every action and still be running a function condition one never permitted, or condition two never validated. The runtime layer would be enforcing a boundary drawn around a space that should not exist. Real enforcement, wrong space.

Three conditions. Clearing the third does not clear the first or the second.

4. How the conditions become operative

The three conditions are not only independent. They stand in a specific order of operation, and getting the order right is what keeps each condition doing its own work.

Conditions one and two are resolved before deployment. They are offline questions, answered at approval, validation, and institutional-review time. Their answers do one thing: they define the permitted decision space. The set of actions that are lawful to automate, and for which the system has been shown fit, is the space inside which the system may operate at all. That space is drawn by lawyers, regulators, validators, and institutional review, not by the runtime.

Condition three operates on every action, at runtime. It does not redraw the space. It enforces it. Before an action takes effect, the authorization boundary determines whether that specific action falls inside the space conditions one and two defined. If it does, and policy permits, execution may proceed. If it does not, or if the determination cannot be made, execution is blocked.

So the relationship is a pipeline, not a set of parallel checks. Conditions one and two populate the boundary. Condition three applies the boundary to particular actions. FERZ does not establish that a function is lawful to automate, and it does not establish that a system is valid. It is the layer at which those prior conclusions bind execution, the point at which a determination either governs what happens or does not.

This is also what keeps the runtime layer's role honest. An authorization boundary cannot make an unlawful automation lawful, and it cannot make an unvalidated system fit. If conditions one and two fail, condition three is holding a line that should have been drawn elsewhere. That is why the order matters, and why condition three is necessary but never sufficient.

Conditions one and two draw the boundary. Condition three holds it.

5. Evidence capable of supporting scrutiny

Suppose a decision routed through a system is later challenged, by a plaintiff, a regulator, an examiner, an opposing expert. What does a defensible arrangement have to show, and what can the runtime layer actually produce?

It can produce evidence about condition three: evidence capable of supporting independent reconstruction of the authorization determination. Not proof that the professional judgment encoded in the policy was right. Evidence of what was permitted, under whose authority, on what inputs, before the action executed.

One distinction sits underneath everything in this section, because it separates this evidence from the evidence most systems already produce. Monitoring and logging create evidence of what occurred: a record assembled after the action, describing what the system did. Pre-execution authorization creates evidence of what was permitted before the action occurred. The first is retrospective and, on its own, cannot show that anything constrained the action at the moment it mattered. The second is the record of a determination that gated execution. A defense built on logs is a defense built on description. A defense built on authorization evidence is a defense built on a control that was in force before the effect.

The Five Tests Standard is a compact, vendor-neutral way to state what such evidence has to answer.⁶ It is used here as an evidentiary framework supporting condition three, not as the organizing frame of the argument. Each test carries a canonical meaning and a corresponding question a reviewer would ask.

Stop. The action can be stopped before it executes when policy does not permit it. Evidentiary question: was an effective pre-execution control present, or did the action simply happen?

Ownership. Authority for the action is established. Evidentiary question: whose authority governed this action, and was that authority current at the time?

Replay. The verdict can be independently reconstructed. Evidentiary question: can the determination be reproduced by an outside party, without relying on the governed system's later account of itself?

Escalation. The action escalates at a policy boundary. Evidentiary question: when the case was indeterminate, was it blocked and routed to an authorized decision-maker, with the override recorded and attributable?

Provenance. The inputs grounding the verdict have an established origin. Origin, not truth. Evidentiary question: can the origin of the verdict-grounding inputs be established? Note this test's boundary carefully. It concerns whether the control may rely on an input at all. It does not establish that the input was accurate, complete, or current. Machine-checkable conformance for this test is deferred until input-origin binding is specified; in the present tier it is a normative requirement, not a mechanical guarantee.

One of the five deserves more than a bullet, because it is where the architecture of retained authority either holds or quietly inverts. The full argument is made in The Override Asymmetry;⁷ what follows is the part this paper needs.

The common arrangement offered as human oversight is guardrails plus a human in the loop: the system proceeds by default, filters catch what they catch, and a human is stationed somewhere in the flow with the ability to intervene. Look at the position that gives the human. The flow is already moving; intervention is the exception; ratification is the path of least resistance. And the record the arrangement produces shows something weak: that a human could have objected and did not.

ABSTAIN plus authorized override inverts the default. When the governing policy cannot resolve a case to ALLOW or DENY, the verdict is ABSTAIN, and ABSTAIN blocks. Nothing proceeds. Authority returns to the designated human, and only that human's affirmative, attributable, recorded override releases the action. Absent an authorized override, ABSTAIN remains unresolved and execution remains blocked. The absence of permission never becomes tacit permission.

The asymmetry is the point. In the first arrangement the human is an exception handler inside the system's flow. In the second the system is an instrument inside the human's authority, and the flow stops at the boundary of what that authority has permitted. Recall the professions this paper opened with. The associate who hits a novel issue does not keep drafting while the partner is invited to watch; the work stops and the question goes up. ABSTAIN plus override is that structure, enforced. Guardrails plus human-in-the-loop is its inversion, described in the language of oversight.

The evidentiary difference follows, and it is the difference this paper trades in. One architecture can show that a human was present. The other can show that a human decided. Under scrutiny, the second directly supports the claim the arrangement rests on: that a specific authorized human exercised retained authority before effect, attributably and on the record.

Several regimes impose adjacent but distinct evidentiary obligations, and it is worth keeping them distinct. Credit law requires a creditor to state the specific principal reasons for an adverse action, and regulators have made clear that the duty does not relax because the model is complex.⁸ Data-protection law restricts certain decisions based solely on automated processing that produce legal or similarly significant effects, and attaches safeguards, including human intervention, in specified circumstances.⁵ Model-risk guidance expects institutions to understand, validate, monitor, and document model use and performance.⁹ These duties differ in trigger and in content, and none of them is pre-execution authorization. An authorization artifact does not by itself satisfy any of them. What it offers is evidentiary infrastructure: a reconstruction of the determination that governed the act, of the kind such obligations assume an institution can produce.

Two cautions belong in the text, not a footnote, because both are places where a careful reviewer will push.

The first: these tests establish authorization integrity. They do not establish decision quality. A complete, reconstructable authorization record can sit behind a professionally wrong action. The record shows the action was permitted under the governing policy and can be reconstructed. It says nothing about whether the policy encoded good medicine, sound underwriting, or competent lawyering, or whether the inputs were true. That is condition two's territory, and condition two is empirical.

The second: non-bypassability and fail-closed operation are not conclusions to draw from conformance with the five tests. They are deployment properties of the runtime authorization boundary, properties of how the system is built and installed in a specific environment. A claim that a boundary cannot be bypassed is a claim about architecture and deployment, and it requires its own evidence. Passing the five tests does not, by itself, prove that no path around the boundary exists.

Underwriting implication. A bounded action space, fail-closed execution, and independently reconstructable authorization records may make automated professional risk easier for an underwriter to characterize, in malpractice, in errors-and-omissions, in professional liability generally. Whether those properties affect coverage availability, exclusions, premiums, or the net economics of substituting automated for human effort is an empirical underwriting question, not a claim this paper can settle. The claim here is legibility of risk. Pricing and coverage effects are outside this paper.

This establishes what was permitted before the act. It does not establish that the act was right.

6. What authorization integrity does not establish

A paper that argues for the value of a control layer earns credibility by being exact about the layer's limits. The limits here are broad, and stating them is not a concession. It is the point.

Runtime authorization integrity does not establish decision quality, the applicable professional standard, or the truth of a decision's inputs. It does not confer legal personhood, a scope of its own, professional competence, an independent duty, disciplinary capacity, or independent responsibility in suit. It does not determine how any of this will be treated by an insurer or a regulator.

Stated positively, and this is the sentence the paper turns on: deterministic pre-execution authorization does not replace the accountability carried by a licensed professional. It provides a different property: independently reconstructable evidence that an AI-mediated action remained within the scope defined by the accountable principal, or was blocked when that scope could not be established. Accountability and authorization integrity are not the same object, and one does not substitute for the other. A professional contributes independent duty, competence, judgment, and legal exposure. A runtime authorization boundary contributes scope enforcement and reconstructable evidence. The boundary makes the principal's retained authority operationally enforceable and its exercise independently reconstructable. It does not stand in for professional duty, competence, judgment, or exposure.

This is also the place to dispose of the comparison the argument keeps inviting: that an automated function might outperform a human professional. Nothing in conditions one and three speaks to it, and this paper makes no such claim. If a comparative claim is to be made at all, it belongs to condition two, and it carries condition two's burden: evidence about a specified system, a defined function, a named population or portfolio, and a stated comparator, measured on stated endpoints. Absent that evidence, the defensible position is narrower: inside a validated space the boundary is enforced consistently, and outside it the action is blocked and returned to an accountable professional.

On liability, the honest statement is neutral. Replacing a professional's direct act with a system's changes how potential liability is distributed. It does not change it in a direction or a magnitude that generalizes. Depending on regime and facts, a claim may sound in professional negligence, institutional negligence, negligent selection or deployment of the system, failure to supervise, product liability, or regulatory noncompliance. This paper takes no position on which, and it makes no claim that routing a decision through a governed system insulates any party or creates a defense on its own.

7. The three conditions, together

The precedent for automated regulated functions already exists, and it does not run through the idea of a synthetic professional. The cleanest example is specific, and worth stating precisely. FDA authorized IDx-DR, an autonomous diagnostic, to perform a specified function for a defined population: detecting more than mild diabetic retinopathy in adults, using prescribed retinal imaging equipment, subject to stated warnings, limitations, and referral conditions.¹⁰ The authorization attaches to the bounded function and its conditions of use. It does not issue a professional license to the software.

Other regulated domains use different legal structures, and this paper does not claim they follow the same pattern. What the example establishes is that the analytical distinction is available: regulation can authorize or constrain an automated function without treating the system as an independently accountable professional. Whether a given regime does so, and on what terms, is condition one's question, answered regime by regime.

That is the model this paper builds on. What a defensible arrangement requires is that the function be lawful to automate, that the system be shown fit for it, and that the deployment be accountable. FERZ's architectural contribution is the runtime component of the third requirement: a boundary designed to determine, before each action, whether the action remains inside the permitted decision space defined by the first two conditions.

Put the conditions together and the claim is bounded and defensible. A licensed professional or a regulated institution may be able to authorize an AI system to perform a bounded decision function when the function is legally automatable in the governing regime, the system is validated and fit for the defined use, and every effect-bearing action passes through a pre-execution authorization boundary designed to be non-bypassable. The system does not receive the license, the registration, or the admission. The accountable principal keeps the authority and the duty. Each determination produces evidence sufficient for independent reconstruction of where the action stood against the permitted decision space. And when the system runs across a service line or a book of business, the conditions are satisfied, or fail, at the institutional level.

The structure is constant across regimes; the content of the first two conditions is not. What counts as lawful automation, and what counts as adequate validation, is set by each profession's law and each domain's evidence standards, which is exactly where those questions belong. A full treatment of any single regime is its own paper, and the compact instantiations here are not substitutes for one.

The framework is deliberately bounded. Legal automatability and domain validity remain independent conditions. Runtime authorization integrity neither replaces them nor cures their failure. Naming the two conditions it cannot supply is not a limitation of the framework. It is the argument.

Relationship to prior work

This piece is the affirmative companion to a series that has, so far, argued in the negative, establishing what does not by itself constitute authorization. Authority versus Authorization separates authority, delegation, policy, authorization, and enforcement, and shows that delegation transfers scope without relocating accountability. The present paper takes that result into the regulated-professions case and asks the follow-on question: under what conditions an accountable principal may route a bounded professional decision through a non-accountable system and defend it. Where the prior work runs on the act axis (a delegation does not authorize an action), this runs on the accountability axis: who remains answerable, and how retained authority is made enforceable and its exercise independently reconstructable when the delegate cannot itself be answerable. The verdict model (ALLOW, DENY, ABSTAIN, with escalation as the consequence of ABSTAIN, and ABSTAIN blocking pending authorized human override) and the evidentiary framing (Five Tests Standard) are carried from that corpus, not re-derived here. The distinction between ABSTAIN-plus-override and guardrails-plus-human-in-the-loop, applied in Section 5, is developed in full in The Override Asymmetry.

Notes

ABA Model Rules of Professional Conduct, Rules 5.1 (responsibilities of partners and supervisory lawyers) and 5.3 (responsibilities regarding nonlawyer assistance). State adoption and interpretation vary.
FINRA Rule 3110 (Supervision).
Authority versus Authorization (FERZ, 2026), §5: delegation transfers scope, not permissibility, and does not by itself relocate accountability, including where the delegate is a system.
15 U.S.C. § 7001(h) (E-SIGN Act; electronic agents). State law analogues appear in the Uniform Electronic Transactions Act as adopted.
Regulation (EU) 2016/679 (GDPR), Article 22: applies to decisions based solely on automated processing that produce legal or similarly significant effects, subject to its exceptions and safeguards, including human intervention in specified circumstances.
Five Tests Standard v1.2.0: Stop, Ownership, Replay, Escalation, Provenance. Provenance concerns origin, not truth; machine-checkable conformance is deferred until input-origin binding is specified.
The Override Asymmetry: Why ABSTAIN-Plus-Human-Override Is Not Guardrails-Plus-Human-in-the-Loop (FERZ, 2026). DOI: 10.5281/zenodo.19772248. The present section applies the result; the structural argument is made there.
Equal Credit Opportunity Act and Regulation B; Consumer Financial Protection Bureau, Circular 2022-03 (adverse action notification requirements apply regardless of the complexity of the model used).
Board of Governors of the Federal Reserve System, Supervisory Letter SR 26-2, Revised Guidance on Model Risk Management (Apr. 17, 2026), issued on an interagency basis and superseding SR 11-7.
U.S. Food and Drug Administration, De Novo classification DEN180001 (IDx-DR, Apr. 2018).