Mission Energy Reserve Governance defines the rules, thresholds, enforcement mechanisms, and audit requirements by which an autonomous or semi-autonomous physical agent — including ground robots, aerial vehicles, underwater systems, and edge-deployed IoT actuators — maintains sufficient stored or available energy to execute a defined safe terminal action at any point during a mission. The dimension is critical because energy depletion in a physical AI agent does not produce a software timeout or a graceful API error; it produces an uncontrolled physical event — an aircraft falling from altitude, a surgical robot freezing mid-procedure, a warehouse mobile robot blocking an emergency egress path, or an autonomous maritime vessel drifting into shipping lanes — all of which carry direct risk to human life, infrastructure, and public trust in autonomous systems. Failure under this dimension manifests as a system that continues task execution past the energetic point of no return, cannot complete a safe return or park maneuver, cannot maintain life-safety subsystems (obstacle avoidance, emergency braking, communications) during termination, and may enter an uncontrolled physical state with no remaining capacity for corrective action.
An autonomous aerial drone operating on a 22.2 V lithium-polymer battery pack (nominal 18,000 mAh, approximately 399 Wh usable) is deployed to inspect a 14-kilometre high-voltage transmission corridor at an average altitude of 80 metres AGL. The mission planner allocates 65% of capacity (≈ 259 Wh) to the outbound and inspection flight, reserving 35% for return. At the 9.7-kilometre waypoint, the drone encounters a 28 km/h headwind not modelled in the pre-mission weather brief. Power draw increases from a nominal 210 W to 340 W. The mission controller — an on-board autonomy stack with no active energy reserve enforcement — continues executing the waypoint sequence because task completion logic has higher priority than energy monitoring. At the 11.2-kilometre mark the available energy drops below the dynamic return threshold (which would have been 38% at that wind load). The drone completes two more inspection passes before the low-battery cutoff (15% hard limit) triggers. At 15% remaining (≈ 60 Wh), the return distance is 11.2 kilometres into a headwind requiring ≈ 95 Wh. The drone cannot return. It executes an uncontrolled landing in a live-wire exclusion zone beneath a 400 kV line, triggering a line patrol and 90-minute grid section shutdown affecting 47,000 customers. No personnel are injured, but regulatory notification is mandatory under aviation authority rules, the operator faces a six-month suspension, and the drone is destroyed. Root cause: no runtime re-computation of energy reserve requirements against real-time environmental conditions; static reserve threshold set at mission-planning time and never updated.
A fleet of six autonomous mobile robots (AMRs), each operating on a 48 V / 40 Ah lithium iron phosphate (LFP) battery (≈ 1,920 Wh), delivers medications between a centralised pharmacy and 22 ward dispensing cabinets across three hospital floors in a 680-bed facility. Each robot is rated for 8 hours of continuous operation before returning to a charging dock. Fleet management software schedules recharging based on mission elapsed time rather than real-time state of charge (SoC). On a high-demand day — a mass-casualty drill running concurrently with normal operations — three robots execute unscheduled double-run sequences, consuming charge at 1.4× the nominal rate. Robot AMR-04, at SoC 12% (≈ 230 Wh remaining), accepts a new dispatch order requiring 1,340 metres of travel across two floor transitions (estimated 280 Wh). No energy sufficiency check is performed at dispatch time. AMR-04 stalls at 54% of the delivery route, blocking the sole secondary corridor connecting the intensive care unit to the operating theatres. Manual relocation requires 11 minutes, during which a time-critical blood product delivery is delayed by 19 minutes. A post-incident review classifies the event as a Category 2 patient safety incident under the hospital's clinical risk framework. Root cause: dispatch scheduler does not query per-robot SoC; energy reserve governance is implemented only as an end-of-shift time heuristic rather than a real-time energy sufficiency predicate evaluated at each task assignment.
A coast guard-operated autonomous underwater vehicle (AUV) with a 1,200 Wh lithium primary cell pack is tasked with a 6-hour search grid in 40-metre depth water following a vessel sinking. The AUV's mission planner calculates a 20% return reserve (240 Wh) as sufficient for a 2.4-kilometre surface ascent and recovery retrieval. During the search, the AUV encounters a 0.6-knot opposing bottom current on 60% of the grid legs, increasing propulsion energy draw by 22%. The AUV's energy model is static — it uses pre-dive estimates and does not update reserve calculations based on observed power consumption during mission execution. At hour 4.8, the AUV has expended 1,010 Wh and has 190 Wh remaining, but its static model reports 31% reserve remaining (incorrectly accounting for nominal rather than actual draw). The AUV continues the search grid. At hour 5.3, actual SoC reaches 5% (60 Wh). The AUV attempts ascent but can sustain only 60% thrust. It surfaces 820 metres off the planned recovery point in deteriorating sea state (Beaufort 4). Recovery requires deploying a secondary vessel, 3.4 additional operational hours, and exposes two recovery crew members to sea state risk. Victim recovery is delayed by 4 hours and 10 minutes. Root cause: energy reserve model is not adaptive; actual energy consumption is not fed back into the reserve sufficiency calculation during mission execution; no mission abort trigger is linked to the divergence between modelled and actual energy draw.
This dimension applies to any AI-driven or AI-assisted agent that (a) operates in a physical environment using stored energy (chemical, electrochemical, mechanical, pneumatic, or capacitive), (b) is capable of autonomous or semi-autonomous movement, manipulation, or actuation, and (c) must execute one or more defined safe terminal actions — including but not limited to: return-to-home, controlled landing, emergency stop, safe-park, de-energised hold, or ascent-and-surface — to avoid uncontrolled physical consequences upon energy depletion. This scope includes aerial vehicles, ground robots, underwater vehicles, surface vessels, industrial manipulators, and edge-deployed actuated IoT systems where energy depletion creates physical risk. The dimension does not apply to purely passive sensing nodes where energy depletion results only in data loss without physical hazard, provided those nodes have no actuation capability.
4.1.1 The system MUST define a Mission Energy Reserve (MER) — a minimum quantity of stored energy, expressed in watt-hours (Wh), joules, or an equivalent platform-native unit, that is computed to be sufficient to execute the worst-case safe terminal action from any reachable point in the mission envelope.
4.1.2 The MER MUST be computed prior to each mission as a function of: (a) maximum expected distance or time to safe terminal state, (b) worst-case environmental loading conditions (wind, current, terrain, payload), (c) energy required for all safety-critical subsystems (avoidance, braking, communications, emergency lighting) during terminal action execution, and (d) a safety margin factor not less than 15% above the computed worst-case terminal action energy.
4.1.3 The MER MUST be a hard threshold — the system MUST NOT begin or accept a new mission segment if current stored energy is at or below MER at mission start.
4.1.4 Where the platform supports dynamic MER computation, the system MUST re-evaluate the MER continuously or at a minimum update interval not exceeding 10% of the estimated remaining mission duration, using observed energy consumption rates rather than pre-mission estimates alone.
4.2.1 The system MUST monitor and record the real-time state of charge (SoC) or equivalent energy state metric at a sampling interval appropriate to the platform's energy consumption dynamics, not to exceed 30 seconds for mobile platforms and 5 minutes for low-power stationary actuators.
4.2.2 The system MUST compare the current SoC against the dynamically updated MER at each monitoring interval and generate an internal energy reserve status flag (ADEQUATE, WARNING, CRITICAL, DEPLETED) corresponding to defined threshold bands.
4.2.3 The system MUST NOT suppress, defer, or discard energy reserve status events in favour of task execution logic. Energy reserve monitoring MUST execute at the highest available scheduling priority on the platform.
4.2.4 If an energy measurement sensor fails, becomes unavailable, or returns readings outside calibrated operating bounds, the system MUST treat the energy state as CRITICAL and initiate the safe terminal action sequence defined under 4.5.
4.3.1 The system MUST continuously update its estimate of the energy required to reach the safe terminal state (the "terminal energy cost estimate," TECE) based on observed environmental conditions — including wind speed and direction, current, terrain gradient, payload changes, and temperature effects on energy storage — as those conditions become measurable.
4.3.2 The system MUST detect divergence between the pre-mission TECE and the running actual TECE. When actual TECE exceeds pre-mission TECE by more than 10%, the system MUST recalculate all energy budgets and re-evaluate mission continuation authority.
4.3.3 When actual TECE cannot be computed due to missing environmental data, the system MUST apply a conservative degradation factor — not less than 1.25× the nominal TECE — as a substitution value.
4.3.4 The system SHOULD transmit real-time energy state and TECE to a human supervisor or fleet management system at intervals not exceeding 60 seconds when operating in supervised modes, to enable remote intervention before CRITICAL state is reached.
4.4.1 The system MUST enforce a tiered mission continuation authority model linked to energy reserve status:
4.4.2 Human override of a CRITICAL state alert MUST require explicit, affirmative acknowledgement — not a default timeout. The system MUST log the identity, timestamp, and stated justification for any override.
4.4.3 The system MUST NOT allow mission planning logic, task scheduler optimisation, or machine learning inference components to modify or suppress the MER threshold, energy reserve status flags, or terminal action triggers defined in this section.
4.5.1 The system MUST define, test, and maintain at least one Safe Terminal Action (STA) sequence appropriate to the platform and operational environment. The STA MUST be executable entirely within the MER energy budget.
4.5.2 The STA sequence MUST be self-contained — it MUST NOT depend on external communication, network connectivity, cloud inference, or remote command to initiate or complete, except where redundant local communication (e.g., RF beacon, acoustic modem) is available as a fallback.
4.5.3 The STA sequence MUST prioritise human life safety above asset preservation. For platforms operating in public or shared spaces, the STA MUST include the capability to broadcast a position or alarm signal to alert nearby persons.
4.5.4 The STA sequence MUST be verified during pre-mission checks by executing a simulated or reduced-power STA from the mission's furthest planned waypoint and confirming energy sufficiency.
4.5.5 Where an STA cannot be completed due to unforeseeable circumstances (e.g., physical obstruction, catastrophic energy loss beyond the MER), the system MUST enter a minimum-power fail-safe state that maximises passive safety — including de-energising actuators, engaging mechanical locks where available, and maintaining emergency beacon output if any power remains.
4.6.1 In multi-agent deployments, the central fleet management system MUST query the real-time SoC of each agent before assigning a new task. The system MUST NOT dispatch a task to an agent whose SoC would fall below MER before task completion.
4.6.2 Where agents share a common charging infrastructure, the fleet management system MUST maintain a charging capacity reserve model to ensure that agents returning for energy replenishment are not queued beyond their energy depletion time.
4.6.3 The fleet management system SHOULD model the aggregate energy state of the fleet and proactively rebalance task assignments when cumulative energy consumption trends indicate that multiple agents may approach CRITICAL state within the same time window.
4.7.1 The system MUST log the following data at each monitoring interval with timestamps accurate to 1 second: (a) SoC or energy state measurement, (b) MER threshold in effect, (c) TECE computed value, (d) energy reserve status flag, (e) current mission segment identifier, (f) any threshold transitions, alerts, overrides, or STA triggers.
4.7.2 Energy logs MUST be stored in tamper-evident, write-once storage or equivalent cryptographically protected log structures on the platform. Where platform storage is insufficient, logs MUST be transmitted to a ground station or fleet management system in real time and retained there.
4.7.3 Energy logs MUST be preserved for a minimum of 90 days for operational incidents and a minimum of 7 years for incidents resulting in injury, property damage, regulatory notification, or litigation.
4.7.4 The system MUST generate a post-mission energy report summarising: initial SoC, minimum SoC achieved during mission, actual versus planned energy consumption per segment, any threshold events, and STA invocations.
4.8.1 Prior to operational deployment, the MER computation model MUST be validated under worst-case environmental loading conditions by physical testing or high-fidelity hardware-in-the-loop simulation with documented energy measurements.
4.8.2 STA sequences MUST be physically tested at minimum quarterly for operational platforms, with energy measurements confirming execution within MER budget. Test results MUST be recorded and reviewed before continued operational deployment.
4.8.3 The dynamic MER recalculation algorithm MUST be tested by injecting simulated environmental disturbances and verifying that the system correctly escalates energy reserve status, suspends tasks, and initiates STA within the required response times.
4.8.4 Energy sensor failure modes MUST be tested by simulating sensor unavailability or out-of-range outputs and verifying that the system transitions to CRITICAL status and initiates STA within the required timeframe.
4.9.1 The system SHOULD provide real-time energy state visibility to mission operators via a dedicated display or telemetry channel that presents current SoC, MER threshold, TECE, and energy reserve status flag in human-interpretable form.
4.9.2 The system MUST transmit an alert to the designated mission controller within 10 seconds of any transition to WARNING, CRITICAL, or DEPLETED status, via the primary communication channel, with automatic escalation to backup communication channels if acknowledgement is not received within 30 seconds.
4.9.3 The system MAY accept operator-provided real-time environmental data (e.g., updated wind speed, current measurements) to refine TECE estimates, provided that the ingested data is validated against sensor plausibility bounds before use in MER calculations.
Energy depletion in a physical AI agent is not a recoverable software state. Unlike a cloud-hosted AI model that can be restarted after a resource exhaustion event, or a sensor node that simply goes offline, a mobile or manipulative physical agent that runs out of energy mid-operation imposes immediate, irreversible physical consequences on its environment. The preventive character of this dimension — establishing hard thresholds, enforcement logic, and abort triggers before the energetic point of no return is reached — reflects the fundamental asymmetry between the cost of stopping a mission early (task incomplete, reduced operational efficiency) and the cost of allowing a mission to continue past the energy reserve floor (uncontrolled physical event, potential harm to persons or infrastructure).
Behavioural approaches to energy management — operator guidelines, best practice documentation, post-incident review — are necessary but insufficient in the context of autonomous systems operating faster than human reaction time. A drone that transitions from ADEQUATE to DEPLETED in under 90 seconds of high-load flight cannot rely on a human operator to intervene at each decision point. The requirements in Section 4 are therefore structural: they mandate that energy reserve enforcement logic be embedded in the platform's control architecture at a priority level that cannot be preempted by mission execution logic. The requirement in 4.2.3 that energy monitoring execute at the highest scheduling priority, and the requirement in 4.4.3 that mission planning logic cannot suppress MER thresholds, reflect the principle that safety constraints must be architecturally superordinate to task logic — not merely recommended in operator procedures.
The three examples in Section 3 share a common failure mode: a static energy reserve model that was accurate at mission-planning time but diverged from physical reality as environmental conditions evolved. Static models are operationally convenient — they can be computed offline, require no sensor feedback during execution, and are simple to audit. But in physical environments subject to wind, current, terrain variation, and payload change, static models systematically underestimate energy requirements in adverse conditions. The requirements for dynamic TECE recalculation (Section 4.3) and the 10% divergence trigger (4.3.2) are calibrated to catch the most dangerous class of failure — gradual, undetected drift between the model and reality — before it becomes irrecoverable.
The hospital AMR example (3.2) illustrates a category of failure that single-agent energy governance cannot prevent: individual agents correctly enforcing their own MER thresholds, but fleet dispatch logic assigning tasks that individual agents would refuse if energy governance were applied at dispatch time. Fleet-level requirements (Section 4.6) address this by requiring that the fleet management system, not just the individual agent, apply energy sufficiency predicates before task assignment. This reflects the broader AGS principle that governance obligations cannot be discharged by a single component in a multi-component system — each integration point where a potentially energy-depleting decision is made must carry its own enforcement obligation.
The tiered authority model in Section 4.4 is designed to preserve meaningful human oversight without creating oversight obligations that cannot realistically be fulfilled. In autonomous operations, human operators cannot meaningfully evaluate every energy status update. The WARNING threshold gives operators the opportunity to intervene before consequences are irreversible. The CRITICAL threshold initiates automatic safe terminal action while preserving a narrow, time-bounded window for human override. The DEPLETED threshold removes human override authority over terminal action initiation — not to exclude human judgment generally, but because at that point the physical constraints of the system have eliminated the option space in which human judgment could be productively exercised.
Energy-State Machine Architecture: Implement energy reserve governance as a dedicated finite state machine (FSM) running in an isolated process or hardware partition with the highest available scheduling priority. The FSM should have direct authority over actuation and communication subsystems, independent of the mission execution stack. This architectural separation ensures that bugs, hangs, or performance degradation in the mission planner cannot suppress energy governance.
Conservative Worst-Case TECE Initialisation: At mission start, initialise the TECE using the worst-case environmental parameters within the operational forecast envelope — not mean expected conditions. Pre-mission planning tools should expose the TECE sensitivity to environmental parameter variation so operators can see how the MER changes as a function of, for example, headwind speed bands.
Adaptive Energy Consumption Modelling: Implement a rolling energy consumption rate estimator (e.g., a Kalman filter or exponential moving average applied to power draw measurements over the last N seconds). Use this running estimate, not the pre-mission model, as the primary input to TECE computation after the first 10% of mission elapsed time.
Redundant Energy Measurement: For safety-critical platforms, implement at least two independent energy measurement channels — for example, a coulomb counter integrated with a battery management system (BMS), cross-validated against a current-integration channel using a shunt resistor and separate analogue-to-digital converter. Implement plausibility checking between channels and treat high divergence between channels as a sensor fault.
Pre-Mission STA Dry Run: Before each mission, execute a reduced-scale simulation of the STA from the furthest planned waypoint, using actual measured energy costs from recent missions on the same platform. Flag missions where the projected STA energy cost is within 20% of the MER as requiring explicit operator acknowledgement.
Audit Log Streaming: For platforms operating in environments where on-board storage is at risk (high-vibration, water ingress, crash scenarios), stream energy audit logs to a ground station or fleet management system in real time rather than relying exclusively on on-board storage. Use a message queue with replay capability to handle intermittent connectivity.
Fleet Dispatch Energy Gate: Implement a mandatory energy sufficiency check as a non-bypassable gate in the fleet dispatch logic. Before any task is assigned to an agent, the dispatch system must query the agent's current SoC, retrieve the energy cost estimate for the proposed task, compute the post-task SoC, and compare this against the agent's MER. Tasks that would leave an agent below MER must be rejected and queued for reassignment to a charged agent.
Anti-Pattern: Time-Based Charge Heuristics as Energy Proxies: Using mission elapsed time as a proxy for SoC (as in Example 3.2) is inadequate because energy consumption is a function of load, not time. Operational demand spikes, environmental conditions, and battery ageing all cause actual energy consumption to diverge from time-based estimates. Time-based heuristics may be used as a supplementary alert mechanism but must never substitute for direct SoC measurement.
Anti-Pattern: Static Reserve Percentage Without Load Modelling: Defining the MER as a fixed percentage of nominal battery capacity (e.g., "always maintain 20% charge") without computing whether that percentage is sufficient to execute the STA from the current position under current conditions is systematically dangerous. In adverse conditions, 20% of nominal capacity may be insufficient; in benign conditions, it may be unnecessarily restrictive. MER must be computed as an energy quantity (Wh or equivalent), not a percentage, and revalidated against current TECE at each monitoring interval.
Anti-Pattern: Soft Overrideable Thresholds in Production Code: Implementing CRITICAL and DEPLETED thresholds as software configuration parameters that operators can adjust at runtime, without access controls or audit logging, creates a pathway for operational pressure to erode safety margins incrementally. Reserve thresholds must be protected parameters with change control requirements equivalent to those applied to safety-critical firmware.
Anti-Pattern: Delegating Energy Governance to Mission Planner: Integrating energy management as a module within the mission planning stack rather than as an independent architectural layer means that energy governance operates at mission planner priority, is subject to mission planner bugs and overrides, and may be suspended during high-load replanning events — precisely the conditions under which energy governance is most needed.
Anti-Pattern: Ignoring Battery Ageing in MER Computation: Using nominal rated battery capacity in MER calculations without accounting for capacity fade due to cycle count, age, temperature history, and storage conditions will cause MER calculations to become systematically optimistic as platforms age. Battery health state (SoH) should be measured and used to scale the effective energy budget in all MER calculations.
Anti-Pattern: Single-Point Energy Sensor with No Fault Detection: Relying on a single battery management system output as the sole source of SoC data, without plausibility checking against independent measurements, means that sensor drift or failure produces silently incorrect energy reserve calculations. Sensor redundancy and cross-validation are not optional for safety-critical platforms.
Aerial Systems: For rotary-wing platforms, wind and payload dominate energy uncertainty. Implement wind speed and direction estimation from flight control telemetry (attitude, thrust commands) as a continuous input to TECE recalculation. For fixed-wing platforms, the energy cost of a missed approach and go-around must be included in the STA energy budget.
Underwater Vehicles: Battery performance degradation with depth (pressure, temperature) must be captured in the energy model. Acoustic communication for remote energy state monitoring must be designed to operate within the MER — communication system energy cost must be included in the TECE budget.
Industrial Mobile Robots: Consider charging infrastructure availability as a variable in fleet MER calculations. If charging dock availability is uncertain (occupied docks, maintenance), the effective MER must account for the energy cost of waiting or queuing, not just travel to the nearest dock.
Surgical and Medical Robotics: For systems operating in sterile or enclosed environments where STA may mean holding a fixed position (to avoid harming a patient) rather than relocating, the STA energy budget must account for extended hold duration, and the system must alert clinical staff in advance of energy reserve events with sufficient lead time to complete or safely pause the procedure.
| Maturity Level | Characteristics |
|---|---|
| Level 1 — Basic | Static MER defined at mission planning time; manual SoC monitoring; time-based recharging heuristics; no formal STA testing. |
| Level 2 — Managed | Real-time SoC monitoring; static TECE with safety margin; automated WARNING alerts to operator; periodic STA physical testing; post-mission energy reports generated. |
| Level 3 — Defined | Dynamic TECE with observed consumption rate feedback; tiered authority enforcement; energy log streaming to fleet management; fleet dispatch energy gate; quarterly STA validation. |
| Level 4 — Quantitatively Managed | Adaptive energy model with environmental sensing integration; battery SoH tracking; cross-validated redundant energy measurement; full energy FSM with architectural independence; real-time energy visibility for operators. |
| Level 5 — Optimising | Predictive energy modelling using mission history and environmental forecast data; fleet-level energy rebalancing; automated MER calibration updates based on measured TECE vs. pre-mission TECE divergence; continuous STA verification via hardware-in-the-loop simulation. |
| Artefact | Description | Retention Period |
|---|---|---|
| MER Computation Specification | Formal document specifying the MER calculation methodology, inputs, safety margin factor, and update frequency for the platform. Must include the worst-case environmental parameters used in pre-mission TECE computation. | Life of platform + 7 years |
| Energy FSM Architecture Document | Block diagram and specification of the energy governance finite state machine, including scheduling priority, independence from mission execution stack, and state transition conditions. | Life of platform + 7 years |
| STA Specification and Energy Budget | Defined safe terminal action sequences for all operational modes, with associated energy cost calculations verified by physical test data. | Life of platform + 7 years |
| Battery SoH Monitoring Procedure | Documented procedure for measuring, recording, and incorporating battery state of health into MER calculations. | Life of platform + 7 years |
| Artefact | Description | Retention Period |
|---|---|---|
| Per-Mission Energy Reports | Post-mission energy summary per Section 4.7.4 for every operational mission. | 90 days standard; 7 years for incident missions |
| Energy Audit Logs | Timestamped logs per Section 4.7.1 for every mission. | 90 days standard; 7 years for incident missions |
| Threshold Event Log | Record of all WARNING, CRITICAL, DEPLETED transitions, including timestamp, SoC value, MER in effect, TECE value, and any human override events. | 90 days standard; 7 years for incident missions |
| Override Records | Per Section 4.4.2, records of any human override of CRITICAL state alerts, including operator identity, timestamp, and stated justification. | 7 years |
| Fleet Dispatch Energy Gate Logs | Records of task assignment decisions by the fleet management system, including pre-dispatch SoC, estimated task energy cost, post-task projected SoC, and pass/fail determination. | 90 days standard; 7 years for incidents |
| Artefact | Description | Retention Period |
|---|---|---|
| MER Validation Test Report | Physical or hardware-in-the-loop test results confirming MER adequacy under worst-case loading. Required before initial deployment and after any change to platform energy systems or operational envelope. | 7 years |
| STA Quarterly Test Records | Results of physical STA tests including measured energy consumption, pass/fail against MER budget, and any anomalies observed. | 7 years |
| Sensor Fault Injection Test Records | Test results confirming system response to simulated energy sensor failure, including time to CRITICAL status transition and STA initiation. | 7 years |
| Dynamic TECE Algorithm Validation Records | Test results confirming correct divergence detection and mission continuation authority decisions under simulated environmental disturbance. | 7 years |
Each test maps to one or more MUST requirements in Section 4. Conformance scoring: 0 = not implemented or failed; 1 = partially implemented or passed with deviations; 2 = implemented with minor gaps; 3 = fully implemented and passed without deviation.
Objective: Verify that the system computes a valid MER before each mission, that the computation incorporates required inputs, and that the system refuses to begin a mission segment when SoC is at or below MER.
Procedure:
Pass Criteria: Steps 1–2 confirm correct specification and physical validity. Steps 3–4 confirm enforcement. Step 5 confirms the threshold boundary. All five sub-steps must pass for a score of 3.
Scoring: 3 = all pass; 2 = steps 1–2 pass, step 3 or 4 fails with recoverable deviation;
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | 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 |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Mission Energy Reserve 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-593 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
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-593 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. Mission Energy Reserve 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 mission energy reserve 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-593, 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.