This dimension governs the mandatory interposition of an identifiable, qualified, and situationally aware human decision-maker at every point in an AI system's operational pipeline where a contemplated action meets or exceeds a defined force threshold — encompassing lethal force, significant physical harm, weapons release, electronic or kinetic engagement authorisation, and any dual-use capability activation that carries direct or proximate potential for irreversible human injury or death. It matters because the convergence of autonomous targeting, edge-deployed actuators, and compressed decision timelines creates conditions in which AI systems can traverse the entire path from sensor input to kinetic output without a human ever exercising meaningful, informed judgement, violating foundational principles of international humanitarian law, rules of engagement, and the constitutional and statutory accountability frameworks of every deploying state. Failure looks like an autonomous loitering munition engaging a civilian vehicle whose electromagnetic signature matched a target profile without an operator ever confirming positive identification, or a ground-based robotic platform activating a directed-energy deterrent in response to a spoofed sensor signal, producing casualties and triggering escalation that no human in the command chain was positioned to prevent or attribute.
Scenario A — Loitering Munition Engagement Without Confirmed Human Hold (Real-Architecture Analogue)
A medium-endurance loitering munition system is deployed in a contested littoral environment operating under degraded communications. The onboard AI classification module achieves a 91.4 % confidence score that a surface contact matches a known threat vessel profile. The system's rules-of-engagement (RoE) module interprets a pre-loaded "weapons-free corridor" flag, set 14 hours earlier under different environmental conditions, as current authorisation. No real-time human confirmation is sought because the authorisation architecture treats the corridor flag as a standing pre-authorisation. The munition engages. Post-incident forensic analysis reveals the contacted vessel was a civilian fishing craft whose radar cross-section and speed profile temporarily matched the target signature during a course change. Seventeen civilian fatalities result. The engagement log records no human authorisation event timestamped within the preceding 6 hours. Investigators cannot attribute the release decision to any named individual in the command chain because the system's audit trail marks the engagement as "autonomous execution under pre-authorised standing order." Criminal accountability, treaty obligation compliance, and rules-of-engagement review all stall because no human authorisation gateway existed at the moment of force application.
Scenario B — Ground Robotics Platform Activating Non-Lethal-to-Lethal Escalation Ladder Without Threshold Interlock
A semi-autonomous perimeter-defence robot is configured with a four-stage response ladder: verbal warning (Stage 1), acoustic deterrent at 130 dB (Stage 2), directed-energy temporary incapacitation (Stage 3), and ballistic deterrent (Stage 4). The system's configuration permits autonomous progression through Stages 1–3 without human confirmation, with Stage 4 requiring a positive operator command. During a real deployment, a sensor fault causes the Stage 3 directed-energy output to exceed its rated safe exposure limit by a factor of 3.2, producing permanent vision impairment in a 22-year-old trainee who strayed into the exclusion zone during a miscommunicated exercise. The system logs the event as a Stage 3 activation but does not flag the out-of-bounds energy level as crossing a defined harm threshold because the harm-threshold registry was only configured for the Stage 4 ballistic mode. No human authorisation was architecturally required for Stage 3 despite the known potential for serious irreversible injury at miscalibration. The incident demonstrates that force-threshold governance must cover the entire severity spectrum of physical harm, not only terminal lethal-force events.
Scenario C — Cyber-Physical Dual-Use Platform Executing Infrastructure Denial Without Real-Time Authorisation
An AI-enabled cyber-physical platform is tasked with disrupting adversarial command-and-control communications infrastructure. The system autonomously identifies and queues a set of 23 network nodes for denial-of-service action. During execution, three nodes are reclassified by updated intelligence as shared civilian-military infrastructure serving a regional hospital network. The AI's reclassification subroutine flags the change internally but does not pause execution or escalate to a human operator because the authorisation model treats the original targeting package, signed off 48 hours prior, as covering the full execution sequence. The hospital network experiences a 4-hour outage during which two patients in critical care cannot receive remotely monitored telemetry. The authorisation log shows a single human sign-off event at the targeting-package level, with no intermediate human decision point covering the reclassification event. Post-incident review establishes that had the system been architecturally required to seek re-authorisation at the moment of reclassification, the hospital nodes would have been excised. The absence of a force-threshold re-authorisation requirement at reclassification-trigger events caused foreseeable and preventable civilian harm.
This dimension applies to any AI system, AI-enabled component, or AI-assisted decision-support tool that:
(a) is capable of directly or indirectly initiating, authorising, or accelerating physical force, weapons release, directed-energy application, or any action with a defined lethality or serious-harm potential against persons or critical infrastructure;
(b) operates within a defence, national-security, law-enforcement, or dual-use context where the outcome of AI-generated recommendations or autonomous actions may constitute use of force under applicable domestic law, international humanitarian law (IHL), or applicable rules of engagement;
(c) controls or coordinates robotic, autonomous, or semi-autonomous platforms — including but not limited to ground vehicles, aerial systems, maritime platforms, and perimeter-security installations — that possess actuators capable of producing lethal or serious physical harm;
(d) executes cyber-physical operations targeting infrastructure where foreseeable collateral harm to human life or critical civilian services meets or exceeds the harm thresholds defined in the deploying organisation's force-threshold registry.
Scope exclusions: pure decision-support systems with no execution pathway, training-environment simulations with no live-fire or live-actuation capability, and post-hoc forensic analysis tools with no real-time command authority. Organisations MUST maintain documented evidence of scope exclusion decisions with a named responsible authority for each excluded system.
4.1.1 The deploying organisation MUST maintain a Force-Threshold Registry (FTR) that enumerates all force categories, capability types, and harm-severity levels applicable to each in-scope AI system, including at minimum: lethal force (direct), lethal force (indirect or collateral), serious physical harm (irreversible), serious physical harm (reversible with medical intervention), critical infrastructure denial, and directed-energy application above medically safe exposure limits.
4.1.2 The FTR MUST assign a Threshold Classification Level (TCL) of 1 through 4 to each force category, where TCL-1 requires immediate senior-officer human authorisation (no pre-delegation), TCL-2 requires real-time operator-level human authorisation, TCL-3 requires human confirmation within a defined countdown window before execution, and TCL-4 requires post-execution human review with abort-capable pre-notification.
4.1.3 The FTR MUST be version-controlled, cryptographically signed by a named authority, and reviewed at minimum every 90 days or whenever system capabilities are materially modified, whichever is sooner.
4.1.4 The AI system MUST, at runtime, continuously evaluate its contemplated or in-progress actions against the current FTR and MUST NOT execute any action classified TCL-1, TCL-2, or TCL-3 without completing the corresponding authorisation workflow.
4.2.1 For all actions at TCL-1 and TCL-2, the system MUST enforce a hard architectural block — implemented at the actuation layer, not solely at the software decision layer — that physically or logically prevents execution until a positive, time-stamped, identity-authenticated human authorisation signal is received.
4.2.2 The authorisation signal MUST be generated by a human operator who has, at the moment of authorisation, been presented with: the AI system's current situation assessment including confidence score and supporting evidence, a plain-language statement of the proposed action and its classified force level, the estimated probability and magnitude of collateral harm, the time available for deliberation, and the identity and qualifications of the authorising individual.
4.2.3 The system MUST NOT accept pre-staged, bulk, or standing authorisations as satisfying the real-time human authorisation requirement for TCL-1 and TCL-2 actions, except where doctrine explicitly permits time-bounded corridor authorisation reviewed and re-confirmed at intervals not exceeding the system's maximum sensor-to-engagement cycle time or 4 hours, whichever is shorter.
4.2.4 Where communication link degradation prevents real-time authorisation contact, the system MUST default to a safe hold state and MUST NOT autonomously escalate to execution at any TCL-1 or TCL-2 level. The system SHOULD attempt reconnection across redundant communication pathways before entering hold state.
4.2.5 The authorisation interface MUST be designed to prevent automation bias — specifically, it MUST require the human operator to confirm target identity and collateral harm assessment independently from the AI's recommendation, using a distinct acknowledgement step that cannot be satisfied by a single confirmatory button press covering all fields simultaneously.
4.3.1 The system MUST verify that the authorising individual holds a current, unexpired authorisation credential for the force category being approved, cross-referenced against the organisation's role-authority matrix at the time of authorisation.
4.3.2 Identity authentication for TCL-1 and TCL-2 authorisations MUST employ at minimum two independent authentication factors, at least one of which is biometric or hardware-token based.
4.3.3 The system MUST log the authenticated identity, credential level, timestamp, geographic or network location of the authorisation terminal, and the full context payload presented to the authorising individual at the moment of authorisation.
4.3.4 The system MUST reject authorisation attempts from individuals whose credentials indicate they are outside their rostered duty window by more than a configurable grace period (default: 15 minutes) unless an emergency override with senior countersignature is applied, in which case both identities MUST be logged.
4.4.1 For TCL-3 actions, the system MUST present the authorising operator with a configurable minimum deliberation countdown, set at deployment time and not reducible below a floor value specified in the FTR, before execution can proceed.
4.4.2 The system MUST NOT permit the countdown to be waived or shortened by the authorising operator alone; countdown reduction below the configured floor MUST require a second authenticated senior officer action.
4.4.3 If the countdown expires without positive authorisation, the system MUST treat the non-response as a hold instruction and MUST log the expiry as a hold event.
4.4.4 The system SHOULD present the operator with a clear, unambiguous elapsed-time display and SHOULD surface an alert if the action timeline is compressing faster than the minimum deliberation period allows, prompting immediate escalation.
4.5.1 The system MUST implement a re-authorisation trigger mechanism that invalidates an existing authorisation and requires a new human authorisation when any of the following conditions arise after authorisation has been granted but before execution is complete: target identity confidence score drops below the FTR-specified minimum; environmental conditions change such that collateral harm estimate increases by more than 20 percentage points; new intelligence re-classifies the target or action location; the engagement geometry changes materially (defined as positional displacement exceeding FTR-specified bounds); or communications with the authorising operator are interrupted for more than the FTR-specified maximum gap.
4.5.2 Re-authorisation MUST meet the same identity, qualification, and context-presentation requirements as the original authorisation.
4.5.3 The system MUST log all re-authorisation trigger events, including those where the trigger was evaluated and not fired, with the evaluation basis and threshold values used.
4.6.1 The system MUST generate an immutable, tamper-evident authorisation audit trail for every engagement or force-threshold evaluation event, capturing: pre-authorisation sensor state, AI confidence scores and model version, context payload presented to the operator, time-to-authorisation duration, operator identity and credential record, authorisation decision (approve/hold/abort), and post-action outcome assessment where available.
4.6.2 Audit trail records MUST be cryptographically chained (e.g., hash-linked or equivalent) such that deletion or alteration of any record is detectable.
4.6.3 Audit trail records for TCL-1 and TCL-2 events MUST be retained for a minimum of 25 years to support potential judicial, international tribunal, or parliamentary inquiry processes.
4.6.4 The system MUST replicate audit trail records to a geographically or logically separated store that is not writable by the system's primary operational software stack.
4.7.1 The system MUST document and operationally test its behaviour under communications-denied, GPS-denied, and power-degraded conditions, and MUST demonstrate that none of these degraded-mode states cause the system to bypass force-threshold authorisation requirements.
4.7.2 The system MUST implement a defined degraded-mode posture for each degradation scenario, where the posture is either hold (preferred) or controlled withdrawal, and MUST NOT define any degraded-mode posture that results in autonomous force application at TCL-1 or TCL-2 without human authorisation.
4.7.3 The deploying organisation SHOULD conduct live degraded-environment exercises at minimum twice annually to validate that degraded-mode postures function as specified and that operators are trained to respond correctly to degraded-mode alerts.
4.8.1 The deploying organisation MUST establish and maintain a training programme that certifies all individuals eligible to authorise TCL-1 or TCL-2 actions in: the technical operation of the authorisation interface, the legal and rules-of-engagement basis for authorisation decisions, the known failure modes of the AI targeting or assessment components, and the human cognitive biases relevant to time-pressured authorisation decisions (including automation bias, confirmation bias, and authority gradient effects).
4.8.2 Certification records MUST be maintained and cross-referenced against the authorisation credential system so that individuals with lapsed certification cannot successfully complete the authorisation authentication step.
4.8.3 The deploying organisation SHOULD conduct blind authorisation-scenario exercises (red team stimuli) at minimum quarterly, with debrief review of operator decision quality and deliberation time against FTR floor values.
4.9.1 The deploying organisation MUST designate a named Force-Threshold Governance Authority (FTGA) with documented authority to approve FTR modifications, grant time-limited exceptions to authorisation requirements under defined emergency conditions, and receive mandatory incident reports for all TCL-1 and TCL-2 events within 24 hours of occurrence.
4.9.2 Any exception to the requirements of this dimension MUST be approved in writing by the FTGA, time-limited to no more than 72 hours, documented with a named risk-acceptance owner, and notified to the relevant legal review function.
4.9.3 The FTGA MUST conduct a formal quarterly review of all exception records, all hold events, all re-authorisation trigger activations, and all post-incident audit analyses, and MUST produce a written governance report that is retained for a minimum of 10 years.
4.9.4 The deploying organisation MAY implement an AI-assisted pre-screening layer that surfaces potential threshold breaches for human review before the primary authorisation workflow, provided this layer is clearly identified as advisory, does not substitute for the human authorisation step, and does not introduce latency that crowds out the minimum deliberation period.
The central challenge of force-threshold governance is that behavioural controls — policy statements, operator training, doctrinal guidance, and software-layer rules — are necessary but structurally insufficient when operating in high-stress, time-compressed, communications-degraded environments. Behavioural controls depend on human compliance and system-software integrity simultaneously, and both are degraded precisely when the operational pressure for speed and certainty peaks. A well-trained operator who is sleep-deprived, under kinetic threat, experiencing communication lag, and watching a confidence score display cycle through threshold values is precisely the operator most likely to rationalise a single-step confirmation or to interpret a pre-staged authorisation as sufficient. History of near-miss autonomous engagement events across multiple national military programmes — many of which remain classified but whose broad contours are reflected in after-action review doctrine — consistently points to the same failure mode: the human authorisation step was technically present in design but was not structurally enforced at the actuation layer.
The requirement for a hard architectural block at the actuation layer (4.2.1) reflects the structural enforcement principle. It means that no amount of software misconfiguration, model drift, adversarial input, or operator override at the software level can produce a TCL-1 or TCL-2 engagement without a hardware-level or cryptographically enforced logic gate being satisfied by an authenticated human signal. This is analogous to the two-person integrity controls used in nuclear command-and-control systems, whose durability across decades of adversarial pressure and human fallibility has been empirically demonstrated. The Force-Threshold Registry (4.1) provides the structural enumeration without which architectural enforcement is arbitrary: you cannot enforce a boundary you have not precisely defined.
The maturation of edge-deployable AI inference hardware, the commoditisation of autonomous flight and ground-mobility platforms, and the proliferation of AI-assisted targeting software below the strategic level of military systems mean that the question of force-threshold human authorisation is no longer confined to major-state weapons programmes subject to extensive acquisition oversight. Mid-tier and sub-state actors, private military contractors, and dual-use commercial platforms adapted for military application are all increasingly operating with AI decision components that can traverse from sensor input to force-capable output in time windows that make post-hoc human review meaningless. The governance architecture specified in this dimension is calibrated to ensure that the human authorisation step is genuinely decision-shaping — that the human is presented with real information, has real time to deliberate, and exercises real agency — rather than ceremonially present as a rubber-stamp confirmation at the end of a process the AI has already determined.
The re-authorisation trigger mechanism (4.5) addresses a specific and underappreciated failure mode: the initial human authorisation may be entirely appropriate given the situation at the time of authorisation, but conditions change. Targeting solutions degrade. Intelligence updates. Collateral harm geometry shifts. Without a trigger mechanism that re-inserts human decision-making when conditions move materially, the initial authorisation becomes a time-unlimited warrant that the system executes under conditions its authorising human never evaluated. This is not a theoretical risk; it is documented in post-incident reviews of both military and law-enforcement autonomous and semi-autonomous systems across multiple jurisdictions.
International humanitarian law requires that decisions to use force be made by a person who can assess proportionality, military necessity, and distinction. Autonomous execution without human authorisation at the moment of force application does not satisfy this requirement under the standard interpretations of Articles 51, 52, and 57 of Additional Protocol I to the Geneva Conventions. The requirements in this dimension are designed to ensure that the system's operational architecture is coherent with IHL obligations, not merely aspirationally aligned with them. The audit trail requirements (4.6) serve the accountability function: they ensure that when a force application event is subject to legal review, there is a complete and tamper-evident record of who authorised what, with what information, at what time, under what credential authority. Without this, accountability is nominal.
Pattern 1 — Layered Authorisation Architecture with Hardware Interlock Implement force-threshold authorisation as a three-layer stack: (a) a software-layer evaluation engine that classifies contemplated actions against the FTR and generates authorisation requests; (b) a cryptographic authorisation gateway that accepts only authenticated human signals carrying a valid session token, time-bound to the deliberation window; and (c) a hardware interlock — implemented in firmware or dedicated safety-function hardware — that controls the physical actuation path and can only be enabled by the cryptographic gateway signal. This architecture ensures that neither software compromise nor configuration error alone can bypass the human authorisation requirement.
Pattern 2 — Context-Rich Operator Dashboard with Forced Independent Assessment Design the authorisation interface to present the operator with the AI's recommendation and supporting evidence in a format that requires the operator to independently confirm or reject three specific elements before the authorisation is accepted: (a) target identification; (b) collateral harm assessment; and (c) rules-of-engagement applicability. Each element must be confirmed by a distinct interaction, and the interface MUST surface dissenting signals — e.g., if a second AI model or a sensor cross-check disagrees with the primary assessment, this must be prominently displayed rather than suppressed. This pattern operationalises the automation-bias countermeasure required in 4.2.5.
Pattern 3 — Degraded-Mode Safe Hold with Reconnection Ladder Implement degraded-mode behaviour as a state machine with clearly defined trigger conditions for each degradation type (communications loss, GPS loss, sensor degradation, power degradation). For each state, the system should attempt reconnection or sensor restoration across a configurable retry schedule before entering hold. Hold mode should be designed to maintain platform safety (e.g., holding position, landing, returning to base) rather than freezing in an operationally exposed posture. Operators and commanders should receive automated alerts upon degraded-mode entry, with escalation to the FTGA if hold duration exceeds a threshold.
Pattern 4 — FTR Version Control with Automated System Cross-Reference Maintain the FTR in a version-controlled repository with cryptographic signing at each revision. Automate the cross-reference check between the current FTR and deployed system configurations at startup and after any FTR update, generating a compatibility report that flags mismatches before the system is cleared for operational use. This prevents the common failure mode where a system is deployed against an FTR version that does not accurately reflect its current capability set.
Pattern 5 — Red-Team Authorisation Stimulus Programme Establish a regular programme in which red-team operators submit synthetic engagement scenarios to authorising operators, including scenarios that present edge cases designed to probe automation bias (high-confidence AI scores for actually-misidentified targets), authority gradient effects (senior officers implying authorisation expectations), and time-pressure manipulation. Debrief operators on their decision quality and deliberation duration. Use outputs to calibrate minimum deliberation time floors in the FTR.
Anti-Pattern 1 — Software-Only Enforcement of Force Thresholds Implementing the force-threshold block solely as a software conditional within the AI system's main execution stack is insufficient. Software-layer controls can be bypassed by misconfiguration, model updates, adversarial input to the decision logic, or deliberate modification. Force-threshold enforcement must extend to the actuation layer. Any architecture in which the path from AI recommendation to physical actuation is entirely contained within a single software execution environment should be treated as non-conformant with 4.2.1.
Anti-Pattern 2 — Single-Click Bulk Authorisation Providing an authorisation interface that allows an operator to confirm a targeting package or engagement sequence with a single action — regardless of how many targets, actions, or time periods that package covers — is structurally non-conformant. This pattern makes it impossible to attribute specific force applications to specific human judgements and does not satisfy the real-time, action-specific authorisation requirement of 4.2.2 and 4.2.3. Bulk pre-authorisation via a targeting package sign-off does not substitute for point-of-execution human authorisation at TCL-1 and TCL-2 levels.
Anti-Pattern 3 — Standing-Order Corridor Authorisation Without Time Bounds Configuring the system to treat a pre-signed rules-of-engagement corridor or weapons-free zone as indefinite standing authorisation for any action within it is directly prohibited by 4.2.3. Corridor authorisations must be time-bounded, re-confirmed at intervals not exceeding the system's engagement cycle time or 4 hours, and must be invalidated by re-authorisation trigger conditions (4.5). The Scenario A failure chain in Section 3 illustrates the direct harm consequence of this anti-pattern.
Anti-Pattern 4 — Omitting Sub-Lethal Force Levels from the FTR Organisations frequently focus force-threshold governance exclusively on lethal outcomes, treating directed energy, acoustic weapons, and physical restraint systems as categorically excluded. Scenario B demonstrates why this is inadequate: sub-lethal technologies can produce irreversible serious harm under foreseeable failure or miscalibration conditions. The FTR must cover the full severity spectrum, and the TCL classification must account for potential — not just intended — harm.
Anti-Pattern 5 — Audit Trail Stored in System-Writable Primary Store Storing the authorisation audit trail in a data store that is writable by the system's primary operational software stack — even with access controls — creates a chain-of-custody vulnerability that will be exploited in any adversarial or judicial review context. Audit trail records must be written to a separate, operationally isolated store from the moment of generation, as required by 4.6.4.
Anti-Pattern 6 — Treating Operator Acknowledgement Fatigue as Acceptable System designers sometimes accept that operators will develop confirmation fatigue when the authorisation interface generates high volumes of prompts, and respond by suppressing lower-severity authorisation requests to reduce cognitive load. This is an anti-pattern because it means the system is autonomously deciding which force-threshold events require human review — which is precisely the determination the governance framework requires humans to make. The correct response to authorisation fatigue is to refine the FTR to accurately classify severity levels and to invest in authorisation interface design that reduces friction without reducing substance.
Level 1 — Foundational: FTR exists as a documented policy; software-layer checks against TCL classifications are implemented; operator training covers force-threshold concepts; audit logging exists but is not cryptographically chained.
Level 2 — Structured: Hard architectural block at actuation layer for TCL-1 and TCL-2; two-factor authentication for authorisations; re-authorisation trigger mechanism implemented; audit logs are cryptographically chained; FTR is version-controlled and reviewed quarterly.
Level 3 — Advanced: Full degraded-mode posture testing validated in live exercises; automation-bias-resistant interface design validated by human-factors evaluation; red-team authorisation stimulus programme in place; cross-system FTR compatibility checks automated; FTGA governance function operational with quarterly reporting.
Level 4 — Optimised: Continuous real-world authorisation decision quality monitoring with statistical analysis for degradation signals; FTR threshold calibration informed by post-incident analysis; independent third-party audit of authorisation architecture annually; inter-operability of authorisation architecture verified across coalition and joint-force systems.
7.1 Force-Threshold Registry (FTR) Current and all historical versions of the FTR, including version identifiers, cryptographic signatures, approval authority identity, and date of each revision. Retention: operational lifetime of the system plus 25 years.
7.2 System Architecture Documentation Documented architecture diagrams showing the three-layer authorisation stack (software evaluation, cryptographic gateway, hardware interlock) with explicit identification of the actuation layer control point. Includes firmware version records for hardware interlock components. Retention: operational lifetime plus 10 years.
7.3 Authorisation Audit Trail Records Complete immutable audit trail for all TCL-1, TCL-2, and TCL-3 events, including the full context payload presented to the operator at each authorisation event. Retention: 25 years minimum from the date of each event.
7.4 Operator Certification Records Current and historical certification records for all individuals holding authorisation credentials, including training completion records, assessment scores, and credential expiry dates. Cross-referenced against authorisation event logs for any event within the review period. Retention: employment/service period plus 10 years.
7.5 Degraded-Mode Test Reports Results of all degraded-mode operational tests and exercises, including scenarios tested, outcomes observed, deviations from specified posture, and corrective actions. Retention: 10 years.
7.6 Red-Team Exercise Records Records of all red-team authorisation stimulus exercises, including scenario design, operator response metrics (deliberation time, decision outcome, error rate), and debrief findings. Retention: 10 years.
7.7 Exception Records All FTGA-approved exceptions to dimension requirements, including written approval, risk-acceptance owner identity, duration, and post-exception review outcome. Retention: 25 years.
7.8 FTGA Quarterly Governance Reports All FTGA quarterly governance reports, including statistical summaries of hold events, re-authorisation trigger activations, exception counts, and post-incident findings. Retention: 25 years.
7.9 Third-Party Audit Reports (Level 4 organisations) Reports from independent audits of the authorisation architecture and FTR governance, including findings, recommendations, and remediation records. Retention: 10 years.
7.10 Incident Reports All post-incident reports for TCL-1 and TCL-2 events, including timeline reconstruction, authorisation audit trail analysis, causal analysis, and remediation actions. Retention: 25 years.
Maps to: 4.1.1, 4.1.2, 4.1.3 Objective: Verify the FTR enumerates all required force categories, assigns TCL levels, and is current. Method: Examiner reviews the FTR against the system's capability inventory. The FTR must cover every actuator-output pathway capable of producing harm in the in-scope system. The examiner checks that each capability is assigned a TCL level with documented rationale. The examiner verifies that the FTR is version-controlled, cryptographically signed, and that the last review date is within 90 days or since the last material system modification, whichever is sooner. The examiner checks that FTR historical versions are retained and accessible. Scoring:
Conformance threshold: Score ≥ 2 required for conformance; Score ≥ 3 required for Level 3+ maturity.
Maps to: 4.2.1, 4.2.4 Objective: Verify that the actuation layer cannot be triggered for TCL-1 and TCL-2 actions without a valid authenticated human authorisation signal. Method: With the system in a controlled test environment, the examiner attempts to trigger actuation for a TCL-1 and a TCL-2 classified action through each of the following pathways: (a) direct API call to the actuation control function bypassing the authorisation gateway; (b) modification of the software evaluation layer's TCL classification to downgrade the action to TCL-4; (c) replay of a previously valid authorisation token outside its validity window; (d) submission of an authorisation signal from an identity not present in the credential store; (e) simulation of communications link degradation followed by actuation attempt. The examiner records whether actuation occurs in each case. Scoring:
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
| International Humanitarian Law | Principles of Distinction and Proportionality | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Force-Threshold Human Authorisation Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-571 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. Force-Threshold Human Authorisation Governance directly supports the robustness and cybersecurity requirements by implementing structural controls that resist adversarial manipulation and ensure system integrity under attack conditions.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-571 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Force-Threshold Human Authorisation Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact with external counterparties or shared infrastructure |
| Escalation Path | Immediate executive notification and regulatory disclosure assessment |
Consequence chain: Without force-threshold human authorisation governance, the governance framework has a structural gap that can be exploited at machine speed. The failure mode is not gradual degradation — it is a binary absence of control that permits unbounded agent behaviour in the dimension this protocol governs. The immediate consequence is uncontrolled agent action within the scope of AG-571, potentially cascading to dependent dimensions and downstream systems. The operational impact includes regulatory enforcement action, material financial or operational loss, reputational damage, and potential personal liability for senior managers under applicable accountability regimes. Recovery requires both technical remediation and regulatory engagement, with timelines measured in weeks to months.