EAAPLEnterprise AI Architecture Pattern Library
EAAPL›Library›Human-in-the-Loop›
Proven
⇄ Compare

Human Override Pattern

👁️ Human-in-the-Loop🏭 Field-tested in AU

Human Override Pattern

Pattern ID: EAAPL-HIL006 Status: Proven Tags: human-oversight audit-logging accountability low-complexity Version: 1.0 Last Updated: 2026-06-12

1. Executive Summary

The Human Override Pattern provides a lightweight, universally applicable mechanism by which authorised humans can reject, modify, or reverse AI decisions at any point — with a complete audit trail and a structured feedback loop that converts overrides into institutional learning. It is the foundational human oversight control that underlies all other human-in-the-loop patterns. Where escalation and collaborative decision deal with pre-decision human involvement, override deals with post-decision human correction.

The pattern is deliberately low-complexity: override should require no more than 30 seconds, a one-click affordance with a mandatory reason selection from a pre-defined taxonomy, and an optional free-text field. It covers authority levels (who can override what), downstream impact awareness (show the human what changes when they override before they confirm), pattern detection (if the same error is overridden 10+ times in a week, trigger a model improvement workflow automatically), and override notification (affected downstream systems are notified). CIOs and CTOs gain a demonstrable, auditable human control point for every AI-driven decision in the enterprise — satisfying EU AI Act Article 14 obligations, APRA model risk requirements, and providing the ground-truth signal that drives model improvement at scale.

2. Problem Statement

Business Problem

AI systems in production will make incorrect decisions. The question is not whether errors occur but whether the organisation can detect them, correct them, and learn from them. Without a structured override mechanism, corrections are applied informally (phone calls, emails, manual database fixes), are not captured in any structured way, and do not feed back into model improvement. Regulatory auditors cannot see the override record. Model risk teams cannot measure override rates. The organisation cannot prove that humans are genuinely in control.

Technical Problem

Most AI deployment architectures treat the AI output as a terminal state. Downstream systems are invoked, records are written, and emails are sent. Introducing override capability after the fact requires re-designing event flows, notification systems, and audit trails. The technical challenge is building override as a first-class capability at design time: every AI-driven action must be reversible (or at minimum undoable with compensating actions), and the override must propagate to all downstream systems that acted on the original AI decision.

Symptoms

  • AI decisions are corrected informally without any structured record
  • Override rate has never been measured; there is no awareness of how often the AI is wrong
  • When auditors ask for evidence of human control, there is none — only informal anecdotes
  • Model improvement is driven by periodic retraining on historical data, not by live override signals
  • Downstream systems are not notified when AI decisions are corrected; they continue operating on the original incorrect decision

Cost of Inaction

  • Regulatory non-compliance: EU AI Act Article 14 requires genuine human oversight with override capability; absence is a violation
  • Uncorrected AI errors propagate downstream, compounding into larger operational or financial failures
  • Model does not improve from production errors; teams must wait for scheduled retraining to fix observed deficiencies
  • Liability: if an AI decision causes harm and no override mechanism existed, the organisation cannot demonstrate due diligence

3. Context

When to Apply

  • Any AI system that makes decisions affecting users, customers, or operational outcomes
  • Regulated industries where human oversight of automated decisions is a compliance requirement
  • AI systems with measurable downstream consequences (financial transactions, communications sent, records updated)
  • All patterns in the EAAPL human-in-the-loop family depend on this pattern as a foundational capability

When NOT to Apply

  • Decisions that are inherently irreversible and where override would be meaningless (real-time fraud block at point of sale — the transaction was declined; nothing to override)
  • Advisory AI output where the human always makes the final decision (no AI action to override)
  • Very low-stakes, fully reversible AI recommendations where the cost of implementing override infrastructure exceeds the benefit

Prerequisites

  • AI decisions are captured in a decision log with a unique decision_id
  • Downstream systems are architecturally capable of receiving override notifications
  • Authority level framework exists or can be defined

Industry Applicability

Industry Override Use Case Override Authority Downstream Notification
Financial Services Override AI credit decision Senior credit officer Core banking system, credit bureau reporting
Insurance Override AI claims assessment Senior adjuster Claims management system, customer communication
Healthcare Override AI treatment recommendation Attending physician EHR system, pharmacy, nursing staff
Legal Override AI document risk classification Senior solicitor Matter management system, client portal
Customer Service Override AI complaint resolution outcome Team leader CRM system, customer notification
Government Override AI benefits eligibility determination Case manager Case management system, payment system

4. Architecture Overview

The Human Override Pattern is built around four core capabilities.

Capability 1 — Override Interface Design. Override must be fast, frictionless for authorised users, and structured for data quality. The interface presents: the original AI decision with its reasoning and confidence; the current downstream state (what actions have already been taken based on this decision); a single "Override" button; a mandatory reason code selector from the override taxonomy; and an optional free-text field for additional context. The entire interaction should complete in under 30 seconds for a standard override. Critically, before confirming, the interface shows the downstream impact preview: "Overriding this decision will: update the customer's credit limit from $5,000 to [your input]; send a revised notification to the customer; amend the credit bureau report." This ensures the human understands the full scope of the override before committing.

Override Taxonomy. The reason taxonomy must be stable (changes require governance) and exhaustive enough that "other" is rarely selected. Standard taxonomy: wrong_facts (the AI used incorrect or outdated data); wrong_reasoning (the AI's logic was flawed even given the correct facts); policy_violation (the AI recommendation violates a current policy the model does not know about); inappropriate_context (technically correct but wrong for this specific case given contextual knowledge); user_preference (the override reflects a known customer preference or relationship context); new_information (information became available after the AI decision that changes the outcome); and other (with mandatory free-text). The taxonomy is surfaced as a radio button group — not a free-text field — to ensure structured data.

Capability 2 — Authority Levels. Not all overrides are equivalent. Junior staff may override AI recommendations (AI output that assists their workflow); only senior staff may override automated decisions (AI output that directly caused an action). Authority levels are defined per decision type: Tier A decisions (recommendations) may be overridden by any authenticated user; Tier B decisions (automated low-impact actions) may be overridden by team leads and above; Tier C decisions (automated high-impact actions with financial, legal, or reputational consequences) may be overridden only by designated override authorities. Authority levels are implemented via RBAC: the Override button is not rendered for users without the required authority level for the specific decision type.

Capability 3 — Downstream Impact and Propagation. When an override is confirmed, the system must propagate the change to all downstream systems that acted on the original decision. This requires an event-driven architecture: the original AI decision emits a decision.created event; downstream systems subscribe and take action; the override emits a decision.overridden event that all original subscribers also process. Systems that cannot process decision.overridden events must be documented as override-incompatible and flagged as technical debt requiring remediation. For irreversible downstream actions (emails already sent, wire transfers already executed), the propagation layer generates compensating actions (follow-up email, reversal request) rather than direct reversal.

Capability 4 — Pattern Detection and Automatic Model Improvement Trigger. Every override is stored in the override event store. A pattern detector runs on a rolling 7-day window and computes: override rate by decision type; override rate by reason code; override rate for specific input clusters (identified by feature similarity). If any decision type's override rate exceeds a threshold (default: 5%) or a specific reason code fires 10+ times in 7 days, the pattern detector automatically creates a model improvement ticket and notifies the ML Ops team. This converts the override mechanism from a purely reactive control into a proactive model improvement signal. The ML Ops team triages the ticket: if the pattern reflects a genuine model deficiency, it initiates an active learning loop or targeted retraining; if it reflects a policy change, it initiates prompt or rule updates.

5. Architecture Diagram

ARCHITECTURE DIAGRAM
flowchart TD subgraph Decision["AI Decision"] A[AI Decision Event] B[(Decision Log)] C[Downstream Systems] end subgraph Override["Human Override"] D[Override Interface] E{User Confirms Override} F[Override Recorded + Event] end subgraph Propagation["Propagation and Learning"] G[Downstream Notification] H[Pattern Detector] I[Model Improvement Ticket] end A --> B A --> C B --> D D --> E E -->|confirm| F F --> G F --> H H -->|threshold exceeded| I style A fill:#dbeafe,stroke:#3b82f6 style B fill:#fef9c3,stroke:#eab308 style C fill:#f0fdf4,stroke:#22c55e style D fill:#f0fdf4,stroke:#22c55e style E fill:#f3e8ff,stroke:#a855f7 style F fill:#d1fae5,stroke:#10b981 style G fill:#d1fae5,stroke:#10b981 style H fill:#f0fdf4,stroke:#22c55e style I fill:#fee2e2,stroke:#ef4444

6. Components

Component Type Responsibility Technology Options Criticality
Decision Log Append-Only Data Store Immutable record of all AI decisions with full context snapshot PostgreSQL append-only table; Event Store; AWS DynamoDB with Streams Critical
Override Interface Web / Mobile UI Render override affordance to authorised users; show impact preview; capture reason and text React component embedded in existing application UI; native mobile overlay Critical
Authority Level Enforcement RBAC / API Layer Verify user authority before rendering override option or accepting override submission Existing IAM/RBAC system; API gateway policy; middleware Critical
Downstream Impact Calculator Application Service Query downstream systems to determine current state; compute impact of proposed override Python service calling downstream system APIs High
Override Event Publisher Event Bus Integration Emit decision.overridden event on confirmed override AWS EventBridge, Azure Event Grid, Kafka, GCP Pub/Sub Critical
Downstream Notification Handler Event Consumer Subscribe to decision.overridden; execute reversal or compensating action in downstream system System-specific event consumer per downstream system Critical
Override Event Store Data Store Store all override events with full metadata PostgreSQL; append-only; fed by event bus Critical
Pattern Detector Analytics Service Compute rolling override metrics; detect threshold breach; create improvement ticket Python analytics job; Airflow DAG; or event-driven Lambda High
Model Improvement Ticket Creator Integration Service Create ticket in ML Ops backlog system when pattern detected Jira API, ServiceNow, GitHub Issues API Medium

7. Data Flow

Primary Flow

Step Actor Action Output
1 AI System Makes decision; emits decision.created event decision_id, decision_type, decision_value, reasoning, confidence, input_snapshot
2 Decision Log Records decision immutably Persisted decision record
3 Downstream Systems Process decision.created event; take action Actions recorded in downstream systems
4 Override Interface Renders override affordance to users with authority for this decision_type Override UI with decision details
5 Authorised User Initiates override Override intent captured
6 Impact Calculator Queries downstream systems for current state impact_preview: list of downstream changes
7 User Reviews impact preview; selects reason code; adds optional text; confirms override_confirmed, reason_code, override_text
8 Override API Validates authority; records override event override_id, decision_id, operator_id, reason_code, override_text, timestamp, new_value
9 Event Publisher Emits decision.overridden event Event with override payload
10 Downstream Handlers Process decision.overridden; execute reversal or compensating action Updated state in each downstream system
11 Pattern Detector Aggregates overrides on rolling window; computes rates by type and reason Pattern report; ticket creation if threshold exceeded
12 ML Ops Triages improvement ticket; initiates model improvement workflow Model improvement sprint item

Error Flow

Error Condition Detected By Recovery Action Notification
Downstream notification handler fails (reversal not applied) Event consumer dead-letter queue Manual remediation ticket created; operator notified; retry with exponential backoff Operations team; affected downstream system owner
Override authority verification fails at API layer RBAC middleware Reject override; return 403; log attempt Security team if repeated unauthorised override attempts
Impact calculator unavailable Override Interface Display warning "impact preview unavailable"; allow override to proceed with user acknowledgement ML Ops; downstream system owner
Pattern detector job failure Airflow / job monitor Alert ML Ops; manual pattern review for the period ML Ops

8. Security Considerations

Authentication and Authorisation

  • Override API endpoints require authenticated session; anonymous override is never permitted
  • Authority levels enforced both in UI (button rendered/hidden) and API layer (server-side validation — UI-only enforcement is insufficient)
  • Tier C override authority requires step-up MFA challenge before submission
  • Override event store write access restricted to override API service account only

Secrets Management

  • Downstream notification handler credentials stored in secrets manager; rotated every 90 days
  • Event bus credentials stored in secrets manager

Data Classification

  • Override records inherit the classification of the original AI decision record
  • Override free-text may contain sensitive customer context; treat as confidential; store with same encryption as decision log

Encryption

  • Override event store encrypted at rest (AES-256) and in transit (TLS 1.3)
  • Event bus messages encrypted in transit

Auditability

  • Override event store is append-only; no update or delete capability
  • All override events contain: operator identity, timestamp, decision_id, reason_code, full context snapshot at override time
  • Access to override records logged with accessor identity

OWASP LLM Top 10 Considerations

OWASP LLM Risk Applicability Mitigation
LLM01: Prompt Injection Low — override is a human action, not an AI inference path N/A
LLM02: Insecure Output Handling Low — override values are human-entered, not AI-generated Validate override input values against allowed value sets; sanitise free-text
LLM03: Training Data Poisoning Medium — override records feed model improvement Validate override record quality; authority level controls limit who can generate override training signals
LLM04: Model Denial of Service Low N/A
LLM05: Supply Chain Vulnerabilities Low N/A
LLM06: Sensitive Information Disclosure Medium — override records aggregate decision context Access controls on override event store; same controls as decision log
LLM07: Insecure Plugin Design Low N/A
LLM08: Excessive Agency Low — override is the human control over AI agency By design
LLM09: Overreliance Low — override pattern is specifically designed to prevent overreliance Pattern detector monitors for low override rate as automation bias signal
LLM10: Model Theft Low — override records do not directly expose model internals Restrict bulk export of override records to authorised ML Ops personnel

9. Governance Considerations

Responsible AI

  • Override rate monitored by protected group: if AI decisions affecting certain demographic groups are overridden at higher rates, investigate for systematic model error affecting that group
  • Override reasons analysed for patterns indicating regulatory or ethical concerns: policy_violation overrides are immediately escalated to Compliance

Model Risk Management

  • Monthly override rate report is a model risk KPI; sustained override rate above 5% for a decision type triggers mandatory model review
  • Pattern detection tickets are tracked to resolution; unresolved patterns older than 30 days escalate to Model Risk Officer

Human Approval Gates

  • Changes to override taxonomy require Legal and Compliance review (reason taxonomy is a compliance artefact)
  • Changes to authority levels require Model Risk and HR/Legal sign-off

Policy Compliance

  • Override authority levels must be reflected in documented delegation of authority matrices
  • Customers have the right to request information about AI decisions affecting them and how they can challenge them; override mechanism is the challenge pathway

Traceability

  • Every AI decision is traceable to any subsequent override with full context at time of both decision and override
  • Override chain is fully auditable: if an override is itself overridden, both events are in the log with independent identity and timestamp

Governance Artefacts

Artefact Owner Frequency Purpose
Override Rate Report Model Risk Monthly Track override rate by decision type, reason code, and user cohort
Pattern Detection Alert Log ML Ops As triggered Document all auto-triggered improvement tickets and their resolution
Authority Level Matrix Legal / HR Annually (or on change) Document who can override what; basis for RBAC configuration
Override Audit Extract Compliance On demand (regulatory request) Extract all override events for a decision type or time period
Model Improvement Backlog ML Ops Continuously maintained Track all pattern-detection-triggered improvement items to resolution

10. Operational Considerations

Monitoring

Metric SLO Alert Threshold Owner
Override interface render latency < 2 seconds > 5 seconds Engineering
Override submission success rate > 99.9% < 99.5% Engineering
Downstream notification delivery rate > 99.5% < 99% or any DLQ message Operations
Override rate by decision type Baseline ± 50% > 3× baseline sustained for 7 days Model Risk
Policy_violation override reason frequency Near zero > 5 in any 7-day window Compliance (immediate)
Pattern detection job success rate > 99% Any failure for > 24 hours ML Ops

Logging

  • Structured JSON logs for all override API calls (including rejected attempts due to insufficient authority)
  • Override event store retained 7 years minimum for regulated decision types
  • Downstream notification handler outcomes logged per event

Incident Response

  • Downstream notification delivery failure: DLQ alert triggers within 5 minutes; manual intervention ticket created; affected downstream system owner notified within 1 hour
  • Policy_violation reason code alert: Compliance notified immediately; incident opened; original AI decision reviewed for systemic issue
  • Override rate spike: Model Risk notified within 24 hours; emergency model review if rate > 10× baseline

Disaster Recovery

Component RTO RPO Strategy
Override API 5 min 0 (stateless) Multi-AZ; auto-scaling; no state
Override Event Store 15 min 5 min PostgreSQL synchronous standby; WAL archiving
Event Bus 5 min 0 (persistent message queue) Cloud-managed event bus with regional replication
Decision Log 15 min 5 min PostgreSQL synchronous standby

Capacity Planning

  • Override volume is a small fraction of total decision volume; infrastructure is not the primary scaling concern
  • Pattern detector job must be capable of processing 30 days of override history in a single batch run (for recovery after outage)

11. Cost Considerations

Cost Drivers

Driver Description Relative Weight
Override Event Store Storage Grows permanently; modest per-record size Low
Downstream Notification Infrastructure Event bus costs; downstream handler compute Low
Pattern Detector Compute Lightweight analytics job Very Low
Development Cost Building override UI component, authority layer, event propagation Medium (one-time)
Model Improvement Labour ML Ops time to triage and resolve pattern-detection tickets Medium (ongoing)

Scaling Risks

  • Downstream notification handler must scale with downstream system complexity: each new downstream system requires a dedicated handler
  • Pattern detector performance degrades if override history is extremely large (hundreds of millions of records); partition by decision type

Optimisations

  • Build override as a reusable component rather than per-application: one override SDK, deployed across all AI-enabled applications
  • Use event-driven architecture so downstream notification is asynchronous and does not block the human override experience
  • Pattern detector runs as a lightweight batch job rather than real-time stream processing; cost-efficient for the required latency

Indicative Cost Range

Scale Monthly Override Volume Infrastructure Cost Development Cost (one-time) Ongoing Operations
Small (1K overrides/month) 1,000 $100–$500/month $20,000–$50,000 $2,000–$5,000/month (labour)
Medium (50K overrides/month) 50,000 $500–$2,000/month $50,000–$100,000 $10,000–$30,000/month
Large (1M overrides/month) 1,000,000 $2,000–$10,000/month $100,000–$200,000 $50,000–$150,000/month

12. Trade-Off Analysis

Override Propagation Approach Options

Approach Downstream Consistency Implementation Complexity Latency Impact Recommended
Synchronous propagation (override API waits for all downstream updates before confirming to user) Highest High High (user waits for all downstream systems) Only for critical financial transactions; not for routine overrides
Asynchronous event-driven propagation (override confirmed immediately; downstream updated via event bus) High (eventual consistency) Medium None for user Default recommendation; DLQ provides recovery
Manual downstream update (override recorded; operator manually updates downstream systems) Low (human error risk) Very Low None Only for legacy systems that cannot receive events; document as technical debt

Architectural Tensions

Tension Option A Option B Resolution Guidance
Override reason taxonomy stability vs evolution Stable taxonomy: consistent historical data for trend analysis Evolving taxonomy: captures new error categories as they emerge Add new codes; never remove or rename existing codes; use versioned taxonomy with effective dates
Authority strictness vs operational agility Strict: only designated authority levels can override Liberal: any authenticated user can override any decision Domain-dependent: financial and clinical require strict authority; operational efficiency decisions can be more liberal
Override impact preview depth vs latency Full impact preview: query all downstream systems (1–3 seconds delay) Minimal preview: no downstream query (instant) Always provide at least a category-level impact statement (e.g. "This override will affect: customer notification, core banking record"); full query for Tier C decisions; minimal for Tier A

13. Failure Modes

Failure Likelihood Impact Detection Recovery
Downstream notification not delivered (DLQ message) Medium High — downstream system acts on original incorrect decision DLQ monitoring; downstream state inconsistency monitoring Manual remediation; DLQ replay after fix
Override UI not rendered to user who needs it (RBAC misconfiguration) Low Medium — user cannot override when needed; informal correction occurs outside system User feedback; override rate monitoring by user role RBAC configuration review; emergency authority grant by admin
Authority check bypass via API (UI-only enforcement) Low Critical — unauthorised overrides possible API-layer authority validation (defence in depth); audit log review Enforce server-side; security investigation of bypass
Pattern detector false positive (normal variation triggers improvement ticket) Medium Low — ML Ops distracted by noise Pattern detector threshold calibration Review and close false positive tickets; adjust thresholds
Override reason "other" used excessively (> 20% of overrides) Medium Medium — override taxonomy is inadequate; model improvement signal is noisy other_rate monitoring in override report Taxonomy review; analyse other free-text to identify new categories

Cascading Failure Scenario

  • Downstream notification handler for System A fails silently (DLQ not monitored) → System A continues acting on original incorrect AI decision for 3 weeks → operational data inconsistency accumulates → reconciliation project required
  • Mitigation: DLQ monitoring with alert within 5 minutes of any DLQ message (not just after accumulation); downstream state reconciliation job runs nightly to detect inconsistencies

14. Regulatory Considerations

Regulation Specific Clause Requirement Implementation
EU AI Act Article 14 — Human oversight High-risk AI system users must be able to override system outputs Override button always rendered for authorised users on high-risk AI decisions; override mechanism documented in technical file
EU AI Act Article 14(4)(d) — Override capability Override must be technically achievable Downstream propagation ensures override has real effect, not just a log entry
EU AI Act Article 12 — Record keeping High-risk AI systems must log sufficient data to enable oversight Override event store with full context snapshot satisfies record-keeping obligation
APRA CPS 234 §36 — Testing of controls Override mechanism must be tested to verify it functions as intended Override functional testing in CI/CD pipeline; periodic DR testing of override propagation
Privacy Act 1988 (Australia) APP 13 — Correction of personal information Individuals have the right to correct inaccurate personal information Override mechanism can correct AI decisions that resulted in incorrect personal information records
ISO 42001:2023 §8.5 — Human oversight and intervention AI systems must support intervention and correction by humans Override mechanism is the ISO 42001 intervention capability
NIST AI RMF RESPOND 2.2 — Corrective actions AI system errors must be correctable Override mechanism is the NIST RESPOND corrective action capability
GDPR Article 22(3) Automated decision-making — right to challenge Data subjects have the right to express their point of view and contest automated decisions Override mechanism provides the internal pathway for decision correction following a subject's challenge

15. Reference Implementations

AWS

  • Override API: AWS Lambda + API Gateway with Cognito authoriser for authority level enforcement
  • Override Event Store: Amazon DynamoDB (append-only table) or RDS PostgreSQL
  • Event Bus: Amazon EventBridge with custom event bus per decision type; DLQ per rule
  • Downstream Handlers: Lambda functions per downstream system subscribing to EventBridge rule
  • Impact Calculator: Lambda function calling downstream system APIs via VPC
  • Pattern Detector: EventBridge Scheduler triggering Lambda; results pushed to SNS for ML Ops notification

Azure

  • Override API: Azure Functions + API Management with Azure AD B2C authority enforcement
  • Override Event Store: Azure Cosmos DB (append-only) or Azure SQL Database
  • Event Bus: Azure Event Grid with dead-letter storage in Azure Blob
  • Downstream Handlers: Azure Functions per downstream system
  • Pattern Detector: Azure Logic Apps or Azure Functions with Timer trigger

GCP

  • Override API: Cloud Run service with Firebase Auth for authority enforcement
  • Override Event Store: Cloud Firestore (append-only mode) or Cloud SQL
  • Event Bus: Cloud Pub/Sub with dead-letter topic
  • Downstream Handlers: Cloud Functions subscribing to Pub/Sub topics
  • Pattern Detector: Cloud Scheduler + Cloud Functions; notifications via Pub/Sub to ML Ops topic

On-Premises / Private Cloud

  • Override API: Python FastAPI service on Kubernetes with LDAP/AD authority enforcement
  • Override Event Store: PostgreSQL with pgaudit (append-only enforcement via trigger)
  • Event Bus: Apache Kafka with per-topic DLQ (dead letter queue via separate topic + consumer group)
  • Downstream Handlers: Spring Boot or Python consumer services per downstream system
  • Pattern Detector: Airflow DAG with daily schedule; results pushed to JIRA API
Pattern ID Relationship Notes
Collaborative AI Decision EAAPL-HIL004 Specialisation — override is embedded in the collaborative decision architecture Collaborative decision adds pre-decision review; override adds post-decision correction
Human Escalation Pattern EAAPL-HIL003 Complementary — escalation is pre-decision; override is post-decision Use both: escalation to prevent errors, override to correct them
Active Learning Loop EAAPL-HIL002 Complementary — override events are a premium training signal Override records with reason codes are high-quality annotation inputs for active learning
AI Confidence Threshold Routing EAAPL-HIL005 Complementary — overrides on Tier 1 automated decisions feed back to threshold calibration High override rate on Tier 1 items indicates threshold is too permissive
Annotation and Feedback Loop EAAPL-HIL007 Complementary — override events are a natural source of annotation data Route override records to annotation feedback pipeline
Human-in-the-Loop Agent EAAPL-MAG003 Dependency — agents must support override of their intermediate and final actions Agent architecture must implement override-compatible action design

17. Maturity Assessment

Overall Maturity Level: Proven

Dimension Score (1–5) Rationale
Technical Maturity 5 Append-only audit logs, event-driven downstream notification, and RBAC are all mature technologies
Operational Maturity 4 Override workflows are well-understood; downstream propagation complexity varies by organisation
Governance Maturity 5 EU AI Act Article 14 directly requires this capability; it is the most commonly cited human oversight implementation
Tooling Ecosystem 4 No purpose-built override frameworks; built from standard components (event buses, RBAC, audit tables)
Enterprise Adoption 4 Override capability exists in most mature AI deployments; structured reason taxonomy and pattern detection are less common
Risk Profile Low Well-understood; primary risks are RBAC misconfiguration and downstream notification failure; both have standard mitigations

18. Revision History

Version Date Author Changes
1.0 2026-06-12 EAAPL Working Group Initial publication covering override interface design, override taxonomy, authority levels, downstream propagation, pattern detection, and governance artefacts
← Back to LibraryMore Human-in-the-Loop →