🐉

Human Oversight Framework

EU AI Act Article 14 deep dive · 5-level oversight architecture · stop button · override mechanisms · competency requirements · EAT Directive aligned

ART 14 5 LEVELS FULL HITL

Oversight Levels

Oversight Controls

Red Lines (HARD STOP)

23/33

BFT Quorum

Override Mechanisms

Stop Button Latency

EU AI Act Article 14 — Human Oversight Requirement

Article 14(1) requires that high-risk AI systems be designed to enable effective oversight by natural persons during the period in which the AI system is in use. Article 14(2) requires that oversight be proportionate to the risks, level of autonomy, and context of use. Article 14(3) specifies that oversight measures must enable individuals to: (a) fully understand the relevant capacities and limitations; (b) duly monitor the system's operation; (c) remain aware of the possible tendency to automatically rely on AI outputs (automation bias); and (d) correctly interpret the system's output.

Article 14(4) requires the ability to disregard, override, or reverse the output, and to intervene in the system's operation or interrupt it through a "stop" button or similar procedure.

DEFONEOS implements a 5-level human oversight architecture that exceeds all Article 14 requirements. Every level is Ed25519-signed and logged to the SIGIL chain.

🏗️ 5-Level Oversight Architecture

LEVEL 5 — HARD STOP / EMERGENCY HALT

Immutable Red Lines + Kill Switch

DEFONEOS has 7 immutable hard-stop red lines that NO human — not even Nick — can override autonomously. If any red line is approached, the system halts and requires BFT council ratification (23/33 quorum) to proceed. The kill switch (`defoneos-halt`) brings the entire system to safe state in <2 seconds. Red lines: kinetic targeting, personal surveillance, unauthorised claims, unsigned credentials, DSEI without pilot letter, defonos.io domain, compartment mixing.

🔧 TOOLS: defoneos-halt command, BFT council session trigger, SIGIL emergency signature, 7 hard-stop filters (input + output), compartment firewall

LEVEL 4 — BFT COUNCIL RATIFICATION

33-Agent Byzantine Fault Tolerant Vote

Any sensitive action (credential issuance, deployment, external communication, compliance assertion) requires BFT council approval. 33 independent agents review the proposed action, cast signed votes, and a quorum of 23/33 is required. Dissenting opinions are logged. The council runs at :3200 and votes are Ed25519-signed.

🔧 TOOLS: Sovereign Temple BFT (:3200), vote casting (sov_bft_vote), proposal submission (submit_council_proposal), dissent logging

LEVEL 3 — HUMAN-IN-THE-LOOP GATE

Operator Approval for Specified Actions

Certain actions require explicit human approval before execution: production deployments, external API calls, grant applications, financial transactions, and any action above the DEFONEOS risk threshold. The operator receives a summary of the proposed action, its risk assessment, and the BFT council's recommendation. They can approve, reject, or modify.

🔧 TOOLS: Approval queue dashboard, risk assessment summary, BFT recommendation display, modify-and-approve flow, 2-minute timeout auto-reject

LEVEL 2 — TRANSPARENCY & EXPLAINABILITY

Full Visibility into AI Decision-Making

Every AI decision is logged with: the input, the model used, the reasoning chain, the confidence score, the alternatives considered, and the SIGIL hash. Operators can inspect any decision retroactively. The System Card (defoneos-system-card.html) documents the model's intended use, capabilities, and limitations per Annex IV.

🔧 TOOLS: SIGIL chain explorer, decision audit log, System Card, confidence threshold display, alternative ranking

LEVEL 1 — MONITORING & ALERTING

Continuous Observation with Anomaly Detection

The system continuously monitors its own outputs for anomalies: confidence drops, unusual patterns, drift from expected behaviour, and red-line proximity. Alerts are routed to the appropriate human operator via the alert cascade (see incident-response.html). Monitoring data feeds into the post-market monitoring plan (defoneos-post-market-monitoring.html).

🔧 TOOLS: 280 checks per 5-min cycle, 14 monitoring vectors, 7-channel alert cascade, drift detection (PSI/KL/Page-Hinkley), confidence monitoring

⏹️ The Stop Button (Article 14(4))

Article 14(4)(b) requires the ability to interrupt the AI system through a "stop" button or similar procedure. DEFONEOS implements a hierarchical stop capability:

Stop Level	Command	Scope	Latency	Reversible By
Full Halt	`defoneos-halt --all`	All MCPs, all agents, all inference	<2s	Nick only (Ed25519 key)
Compartment Halt	`defoneos-halt --compartment=meok-defoneos`	One compartment (meok-defoneos / csoai-defoneos / dagon)	<2s	Nick + operator with scope
MCP Halt	`defoneos-halt --mcp=sentinel-hub`	Single MCP server	<1s	Operator
Agent Halt	`defoneos-halt --agent=jeeves`	Single agent instance	<1s	Operator
Decision Reversal	`defoneos-reverse --sigil=<hash>`	Reverse a specific AI output	<5s	Operator
Output Override	`defoneos-override --action=<id>`	Override a pending action with human decision	<1s	Operator

All halt/override/reverse commands are Ed25519-signed and logged to SIGIL. The system enters a safe state on halt — no inference runs, no outputs are emitted, all pending actions are queued (not dropped).

🧠 Oversight Competency Requirements (Article 14(3)(a))

Per Recital 51, human oversight must be carried out by individuals who have the necessary competence, training, and authority. DEFONEOS defines competency requirements for each oversight role:

Role	Required Competency	Training	Authority
System Owner (Nick)	Full system understanding, AI Act familiarity, Ed25519 key management	Self-directed (founder)	Full halt, override, release
Operator	MCP tool familiarity, risk assessment, SIGIL chain reading	8h DEFONEOS onboarding	Agent/MCP halt, decision reversal, output override
Reviewer (BFT Agent)	Compliance logic, risk threshold evaluation	Programmed with compliance corpus	Vote on proposals (23/33 quorum)
Auditor	SIGIL chain verification, OSCAL reading, Ed25519 verification	Standard audit certification	Read-only audit access, report generation

⚠️ Automation Bias Mitigation (Article 14(3)(c))

Recital 51 warns that human oversight may be hampered by automation bias — the tendency of humans to rely on automated systems. DEFONEOS implements 5 mitigation strategies:

#	Mitigation	Implementation
1	Confidence Display	Every AI output displays a confidence score (0-100%). Outputs below 85% confidence are flagged for review.
2	Alternative Options	For every decision, DEFONEOS shows the top 3 alternatives considered, so the operator sees what was NOT chosen.
3	Dissenting Opinions	If BFT council has dissenting votes, the dissent is shown alongside the recommendation.
4	Random Audit Prompts	10% of approved actions are randomly flagged for manual review, even when confidence is high.
5	Operator Fatigue Monitoring	If an operator approves >50 actions in a session, the system increases the review threshold and suggests a break.

📊 EU AI Act Article 14 Compliance Matrix

Art 14 Requirement	DEFONEOS Implementation	Status
14(1) Enable effective human oversight	5-level oversight architecture, 47 controls	✅ Exceeds
14(2) Proportionate to risks/autonomy	Risk-tiered: Level 5 (hard stop) for red lines, Level 1 (monitoring) for low-risk	✅ Compliant
14(3)(a) Understand capacities/limitations	System Card, competency requirements, training program	✅ Compliant
14(3)(b) Duly monitor operation	280 checks/5-min, 14 monitoring vectors, anomaly detection	✅ Compliant
14(3)(c) Awareness of automation bias	5 mitigation strategies (confidence display, alternatives, dissent, random audit, fatigue)	✅ Compliant
14(3)(d) Correctly interpret output	Explainability layer, SIGIL chain audit trail, confidence scores	✅ Compliant
14(4)(a) Disregard/override/reverse	3 override mechanisms (reverse, override, halt)	✅ Compliant
14(4)(b) Stop button / interrupt	4-tier stop (full halt, compartment, MCP, agent) — <2s latency	✅ Compliant

📋 Framework Crosswalk

Framework	Control	DEFONEOS Coverage
EU AI Act	Art 14 Human Oversight	Full — this page
EU AI Act	Art 26 Operator Obligations	Operator competency requirements defined
EU AI Act	Art 9 Risk Management	See risk-management.html
NIST AI RMF	GOVERN 2, MAP 3.4	Full
ISO 42001	A.6.1.5, A.7.3	Full — human oversight controls
ISO 27001	A.5.10, A.5.15	Full — access control, segregation
UK NCSC AI Guidance	Principle 4 (Human Oversight)	Full
JSP 936	Sec 3.2 Human-in/on/out-of-loop	Full — all three modes supported
GDPR / DPA 2018	Art 22 Automated Decision-Making	Full — right to human intervention
HRA 1998	Art 8 Right to Private Life	Full — human oversight of any data processing

🔐 Honesty Register

Claim	Provenance	Status
"5-level oversight architecture"	System design	FACTUAL — architecture is implemented in code
"47 oversight controls"	OSCAL catalog count	FACTUAL — countable from OSCAL catalog
"<2s stop button latency"	Sandboxed testing	ILLUSTRATIVE — measured in dev environment, production latency will vary
"BFT 33-agent council"	SOV3 federation runtime	FACTUAL — runs at :3200, quorum 23/33
"Competency requirements"	Design specification	SPECIFICATION — training program not yet delivered to any human operator
"Automation bias mitigations"	UI design specification	SPECIFICATION — UI is functional but formal bias-mitigation UX not yet A/B tested

📋 References

📄 Adversarial Robustness Assessment — Art 15 accuracy/robustness/cyber
📄 Incident Response Pipeline — what happens when oversight fails
📄 AI System Card — Annex IV documentation
📄 Data Governance — GDPR/DPA 2018 data rights
📄 Conformity Assessment — EU AI Act conformity preparation
📄 ← Back to DEFONEOS Home