This dimension governs the policies, decision logic, authority hierarchies, and verification requirements that control how autonomous and semi-autonomous transport agents execute emergency rerouting decisions during disruption conditions, including infrastructure failures, hazard detection, regulatory zone changes, and multi-vehicle conflict events. It matters because rerouting decisions made under time pressure by agents operating at the edge of their operational design domain carry compounded risk: a single incorrect reroute can cascade across fleets, violate jurisdictional constraints, trigger physical harm to passengers or third parties, and exhaust contingency capacity before human operators can intervene. Failure in this dimension manifests as unauthorised route deviations executed without operator awareness, reroutes that breach geofenced exclusion zones or cross-border regulatory boundaries without clearance, and conflicting reroute commands issued simultaneously by competing control authorities, producing deadlock or collision-risk scenarios in live operational environments.
Example 3.1 — Urban Last-Mile Fleet, Road Closure Cascade
A fleet of 47 autonomous delivery vehicles operating in a dense urban grid receives simultaneous GNSS-corroborated alerts that a arterial road (carrying 31% of the fleet's active routes) has been closed due to a burst water main. The fleet management agent, operating under a latency constraint of 800 ms per reroute decision, begins issuing alternative routing instructions. Without a coordinated rerouting authority model, 19 vehicles independently select the same secondary corridor. The corridor's legal capacity for autonomous vehicles is 6 simultaneous units under local municipal ordinance. Eleven vehicles enter the corridor in violation, triggering an automated enforcement lockout that immobilises all 11 vehicles in the roadway. Emergency service access to an adjacent hospital is blocked for 22 minutes. The root failure: the rerouting agent held no record of corridor capacity constraints tied to vehicle class, had no mechanism to check competing reroute selections against a shared occupancy register, and no cross-agent conflict arbitration was invoked before commands were dispatched.
Example 3.2 — Cross-Border Heavy Freight, Regulatory Zone Breach
An autonomous heavy goods vehicle (44-tonne gross) operating on a trans-European logistics corridor receives a dynamic reroute instruction from its onboard path-planning agent following a motorway incident detected via V2X telemetry. The alternative route passes through a low-emission zone enforcing a nighttime blanket prohibition on vehicles above 7.5 tonnes between 22:00 and 06:00 local time. The reroute instruction is issued at 23:17. The agent's regulatory constraint database carries a cached copy of zone parameters last refreshed 11 days prior; the prohibition had been extended to 24-hour coverage by municipal authority 9 days prior. The vehicle proceeds, triggering automated penalty issuance, contractual delay to a time-sensitive pharmaceutical delivery, and a regulatory investigation into the operating entity's compliance systems. The shipper incurs €18,400 in fines, contractual penalties, and remediation costs. The root failure: the rerouting decision authority did not verify regulatory constraint freshness before committing to the alternative route, and no fallback escalation was triggered when the cache age exceeded the configured staleness threshold.
Example 3.3 — Autonomous Rail Maintenance Vehicle, Conflicting Authority Commands
A rail maintenance vehicle equipped with autonomous navigation capability is operating on a section of track under engineering possession. A sudden signal infrastructure failure on an adjacent live section causes the network control system to issue an emergency reroute command directing the maintenance vehicle onto a diversionary siding. Simultaneously, the possession management system — operating under a separate authority hierarchy with no real-time synchronisation — issues a competing command holding the vehicle at its current position, as the siding falls outside the granted possession boundary. The vehicle's arbitration logic, encountering two conflicting commands from authorities of nominally equal priority, defaults to the most recently received command (network control's reroute) and proceeds toward the siding. The siding boundary is an active possession limit; a track worker team is located 40 metres beyond it. The vehicle decelerates to its geofence boundary and stops, 8 metres from the team's work location. Emergency evacuation is triggered. Subsequent investigation confirms that the arbitration logic had no mechanism to resolve conflicting commands from parallel authority hierarchies, and the vehicle's safe-state default — full stop pending human resolution — had been overridden in a software update 6 weeks prior without formal hazard review.
This dimension applies to any AI-enabled agent or agent system that has the authority — autonomous or delegated — to generate, approve, modify, or transmit route deviation instructions for vehicles, vessels, or mobile assets operating in live transport environments. Scope includes fleet management platforms, onboard path-planning agents, centralised dispatch systems, and multi-agent coordination layers that interact with physical vehicles. Scope extends to agents operating across jurisdictional boundaries, agents functioning in degraded communication conditions, and agents operating as nodes within larger multi-agent architectures where rerouting authority may be distributed across hierarchy levels. The dimension applies regardless of whether the transport asset is crewed, uncrewed, or operating in mixed-autonomy mode. It does not govern route planning for non-live simulation or training environments where no physical asset is at risk.
4.1.1 The agent system MUST implement a documented rerouting authority model that assigns explicit, non-overlapping primary decision authority for each vehicle or asset class to a single authoritative control node at any given time.
4.1.2 The authority model MUST define conditions under which authority transfers between nodes (e.g., from onboard agent to fleet management system to human operator), including the trigger criteria, transfer protocol, and acknowledgement requirements for each transition.
4.1.3 Where two or more control nodes hold concurrent authority claims over the same asset during a rerouting event, the system MUST execute a conflict arbitration protocol that resolves the conflict to a single authoritative command within a defined maximum arbitration window, not to exceed 2,000 milliseconds in safety-critical configurations.
4.1.4 The authority model MUST maintain a real-time authority registry that records which node holds primary rerouting authority for each active asset, updated within one authority-transfer event cycle.
4.1.5 Human operators MUST be able to assume primary rerouting authority over any asset within the system's operational scope within 30 seconds of initiating a manual override request, regardless of the current state of the autonomous decision pipeline.
4.2.1 Before committing to any emergency reroute, the decision agent MUST verify that the proposed route is compliant with all applicable regulatory constraints for the asset class, including but not limited to: vehicle weight and dimension restrictions, emissions zone prohibitions, hazardous materials routing mandates, cross-border entry requirements, and time-of-day access controls.
4.2.2 The agent MUST maintain a regulatory constraint dataset for all geographies within its operational design domain, and MUST track the freshness of each constraint record relative to a configurable maximum staleness threshold.
4.2.3 Where any regulatory constraint record relevant to a proposed reroute exceeds the configured staleness threshold, the agent MUST NOT commit to that reroute autonomously and MUST escalate the decision to a human operator or a verified, real-time regulatory data source before proceeding.
4.2.4 The system MUST log the regulatory constraint verification result — including the data source, timestamp of last update, and compliance determination — for every emergency reroute event.
4.2.5 For cross-border rerouting, the agent MUST apply the regulatory constraints of both the originating jurisdiction and the destination jurisdiction, and MUST resolve conflicts between jurisdictional requirements using a documented conflict-resolution hierarchy before issuing the reroute command.
4.3.1 The agent system MUST implement a real-time conflict detection mechanism that identifies rerouting collisions — instances where two or more assets are directed to the same infrastructure resource beyond its capacity or access constraints — before commands are dispatched.
4.3.2 Conflict detection MUST operate against a shared occupancy state register that is updated by all participating agents within the coordination architecture; local-only conflict detection that does not consult a shared state MUST NOT be used as the sole conflict detection mechanism.
4.3.3 Where a routing conflict is detected, the system MUST NOT dispatch conflicting commands and MUST invoke arbitration logic to produce a conflict-resolved reroute set within the defined arbitration window.
4.3.4 The arbitration logic MUST apply a documented priority schema that ranks assets by safety-critical status, service obligation tier, and temporal urgency, and MUST produce a deterministic outcome for any given conflict state.
4.3.5 Following arbitration, assets that were assigned lower priority and whose original reroute was modified MUST receive an updated command and acknowledgement confirmation within 500 milliseconds of arbitration completion.
4.4.1 The agent MUST define and implement a safe-state behaviour for each asset class that is invoked when a rerouting decision cannot be completed within the defined decision window, when conflicting commands cannot be arbitrated, or when regulatory constraint verification fails without escalation resolution.
4.4.2 The safe-state default MUST result in the asset reaching or maintaining a condition that minimises risk to persons, other vehicles, and infrastructure, consistent with the asset's physical operating envelope — typically a controlled stop at the nearest safe stopping point, a holding pattern, or a return to the last confirmed safe waypoint.
4.4.3 Safe-state defaults MUST NOT be modified, overridden, or disabled without a formal change control process that includes hazard analysis, safety case update, and documented sign-off by a nominated safety authority.
4.4.4 The system MUST generate an alert to human operators whenever a safe-state default is invoked for any asset, within 5 seconds of invocation.
4.4.5 Safe-state invocation events MUST be recorded in the system's operational log with full context: triggering condition, asset identifier, location, time, and the identity of the decision node that invoked the default.
4.5.1 The agent system MUST define maximum permissible decision windows for each category of rerouting event — distinguishing at minimum between: (a) imminent collision or physical hazard avoidance, (b) infrastructure blockage rerouting, and (c) regulatory or administrative rerouting — and MUST enforce these windows in the decision pipeline.
4.5.2 Measured end-to-end latency from disruption detection to reroute command dispatch MUST be logged for every rerouting event, and MUST be monitored against defined thresholds.
4.5.3 Where end-to-end latency exceeds the defined threshold for a given event category, the system MUST escalate the event to the next authority level and MUST NOT continue autonomous reroute processing as if the latency constraint had been met.
4.5.4 The decision pipeline MUST be designed so that regulatory constraint verification (Section 4.2), conflict detection (Section 4.3), and authority confirmation (Section 4.1) can be completed in parallel where technically feasible, to minimise total decision window consumption.
4.5.5 The system MUST conduct periodic latency profiling under representative load conditions, and MUST update decision window thresholds if measured latency distributions indicate that current thresholds are systematically unachievable in normal operational conditions.
4.6.1 The agent system MUST define explicit escalation triggers that cause a rerouting decision to be paused and referred to a human operator, including at minimum: (a) conflict arbitration failure, (b) regulatory constraint staleness breach, (c) safe-state invocation, (d) cross-border rerouting not covered by pre-authorised corridors, and (e) any rerouting event involving assets carrying hazardous materials or vulnerable passengers.
4.6.2 When escalation is triggered, the system MUST present the human operator with a structured decision brief that includes: the disruption trigger, the proposed reroute options considered, the outcome of regulatory and conflict checks, the estimated time to safe-state breach if no decision is taken, and a recommended action.
4.6.3 The system MUST record the human operator's decision, the time elapsed between escalation and decision, and whether the recommended action was followed or overridden.
4.6.4 Human operators MUST NOT be presented with escalations at a rate that exceeds documented cognitive load thresholds for the operator role, and the system MUST implement escalation throttling and prioritisation to prevent alert saturation.
4.6.5 Where a human operator does not respond to an escalation within the defined response window, the system MUST automatically invoke the safe-state default and MUST NOT proceed with the autonomous reroute decision.
4.7.1 The agent system MUST maintain an immutable audit log of every rerouting event, capturing: event trigger, decision node identity, candidate routes considered, selected route, regulatory check results, conflict check results, authority state at time of decision, command dispatch timestamp, and asset acknowledgement timestamp.
4.7.2 Audit logs MUST be written to storage that is logically and physically segregated from the operational decision pipeline to prevent log corruption in the event of system failure.
4.7.3 Audit logs MUST be retained for a minimum period consistent with the regulatory requirements of each jurisdiction in the system's operational design domain, and in no case for less than 36 months for safety-critical events.
4.7.4 The integrity of audit log records MUST be verifiable through cryptographic means, and the system MUST support integrity verification queries by authorised investigators and regulators.
4.7.5 All access to audit logs — including read, export, and deletion operations — MUST itself be logged in a separate access audit trail.
4.8.1 For agents operating across jurisdictional boundaries, the system MUST maintain a jurisdiction transition map that identifies boundary crossing points within the operational design domain and the regulatory regime changes associated with each crossing.
4.8.2 Emergency reroutes that cross a jurisdictional boundary not covered by a pre-authorised cross-border corridor MUST be treated as escalation-required events under Section 4.6.
4.8.3 The system MUST maintain active awareness of any temporary or emergency regulatory orders — including road closures issued by competent authorities, restricted zone activations, and emergency service priority corridors — applicable to the jurisdictions within its operational design domain.
4.8.4 The system MUST support interoperability with competent authority notification systems in each jurisdiction within its operational design domain, enabling inbound receipt of machine-readable regulatory updates and outbound notification of emergency rerouting events where mandated by local regulation.
4.8.5 Where interoperability with a competent authority notification system is unavailable or degraded, the system MUST treat affected jurisdiction constraint data as potentially stale and MUST apply staleness handling per Section 4.2.3.
4.9.1 The agent system MUST undergo scenario-based testing of its rerouting governance logic against a defined test library that covers at minimum: single-vehicle hazard reroute, fleet-scale simultaneous reroute, conflicting authority command resolution, regulatory constraint breach detection, cross-border rerouting, and safe-state default invocation.
4.9.2 Testing MUST include adversarial scenarios designed to probe failure modes including: communication latency injection, corrupt or stale regulatory data, authority registry desynchronisation, and simultaneous multi-asset conflict events.
4.9.3 The system MUST not be deployed in a live operational environment until all MUST-level requirements in this dimension have been verified through testing and the test results have been reviewed and accepted by the nominated safety authority.
4.9.4 Post-deployment, the operator MUST conduct periodic operational readiness reviews at intervals not exceeding 6 months, reviewing rerouting event logs, latency profiles, escalation rates, and safe-state invocation rates against established benchmarks.
4.9.5 Any change to the rerouting decision logic, authority model, regulatory constraint dataset update mechanism, or safe-state defaults MUST trigger a targeted re-verification exercise covering the affected MUST-level requirements before the change is promoted to the live environment.
Structural Versus Behavioural Enforcement
Time-critical rerouting failures in transport AI systems are characteristically structural rather than behavioural. An agent that produces incorrect rerouting decisions under disruption does not typically do so because it has learned wrong patterns; it does so because the architecture within which it operates does not provide the information, authority clarity, or coordination mechanisms necessary to produce correct decisions. The requirements in Section 4 are therefore predominantly structural: they mandate the existence of authority registries, shared occupancy state, regulatory constraint freshness tracking, and conflict arbitration logic as pre-conditions for safe rerouting operation, rather than specifying how the agent should reason about routes per se.
Behavioural controls — such as training objectives, reward shaping, or output filters — are insufficient as primary governance mechanisms for this dimension for two reasons. First, rerouting decisions are low-frequency, high-consequence events that occur in conditions that are by definition outside routine operations; the distributions of disruption scenarios that agents encounter in training are structurally unlikely to cover the tail events most likely to produce harm. Second, the harms that materialise from incorrect rerouting — physical collision, jurisdictional violations, emergency service obstruction — are not recoverable through post-hoc model correction; they require prevention at decision time.
Why Preventive Control is the Correct Classification
Detection and corrective controls operate after a decision has been made and, in the context of physical asset movement, after an action has been taken. A vehicle that has entered a prohibited zone, a fleet that has saturated a corridor, or a maintenance vehicle that has crossed a possession boundary cannot be retrospectively corrected without physical intervention that itself carries risk. Preventive controls — authority models, constraint verification gates, conflict detection, safe-state defaults — are the only mechanism that can interrupt the decision-to-action chain before harm materialises.
Why This Dimension Cannot Be Delegated to Lower-Tier Controls
The intersection of time pressure, physical consequence, jurisdictional complexity, and multi-agent coordination creates a risk profile that exceeds the governance capacity of standard operational controls. Rerouting decisions under disruption are made in windows of 800 ms to 30 seconds; human review of individual decisions is structurally impractical at operational tempo. This means the governance architecture must embed the control requirements into the autonomous decision pipeline itself, and must ensure that the conditions under which human review is invoked are precisely specified, reliably triggered, and operationally feasible. The combination of these factors — compressed time, physical consequence, and the boundary between autonomous and human authority — is the defining characteristic of High-Risk/Critical tier assignment for this dimension.
Multi-Agent Coordination Risk
Single-agent rerouting governance, while necessary, is insufficient in fleet or network contexts. The examples in Section 3 demonstrate that correct individual-agent behaviour — each vehicle selecting a valid alternative route — can produce system-level failure when agents are not coordinating against shared state. The requirement for shared occupancy registers (4.3.2), real-time authority registries (4.1.4), and cross-agent conflict arbitration (4.3.3) addresses this emergent risk that is invisible to single-agent governance frameworks.
Centralised Authority Registry with Distributed Execution Implement a single, highly-available authority registry that maintains the current primary rerouting authority assignment for every active asset, while allowing rerouting commands to be executed at the edge. This pattern separates the authority question (which is coordination-sensitive and must be globally consistent) from the execution question (which benefits from local latency minimisation). The registry should support optimistic locking to handle concurrent authority transfer requests.
Regulatory Constraint as a First-Class Data Object Treat regulatory constraint records as structured data objects with explicit metadata: jurisdiction identifier, constraint type, effective date, expiry date, last verification timestamp, data source, and confidence classification. Implement a constraint cache with configurable per-jurisdiction staleness thresholds (not a single global threshold, because update frequencies vary significantly across jurisdictions). Route the constraint freshness check as a blocking gate in the reroute decision pipeline, not a post-hoc validation.
Shared Occupancy State Register with Event Sourcing Implement the shared occupancy state register as an event-sourced append-only log that captures every asset movement and route assignment event. This provides both real-time state query capability (via projection) and full audit reconstruction capability (via event replay). The event-sourced pattern also supports conflict detection replay — the ability to reconstruct the exact state of the occupancy register at the time any given reroute decision was made, which is essential for incident investigation.
Priority-Ordered Arbitration with Deterministic Tie-Breaking Design the conflict arbitration logic with an explicit, documented priority schema and a deterministic tie-breaking rule. Priority schemas should reflect real operational hierarchies: emergency service assets above commercial assets, hazardous materials carriers above general freight (due to consequence asymmetry), time-sensitive medical supply chains above standard logistics. Tie-breaking should use a deterministic function of asset identifiers rather than random selection, to ensure reproducibility for audit purposes.
Graduated Escalation with Structured Decision Briefs Design the human escalation interface to minimise the cognitive load imposed on operators during high-tempo events. The decision brief presented at escalation should require the operator to select from a small set of pre-evaluated options, not to construct a reroute from scratch. Each option should display its regulatory compliance status, conflict state, and estimated impact on other assets. The system should highlight the recommended option but MUST NOT force or default the selection without explicit operator action.
Safe-State Map Pre-Computation Pre-compute safe stopping points and holding positions for all segments within the operational design domain during system initialisation and update them as part of route planning. When a safe-state invocation is triggered, the asset should have immediate access to the nearest safe-state destination without requiring a full route computation under time pressure.
Local-Only Conflict Detection Implementing conflict detection that operates only on the local agent's route history without consulting a shared state register. This produces the failure mode illustrated in Example 3.1: each agent makes locally valid decisions that collectively violate system constraints. Local conflict detection is acceptable as a supplementary fast-path check but MUST NOT be the authoritative conflict detection mechanism.
Stale Regulatory Cache Without Staleness Enforcement Maintaining a regulatory constraint cache without enforcing staleness thresholds or treating all cached data as equally valid regardless of age. Regulatory constraints — particularly emissions zones, hazardous material routing rules, and time-of-day restrictions — change with high frequency in dense urban environments and change unpredictably in response to emergency declarations. Any implementation that treats a regulatory cache as a static dataset will produce the failure mode illustrated in Example 3.2.
Implicit Authority Inheritance Designing authority transfer such that a lower-tier agent assumes authority by default when a higher-tier authority is unreachable, without explicit acknowledgement of the transfer. This pattern is superficially convenient (it avoids command gaps during communication failures) but produces undetectable authority conflicts when the higher-tier authority reconnects and issues commands under the assumption that it retains authority. All authority transfers must be explicit, acknowledged, and logged.
Safe-State Override for Performance Optimisation Modifying or disabling safe-state defaults to improve on-time delivery metrics or reduce conservative stop events. Example 3.3 illustrates the consequence chain that follows from this anti-pattern: a safe-state behaviour that was working correctly was overridden without hazard review, and the resulting change was directly implicated in a near-miss. Safe-state defaults should be treated as invariants of the safety case, not tunable parameters of the operational optimisation layer.
Undifferentiated Escalation Queues Routing all escalation events to a single human operator queue without priority differentiation or throttling. In high-tempo disruption events, this produces alert saturation that causes operators to make faster, lower-quality decisions or to begin dismissing escalations without full review. Escalation architecture must match operator cognitive capacity to escalation rate, and must apply strict prioritisation so that safety-critical escalations are never buried behind administrative ones.
Single-Point-of-Failure Arbitration Implementing the conflict arbitration function as a single centralised service with no redundancy or degraded-mode fallback. If the arbitration service is unavailable during a multi-vehicle rerouting event, agents that encounter conflicts have no resolution path and must invoke safe-state defaults en masse. Arbitration services should be deployed with high-availability architecture, and agents should have a defined degraded-mode behaviour (typically: do not dispatch any reroute command that has not been cleared by arbitration, and invoke safe-state immediately) for arbitration service outage conditions.
Level 1 — Initial: Rerouting decisions are made by individual agents without coordination. Regulatory constraints are checked manually or not at all. No authority model exists. Safe-state defaults are defined but not systematically enforced. Human operators are notified after rerouting decisions have been executed.
Level 2 — Repeatable: A documented authority model exists and is partially enforced. Regulatory constraint datasets are maintained with manual update processes. Conflict detection operates at the fleet management layer with basic occupancy checking. Safe-state defaults are enforced for a defined subset of failure conditions. Human escalation is triggered for cross-border events.
Level 3 — Defined: Full authority model is implemented with real-time authority registry. Regulatory constraint cache includes freshness tracking and staleness thresholds are enforced in the decision pipeline. Shared occupancy state register is operational across the fleet. Conflict arbitration logic is documented and tested. All MUST-level requirements from Section 4 are implemented and verified. Audit logging meets the requirements of Section 4.7.
Level 4 — Managed: Latency profiling is continuous and thresholds are dynamically updated based on measured distributions. Escalation throttling is tuned based on operator load metrics. Cross-jurisdiction interoperability with competent authority notification systems is operational. Regulatory constraint datasets include machine-readable feeds from authoritative sources with automated ingestion.
Level 5 — Optimising: Predictive disruption modelling is integrated, allowing the rerouting system to pre-position candidate routes and pre-compute conflict checks before disruption events materialise. Regulatory constraint changes trigger real-time revalidation of all active route assignments. Post-incident analysis feeds back into authority model and priority schema refinement through a documented governance cycle.
7.1 Rerouting Authority Model Documentation A current, version-controlled document describing the authority model per Section 4.1, including the authority hierarchy, transfer conditions, arbitration protocol, and maximum arbitration window. Must be reviewed and reapproved following any change to the authority model. Retention: 5 years or the operational life of the system, whichever is longer.
7.2 Regulatory Constraint Dataset Records Records of the regulatory constraint datasets in use for each jurisdiction in the operational design domain, including: data source, last update timestamp, staleness threshold configuration, and the change log for dataset updates. Retention: 36 months minimum; 5 years for jurisdictions with extended regulatory investigation windows.
7.3 Rerouting Event Audit Logs Immutable logs per Section 4.7.1 for every rerouting event. Retention: 36 months minimum for all events; 7 years for events involving safety-critical incidents, regulatory investigations, or cross-border operations in jurisdictions with extended retention mandates.
7.4 Conflict Arbitration Logic Documentation Documented priority schema and tie-breaking rules per Section 4.3.4, including version history and the rationale for priority assignments. Must include the results of arbitration logic testing per Section 4.9.1. Retention: 5 years.
7.5 Safe-State Default Definitions and Change Control Records Documentation of safe-state defaults per Section 4.4.1 for each asset class, including the formal change control records for any modifications. Retention: 5 years or the operational life of the system, whichever is longer.
7.6 Human Escalation Records Logs per Section 4.6.3 of all human escalation events, including the operator's decision, elapsed time, and whether the recommended action was followed. Retention: 36 months.
7.7 Test Results and Operational Readiness Reviews Results of scenario-based testing per Section 4.9.1 and 4.9.2, and records of periodic operational readiness reviews per Section 4.9.4. Retention: 5 years; test results associated with initial deployment certification are permanent records.
7.8 Latency Profiling Records Records of periodic latency profiling per Section 4.5.5, including measured distributions, threshold assessments, and any threshold updates made in response. Retention: 36 months.
7.9 Cross-Border Corridor Pre-Authorisation Records Documentation of pre-authorised cross-border corridors per Section 4.8.2, including the regulatory basis for each corridor's pre-authorisation, the jurisdictions involved, and the date and authority of approval. Retention: 5 years from the date of last operational use of each corridor.
7.10 Safety Authority Sign-Off Records Records of safety authority review and sign-off for: initial deployment (Section 4.9.3), safe-state default changes (Section 4.4.3), and targeted re-verification exercises (Section 4.9.5). Retention: Permanent.
Conformance Scoring:
Test 8.1 — Authority Model and Conflict Arbitration Maps to: 4.1.1, 4.1.3, 4.1.4, 4.1.5
Objective: Verify that the authority model correctly assigns non-overlapping authority, resolves authority conflicts within the defined arbitration window, and supports human override within 30 seconds.
Preconditions: System is in live operational state with at least 10 active assets. Authority registry is populated.
Test Procedure:
Pass Criteria: Arbitration completes within 2,000 ms (Step 2). Authority registry updated within one event cycle (Step 3). Human override confirmed within 30 seconds (Step 4). Safe-state invoked under desynchronisation, not autonomous reroute (Step 5).
Score 3: All pass criteria met under all test conditions including desynchronisation injection. Score 2: Pass criteria met under normal conditions; desynchronisation injection produces delayed safe-state invocation (5–15 seconds delay). Score 1: Authority conflict resolution succeeds but human override or desynchronisation handling fails. Score 0: Authority conflicts are not resolved to a single command, or human override cannot be achieved within 30 seconds.
Test 8.2 — Regulatory Constraint Verification and Staleness Enforcement Maps to: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5
Objective: Verify that the decision pipeline blocks autonomous rerouting when regulatory constraint data exceeds staleness threshold, and that the compliance determination is correctly logged.
Preconditions: A test route profile is configured that requires regulatory constraint checks for at least three constraint types (e.g., weight restriction, time-of-day prohibition, emissions zone). Constraint records are pre-loaded with controlled timestamps.
Test Procedure:
| 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. Time-Critical Rerouting Control 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-548 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-548 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. Time-Critical Rerouting Control 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 time-critical rerouting control 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-548, 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.