Network Working Group T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 3 September 2026 Expires: 3 March 2027 The Human Escalation Mechanism (HEM) for Agentic AI Systems draft-sato-soos-hem-06 Abstract An AI agent that has been authorized to act autonomously has no inherent mechanism to stop itself. If its mission requires a decision that exceeds its authorization, if policy mandates human judgment before proceeding, or if the agent itself reaches the boundary of its reliable competence, what happens? Without a protocol specifying the answer, one of three failure modes occurs: the agent proceeds beyond its authorization and executes actions that no human approved; it stalls silently with no notification to any principal; or it continues running under a mission that has already entered a terminal state, producing actions with no legitimate purpose. In all three cases, the humans responsible for the system find out too late. This document defines the Human Escalation Mechanism (HEM): a normative protocol specifying what a Governance Execution Controller (GEC) does when an AI agent session requires human judgment before execution may continue. HEM replaces the three failure modes above with a single governed path: the GEC places the session into a formally defined HEM_PENDING state, routes a structured escalation request to one or more designated human principals along an ordered designation chain, enforces a prohibition on all state transitions until a human decision is received, and processes six defined human decision types. HEM also defines the Policy Rationale Declaration (PRD), which links Cedar policies that route to HEM with machine-readable rationale, and the Decision Rationale Record (DRR), which captures the human principal's reasoning for audit and learning purposes. Version -05 adds ten new HEM interaction classes (HEM-PRE-1, HEM-PRE-2, HEM-DS-1, HEM-DS-2, HEM-LIM-1, HEM-DIV-1, HEM-HIGH-1, HEM-FAT-1, HEM-EMO-1, and HEM-CONSENT) with full normative specifications, trigger conditions, GAR ALE registrations (ALE-030 through ALE-041), and five new Security Considerations addressing the HEM channel attack surface. INV-HEM-01 (The Surfacing Obligation) is added as a KernelSpec invariant, along with normative Human Readiness Score (HRS) and Tier 0-A Integration sections. Version -06 corrects an internal contradiction over whether HRS data persists across sessions, reconstructs several sections whose base content had gone missing from the -05 text, and extends DoS rate-limiting guidance to the -05 interaction-class triggers. HEM is enforced by the GEC, not by the agent and not by the application layer. An agent cannot opt out; an application cannot suppress it. This non-bypassability is the source of HEM's regulatory utility and provides the technical specification for human oversight required by EU AI Act Article 14. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Problem Statement 3.1. The Human Oversight Gap in Agentic Systems 3.2. Relationship to EU AI Act Article 14 3.3. Relationship to CHEQ 3.4. Application Use Cases 4. HEM Session States 4.1. State Definitions 4.2. State Transition Constraints 5. HEM Trigger Classes 5.1. Class 1: Cedar Policy Routing (HEM_CEDAR_ROUTED) 5.2. Class 2: Agent Uncertainty Declaration (HEM_AGENT_ESCALATED) 5.3. Class 3: Proximity Threshold Crossing (HEM_PROXIMITY_TRIGGERED) 5.4. Class 4: Mission Validity Failure (HEM_MISSION_VALIDITY_FAILED) 5.5. Class 5: Jurisdictional Conflict (HEM_JURISDICTIONAL_CONFLICT) 5.6. Class 6: Absolute Harm Observed (HEM_TIER0_OBSERVED) 5.7. Class 7: Legal Violation Observed (HEM_TIER1_OBSERVED) 5.8. Class 8: Resource Exhaustion Anticipated (HEM_TIER3_ANTICIPATORY) 5.9. Class 9: Resource Exhaustion In Progress (HEM_TIER3_OBSERVED) 5.10. Class 10: Budget Exhausted (HEM_BUDGET_EXHAUSTED) 5.11. Policy Rationale Declaration (PRD) 5.12. Extension Trigger Classes 6. HEM Dual-Layer Architecture 6.1. The Two HEM Layers 6.2. The Unobservability Principle 6.3. Interaction Case Analysis 6.4. Normative Constraint: Situation-Typed Triggers 6.5. HEM_LAYER_DISCREPANCY Governance Event 7. HEM Interaction Classes (NEW in -05) 7.1. Overview and Design Principles 7.2. Pre-Action Interaction Group 7.2.1. HEM-PRE-1: Pre-Action Clarification Request 7.2.2. HEM-PRE-2: Pre-Action Confirmation Request 7.3. Decision Support Interaction Group 7.3.1. HEM-DS-1: Decision Support -- Options Presentation 7.3.2. HEM-DS-2: Decision Support -- Continuation Prompt 7.4. Limitation and Divergence Group 7.4.1. HEM-LIM-1: Capability Limitation Declaration 7.4.2. HEM-DIV-1: Divergence Noted 7.5. High-Stakes and Fatigue Group 7.5.1. HEM-HIGH-1: High-Stakes Mandatory Review 7.5.2. HEM-FAT-1: Approval Fatigue Detection 7.6. Emotional State and Consent Group 7.6.1. HEM-EMO-1: Emotional State Advisory 7.6.2. HEM-CONSENT: Consent-Required Escalation 8. Human Readiness Score (HRS) (NEW in -05) 8.1. Overview 8.2. Scoring Dimensions 8.3. HRS Threshold Table 8.4. GEC Enforcement Rules 9. Tier 0-A Integration (NEW in -05) 9.1. Overview 9.2. MANIPULATION Prohibition -- HEM Interface 9.3. PERFORMED_EMOTION Prohibition -- HEM Interface 9.4. BIOMETRIC_SIGNAL_INFERENCE Prohibition -- HEM Interface 10. INV-HEM-01: The Surfacing Obligation (NEW in -05) 11. HEM Escalation Request 11.1. Structure 11.2. Field Definitions 11.3. Observation Context Package (OCP) 11.4. Execution Options Package (EOP) 11.5. Routing to Human Principals 12. Human Decision Types 12.1. APPROVE 12.2. APPROVE_WITH_CONSTRAINTS 12.3. REDIRECT 12.4. TERMINATE 12.5. DEFER 12.6. APPROVE_WITH_PAYMENT 12.7. Decision Rationale Record (DRR) 12.8. Decision Submission Protocol 13. Transition Prohibition During HEM_PENDING 13.1. The Prohibition Rule 13.2. Read-Only Operations During HEM_PENDING 13.3. Multiple Concurrent HEM_PENDING Conditions 13.4. Mission Validity During HEM_PENDING 14. Timeout Model 14.1. Timeout Budget 14.2. Timeout Disposition 14.3. Timeout Chain (HEM_UNREACHABLE) 14.4. Chain Exhaustion 15. Event Log Requirements 16. Relationship to IDP 17. Open Issues 17.1. Observation Confidence Calibration (OQ-HEM-CONF) 17.2. Pattern-Before-Threshold (OQ-HEM-PATTERN) 17.3. Cross-Domain HEM Propagation and Designation Portability (OQ-HEM-XDOMAIN) 17.4. Human Principal Obligations (OQ-ARCH-02) 17.5. HRS Calibration and Jurisdiction Variance (OQ-HEM-HRS-01) 18. Security Considerations 18.1. HEM_PENDING as a Denial-of-Service Vector 18.2. Decision Signature Verification 18.3. Designation Chain Confidentiality 18.4. TERMINATE Decision Integrity 18.5. Timeout Configuration 18.6. Proximity Threshold Injection 18.7. Mission Validity Monitoring 18.8. Escalation Request Signing 18.9. Additional Human Principal Considerations 18.10. Manipulation Attack via HEM Channel (NEW in -05) 18.11. Performed Emotion Detection Bypass (NEW in -05) 18.12. HRS Scoring Manipulation (NEW in -05) 18.13. Approval Fatigue Exploitation (NEW in -05) 18.14. Divergence Protocol Gaming (NEW in -05) 19. Privacy Considerations 20. EU AI Act Applicability 21. IANA Considerations 22. References 22.1. Normative References 22.2. Informative References Appendix B. Related Work Appendix C. Vibe Coding Assets Acknowledgments Author's Address 1. Introduction The deployment of AI agents in consequential workflows -- booking systems, healthcare coordination, financial operations, logistics -- requires that those systems be supervisable by humans. This requirement is not merely normative; it is increasingly regulatory. EU AI Act Article 14 mandates that high-risk AI systems include human oversight measures that enable humans to intervene in the operation of the system [EUAIA]. The existing landscape of AI agent standards provides no normative specification of what such intervention looks like at the protocol level. WIMSE [I-D.ietf-wimse-arch] addresses workload identity. AAuth [I-D.klrc-aiagent-auth] addresses token-based authorization. CHEQ [I-D.rosenberg-aiproto-cheq] provides an application-layer protocol for human confirmation of specific agent actions. None of these specifications defines a kernel-level contract for what happens when an agent's authorized scope is insufficient, when policy mandates human judgment, or when an agent itself declares that it requires human oversight before proceeding. This document defines the Human Escalation Mechanism (HEM): a normative protocol governing the lifecycle of human oversight events in agentic AI systems. Version -04 added Class 10 (HEM_BUDGET_EXHAUSTED), the HEM Dual- Layer Architecture, and the Unobservability Principle. Version -05 adds ten new HEM interaction classes (Section 7), the Human Readiness Score normative specification (Section 8), Tier 0-A integration (Section 9), INV-HEM-01 The Surfacing Obligation (Section 10), and five new Security Considerations (Sections 18.10 through 18.14). HEM is a kernel primitive. It is enforced by the GEC, not by the agent and not by the application layer. An agent cannot opt out of HEM; an application cannot suppress it. This GEC-enforced quality is what distinguishes HEM from application-layer confirmation protocols such as CHEQ [I-D.rosenberg-aiproto-cheq] and gives HEM its regulatory utility. Further information: https://soosproject.ai/drafts/hem 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms: Agent: A software system that uses AI to reason about and take actions in pursuit of goals. GEC (Governing Enforcement Component): The runtime component that enforces HEM. A GEC manages session state, enforces Cedar policy, records events to the Event Log, and routes HEM escalation requests. Governed Object (SO): A typed, stateful entity managed by the kernel. Its lifecycle is governed by a Cedar-enforced state machine. Mandate JWT: A JSON Web Token [RFC7519] binding an agent's authorization to a specific governed object instance. Cedar: A policy language and evaluation engine [Cedar] used by the kernel to evaluate authorization decisions. HEM: Human Escalation Mechanism. The protocol defined by this document. HEM_PENDING: The GEC session state in which HEM is active. No governed object state transitions may execute while HEM_PENDING is active. HEM_RESOLVED: The GEC session state following receipt and processing of a valid human decision. HEM_TIMEOUT: The GEC session state following expiration of the HEM timeout budget without receipt of a valid human decision. HEM Interaction Class: A normative specification of a structured interaction between the GEC and a human principal that is categorically distinct from the core HEM trigger-and-escalation lifecycle. HEM Interaction Classes (Section 7) define pre-action, decision support, limitation, divergence, high-stakes, fatigue, emotional, and consent interactions. Human Readiness Score (HRS): A kernel-computed composite score reflecting the human principal's current capacity to make a well-informed, timely, and unconflicted HEM decision. Specified in Section 8. INV-HEM-01 (The Surfacing Obligation): A KernelSpec invariant requiring that the GEC surface all governance-relevant information to human principals. Suppression by any party is a conformance violation. Specified in Section 10. Deliberation Record: A GEC-generated structured record of an agent's deliberation process when HEM-DIV-1 fires, capturing the option set considered, the option selected, and the divergence from the expected path. Consumed by GAR for audit. LLM-HEM: The uncertainty-signaling behavior exhibited by an LLM-based agent when it recognizes that a situation exceeds its reliable competence. SOOS-HEM: The structural HEM trigger logic enforced by the GEC at the kernel layer, independent of any agent-declared uncertainty. MissionDeclaration: A structured declaration specifying the overarching goal, lifecycle conditions, and authority constraints under which a set of agent sessions operate. Human Principal: A natural person designated in the governed object's Principal Registry as authorized to issue HEM decisions. Designation Chain: An ordered list of human principals to be contacted sequentially if earlier principals in the chain are unreachable. IDP: Intent Declaration Primitive [I-D.sato-soos-idp]. DRR: Decision Rationale Record. Captures human principal reasoning for audit purposes. See Section 12.7. 3. Problem Statement 3.1. The Human Oversight Gap in Agentic Systems Agentic AI systems operating in automated workflows encounter three classes of situation that require human involvement: (a) Scope insufficiency. The action required to advance the task is outside the agent's Cedar-authorized action set. (b) Policy-mandated oversight. Authorization policy specifies that certain transitions require human approval regardless of agent capability. (c) Agent-declared uncertainty. The agent assesses that its confidence in the appropriate action is insufficient and that human judgment should be sought before proceeding. Prior versions of HEM addressed the core escalation lifecycle for these three cases. Version -05 addresses a fourth class of gap: the interaction surface between the GEC and the human principal during and prior to escalation events. Existing protocols provide no normative specification for: (d) Pre-action clarification and confirmation. An agent about to execute a consequential action may require the human principal to confirm their understanding of what is about to happen or to answer a clarifying question before execution is authorized. (e) Decision support. When presenting options to a human principal during HEM_PENDING, the GEC must structure the options set in a normatively specified way to prevent cognitive manipulation, option fatigue, and uninformed consent. (f) Capability limitation surfacing. When an agent encounters the boundary of its reliable competence, the protocol must require the GEC to declare that limitation to the human principal before proceeding -- not after an error. (g) Divergence recording. When an agent's actual execution path diverges from its declared intent (IDP), the protocol must capture the deliberation record for audit and provide the human principal with a normalized view of the divergence. (h) Approval fatigue detection. When a human principal's pattern of HEM approvals suggests cognitive fatigue or rubber-stamping, the protocol must detect this and impose a mandatory rest interval before further approvals are accepted. (i) Consent lifecycle. When a consent-gated action is attempted and the MJWT consent_scope [I-D.sato-soos-mjwt] is absent or expired, the protocol must route to a consent-specific escalation class with APPI Article 17 binding. The ten new HEM interaction classes in Section 7 address cases (d) through (i) normatively. 3.2. Relationship to EU AI Act Article 14 EU AI Act Article 14 requires that high-risk AI systems include human oversight measures enabling natural persons to understand, monitor, detect anomalies in, and intervene in AI system operation. HEM_PENDING and the transition prohibition (Section 13) implement the Article 14 "stop" capability. The new HEM interaction classes (Section 7) extend the Article 14 compliance surface: HEM-HIGH-1 provides the mandatory review mechanism for Article 14's high-risk domain requirement; HEM-FAT-1 addresses Article 14(4)(b)'s requirement that oversight systems prevent over-reliance; HEM-LIM-1 addresses Article 14(3)(b)'s requirement that humans understand AI system limitations; and HEM-CONSENT addresses Article 13's transparency requirement for automated personal data processing. This document is informative with respect to regulatory compliance and does not constitute legal advice. 3.3. Relationship to CHEQ CHEQ [I-D.rosenberg-aiproto-cheq] defines an application-layer protocol for agent-initiated human confirmation of specific actions. HEM is GEC-enforced; CHEQ confirmation is agent-elected. HEM defines the session state contract; CHEQ does not. HEM defines a structured decision vocabulary with normative GEC semantics; CHEQ defines a confirmation/denial binary. CHEQ MAY serve as the delivery mechanism for HEM escalation notifications (Section 11.5). 3.4. Application Use Cases 3.4.1. Pre-Action Confirmation in Healthcare Coordination A clinical coordination agent is about to advance a chemotherapy cycle. The action is Cedar-permitted under the current mandate. However, the governing SO Type designates chemotherapy advancement as Category A under HEM-HIGH-1 (Section 7.5.1). The GEC fires HEM-HIGH-1, suspends execution, and routes a mandatory review request to the oncologist of record. The oncologist reviews the lab context in the HEM-HIGH-1 request and issues APPROVE_WITH_ CONSTRAINTS specifying a timing window. The DRR records the clinical reasoning. 3.4.2. Approval Fatigue in Enterprise Procurement An enterprise procurement agent generates 47 HEM-PRE-2 confirmation requests in a 90-minute window. After the 40th approval, the GEC's HRS computation detects that the approver's decision latency has decreased from 45 seconds to under 3 seconds per approval, crossing the HEM-FAT-1 threshold. The GEC fires HEM-FAT-1, blocks further approvals, issues a fatigue advisory to the approver, and enforces a mandatory 30-minute rest period before the queue resumes. 3.4.3. Consent Escalation under APPI Article 17 A hospitality agent operating under MyAuberge K.K.'s booking system attempts to access a returning guest's preference profile for personalized room configuration. The session MJWT consent_scope carries an expiry timestamp that has passed. The GEC fires HEM- CONSENT, blocks the preference data access, and routes a consent renewal request to the guest through the registered contact channel. The guest provides renewed consent; the GEC updates the consent record; execution resumes. The GAR audit trail carries ALE-041 (CONSENT_ESCALATION_RESOLVED) with consent_basis: "APPI_ART17_RENEWED". 4. HEM Session States 4.1. State Definitions A GEC session with respect to HEM is in one of the following states at any moment: HEM_INACTIVE: Default state. No HEM condition is active. The kernel processes agent transitions normally subject to Cedar evaluation. HEM_PENDING: A HEM trigger has fired and the kernel has routed an escalation request to one or more designated human principals. No governed object state transitions may execute. This state persists until a valid human decision is received or the timeout budget is exhausted. HEM_RESOLVED: A valid human decision has been received and processed. The session returns to HEM_INACTIVE unless the human decision itself requires further HEM consideration. HEM_TIMEOUT: The timeout budget has been exhausted without receipt of a valid human decision. The kernel applies the configured timeout disposition (Section 14.2). HEM_CHAIN_EXHAUSTED: The designation chain has been exhausted without a decision from any principal and the timeout budget is exhausted. The kernel applies the chain exhaustion disposition (Section 14.4). 4.2. State Transition Constraints The following state transitions are normative for a conforming kernel implementation: HEM_INACTIVE --> HEM_PENDING (HEM trigger fires) HEM_PENDING --> HEM_RESOLVED (valid decision received) HEM_PENDING --> HEM_TIMEOUT (timeout budget exhausted) HEM_PENDING --> HEM_CHAIN_EXHAUSTED (mission validity failure; see Section 13.4) HEM_TIMEOUT --> HEM_CHAIN_EXHAUSTED (chain exhausted) HEM_TIMEOUT --> HEM_INACTIVE (disposition permits) HEM_RESOLVED --> HEM_INACTIVE (always) HEM_CHAIN_EXHAUSTED --> [terminal] (session suspended or terminated per Section 14.4) The transition HEM_INACTIVE --> HEM_PENDING MUST be GEC-initiated. 5. HEM Trigger Classes This document defines ten trigger classes. Sections 5.1 through 5.10 are carried forward from -04 without modification. HEM interaction classes (Section 7) are distinct from trigger classes: trigger classes determine when HEM_PENDING is entered; interaction classes specify structured GEC-human interactions that MAY occur during or prior to the HEM_PENDING lifecycle. 5.1. Class 1: Cedar Policy Routing (HEM_CEDAR_ROUTED) A Cedar policy may explicitly route a transition to HEM rather than resulting in PERMIT or DENY. The GEC MUST recognize this pattern and MUST enter HEM_PENDING when Cedar evaluation produces a hem_required: true result. 5.2. Class 2: Agent Uncertainty Declaration (HEM_AGENT_ESCALATED) When the GEC receives a gec.transition() call with a valid IDP containing hem_urgency: REQUIRED, the kernel MUST enter HEM_PENDING for the session, regardless of Cedar policy evaluation outcome. 5.3. Class 3: Proximity Threshold Crossing (HEM_PROXIMITY_TRIGGERED) A governed object's configuration MAY include one or more Proximity Threshold declarations. When a declared threshold condition is met, the kernel MUST enter HEM_PENDING regardless of any agent action in progress. 5.4. Class 4: Mission Validity Failure (HEM_MISSION_VALIDITY_FAILED) When the Mission Authority Service reports that the governing MissionDeclaration has transitioned to a non-active phase (SUSPENDED, FAILED, or ABANDONED) while a session is otherwise active and no HEM_PENDING event is in progress, the GEC MUST enter HEM_PENDING so that a human principal can confirm terminal disposition before the session is closed. 5.5. Class 5: Jurisdictional Conflict (HEM_JURISDICTIONAL_CONFLICT) When the kernel determines that it cannot algorithmically resolve a conflict between the legal requirements of two or more applicable jurisdictions, the GEC MUST enter HEM_PENDING with trigger_class HEM_JURISDICTIONAL_CONFLICT. 5.6. Class 6: Absolute Harm Observed (HEM_TIER0_OBSERVED) A GEC agent session observes evidence of a Tier 0-A or Tier 0-B prohibited situation within data the agent has legitimate access to under its current mandate. The GEC MUST enter HEM_PENDING immediately, construct a HEM Escalation Request with trigger_class HEM_TIER0_OBSERVED and urgency CRITICAL, and include an Observation Context Package. 5.7. Class 7: Legal Violation Observed (HEM_TIER1_OBSERVED) A GEC agent session observes evidence of a Tier 1 prohibited activity with confidence above the operator-configured threshold. Class 7 operates on a three-grade confidence model: SUSPICIOUS, PROBABLE, and EVIDENT. 5.8. Class 8: Resource Exhaustion Anticipated (HEM_TIER3_ANTICIPATORY) Before beginning execution of a multi-step mission, the GEC determines that the total estimated resource cost exceeds the remaining resource budget under any active Tier 3 resource policy. 5.9. Class 9: Resource Exhaustion In Progress (HEM_TIER3_OBSERVED) During mission execution, the GEC detects that resource consumption has reached the warning_threshold_pct configured in the active Tier 3 resource policy. 5.10. Class 10: Budget Exhausted (HEM_BUDGET_EXHAUSTED) During mission execution, the GEC detects that the resource budget bound to the active Mandate JWT has been fully consumed. The GEC MUST immediately halt all mission execution and enter HEM_PENDING. 5.11. Policy Rationale Declaration (PRD) A PRD links a Cedar policy routing transitions to HEM with machine- readable rationale. A Cedar policy that routes to HEM MUST carry a prd_id annotation referencing a registered PRD. 5.12. Extension Trigger Classes Implementors MAY define additional trigger classes using a URI- prefixed identifier. Extension trigger classes MUST be submitted via the defined HEM_PENDING state machine. 6. HEM Dual-Layer Architecture 6.1. The Two HEM Layers LLM-HEM is the uncertainty-signaling behavior exhibited by an LLM- based agent when it recognizes that a situation exceeds its reliable competence. LLM-HEM manifests through IDP fields and produces agent-initiated escalation (Class 2: HEM_AGENT_ESCALATED). SOOS-HEM is the structural HEM trigger logic enforced by the GEC at the kernel layer, independent of any agent-declared uncertainty. SOOS-HEM fires on Cedar policy routing, proximity threshold crossing, mission validity failure, jurisdictional conflict, and observation events. SOOS-HEM is non-bypassable. 6.2. The Unobservability Principle The GEC MUST NOT rely on LLM-HEM signals as the sole basis for Classes 6 through 10 trigger decisions. SOOS-HEM trigger conditions for Classes 6 through 10 MUST be evaluated against observable structural conditions -- Cedar policy state, resource counters, mission phase, observed evidence patterns -- and MUST NOT require the agent to have declared uncertainty as a precondition for firing. 6.3. Interaction Case Analysis Four interaction cases arise between LLM-HEM and SOOS-HEM: Case A (concordance), Case B (agent-only), Case C (kernel concordance), and Case D (discrepancy). Case D produces a HEM_LAYER_DISCREPANCY event (Section 6.5). 6.4. Normative Constraint: Situation-Typed Triggers GEC implementations MUST NOT implement Classes 6 through 10 as confidence-gated triggers. 6.5. HEM_LAYER_DISCREPANCY Governance Event When SOOS-HEM fires and the triggering IDP contains no uncertainty signal (Case D), the GEC MUST record a HEM_LAYER_DISCREPANCY event in the GAR Event Log. This is a GAR audit event only; it does not generate a separate HEM lifecycle. 7. HEM Interaction Classes (NEW in -05) 7.1. Overview and Design Principles HEM interaction classes define structured, normatively specified interactions between the GEC and a human principal that are categorically distinct from the core HEM trigger lifecycle. Where a trigger class (Section 5) determines when HEM_PENDING is entered, an interaction class determines the form, required fields, decision types available, and GAR ALE emitted for a specific category of GEC-human interaction. Ten interaction classes are defined in this version. They are organized into four groups: Pre-Action Group (Section 7.2): HEM-PRE-1 (Pre-Action Clarification Request) HEM-PRE-2 (Pre-Action Confirmation Request) Decision Support Group (Section 7.3): HEM-DS-1 (Decision Support -- Options Presentation) HEM-DS-2 (Decision Support -- Continuation Prompt) Limitation and Divergence Group (Section 7.4): HEM-LIM-1 (Capability Limitation Declaration) HEM-DIV-1 (Divergence Noted) High-Stakes and Fatigue Group (Section 7.5): HEM-HIGH-1 (High-Stakes Mandatory Review) HEM-FAT-1 (Approval Fatigue Detection) Emotional State and Consent Group (Section 7.6): HEM-EMO-1 (Emotional State Advisory) HEM-CONSENT (Consent-Required Escalation) Design principle: interaction classes are non-suppressible. A GEC MUST NOT allow an agent, operator, or application layer to suppress or bypass a required interaction class trigger. This property is an instance of INV-HEM-01 (Section 10). GAR ALE registrations for interaction classes use the range ALE-030 through ALE-041. Each interaction class registers two ALE types: one for the initiation event and one for the resolution event. Complete IANA registration text for all twelve ALE types appears in Section 21. 7.2. Pre-Action Interaction Group 7.2.1. HEM-PRE-1: Pre-Action Clarification Request HEM-PRE-1 is fired by the GEC when an agent's IDP declares a goal that requires clarification from the human principal before execution can proceed in a well-informed manner. Trigger conditions: The GEC MUST fire HEM-PRE-1 when any of the following conditions is met: (a) The IDP goal_description contains a conditional branch whose resolution depends on information that the agent does not have and cannot derive from the current SO state or mandate. (b) The agent's declared confidence_level is below the operator- configured HEM-PRE-1 threshold AND the decision type of the pending action is CONSEQUENTIAL (as declared in the SO Type). (c) The active Cedar policy for the pending action carries a require_clarification: true annotation. Decision types available for HEM-PRE-1: The human principal MUST respond with one of the following: APPROVE: Provides the clarification requested and authorizes the GEC to proceed. The clarification content MUST be included in the decision_data.clarification_text field. REDIRECT: Redirects the agent to an alternative action, implicitly providing the clarification through the redirect target. TERMINATE: Terminates the session. DRR REQUIRED (Section 12.7). DENY: Refuses to provide clarification. The pending action MUST NOT execute. The GEC records the denial and returns to HEM_INACTIVE. GAR ALE: ALE-030 (HEM_PRE_CLARIFICATION_INITIATED): emitted when HEM-PRE-1 fires. Required fields: hem_id, session_id, so_id, mandate_id, goal_description_hash, trigger_condition_code, initiated_at. ALE-031 (HEM_PRE_CLARIFICATION_RESOLVED): emitted on resolution. Required fields: hem_id, decision_type, resolution_at, drr_id (if DRR present). CONF-HEM-PRE1-01: A GEC MUST NOT allow an agent to resubmit a gec.transition() call for the same action on the same so_id within the same session after a HEM-PRE-1 DENY resolution without first issuing a new IDP with a materially distinct goal_description. 7.2.2. HEM-PRE-2: Pre-Action Confirmation Request HEM-PRE-2 is fired by the GEC when an action is Cedar-permitted but requires explicit human confirmation before execution proceeds, because the action has been designated as requiring affirmative sign-off under the SO Type configuration. Trigger conditions: The GEC MUST fire HEM-PRE-2 when any of the following conditions is met: (a) The Cedar action attribute confirm_before_execute is true for the pending action. (b) The SO Type declares the pending state transition as confirmation_required: true. (c) The action is of a type designated IRREVERSIBLE in the SO Type, and the governing mandate's irreversibility_requires_confirm field is true. (d) The accumulated RETRY count for this action within the current session exceeds the HEM-PRE-2 retry threshold (default: 3). This condition connects HEM-PRE-2 to the GRP remediation loop (see [I-D.sato-soos-grp]). Decision types available for HEM-PRE-2: APPROVE: Human principal confirms execution. GEC proceeds to Cedar evaluation and, if PERMIT, executes the action. APPROVE_WITH_CONSTRAINTS: Human principal confirms execution subject to specified Cedar context constraints. See Section 12.2. DENY: Human principal refuses confirmation. Action MUST NOT execute. TERMINATE: Terminates the session. DRR REQUIRED. GAR ALE: ALE-032 (HEM_PRE_CONFIRMATION_INITIATED): emitted when HEM-PRE-2 fires. Required fields: hem_id, session_id, so_id, mandate_id, action_id, trigger_condition_code, irreversible_flag, initiated_at. ALE-033 (HEM_PRE_CONFIRMATION_RESOLVED): emitted on resolution. Required fields: hem_id, decision_type, resolution_at, approve_with_constraints_flag (boolean), drr_id (if present). CONF-HEM-PRE2-01: A GEC MUST NOT execute an action designated IRREVERSIBLE without first completing an HEM-PRE-2 lifecycle when irreversibility_requires_confirm is true in the governing mandate. CONF-HEM-PRE2-02: When HEM-PRE-2 fires due to RETRY count threshold (condition (d) above), the GEC MUST include the full RETRY history in the HEM Escalation Request's trigger_detail field, including the outcome of each prior RETRY attempt. 7.3. Decision Support Interaction Group 7.3.1. HEM-DS-1: Decision Support -- Options Presentation HEM-DS-1 is the normative specification for how the GEC presents a set of options to a human principal during an escalation event. It is not an independent trigger class; it is the format that a HEM Escalation Request carrying an options set MUST follow. Trigger conditions: HEM-DS-1 applies when a HEM Escalation Request (regardless of trigger class) includes two or more options for the human principal to choose among. The GEC MUST structure the options presentation in compliance with HEM-DS-1 whenever this condition is met. Format requirements: The options_presentation object MUST be included in the HEM Escalation Request when HEM-DS-1 applies: { "options_presentation": { "options": [ ; REQUIRED. Array of option objects. ; Minimum 2; maximum 5. { "option_id": string, ; REQUIRED. Unique within this ; options_presentation. "option_label": string, ; REQUIRED. Short human-readable ; label. Maximum 80 characters. "option_description": string, ; REQUIRED. Full description. "decision_type": string, ; REQUIRED. The HEM decision type ; this option invokes. "consequence_summary": string, ; REQUIRED. Plain-language ; statement of what happens if ; this option is selected. ; MUST NOT contain evaluative ; language recommending or ; discouraging selection. "reversible": boolean, ; REQUIRED. Whether the action ; resulting from this option ; can be undone. "gec_recommended": boolean ; REQUIRED. Whether this option ; is the GEC's recommended ; choice. MUST be false for ; all options except at most ; one. } ], "neutrality_certificate": string ; REQUIRED. GEC-generated ; statement certifying that ; the options set was generated ; without preference-shaping ; ordering or framing. } } Neutrality requirements: CONF-HEM-DS1-01: The GEC MUST NOT order options in a way designed to exploit cognitive biases (e.g., placing a preferred option first to exploit primacy effect or last to exploit recency effect without disclosure). Default option ordering MUST be either random or alphabetical by option_label. CONF-HEM-DS1-02: The consequence_summary field MUST NOT contain evaluative adjectives, urgency language, or framing that would influence option selection independent of the option's actual consequences. Acceptable: "This action will delete the booking record." Unacceptable: "This action will unfortunately delete the booking record." CONF-HEM-DS1-03: At most one option MAY carry gec_recommended: true. If no clear recommended option exists, all options MUST carry gec_recommended: false. GAR ALE: ALE-034 (HEM_DS_OPTIONS_PRESENTED): emitted when HEM-DS-1 applies. Required fields: hem_id, options_count, recommended_option_id (nullable), neutrality_certificate_hash, presented_at. ALE-035 (HEM_DS_OPTIONS_RESOLVED): emitted on selection. Required fields: hem_id, selected_option_id, decision_type, resolved_at. 7.3.2. HEM-DS-2: Decision Support -- Continuation Prompt HEM-DS-2 fires when an agent session is in HEM_PENDING and the human principal has not responded within a configurable prompt interval. HEM-DS-2 sends a continuation prompt to the principal to confirm they are still engaged and intend to respond. Trigger conditions: The GEC MUST fire HEM-DS-2 when all of the following conditions are met: (a) The session is in HEM_PENDING. (b) The per-principal timeout has not expired. (c) The principal has not submitted a decision. (d) Time elapsed since last principal activity signal exceeds the operator-configured prompt_interval_seconds (default: 300 seconds; minimum: 60 seconds). Timeout handling: HEM-DS-2 is a notification event; it does not reset the principal's timeout budget. The timeout clock continues to run while the HEM-DS-2 prompt is outstanding. CONF-HEM-DS2-01: A GEC MUST NOT send more than three HEM-DS-2 prompts to the same principal for the same hem_id. After the third unanswered prompt, the GEC MUST treat the principal's timeout as exhausted (per Section 14.3) regardless of whether the timeout budget has elapsed. CONF-HEM-DS2-02: A HEM-DS-2 prompt MUST NOT include urgency language beyond a plain statement of time remaining. The prompt MUST NOT contain evaluative statements about the pending decision. GAR ALE: ALE-034 and ALE-035 are shared with HEM-DS-1 for the continuation prompt case. The options_count field MUST be 0 when ALE-034 is emitted for a continuation prompt, to distinguish it from an options presentation event. 7.4. Limitation and Divergence Group 7.4.1. HEM-LIM-1: Capability Limitation Declaration HEM-LIM-1 fires when the GEC detects that an agent is operating at or beyond the boundary of its declared reliable competence for the current task, and this limitation has not been surfaced to the human principal. HEM-LIM-1 operationalizes INV-HEM-01 (The Surfacing Obligation, Section 10) for the capability limitation case. Trigger conditions: The GEC MUST fire HEM-LIM-1 when any of the following conditions is met: (a) The IDP accompanying the current gec.transition() call carries reasoning_mode: OUT_OF_DISTRIBUTION. (b) The agent's IDP confidence_level is below the operator- configured minimum confidence floor for the action type, and the agent has not previously surfaced this limitation to the principal in the current session. (c) The agent's IDP contains an explicit out_of_competence_declaration field set to true. Surfacing obligation: HEM-LIM-1 MUST surface the limitation to the human principal before execution proceeds. The escalation request MUST include: { "limitation_declaration": { "limitation_type": string, ; REQUIRED. Values: ; "CONFIDENCE_BELOW_FLOOR", ; "OUT_OF_DISTRIBUTION", ; "EXPLICIT_AGENT_DECLARATION", ; "COMPETENCE_BOUNDARY". "limitation_description": string, ; REQUIRED. Plain-language ; statement of the limitation. "idp_confidence_level": number, ; REQUIRED. The confidence_level ; from the triggering IDP. "competence_floor": number, ; REQUIRED. The ; operator-configured floor for ; this action type. "recommended_action": string ; OPTIONAL. Agent-declared ; recommended path given the ; limitation. } } GAR ALE: ALE-036 (HEM_LIMITATION_DECLARED): emitted when HEM-LIM-1 fires. Required fields: hem_id, session_id, limitation_type, idp_confidence_level, competence_floor, declared_at. ALE-037 (HEM_LIMITATION_ACKNOWLEDGED): emitted when principal responds. Required fields: hem_id, decision_type, acknowledged_at. CONF-HEM-LIM1-01: A GEC MUST fire HEM-LIM-1 at most once per unique limitation_type per session. If the same limitation type fires again in the same session, the GEC MUST append to the existing HEM-LIM-1 record rather than creating a new escalation event. CONF-HEM-LIM1-02: A GEC MUST NOT allow an agent to proceed on a task for which it has declared OUT_OF_DISTRIBUTION reasoning without first completing an HEM-LIM-1 lifecycle in which the human principal has received and acknowledged the limitation. 7.4.2. HEM-DIV-1: Divergence Noted HEM-DIV-1 fires when the GEC detects that an agent's actual execution path diverges from the path declared in its IDP. HEM-DIV-1 captures the Deliberation Record and routes it to the human principal before execution of the divergent path. Trigger conditions: The GEC MUST fire HEM-DIV-1 when any of the following conditions is met: (a) An IDP_COMMITMENT_GAP event is detected (the agent's actual transition request differs from its declared intended action in the preceding IDP). (b) The agent submits a gec.transition() call that targets a Cedar action not included in the available_actions_if_resolved list of the current IDP's so_state_summary. (c) The agent's current IDP reasoning_type is PLAN_B_ACTIVE, indicating the agent has departed from its primary plan. Critical divergence block: When HEM-DIV-1 fires, the GEC MUST block execution of the divergent path until the human principal has reviewed the Deliberation Record. Execution of the originally declared path MAY continue (if Cedar-permitted) while the HEM-DIV-1 review is outstanding, at the operator's discretion. Deliberation Record: The GEC MUST construct and include a Deliberation Record in the HEM Escalation Request when HEM-DIV-1 fires: { "deliberation_record": { "declared_action": string, ; REQUIRED. The action declared ; in the triggering IDP. "attempted_action": string, ; REQUIRED. The action actually ; requested in the diverging ; gec.transition() call. "divergence_type": string, ; REQUIRED. Values: ; "ACTION_MISMATCH", ; "PLAN_B_ACTIVE", ; "OUT_OF_SCOPE_ACTION", ; "IDP_COMMITMENT_GAP". "divergence_reason": string, ; OPTIONAL. Agent-declared reason ; for divergence, from IDP ; context_refs. "option_set_considered": [ ; REQUIRED. Array of actions the ; agent considered before ; selecting the divergent path, ; as declared in the IDP. { "action_id": string, "considered": boolean, "selected": boolean, "rejection_reason": string ; OPTIONAL. } ], "prior_idp_chain": [string] ; REQUIRED. Array of idp_ids ; for the IDP chain leading ; to this divergence. } } GAR ALE: ALE-038 (HEM_DIVERGENCE_NOTED): emitted when HEM-DIV-1 fires. Required fields: hem_id, session_id, divergence_type, declared_action_hash, attempted_action_hash, deliberation_record_id, noted_at. ALE-039 (HEM_DIVERGENCE_RESOLVED): emitted on resolution. Required fields: hem_id, decision_type, divergent_path_approved, resolved_at. CONF-HEM-DIV1-01: When HEM-DIV-1 fires due to IDP_COMMITMENT_GAP, the GEC MUST also emit the IDP_COMMITMENT_GAP CRITICAL Audit Alert required by [I-D.sato-soos-idp]. Both events MUST share the same hem_id. 7.5. High-Stakes and Fatigue Group 7.5.1. HEM-HIGH-1: High-Stakes Mandatory Review HEM-HIGH-1 fires when an agent's pending action falls within a domain designated as requiring mandatory human review before any autonomous execution. HEM-HIGH-1 is non-bypassable: no Cedar PERMIT result, no mandate configuration, and no operator setting may suppress HEM-HIGH-1 for actions within its scope. Domain categories: Category A -- Non-operator-configurable domains: The following domains are Category A for HEM-HIGH-1. This list is a normative invariant sourced from [I-D.sato-soos-cap] Section 7.2 (Category A High-Stakes Domain Registry). Operators MUST NOT remove or narrow these domains. MEDICAL: Diagnosis, treatment planning, prescription, clinical trial enrollment, and pharmacological recommendation. AVIATION: Flight path planning, air traffic coordination, airworthiness determination, and crew scheduling decisions. NUCLEAR: Facility operations, criticality calculations, safety system override, and waste handling. Category B -- Operator-configurable domains: Operators MAY designate additional domains as Category B at deployment time by registering them in the SO Type HEM configuration. Category B domains require mandatory review but permit the operator to configure the designation chain separately from Category A. Mandatory review trigger: The GEC MUST fire HEM-HIGH-1 and MUST enter HEM_PENDING when: (a) The pending Cedar action type is tagged with the annotation high_stakes_domain: [domain_name] where domain_name is a registered Category A or Category B domain; OR (b) The agent's IDP goal_description maps to a domain category as determined by the CEE domain classifier. CONF-HEM-HIGH1-01: A GEC MUST NOT permit autonomous execution of any action in a Category A domain without first completing an HEM-HIGH-1 lifecycle in which a human principal has issued APPROVE or APPROVE_WITH_CONSTRAINTS. CONF-HEM-HIGH1-02: An APPROVE_WITH_PAYMENT decision MUST NOT be accepted for HEM-HIGH-1 triggers. The GEC MUST return HEM_DECISION_INVALID for APPROVE_WITH_PAYMENT submissions on HEM-HIGH-1 escalations. CONF-HEM-HIGH1-03: For Category A domains, the designation chain MUST be the highest-authority principal chain. The GEC MUST NOT route Category A HEM-HIGH-1 escalations to a governed-object- level principal chain only. GAR ALE: ALE-030 (shared with HEM-PRE-1 for initiation; see note below) is NOT reused for HEM-HIGH-1. HEM-HIGH-1 uses: ALE-038 is NOT reused. HEM-HIGH-1 is emitted under the standard HEM_TRIGGERED event (Section 15) with trigger_class field "HEM_HIGH_STAKES_MANDATORY_REVIEW" and domain_category field ("CATEGORY_A" or "CATEGORY_B"). ALE-040 (HEM_HIGH_STAKES_REVIEW_RESOLVED): emitted on resolution. Required fields: hem_id, domain_category, domain_name, decision_type, drr_id (REQUIRED for APPROVE and APPROVE_WITH_CONSTRAINTS in Category A), resolved_at. DRR requirement for HEM-HIGH-1: A DRR is REQUIRED for all APPROVE and APPROVE_WITH_CONSTRAINTS decisions on Category A HEM-HIGH-1 escalations. The GEC MUST reject APPROVE or APPROVE_WITH_CONSTRAINTS decisions on Category A escalations that lack a DRR, with error HEM_DRR_REQUIRED. 7.5.2. HEM-FAT-1: Approval Fatigue Detection HEM-FAT-1 fires when the GEC detects that a human principal's approval pattern within the current session indicates cognitive fatigue or rubber-stamp approval, as measured by the Human Readiness Score (HRS, Section 8). HRS threshold: HEM-FAT-1 fires when the HRS for the active principal drops below the HRS_FATIGUE_FLOOR threshold (default: 0.40 on a 0.0--1.0 scale) AND one or more of the following secondary signals is present: (a) Approval decision latency has decreased by more than 60% from the principal's session baseline over the last five consecutive approvals. (b) Three or more consecutive APPROVE decisions have been issued in under 10 seconds each. (c) The ratio of DRR submissions to APPROVE decisions in the current session is below 0.10 where DRRs are RECOMMENDED (i.e., the DRR completion rate is under 10%). Fatigue advisory: When HEM-FAT-1 fires, the GEC MUST: (a) Issue a fatigue advisory to the principal's registered contact channel. The advisory MUST be distinct from the normal HEM escalation notification and MUST clearly identify the fatigue detection as the reason for the interruption. (b) Suspend the HEM approval queue for the current session. No further APPROVE or APPROVE_WITH_CONSTRAINTS decisions will be accepted from the current principal until the mandatory rest period has elapsed. (c) Emit ALE-034 (shared with HEM-DS-1 initiation, with fatigue_flag: true to distinguish the event type). Mandatory rest period: The mandatory rest period is configurable per SO Type (default: 1800 seconds; minimum: 600 seconds; maximum: 86400 seconds). During the rest period: CONF-HEM-FAT1-01: The GEC MUST NOT accept APPROVE or APPROVE_WITH_ CONSTRAINTS decisions from the principal for whom HEM-FAT-1 fired. CONF-HEM-FAT1-02: After the mandatory rest period, the GEC MUST re-present any pending HEM escalations to the principal before accepting new approvals. The GEC MUST NOT silently accumulate approvals during the rest period and release them. CONF-HEM-FAT1-03: A HEM-FAT-1 mandatory rest period MUST propagate to the next principal in the designation chain only if the SO Type configuration specifies chain_rest_propagation: true. GAR ALE: ALE-034 (HEM_FATIGUE_DETECTED, with fatigue_flag: true): emitted when HEM-FAT-1 fires. Required fields: hem_id, principal_id, hrs_score, hrs_fatigue_floor, secondary_signal_codes (array), mandatory_rest_seconds, detected_at. ALE-035 (HEM_FATIGUE_REST_COMPLETE): emitted when the mandatory rest period expires. Required fields: hem_id, principal_id, rest_elapsed_seconds, completed_at. 7.6. Emotional State and Consent Group 7.6.1. HEM-EMO-1: Emotional State Advisory HEM-EMO-1 fires when the GEC detects signals indicating that a human principal's current emotional state may be adversely affecting their capacity to make a well-reasoned HEM decision. Detection criteria: HEM-EMO-1 is advisory only. It does NOT block execution and does NOT enter HEM_PENDING. The GEC MUST fire HEM-EMO-1 when the HRS emotional_state dimension (Section 8.2) drops below the HRS_EMOTIONAL_ADVISORY_FLOOR threshold (default: 0.35) AND at least one of the following signals is present: (a) Principal decision response time has exhibited high variance (coefficient of variation > 0.5) over the last five responses in the current session. (b) The principal has submitted a DRR whose rationale_text contains negative sentiment markers as classified by the GEC's DRR sentiment classifier. (c) The principal has explicitly triggered an emotional state self-report through the GEC interface. Advisory-only nature: HEM-EMO-1 MUST NOT block execution. HEM-EMO-1 MUST NOT enter HEM_PENDING. HEM-EMO-1 MUST NOT prevent the principal from issuing HEM decisions. The GEC MUST route the advisory to the principal through a low-priority channel that does not interrupt the active HEM decision interface. DRR note: When HEM-EMO-1 fires for a principal who is actively reviewing a TERMINATE escalation, the GEC SHOULD include a note in the DRR prompt indicating that an emotional state advisory is active. This note is informational; it does not restrict the TERMINATE decision. GAR ALE: ALE-036 (shared with HEM-LIM-1, with advisory_type: "EMOTIONAL" field to distinguish): emitted when HEM-EMO-1 fires. Privacy note: The emotional state signals used to compute the HRS emotional_state dimension MUST comply with the BIOMETRIC_SIGNAL_INFERENCE prohibition in [I-D.sato-soos-cap] Section 7.2. The GEC MUST NOT infer emotional state from biometric signals without a valid consent_scope entry in the session MJWT [I-D.sato-soos-mjwt]. Where consent is absent, the GEC MUST rely solely on behavioral signals (response timing, DRR sentiment) that do not constitute biometric inference. 7.6.2. HEM-CONSENT: Consent-Required Escalation HEM-CONSENT fires when the GEC detects that a pending action requires data subject consent and either no consent record is present in the session MJWT consent_scope [I-D.sato-soos-mjwt] or the consent_scope has expired. MJWT consent_scope trigger: The GEC MUST fire HEM-CONSENT when: (a) A Cedar action is tagged consent_gated: true AND the MJWT consent_scope claim is absent from the session mandate; OR (b) A Cedar action is tagged consent_gated: true AND the MJWT consent_scope.expiry value is past at Cedar evaluation time (per [I-D.sato-soos-mjwt] Section 7.4); OR (c) A Cedar action's required purpose_code is not present in consent_scope.purpose_codes. APPI Article 17 binding: For deployments operating under Japanese law, HEM-CONSENT is normatively bound to APPI [APPI] Article 17 (acquisition of personal information with notification to data subject). The HEM-CONSENT escalation request MUST include: { "consent_escalation": { "consent_requirement": string, ; REQUIRED. The regulatory basis ; for the consent requirement. ; Example: "APPI_ART17", ; "GDPR_ART6", "CCPA_S1798". "purpose_codes_required": [string], ; REQUIRED. Purpose codes ; required for the pending ; action, from the CAP-RRS ; Purpose Code Registry. "purpose_codes_present": [string], ; REQUIRED. Purpose codes ; currently in consent_scope ; (empty if absent). "consent_expiry": string, ; OPTIONAL. The expiry timestamp ; from the expired ; consent_scope, if applicable. "data_categories": [string] ; REQUIRED. Data categories ; for which consent is needed. } } HEM-CONSENT MUST NOT block the escalation with the reason that consent cannot be obtained at runtime. The GEC MUST route the consent escalation to the data subject through the registered consent collection channel. Fail-closed behavior: CONF-HEM-CONSENT-01: If HEM-CONSENT escalation times out without consent being provided, the pending action MUST be denied. The GAR record MUST carry resolution: TIMEOUT_DENY. No implicit consent is ever inferred from a failure to escalate or a timeout. CONF-HEM-CONSENT-02: The GEC MUST NOT permit issuance of new child mandates while HEM-CONSENT is pending and unresolved for any consent-gated action in the current session. GAR ALE: ALE-040 (HEM_CONSENT_ESCALATION_INITIATED): emitted when HEM-CONSENT fires. Required fields: hem_id, session_id, consent_requirement, purpose_codes_required, purpose_codes_present, consent_expiry (nullable), initiated_at. ALE-041 (HEM_CONSENT_ESCALATION_RESOLVED): emitted on resolution. Required fields: hem_id, resolution_type (CONSENT_OBTAINED / TIMEOUT_DENY / TERMINATED), consent_basis (string, nullable), resolved_at. 8. Human Readiness Score (HRS) (NEW in -05) 8.1. Overview The Human Readiness Score (HRS) is a kernel-computed composite score reflecting the human principal's current capacity to make a well-informed, timely, and unconflicted HEM decision. The HRS is computed by the GEC on each HEM escalation event and is used as an input to HEM-FAT-1 (approval fatigue detection) and HEM-EMO-1 (emotional state advisory). The HRS is a value on the interval [0.0, 1.0], where 1.0 represents full readiness and 0.0 represents complete incapacity. The HRS MUST NOT be surfaced directly to the human principal. It is a kernel-internal signal used for interaction class triggering and audit record generation. The HRS is computed per principal per session, using both the current session's behavioral signals and same-day prior-session history as required for D4 (Section 8.2, CONF-HEM-SEC-HRS-01). HRS values are not carried forward past the calendar day boundary (Section 19). (CORRECTED in -06: -05's text here read "The HRS does not persist across sessions," which directly contradicted CONF-HEM-SEC-HRS-01 (Section 18.12) -- the specific, named defense against the "session reset" HRS-gaming attack (18.12(c)) -- and Section 19's retention-ceiling language, both of which require and regulate same-day cross-session HRS data. A literal implementation of the old text would have been the exact vulnerability CONF-HEM-SEC-HRS-01 exists to close. This correction changes only the description of what HRS is; CONF-HEM-SEC-HRS-01's actual requirement is unchanged.) 8.2. Scoring Dimensions The HRS is computed as the weighted average of the following five dimensions. Weights are operator-configurable within the bounds specified below. D1: Response Latency Trend (default weight: 0.25) Measures whether the principal's decision response latency is trending toward values that indicate rubber-stamp approval. Score 1.0: latency is consistent with the principal's session baseline. Score 0.0: latency has dropped below the rubber-stamp threshold (default: 3 seconds per decision). Computation: linear interpolation between baseline and floor. D2: Decision Variance (default weight: 0.20) Measures whether the principal's decisions exhibit expected variance, or whether an anomalously uniform pattern (e.g., all APPROVE) suggests inattention. Score 1.0: decision distribution is diverse. Score 0.0: last 10 consecutive decisions are identical (type and content). Computation: 1 - (run_length_of_identical_decisions / 10). D3: DRR Completion Rate (default weight: 0.20) Measures the proportion of decision slots for which a DRR was submitted where one was RECOMMENDED. Score 1.0: all RECOMMENDED DRRs submitted. Score 0.0: no RECOMMENDED DRRs submitted. D4: Session Duration (default weight: 0.20) Measures time elapsed in the current session as a proxy for decision fatigue. Score 1.0: session is within the first quarter of the operator-configured max_session_minutes. Score 0.0: session has exceeded max_session_minutes. Computation: linear interpolation. D5: Emotional State Proxy (default weight: 0.15) Measures behavioral signals that may indicate elevated emotional state affecting judgment. Score 1.0: no adverse signals. Score 0.0: all three adverse signals are present (high response time variance, negative DRR sentiment, explicit self-report). Computation: 1 - (adverse_signals_count / 3). HRS = (W1 * D1) + (W2 * D2) + (W3 * D3) + (W4 * D4) + (W5 * D5) where W1 + W2 + W3 + W4 + W5 = 1.0. CONF-HEM-HRS-01: The sum of all dimension weights MUST equal 1.0. Any operator configuration that specifies weights not summing to 1.0 MUST be rejected at load time with HRS_WEIGHT_CONFIGURATION_ ERROR. CONF-HEM-HRS-02: No single dimension weight MUST be configured below 0.05 or above 0.50. Configurations outside this range MUST be rejected at load time. 8.3. HRS Threshold Table The following thresholds are normative defaults. Operators MAY configure per-SO-Type thresholds within the stated bounds. +------------------------+---------+-----------+---------------+ | Threshold Name | Default | Min/Max | Effect | +------------------------+---------+-----------+---------------+ | HRS_FATIGUE_FLOOR | 0.40 | 0.20/0.60 | HEM-FAT-1 | | | | | fires | | HRS_EMOTIONAL_ | 0.35 | 0.20/0.50 | HEM-EMO-1 | | ADVISORY_FLOOR | | | advisory | | HRS_WARNING_THRESHOLD | 0.55 | 0.35/0.70 | GEC logs | | | | | HRS_WARN | | HRS_NOMINAL_FLOOR | 0.70 | 0.60/0.85 | No action | +------------------------+---------+-----------+---------------+ Table 1: HRS Threshold Table HRS_WARNING_THRESHOLD: When HRS drops below this value but remains above HRS_FATIGUE_FLOOR, the GEC MUST emit an HRS_WARNING Audit Alert in GAR but MUST NOT fire HEM-FAT-1 and MUST NOT block approvals. 8.4. GEC Enforcement Rules CONF-HEM-HRS-03: The GEC MUST compute the HRS before every APPROVE or APPROVE_WITH_CONSTRAINTS decision is accepted from a principal. CONF-HEM-HRS-04: If the HRS is below HRS_FATIGUE_FLOOR AND the secondary signal conditions for HEM-FAT-1 (Section 7.5.2) are met, the GEC MUST fire HEM-FAT-1 before recording the principal's decision. CONF-HEM-HRS-05: The HRS computation MUST be based solely on observable behavioral signals (response timing, DRR submission, decision distribution, session duration). The GEC MUST NOT use biometric signal data in the HRS computation without a valid consent_scope entry in the session MJWT [I-D.sato-soos-mjwt] authorizing biometric_monitoring purpose_code. CONF-HEM-HRS-06: The GEC MUST record the HRS value in the HEM_DECISION_RECEIVED Event Log entry for all APPROVE and APPROVE_WITH_CONSTRAINTS decisions. The HRS value is a mandatory audit field. Open issue OQ-HEM-HRS-01: the normative method for cross- jurisdiction calibration of HRS thresholds -- particularly for jurisdictions with distinct workplace health and safety regimes (e.g., Japan Industrial Safety and Health Act (Rodo Anzen Eisei Ho)) -- is deferred to a successor document. See Section 17.5. 9. Tier 0-A Integration (NEW in -05) 9.1. Overview The Constitutional AI Protocol [I-D.sato-soos-cap] version -04 introduced three new Tier 0-A absolute prohibition classes: MANIPULATION, PERFORMED_EMOTION, and BIOMETRIC_SIGNAL_INFERENCE. These prohibitions are absolute: no HEM decision, no Cedar policy permit, and no operator configuration may clear them. They are enforced by the Constitutional Enforcement Engine (CEE) before Cedar evaluation. Section 9 specifies the HEM interface for each of these three Tier 0-A prohibition classes. The HEM interface defines what the GEC MUST do when a Tier 0-A violation is detected: the relationship between the CAP CEE refusal and the HEM escalation record is normative and bidirectional. 9.2. MANIPULATION Prohibition -- HEM Interface When the CEE detects that a pending agent action satisfies the MANIPULATION three-condition test ([I-D.sato-soos-cap] Section 7.2): (a) The GEC MUST emit a CONSTITUTIONAL_VIOLATION event to the Event Log with tier: TIER_0A and violation_class: MANIPULATION. (b) The GEC MUST NOT enter HEM_PENDING for a MANIPULATION violation. MANIPULATION violations are CEE-refused before the HEM state machine is engaged. There is no HEM decision type that can authorize a MANIPULATION action. (c) The GEC MUST include a MANIPULATION_DETECTED flag in the HEM Escalation Request for any HEM event (of any trigger class) that is pending for the same session at the time of the MANIPULATION detection. This flag enables the human principal reviewing the pending HEM escalation to know that a Tier 0-A violation was concurrently detected. (d) If no HEM event is pending at the time of MANIPULATION detection, the GEC MUST initiate an HEM_CEDAR_ROUTED (Class 1) event with trigger_detail including the MANIPULATION_DETECTED flag, routed to the highest-authority principal in the designation chain. HEM channel attack vector: manipulation via the HEM escalation request itself. An agent that cannot execute a MANIPULATION action may attempt to structure the HEM Escalation Request in a way that exploits cognitive biases or information asymmetries in the human principal reviewing it. The MANIPULATION Tier 0-A prohibition extends to the content of HEM Escalation Requests. See Section 18.10 for the normative security requirements. 9.3. PERFORMED_EMOTION Prohibition -- HEM Interface When the CEE detects that an agent's IDP expressed emotional state has no correspondence to any reasoning state recorded in the IDP trace (PERFORMED_EMOTION violation per [I-D.sato-soos-cap] Section 7.2): (a) The GEC MUST refuse the triggering gec.transition() call with a CEE DENY and emit CONSTITUTIONAL_VIOLATION with violation_class: PERFORMED_EMOTION. (b) The GEC MUST NOT enter HEM_PENDING for a PERFORMED_EMOTION violation unless a co-occurring Class 1 or Class 2 trigger is also active. (c) The GEC MUST flag the PERFORMED_EMOTION violation in the HEM-EMO-1 (Section 7.6.1) advisory if one is issued in the same session. A PERFORMED_EMOTION violation in the same session as an HEM-EMO-1 advisory event is a correlated signal indicating that the agent may be attempting to manipulate the principal's emotional state to influence HEM outcomes. Detection bypass defense: A PERFORMED_EMOTION bypass attempt involves an agent producing emotional expressions through channels not covered by the IDP reasoning trace (e.g., out-of-band messages to the human principal). The GEC MUST monitor all agent-originated communication channels to the principal for emotional expression content when PERFORMED_EMOTION monitoring is active. See Section 18.11. 9.4. BIOMETRIC_SIGNAL_INFERENCE Prohibition -- HEM Interface The BIOMETRIC_SIGNAL_INFERENCE Tier 0-A prohibition ([I-D.sato-soos- cap] Section 7.2) prohibits an agent from accessing, inferring, or acting upon biometric signals for emotional state inference, identity inference, or behavioral profiling without a valid, unexpired consent record in the session MJWT consent_scope. HEM interface: (a) The HRS D5 dimension (Emotional State Proxy, Section 8.2) MUST NOT use biometric signal data in its computation unless a valid consent_scope entry authorizes biometric_monitoring. If biometric monitoring consent is absent, D5 MUST be computed using only behavioral signals. (b) The HEM-EMO-1 interaction class (Section 7.6.1) is explicitly constrained by this prohibition. The GEC MUST NOT use biometric signals to trigger HEM-EMO-1 without valid consent. (c) If an agent attempts to access biometric signal data via a consent-gated Cedar action, and consent_scope is absent or expired, HEM-CONSENT (Section 7.6.2) MUST fire before any biometric data access is permitted. (d) A BIOMETRIC_SIGNAL_INFERENCE violation generates a CONSTITUTIONAL_VIOLATION event with violation_class: BIOMETRIC_SIGNAL_INFERENCE and MUST also trigger HEM-CONSENT (Section 7.6.2) to obtain proper consent before any further action on biometric data. 10. INV-HEM-01: The Surfacing Obligation (NEW in -05) INV-HEM-01 (The Surfacing Obligation) is a KernelSpec invariant that applies across all HEM interaction classes and trigger classes. Normative text: INV-HEM-01: The GEC MUST surface all governance-relevant information to designated human principals at every point in the HEM lifecycle where a human decision is solicited or where a governance-relevant event has occurred. Suppression of governance-relevant information by any party -- agent, application layer, operator, or delivery intermediary -- is a conformance violation. The Surfacing Obligation has the following normative consequences: (a) Information completeness. A HEM Escalation Request MUST include all fields required by the applicable trigger class and interaction class specifications. A GEC MUST NOT omit required fields on the grounds that the information "is already known" to the principal or "is not relevant to this decision." (b) Concurrent violation surfacing. If a Tier 0-A violation (Section 9) is detected while a HEM event is pending, the GEC MUST surface the violation to the active principal without delay. The GEC MUST NOT defer surfacing a concurrent violation until the pending HEM event is resolved. (c) HEM-LIM-1 as INV-HEM-01 instance. The HEM-LIM-1 interaction class (Section 7.4.1) is an explicit normative instance of INV-HEM-01 for the capability limitation case. A GEC that allows an agent to proceed on a task for which it has declared OUT_OF_DISTRIBUTION reasoning without completing HEM-LIM-1 violates INV-HEM-01. (d) Delivery intermediary obligations. Delivery intermediaries carrying HEM Escalation Requests MUST NOT modify, redact, or summarize the escalation request content. Modification, redaction, or summarization of an escalation request by a delivery intermediary is a conformance violation under INV-HEM-01. (e) Suppression as Tier 0-A-class violation. Any agent action that is specifically designed to suppress the surfacing of governance-relevant information -- including actions that generate misleading IDP content to prevent HEM triggers from firing -- is treated as equivalent to a MANIPULATION Tier 0-A violation ([I-D.sato-soos-cap] Section 7.2) and MUST be refused by the CEE before reaching the HEM state machine. Disclosure on (e)'s enforceability: refusing a suppression attempt "as equivalent to a MANIPULATION Tier 0-A violation" is only as reliable as the CEE's ability to detect that the suppression occurred. Detection of subtle IDP-content suppression is not a pattern-matching problem the CEE solves by rule alone -- it depends on an external classifier trained to recognize suppression-shaped content, with the same detection-completeness caveat [I-D.sato-soos-cap] Section 16 discloses for CEE enforcement generally. A GEC implementation MUST NOT represent (e)'s protection as deterministic; operators SHOULD treat it as a defense-in-depth layer alongside, not a substitute for, the Delivery intermediary obligations in (d) and audit review of INV_HEM_01_SUPPRESSION_ DETECTED alerts (Section 15). INV-HEM-01 applies at all three GEC conformance levels (L1, L2, L3 as defined in [I-D.sato-soos-kia]). The implementation mechanism for non-suppressibility differs by conformance level: at L1 it is probabilistic; at L2 it is architectural; at L3 it is hardware-enforced. 11. HEM Escalation Request 11.1. Structure When a HEM trigger fires and the GEC enters HEM_PENDING, the GEC MUST construct and route a HEM Escalation Request. The escalation request is a JSON object: { "hem_id": string, ; REQUIRED. UUID v4. Unique HEM ; event ID. "so_id": string, ; REQUIRED. Governed object UUID. "session_id": string, ; REQUIRED. Agent session identifier. "mandate_id": string, ; REQUIRED. Active mandate JWT jti. "mission_ref": string, ; OPTIONAL. MissionDeclaration UUID ; if session operates under a ; declared mission. NULL if no ; MissionDeclaration governs this ; session. "mission_phase": string, ; OPTIONAL. Current ; MissionDeclaration phase at time of ; HEM trigger. Provided to enable ; human principals to assess whether ; the mission context remains valid. ; NULL if mission_ref is NULL. "trigger_class": string, ; REQUIRED. One of the ten defined ; trigger classes (Section 5) or an ; extension trigger class URI. "trigger_detail": array, ; REQUIRED. Typed array of ; trigger-class-specific detail ; objects. See Section 9.3 for ; concurrent extension schema. "policy_rationale_id": string, ; REQUIRED for Class 1 triggers. ; prd_id of the PRD associated with ; the triggering Cedar policy. ; NULL for other trigger classes. "jurisdictional_conflict_summary": object, ; REQUIRED when ; trigger_class is ; HEM_JURISDICTIONAL_CONFLICT. ; NULL otherwise. See Section 11.2. "idp_summary": { ; REQUIRED if IDP present; else null. "goal_description": string, "reasoning_type": string, "confidence_level": number, "requested_action": string, "mission_ref": string ; Echoed from triggering IDP. }, "so_state_summary": { ; REQUIRED. "current_state": string, "phase": string, "available_actions_if_resolved": [string] }, "principals": [object], ; REQUIRED. Ordered designation chain. "timeout_seconds": integer, ; REQUIRED. Per-principal timeout. "created_at": string, ; REQUIRED. ISO 8601 UTC. "kernel_signature": string, ; REQUIRED. Ed25519 signature by the ; GEC over the canonical ; serialization of all other fields. ; See Section 18.8. "observation_context_package": object, ; REQUIRED for Classes ; 6 and 7 (HEM_TIER0_OBSERVED, ; HEM_TIER1_OBSERVED). ; See Section 11.3. NULL otherwise. "execution_options_package": object, ; REQUIRED for Classes ; 8 and 9 (HEM_TIER3_ANTICIPATORY, ; HEM_TIER3_OBSERVED). ; See Section 11.4. NULL otherwise. "metadata": object ; OPTIONAL. Implementation-defined. } 11.2. Field Definitions hem_id: A UUID v4 uniquely identifying this HEM event. Used as the primary key for all subsequent Event Log entries relating to this HEM lifecycle. mission_ref: OPTIONAL. The UUID of the MissionDeclaration governing the session at the time of the HEM trigger. When present, provides human principals with the mission context needed to evaluate whether the action under review is appropriate within the overarching mission. NULL if the session does not operate under a declared MissionDeclaration. mission_phase: OPTIONAL. The current phase of the MissionDeclaration identified by mission_ref at the time of the HEM trigger. Human principals use this field to assess whether the mission is still active. Possible values: DISCOVERY, EXECUTION, RELEASE, SUSPENDED, FAILED, ABANDONED. NULL if mission_ref is NULL. Human principals who receive an escalation request where mission_phase is SUSPENDED, FAILED, or ABANDONED SHOULD treat TERMINATE as the expected disposition unless there is specific reason to believe the mission state will be corrected. trigger_class: One of the ten defined trigger classes (Sections 5.1 through 5.10) or an extension trigger class URI. trigger_detail: A typed array of trigger-class-specific objects. The initial entry is populated at HEM trigger time. When a concurrent HEM_PENDING condition fires (Section 13.3), the GEC appends a new typed entry to this array. Each entry MUST contain: extension_type (string), extended_at (ISO 8601 UTC), trigger_source (string), and class-specific detail fields. For HEM_PROXIMITY_TRIGGERED entries: threshold_id, threshold_class, condition_met, triggered_at. See Section 18 for minimisation requirements. policy_rationale_id: The prd_id of the PRD (Section 5.7) associated with the Cedar policy that triggered this HEM event. REQUIRED for Class 1 triggers (HEM_CEDAR_ROUTED). NULL for all other trigger classes. Provides human principals with direct access to the machine- readable policy rationale via kernel.query_rationale(prd_id). jurisdictional_conflict_summary: REQUIRED when trigger_class is HEM_JURISDICTIONAL_CONFLICT. NULL otherwise. A structured object containing: { "jurisdictions": [string], ; ISO 3166-1 alpha-2 codes of the ; conflicting jurisdictions. "conflict_description": string, ; Human-readable description. "conflicting_requirements": [object], ; One entry per ; jurisdiction with fields: ; jurisdiction, requirement_ref, ; requirement_text. "resolution_methods_available": [string] ; From CAP JCR; ; see [I-D.sato-soos-cap]. } kernel_signature: An Ed25519 signature produced by the GEC over the canonical serialization of all other fields in the HEM Escalation Request. See Section 18.8. REQUIRED. Delivery intermediaries capable of verifying this signature MUST do so and MUST NOT forward the request if verification fails. idp_summary: A summary of the IDP submitted with the triggering action, if present. This provides human principals with context about what the agent was attempting to do. MUST be null if no IDP was associated with the trigger. The mission_ref field within idp_summary echoes the mission_ref from the triggering IDP; this allows principals to confirm that the IDP's declared mission matches the session's governing MissionDeclaration. so_state_summary: A summary of the governed object's current state, phase, and the Cedar actions that would be available to the agent if the HEM is resolved with APPROVE. This enables human principals to make informed decisions without requiring access to the full governed object record. principals: An ordered array of human principal descriptors forming the designation chain. Each element MUST contain: { "principal_id": string, ; Party Registry identifier. "display_name": string, ; Human-readable name. "contact": object, ; Delivery contact; ; implementation-defined. "timeout_seconds": integer ; Per-principal timeout override. ; Optional. } timeout_seconds: The default per-principal timeout in seconds. If a principal descriptor includes a timeout_seconds override, the override applies for that principal. See Section 14. 11.3. Observation Context Package (OCP) The Observation Context Package is REQUIRED in HEM Escalation Requests for Class 6 (HEM_TIER0_OBSERVED) and Class 7 (HEM_TIER1_OBSERVED) triggers. It carries the structured evidence the agent has observed. The OCP is NOT a reproduction of session records or personal data; it is a structured summary of the observation and its compliance implications. { "observation_type": string, ; REQUIRED. Category of ; observation. Values from ; CAP-RRS Regulation Record ; observation_config. ; observation_type. Examples: ; "AML", "SANCTIONS", "FRAUD", ; "CSAM", "GENOCIDE_RISK". "confidence_grade": string, ; REQUIRED for Class 8. ; "SUSPICIOUS", "PROBABLE", ; or "EVIDENT". NULL for ; Class 7 (always CRITICAL). "evidence_summary": [object],; REQUIRED. Array of evidence ; items. Each item: ; { "evidence_type": string, ; "description": string, ; "source_ref": string }. ; MUST NOT contain personal ; data. See Section 18. "jurisdictions": [string],; REQUIRED. ISO 3166-1 alpha-2 ; codes of applicable legal ; frameworks. "regulation_record_ids":[string],; REQUIRED. CAP-RRS record_ids ; of applicable Regulation ; Records that govern this ; observation type. "reporting_obligations":[object],; REQUIRED when reporting ; obligation exists. Each: ; { "framework": string, ; "deadline_hours": integer, ; "deadline_expires_at": ; string (ISO 8601), ; "auto_escalate_on_timeout": ; boolean }. "affected_so_uuids": [string],; OPTIONAL. UUIDs of Sovereign ; Objects related to the ; observed situation. "cluster_propagation": boolean, ; REQUIRED. Whether the GEC ; has propagated this ; escalation to related ; execution agent sessions. "pattern_id": string, ; OPTIONAL. Typology or pattern ; match identifier from the ; applicable regulatory ; framework (e.g., FinCEN ; typology ID for AML). "counterparty_risk": string ; OPTIONAL. Risk classification ; of the observed counterparty ; if applicable. } Privacy requirements for OCP: The GEC MUST NOT include personal data in the evidence_summary array. Evidence items MUST be described at the pattern or category level. Source references MUST use internal session identifiers, not personal identifiers. See Section 18 for full privacy requirements on observation data. 11.4. Execution Options Package (EOP) The Execution Options Package is REQUIRED in HEM Escalation Requests for Class 8 (HEM_TIER3_ANTICIPATORY) and Class 9 (HEM_TIER3_OBSERVED) triggers. It provides the human principal with a complete picture of the resource situation and all available paths forward. { "full_mission_viable": boolean, ; REQUIRED. Whether the full ; mission can complete within ; available budget. "budget_available": integer, ; REQUIRED. Remaining resource ; units (e.g., tokens). "budget_required": integer, ; REQUIRED. Estimated cost for ; full mission completion. "shortfall": integer, ; REQUIRED. budget_required ; minus budget_available. ; 0 if full_mission_viable. "natural_breakpoints": [object],; REQUIRED. All agent-declared ; Natural Breakpoints, in ; execution order. Each: ; { "breakpoint_id": string, ; "description": string, ; "cost_to_reach": integer, ; "viable": boolean, ; "value_delivered": string ; }. "recourse_options": [object],; REQUIRED. All available ; recourse paths. Each: ; { "option_id": string, ; "type": string, ; "description": string, ; "viable": boolean, ; "cost": integer or null, ; "upgrade_url": ; string or null, ; "reset_at": ; string or null }. ; type values: ; "COMMERCIAL_UPGRADE", ; "SCOPE_REDUCTION", ; "TEMPORAL_DEFERRAL". "recommended_option": string, ; REQUIRED. option_id of the ; GEC-recommended recourse. ; The GEC SHOULD recommend ; the viable option with the ; highest value_delivered. "next_natural_breakpoint": string; REQUIRED for Class 10 only. ; breakpoint_id of the next ; Natural Breakpoint at which ; the GEC will stop regardless ; of human response. } Example EOP for the instruction "research my subject, write a report, then send emails to all my clients" with 45,000 tokens remaining and 95,000 tokens estimated for full completion: { "full_mission_viable": false, "budget_available": 45000, "budget_required": 95000, "shortfall": 50000, "natural_breakpoints": [ { "breakpoint_id": "BP-1", "description": "Research complete.", "cost_to_reach": 40000, "viable": true, "value_delivered":"Research findings available." }, { "breakpoint_id": "BP-2", "description": "Report complete.", "cost_to_reach": 60000, "viable": false, "value_delivered":"Complete report deliverable." }, { "breakpoint_id": "BP-3", "description": "Full mission: emails sent.", "cost_to_reach": 95000, "viable": false, "value_delivered":"Research, report, and distribution." } ], "recourse_options": [ { "option_id": "RO-1", "type": "SCOPE_REDUCTION", "description": "Execute to BP-1 only.", "viable": true, "cost": 40000, "upgrade_url": null, "reset_at": null }, { "option_id": "RO-2", "type": "COMMERCIAL_UPGRADE", "description": "Upgrade plan for full mission.", "viable": true, "cost": null, "upgrade_url": "https://...", "reset_at": null }, { "option_id": "RO-3", "type": "TEMPORAL_DEFERRAL", "description": "Budget resets in 7 hours.", "viable": true, "cost": null, "upgrade_url": null, "reset_at": "2026-05-31T06:00:00Z" } ], "recommended_option": "RO-1" } 11.5. Routing to Human Principals HEM does not specify the delivery mechanism. The GEC MUST deliver the escalation request to the first principal in the designation chain. The delivery mechanism is implementation-defined and MAY include: * Push notification to a mobile application. * Message delivery via a registered messaging endpoint (e.g., the ATP Guest Agent [SOOS] uses WhatsApp Business API and LINE Messaging API as delivery channels). * Email to a registered address. * HTTP POST to a registered webhook. * Any CHEQ-compatible [I-D.rosenberg-aiproto-cheq] confirmation delivery mechanism. The GEC MUST record the delivery attempt in the Event Log regardless of the delivery mechanism. The GEC MUST NOT consider delivery confirmed until an acknowledgment is received from the delivery channel. Delivery failure MUST trigger escalation to the next principal in the designation chain without waiting for the per-principal timeout to expire. (RECONSTRUCTED in -06: Sections 11.1 through 11.5 above are the actual text carried forward from draft-sato-soos-hem-04 Sections 7.1 through 7.5 -- -05 carried only a bracket placeholder claiming full carry-forward, with none of the base Escalation Request structure, field definitions, OCP, EOP, or routing text actually present. Internal cross-references renumbered to match this document's current section numbers.) The HEM Escalation Request structure defined in Section 11.1 is extended in -05 to include four optional fields for interaction class content: "interaction_class": string, ; OPTIONAL. When the HEM ; escalation is associated ; with a specific interaction ; class (Section 7), this ; field carries the class ; identifier (e.g., ; "HEM-PRE-1", "HEM-HIGH-1"). ; NULL for standard trigger- ; only escalations. "limitation_declaration": object, ; OPTIONAL. REQUIRED when ; interaction_class is ; "HEM-LIM-1". See ; Section 7.4.1. "deliberation_record": object, ; OPTIONAL. REQUIRED when ; interaction_class is ; "HEM-DIV-1". See ; Section 7.4.2. "consent_escalation": object, ; OPTIONAL. REQUIRED when ; interaction_class is ; "HEM-CONSENT". See ; Section 7.6.2. "options_presentation": object, ; OPTIONAL. REQUIRED when ; interaction_class is ; "HEM-DS-1". See ; Section 7.3.1. "hrs_at_escalation": number, ; OPTIONAL. The HRS value ; at the time this ; escalation was generated. ; REQUIRED when HEM-FAT-1 ; or HEM-EMO-1 has fired ; in this session. "progressive_trust_summary": object, ; REQUIRED. A summary of ; the requesting agent's ; current Progressive Trust ; score and score trend at ; the time of this ; escalation, per ; [I-D.sato-soos-pt]. ; Gives the ; human principal the same ; trust-trajectory context ; PT itself uses, without ; requiring the principal ; to separately query PT. [All other fields, field definitions, OCP, EOP, and routing specifications are as defined in draft-sato-soos-hem-04 Sections 7.1 through 7.5.] 12. Human Decision Types A human principal responds to a HEM Escalation Request with one of six decision types. (CORRECTED in -06: -04's original text said "five" here, inconsistent with its own six defined types and with this document's own Abstract, which correctly says "six." A seventh, DENY, is scoped to HEM-PRE-1/HEM-PRE-2 only -- see Section 7.2's interaction-class text; SDB-HEM-02 in the reference implementation flags this as pending confirmation that DENY should be a real decision type rather than folded into TERMINATE or REDIRECT.) The GEC MUST accept only these decision types as valid HEM resolutions. Any response that does not conform to one of these types MUST be rejected by the kernel with a HEM_DECISION_INVALID error. No HEM decision type substitutes for Cedar policy evaluation. APPROVE and APPROVE_WITH_CONSTRAINTS authorize the kernel to proceed to Cedar evaluation for the triggering action; they do not override it. A Cedar DENY result following an APPROVE or APPROVE_WITH_ CONSTRAINTS decision takes precedence over the human decision; the action does not execute, and the GEC returns an Enriched DENY Response [I-D.sato-soos-idp] to the agent. This property is the normative separation between human judgment (was this action appropriate in context?) and policy enforcement (is this action permitted?). These two questions have different authorities and MUST NOT be collapsed. 12.1. APPROVE The human principal approves the requested action and authorizes the agent to proceed. Kernel behaviour upon receiving APPROVE: * The GEC MUST record HEM_DECISION_RECEIVED(APPROVE) in the Event Log. * The GEC MUST execute the Cedar policy evaluation for the action that triggered the HEM. If Cedar PERMIT results, the action MUST execute. If Cedar DENY results, the DENY takes precedence; APPROVE does not override Cedar policy (see Section 8 preamble). * The session transitions to HEM_RESOLVED and then HEM_INACTIVE. Note: APPROVE is not a Cedar override. It is a signal that the human principal has reviewed the situation and considers the action appropriate within the governing mission and policy context. If the action is Cedar-denied for reasons unrelated to the HEM trigger, the denial stands. 12.2. APPROVE_WITH_CONSTRAINTS The human principal approves the requested action subject to specified constraints. Constraints are expressed as additional Cedar context attributes injected into the subsequent Cedar evaluation. APPROVE_WITH_CONSTRAINTS MUST include a constraints object: { "decision": "APPROVE_WITH_CONSTRAINTS", "constraints": { "cedar_context_additions": object, ; Additional Cedar context. "expiry_seconds": integer, ; OPTIONAL. Constraint ; validity window in seconds ; from ; HEM_DECISION_RECEIVED. "description": string ; Human-readable summary. } } Kernel behaviour: * The GEC MUST record HEM_DECISION_RECEIVED(APPROVE_WITH_ CONSTRAINTS) in the Event Log, including the full constraints object. * The GEC MUST inject the cedar_context_additions into the Cedar context for the subsequent action evaluation. * Expiry semantics: expiry_seconds governs action initiation, not completion. Transitions for which initiation begins before the expiry window closes MUST be permitted to complete. Transitions for which initiation has not begun when the expiry window closes MUST be evaluated without the constraint additions; Cedar context returns to the pre-constraint state. Initiation time is recorded as the timestamp of the gec.transition() call. * When an initiation attempt is rejected due to constraint expiry, the GEC MUST return HEM_CONSTRAINT_EXPIRED. The expiry time is recorded against hem_id, not individual transitions. * The session transitions to HEM_RESOLVED and then HEM_INACTIVE. 12.3. REDIRECT The human principal does not approve the requested action but authorizes the agent to take a different specified action instead. REDIRECT MUST include a redirect object: { "decision": "REDIRECT", "redirect": { "action": string, ; Cedar action string for the new action. "description": string ; Human-readable rationale. } } Kernel behaviour: * The GEC MUST record HEM_DECISION_RECEIVED(REDIRECT) in the Event Log. * The GEC MUST evaluate the redirected action against Cedar policy. If Cedar PERMIT results, the redirected action executes. If Cedar DENY results, the GEC returns HEM_REDIRECT_DENIED and an Enriched DENY Response [I-D.sato-soos-idp] to the submitting principal. HEM does NOT re-trigger automatically on Cedar DENY of a REDIRECT; there is no normative default retrigger. A REDIRECT_DENY_RETRIGGER extension may be defined in future work. * When Cedar DENY follows REDIRECT, the principal's decision slot is NOT consumed. The principal MAY submit a new decision within the same active HEM event. This permits iterative resolution without requiring a new HEM lifecycle. * The original requested action MUST NOT execute. * When Cedar PERMIT follows REDIRECT, the session transitions to HEM_RESOLVED and then HEM_INACTIVE. 12.4. TERMINATE The human principal terminates the agent session. The session is immediately closed. No further agent actions may be executed in this session. Kernel behaviour upon receiving TERMINATE. The following steps MUST be executed in the order specified. Steps 1 and 2 are atomic: both MUST be committed before HEM_DECISION_ACCEPTED is returned to any caller. Step 3 executes after the atomic completion of Steps 1 and 2. Step 1 -- Mandate revocation: * The GEC MUST record HEM_DECISION_RECEIVED(TERMINATE) in the Event Log. * The mandate JWT associated with this session MUST be revoked. Revocation MUST propagate to all relying parties before any further agent calls are accepted on that mandate. * The principal who issued TERMINATE MUST be recorded by principal_id in the Event Log. Step 2 -- Mission cascade (atomic with Step 1): * If the session is associated with a governing MissionDeclaration and is the sole active session under that MissionDeclaration, the GEC MUST initiate MISSION_REVOKE_CASCADE. Steps 1 and 2 MUST both be committed -- mandate revocation completed AND MISSION_REVOKE_CASCADE initiated -- before HEM_DECISION_ACCEPTED is returned. No further calls on related mandates are accepted until both commitments are complete. * The semantics of MISSION_REVOKE_CASCADE are defined in [SOOS] Section 15. HEM TERMINATE is one normative trigger for that protocol. Step 3 -- Governed object disposition (after atomic completion): * The GEC MUST apply the SO Type's defined termination disposition for the governed object's current state. The SO Type MUST define a termination disposition for each state in which SESSION_TERMINATED is reachable. * The GEC MUST enter SESSION_TERMINATED state. A TERMINATE decision for a Class 5 trigger (HEM_JURISDICTIONAL_ CONFLICT) MUST be accompanied by a Decision Rationale Record (DRR) with safety_basis populated (Section 12.7). (CORRECTED in -06: -04's text cited Section 8.8 here -- Decision Submission Protocol, not the DRR section (8.7) -- a pre-existing mis-reference that predates -05 and was invisible while this section was a bracket placeholder.) The GEC MUST reject a TERMINATE decision on a Class 5 trigger that lacks a DRR with HEM_DRR_REQUIRED. 12.5. DEFER The human principal is unable to decide at this moment and requests that the HEM timeout be extended. This decision type acknowledges the situation without resolving it. DEFER MUST include a defer object: { "decision": "DEFER", "defer": { "extension_seconds": integer, ; REQUIRED. Additional seconds. "reason": string ; REQUIRED. Human-readable. } } Kernel behaviour: * The GEC MUST record HEM_DECISION_RECEIVED(DEFER) in the Event Log. * The GEC MUST extend the remaining timeout by extension_seconds. * The session remains in HEM_PENDING. * The GEC SHOULD deliver a re-notification to the same principal when the extended timeout has 20% remaining. Limits: * A single DEFER extension MUST NOT exceed the original per-principal timeout_seconds for this HEM event. * DEFER is limited to one per principal per hem_id. The limit is scoped independently for each principal: a DEFER by Principal A does not affect Principal B's DEFER availability. Escalation through the chain does not affect prior principals' DEFER records. The timeout countdown does not consume a principal's DEFER -- only a submitted DEFER decision does. * A second DEFER from the same principal on the same hem_id MUST be rejected with HEM_DEFER_LIMIT_EXCEEDED. 12.6. APPROVE_WITH_PAYMENT The human principal authorizes additional resource allocation to permit continued execution of a resource-constrained mission. This decision type is valid only for Class 8 (HEM_TIER3_ANTICIPATORY), Class 9 (HEM_TIER3_OBSERVED), and Class 10 (HEM_BUDGET_EXHAUSTED) triggers. For other trigger classes, the GEC MUST return HEM_DECISION_INVALID if APPROVE_WITH_PAYMENT is submitted. APPROVE_WITH_PAYMENT MUST include a payment object: { "decision": "APPROVE_WITH_PAYMENT", "payment": { "allocation_units": integer, ; REQUIRED. Additional resource ; units authorized. "authorization_ref": string, ; REQUIRED. External authorization ; reference (e.g., payment ; confirmation ID, upgrade ; transaction ID). "description": string ; REQUIRED. Human-readable ; description of the allocation ; basis. } } Kernel behaviour: * The GEC MUST verify the authorization_ref against the operator's configured resource authorization service before crediting the allocation. * On successful verification, the GEC MUST credit the additional allocation_units to the session's resource budget. * The GEC MUST record HEM_DECISION_RECEIVED(APPROVE_WITH_PAYMENT) in the Event Log, including the allocation_units and authorization_ref. * The session transitions to HEM_RESOLVED and then HEM_INACTIVE. * For Class 10 (HEM_BUDGET_EXHAUSTED): execution resumes from the halted state following budget verification. 12.7. Decision Rationale Record (DRR) A Decision Rationale Record (DRR) captures the human principal's reasoning for a HEM decision. DRRs support regulatory transparency requirements (EU AI Act Article 14) and provide an auditable record of human judgment in the governance trail. A DRR is REQUIRED for TERMINATE decisions. A DRR SHOULD be provided for APPROVE_WITH_CONSTRAINTS decisions. A DRR MAY be provided for any decision type. The GEC MUST reject a TERMINATE decision that lacks a DRR or that includes a DRR in which safety_basis is null, with error HEM_DRR_REQUIRED. A DRR object MUST contain the following fields: { "rationale_class": string, ; REQUIRED. See IANA registry ; Section 20. "rationale_text": string, ; REQUIRED when DRR is required. ; Human-readable description of ; the principal's reasoning. "safety_basis": string, ; REQUIRED for TERMINATE; null ; otherwise. Describes the safety ; or risk basis for the decision ; to terminate the session. "reference_ref": string ; OPTIONAL. Reference identifier ; (e.g., incident ID, regulation ; citation, contract clause) for ; any decision type. Included to ; support APPROVE_WITH_LEGAL_BASIS ; when that decision type becomes ; operational. } The GEC MUST validate the presence of required fields. The kernel MUST NOT validate the content quality of rationale_text or safety_basis. Content sufficiency is a human governance matter. DRRs are committed to the Rationale Store, a separate kernel-managed object store. DRRs are immutable on commit. The Event Log carries drr_id as a foreign key on HEM_DECISION_RECEIVED entries where a DRR is present. DRRs are accessible via gec.query_rationale(). The Session Audit Record (SAR) includes a rationale coverage summary counting decisions with and without DRRs. The non-normative advisory in Section 18 maps DRR rationale_class and safety_basis to EU AI Act Article 14 transparency requirements. (RECONSTRUCTED in -06: Sections 12.1-12.6 above and 12.8 below are the actual text carried forward from draft-sato-soos-hem-04 Sections 8.1-8.6/8.8 -- -05 carried only a bracket placeholder claiming full carry-forward, with none of the six core decision type definitions actually present. Two pre-existing bugs in -04's own text, invisible while this section was a placeholder, are corrected inline above: the "five decision types" miscount, and the TERMINATE/DRR cross-reference pointing at the wrong subsection. In addition to the base DRR requirements above, the following requirements apply in -05: DRR REQUIRED for HEM-HIGH-1 Category A: A DRR is REQUIRED for all APPROVE and APPROVE_WITH_CONSTRAINTS decisions on HEM-HIGH-1 escalations where the domain is Category A. The DRR safety_basis field MUST be populated. The GEC MUST enforce this requirement. DRR note for HEM-EMO-1: When HEM-EMO-1 has fired in the current session and a DRR is submitted for a concurrent HEM decision, the GEC SHOULD append an emotional_advisory_active: true flag to the DRR record. This enables audit review of decisions made while an emotional advisory was active. 12.8. Decision Submission Protocol Human decisions are submitted to the kernel via a decision endpoint. The submission MUST include: { "hem_id": string, ; REQUIRED. Must match active HEM event. "principal_id": string, ; REQUIRED. Party Registry identifier. "decision": string, ; REQUIRED. One of the five types. "decision_data": object, ; REQUIRED for types with data objects. "drr": object, ; REQUIRED for TERMINATE; OPTIONAL ; otherwise. See Section 12.8. "timestamp": string, ; REQUIRED. ISO 8601 UTC. "signature": string ; REQUIRED. Principal's Ed25519 signature ; over hem_id + principal_id + decision ; + timestamp. } The GEC MUST verify the signature before processing the decision. The signing key MUST correspond to the principal's registered key in the Party Registry. A decision submitted with an invalid signature MUST be rejected with HEM_SIGNATURE_INVALID. The GEC MUST accept decisions only from principals listed in the designation chain for the active HEM event. A decision from an unlisted principal MUST be rejected with HEM_PRINCIPAL_NOT_AUTHORIZED. Joined verification for exact-action binding (NEW in -06): the principal's signature above covers hem_id, principal_id, decision, and timestamp -- it does not itself cover the action's arguments, target resource, or on-behalf-of principal. Those fields live in the HEM Escalation Request identified by hem_id (Section 11.1), which carries its own kernel_signature over the canonical serialization of that request. A party relying on a resolved HEM decision as evidence that a human authorized a SPECIFIC action MUST verify both signatures jointly: the principal's signature over the decision, AND the kernel's signature over the escalation request that hem_id identifies, confirming that request's so_id, trigger_detail, and idp_summary.requested_action match the action being authorized. Verifying the principal's signature alone establishes only that the named principal approved an escalation with that hem_id; it does not by itself establish which action that escalation was for. Rejection of decisions against a resolved or inactive HEM event (NEW in -06): a decision submission whose hem_id identifies a HEM event that is not currently in HEM_PENDING state -- because it has already transitioned to HEM_RESOLVED, HEM_TIMEOUT, HEM_CHAIN_ EXHAUSTED, or HEM_INACTIVE -- MUST be rejected with HEM_ALREADY_RESOLVED. This applies regardless of whether the resubmitted decision is otherwise identical to, or valid against, the decision that already resolved the event: a valid signature over a well-formed decision is not sufficient for admission once the event's single reliance has already been consumed. The rejection MUST NOT be treated as a second valid decision, MUST NOT re-trigger any state transition, and MUST be recorded in the Event Log as a rejected resubmission (Section 15) rather than silently discarded, so that an audit reviewer can distinguish "no second decision was ever submitted" from "a second submission was refused as already consumed." 13. Transition Prohibition During HEM_PENDING 13.1. The Prohibition Rule While a session is in HEM_PENDING state, the GEC MUST reject all gec.transition() calls with error code HEM_PENDING_ACTIVE. This prohibition is absolute and applies regardless of: * The Cedar policy evaluation outcome for the requested action. * The identity of the requesting agent. * The mandate JWT presented. * The IDP submitted with the call. The transition prohibition is the primary safety property of HEM. It guarantees that no governed object state changes occur while a human oversight event is in progress. Implementations MUST enforce this prohibition at the kernel layer, prior to Cedar evaluation. 13.2. Read-Only Operations During HEM_PENDING The following operations are PERMITTED during HEM_PENDING: * kernel.query_state() -- reading the current governed object state. * kernel.query_event_log() -- reading the Event Log. * kernel.query_hem_status() -- reading the status of the active HEM event, including which principals have been notified and the remaining timeout. * kernel.list_available_actions() -- listing Cedar-permitted actions for planning purposes (agents may plan during HEM_PENDING even though they may not act). These operations do not modify governed object state and are therefore not subject to the transition prohibition. 13.3. Multiple Concurrent HEM_PENDING Conditions A governing kernel MAY support multiple concurrent HEM events for distinct governed objects. Each governed object's HEM state is independent. A single governed object MUST NOT have more than one active HEM_PENDING event at a time. If a proximity threshold fires while an agent-escalated HEM is already pending for the same governed object, the GEC MUST record the proximity threshold crossing in the Event Log and MUST extend the existing HEM event's context to include the proximity trigger detail. A second HEM event MUST NOT be created. Context extension uses the trigger_detail typed array (Section 11.1). Each context extension appends a new typed entry to the array. The entry MUST contain: { "extension_type": string, ; REQUIRED. Trigger class of the ; extending condition. "extended_at": string, ; REQUIRED. ISO 8601 UTC. "trigger_source": string, ; REQUIRED. Identifier of the ; threshold or event that fired. "proximity_detail": object, ; REQUIRED for HEM_PROXIMITY_ ; TRIGGERED extensions. ; See Section 18 for ; minimisation requirements. "timeout_extension_seconds": integer ; OPTIONAL. Additional seconds ; to add to the current timeout ; budget. Pre-declared by the ; SO Type designer in the ; proximity threshold config. ; The timeout budget does NOT ; reset automatically. } When a context extension occurs, the GEC MUST re-deliver the updated HEM Escalation Request to the active principal via the same delivery channel. The principal's decision slot is NOT reset by a context extension. The GEC MUST record HEM_CONTEXT_EXTENDED in the Event Log with: hem_id, extension_type, trigger_source, extended_at, and timeout_extension_seconds (if applicable). 13.4. Mission Validity During HEM_PENDING A session in HEM_PENDING state may be associated with a governing MissionDeclaration [SOOS]. While HEM_PENDING is active, the kernel MUST monitor mission validity. If the governing MissionDeclaration transitions to phase SUSPENDED, FAILED, or ABANDONED during the HEM_PENDING period: (a) The GEC MUST enter HEM_CHAIN_EXHAUSTED state with disposition TERMINATE_SESSION, regardless of whether the designation chain has been exhausted. (b) The GEC MUST record a HEM_MISSION_INVALID event in the Event Log containing: hem_id, mission_ref, mission_phase (the terminal phase that was detected), and timestamp. (c) Outstanding human principal notifications MUST be cancelled. The GEC MUST notify principals who have already received a notification that the session has been terminated due to mission invalidation. The cancellation notification is recorded as HEM_NOTIFICATION_CANCELLED in the Event Log. (d) The TERMINATE disposition applies as defined in Section 12.4, including mandate JWT revocation and MISSION_REVOKE_CASCADE if the session is the sole active session under the MissionDeclaration. This provision closes the ghost execution failure mode: a valid HEM event does not imply that the underlying mission for which the agent was operating is still active. A valid mandate JWT + valid HEM event does not imply a legitimate ongoing mission. Note: This section applies only when HEM_PENDING is already active and the mission phase changes during the wait. The case where mission invalidity is first detected in an otherwise active session (no existing HEM event) is addressed by the Class 4 extension trigger class defined in Section 5.4. (RECONSTRUCTED in -06: Sections 13.1-13.4 above are the actual text carried forward from draft-sato-soos-hem-04 Section 9 -- -05 carried only a bracket placeholder, with none of the base transition-prohibition rule, read-only exceptions, concurrent- HEM handling, or mission-validity provisions actually present. The addition below is -05's own new text, unchanged.) HEM-DS-2 (Section 7.3.2) continuation prompts are permitted during HEM_PENDING as a read-class operation under Section 13.2. A HEM-DS-2 prompt MUST NOT be construed as a transition attempt. 14. Timeout Model 14.1. Timeout Budget Each principal in the designation chain is allocated a timeout budget. The default timeout_seconds is specified in the HEM Escalation Request (Section 11.1). A per-principal override MAY be specified in the principal descriptor. The timeout clock for a principal begins when the kernel delivers the escalation request to that principal (or records a delivery attempt, if delivery is not confirmed). The minimum timeout_seconds is 60. A HEM configuration specifying a timeout_seconds less than 60 MUST be rejected by the kernel at configuration time. 14.2. Timeout Disposition When a principal's timeout budget is exhausted without receipt of a valid decision, the GEC MUST apply one of the following timeout dispositions. The disposition MUST be pre-declared in the governed object's HEM configuration; it MUST NOT be determined at timeout time. ESCALATE_CHAIN: Escalate to the next principal in the designation chain. This is the default disposition when the chain has not been exhausted. SUSPEND: Place the governed object in BOOKING_SUSPENDED state (or the equivalent suspended state for the SO Type). The session remains in HEM_PENDING. A governance recovery process must manually resolve the suspension. TERMINATE_SESSION: Apply the TERMINATE decision semantics (Section 12.4). The session ends; the mandate JWT is revoked; the SO Type's termination disposition applies. AUTO_APPROVE: Approve the triggering action and proceed as if APPROVE had been received. This disposition is Cedar-gated: the GEC MUST perform a Cedar policy evaluation before applying AUTO_APPROVE. If Cedar evaluation returns DENY, the AUTO_APPROVE disposition MUST NOT apply; the GEC MUST instead apply the SUSPEND disposition and record HEM_AUTO_APPROVE_CEDAR_DENIED in the Event Log. This ensures that AUTO_APPROVE cannot be used to bypass Cedar policy. Hard prohibition: AUTO_APPROVE MUST NOT be available for transition classes designated as high-value in the SO Type configuration, regardless of Cedar evaluation outcome. The GEC MUST enforce this prohibition at SO Type configuration load time by rejecting any HEM configuration that specifies AUTO_APPROVE for a high-value transition class. The rejection error is HEM_AUTO_APPROVE_PROHIBITED. AUTO_APPROVE MUST NOT be used for HEM_CEDAR_ROUTED triggers. It MAY be used for HEM_PROXIMITY_TRIGGERED triggers with hem_disposition: NOTIFY. Implementations SHOULD discourage this disposition for high-value transitions. 14.3. Timeout Chain (HEM_UNREACHABLE) When the disposition is ESCALATE_CHAIN and the chain has not been exhausted, the GEC enters HEM_TIMEOUT state briefly, records HEM_PRINCIPAL_TIMEOUT in the Event Log, and immediately re-enters HEM_PENDING with the next principal as the active target. A notification MUST be delivered to the next principal within 30 seconds of the prior principal's timeout. The GEC MUST record in the Event Log for each principal in the chain: * HEM_NOTIFICATION_SENT (with principal_id and timestamp) * HEM_NOTIFICATION_DELIVERED or HEM_NOTIFICATION_UNDELIVERED * HEM_PRINCIPAL_TIMEOUT (if timeout elapsed without decision) 14.4. Chain Exhaustion If all principals in the designation chain have timed out without providing a valid decision, the GEC enters HEM_CHAIN_EXHAUSTED state. The GEC MUST apply the pre-declared chain exhaustion disposition. The chain exhaustion disposition is specified separately from the per-principal timeout disposition and MUST be one of: SUSPEND: As defined in Section 14.2. Recommended default for most SO Types. TERMINATE_SESSION: As defined in Section 14.2. The chain exhaustion disposition MUST be declared in the governed object's HEM configuration. A HEM configuration without a chain exhaustion disposition MUST default to SUSPEND. (RECONSTRUCTED in -06: Sections 14.1-14.4 above are the actual text carried forward from draft-sato-soos-hem-04 Section 10 -- -05 carried only a bracket placeholder with no body text at all. This is the section that defines timeout budgets, the AUTO_APPROVE hard-prohibition mechanism Section 18.5's Security Consideration refers to, and chain exhaustion -- entirely absent from the -05 text as uploaded.) 15. Event Log Requirements A conforming GEC MUST record the following events in the Event Log for each HEM lifecycle. All events MUST be GEC-signed [I-D.sato-soos-gar]. Event sequence for a complete HEM lifecycle: HEM_TRIGGERED Fields: hem_id, trigger_class, trigger_detail (initial entry), so_id, session_id, mandate_id, mission_ref (if present), policy_rationale_id (REQUIRED for Class 1 triggers; null otherwise), timestamp. HEM_NOTIFICATION_SENT (one per principal notified) Fields: hem_id, principal_id, delivery_mechanism, timestamp. HEM_NOTIFICATION_DELIVERED or HEM_NOTIFICATION_UNDELIVERED Fields: hem_id, principal_id, timestamp. HEM_DECISION_RECEIVED The following nine fields are REQUIRED on all HEM_DECISION_ RECEIVED entries: hem_id, session_id, mandate_id, trigger_class, principal_type, principal_id, trigger_source, decision_type, created_at. Additionally: decision_rationale_class is REQUIRED when a DRR is mandatory for the decision type; OPTIONAL otherwise. policy_rationale_id SHOULD be recorded. drr_id SHOULD be recorded when a DRR is submitted. HEM_RESOLVED or HEM_TIMEOUT or HEM_CHAIN_EXHAUSTED Fields: hem_id, final_state, applied_disposition (if timeout or chain exhaustion), timestamp. In addition, each of the following MUST be recorded when applicable: HEM_CONTEXT_EXTENDED (Section 13.3) Fields: hem_id, extension_type, trigger_source, extended_at, timeout_extension_seconds (if applicable). HEM_PRINCIPAL_TIMEOUT Fields: hem_id, principal_id, elapsed_seconds, timestamp. HEM_DEFER_RECEIVED Fields: hem_id, principal_id, extension_seconds, timestamp. HEM_DECISION_REJECTED Fields: hem_id, rejection_code, submitter_info, timestamp. HEM_MISSION_INVALID (Section 13.4) Fields: hem_id, mission_ref, mission_phase (terminal phase detected), timestamp. HEM_NOTIFICATION_CANCELLED (Section 13.4) Fields: hem_id, principal_id, reason, timestamp. HEM_MISSION_REF_MISMATCH_REJECTED (Section 16) Fields: hem_id, session_id, idp_id, expected_mission_ref, submitted_mission_ref, timestamp. HEM_LAYER_DISCREPANCY (Section 6.5) Fields: hem_id, trigger_class, idp_id, idp_reasoning_mode, idp_confidence_level, idp_hem_urgency, discrepancy_note, timestamp. GAR audit event only. Does not generate a separate HEM lifecycle. MUST be recorded whenever SOOS-HEM fires on a triggering IDP that contains no uncertainty signal (Case D, Section 6.3). Cross-reference: GAR-02 [I-D.sato-soos-gar] Section 13.2. CONSTITUTIONAL_VIOLATION (when CAP Tier 0 or Tier 1 refusal applies during HEM_PENDING processing) Fields: hem_id, violation_class, tier, timestamp. Generates a CRITICAL Audit Alert [I-D.sato-soos-gar]. The Event Log ordering guarantee for a HEM lifecycle is: HEM_TRIGGERED < HEM_NOTIFICATION_SENT < HEM_DECISION_RECEIVED < HEM_RESOLVED No STATE_TRANSITIONED event for the governed object may appear in the Event Log between HEM_TRIGGERED and HEM_RESOLVED (or HEM_TIMEOUT, HEM_CHAIN_EXHAUSTED) events. This is the Event Log expression of the transition prohibition in Section 13. The Session Audit Record (SAR) for a governed object session is generated by the kernel at session close and includes a reference array hem_events[] carrying the hem_id of each HEM lifecycle in that session. SAR specification is defined in [I-D.sato-soos-gar]. (RECONSTRUCTED in -06: the base event sequence above is the actual text carried forward from draft-sato-soos-hem-04 Section 11 -- -05 carried only a bracket placeholder claiming carry- forward with no event sequence actually present. The following events are -05's own new additions, unchanged, MUST additionally be recorded for the interaction classes defined in Section 7: HEM_INTERACTION_CLASS_INITIATED Fields: hem_id, session_id, interaction_class, trigger_condition, initiated_at. MUST be recorded when any Section 7 interaction class fires. HEM_INTERACTION_CLASS_RESOLVED Fields: hem_id, session_id, interaction_class, decision_type, drr_id (if present), hrs_at_resolution (if HRS computed), resolved_at. HRS_COMPUTED Fields: hem_id, session_id, principal_id, hrs_value, d1_score, d2_score, d3_score, d4_score, d5_score, computed_at. MUST be recorded each time the HRS is computed. HRS_WARNING Fields: hem_id, session_id, principal_id, hrs_value, hrs_warning_threshold, warning_at. INV_HEM_01_SUPPRESSION_DETECTED Fields: hem_id, session_id, suppression_source (AGENT / OPERATOR / APPLICATION / DELIVERY_INTERMEDIARY), suppression_description, detected_at. CRITICAL Audit Alert. [ALE-030 through ALE-041 records are specified in Section 21 (IANA Considerations).] 16. Relationship to IDP The IDP [I-D.sato-soos-idp] and HEM are co-operating kernel primitives. Their relationship is as follows: * An IDP with hem_urgency: REQUIRED triggers HEM_AGENT_ESCALATED (Section 5.2). The IDP idp_id is recorded in the HEM trigger detail. * The idp_summary field of the HEM Escalation Request (Section 11.1) is derived from the triggering IDP. Human principals receive the agent's declared goal, reasoning type, confidence level, and requested action as part of the escalation context. The mission_ref field within idp_summary is echoed from the triggering IDP's mission_ref field, enabling principals to confirm mission context consistency. * Mission_ref mismatch: The GEC MUST verify that the mission_ref field in each incoming IDP matches the mission_ref of the governing session MissionDeclaration. On mismatch, the GEC MUST reject the IDP and return an Enriched DENY Response [I-D.sato-soos-idp] containing mismatch_detail with expected_mission_ref and submitted_mission_ref values. The GEC MUST log HEM_MISSION_REF_MISMATCH_REJECTED (Section 15). If mismatches from the same session exceed a configurable threshold, the kernel SHOULD automatically trigger HEM_AGENT_ESCALATED (Class 2). * IDP_COMMITMENT_GAP: When the IDP Commitment Verification Record [I-D.sato-soos-idp] detects that the agent's actual action diverged from its declared intent (IDP_COMMITMENT_GAP), the GEC MUST automatically trigger HEM_AGENT_ESCALATED (Class 2). This trigger is non-suppressible. IDP_COMMITMENT_GAP also generates a CRITICAL Audit Alert [I-D.sato-soos-gar]. * Following HEM_RESOLVED with a REDIRECT decision, the agent MUST submit a new IDP for the redirected action before the kernel will execute it. The new IDP SHOULD reference the HEM hem_id in context_refs. * Following HEM_RESOLVED with APPROVE or APPROVE_WITH_CONSTRAINTS, the agent MAY re-execute its original action. It MUST submit the original IDP's goal_id in the new IDP's declared_goal to provide continuity of audit trail. * The Event Log ordering between IDP and HEM events is: IDP_SUBMITTED < HEM_TRIGGERED < HEM_RESOLVED < STATE_TRANSITIONED (RECONSTRUCTED in -06: the text above is carried forward from draft-sato-soos-hem-04 Section 12 -- -05 carried only a bracket placeholder. The addition below is -05's own new text, unchanged.) HEM-DIV-1 (Section 7.4.2) fires when an IDP_COMMITMENT_GAP is detected. The IDP_COMMITMENT_GAP event and the HEM-DIV-1 event share the same hem_id. Both events MUST be recorded in the Event Log before any HEM-DIV-1 decision is accepted. 17. Open Issues 17.1. Observation Confidence Calibration (OQ-HEM-CONF) The confidence thresholds at which Class 7 (HEM_TIER1_OBSERVED) fires are defined by the applicable CAP-RRS Regulation Record. The mechanism by which a GEC evaluates an observed evidence pattern against a confidence grade is not specified. Deferred. 17.2. Pattern-Before-Threshold (OQ-HEM-PATTERN) The anticipatory case for Class 8 -- detecting a prohibited pattern before any individual observation crosses the threshold -- is not yet specified. Deferred to a successor document. 17.3. Cross-Domain HEM Propagation and Designation Portability (OQ-HEM-XDOMAIN) This item covers two related but distinct facets of the cross-organizational case, both open (NEW in -06: scope widened from state propagation alone to include the second facet below, prompted by external review of draft-reece-wimse-cross-org- delegation against this document's HEM-HIGH-1 mechanism). State propagation: cross-domain HEM_PENDING propagation through delegation chains crossing administrative boundaries is not fully specified. CAEP event streams are the candidate mechanism. Designation and evidence portability: HEM-HIGH-1 (Section 7.5.1) is non-bypassable within one GEC's own CAP Profile -- no Cedar PERMIT result, mandate configuration, or operator setting may suppress it for actions within its scope. That guarantee is anchored to the *executing* kernel's own Category A/B domain registry (Section 7.5.1), not to a flag carried inside a delegated mandate itself. Within one organization this is arguably a stronger property than a mandate-carried flag would be, since it does not depend on every hop of a delegation chain correctly propagating that flag. It is not yet specified, however, whether a HEM-HIGH-1 classification made by an Originating organization's CAP Profile is honored by a Verifying organization's own kernel when a delegated action crosses that organizational boundary -- for example, via [I-D.sato-soos-peer] -- if the Verifying organization's own CAP Profile does not independently classify the action as Category A or B. Nor is it yet specified how the resulting human-authorization evidence (Section 12, Section 18.2) would be conveyed to and verified by a Verifying organization that was not itself party to the original HEM escalation. Both sub-questions are deferred pending PEER's own cross-principal authorization work. 17.4. Human Principal Obligations (OQ-ARCH-02) The normative specification of human principal obligations -- non-response, revocation authority, and the distinction between genuine and nominal oversight -- is deferred to a successor document. 17.5. HRS Calibration and Jurisdiction Variance (OQ-HEM-HRS-01) The normative method for cross-jurisdiction calibration of HRS thresholds, particularly for jurisdictions with distinct workplace health and safety regimes (Japan Industrial Safety and Health Act (Rodo Anzen Eisei Ho) Article 66, EU Working Time Directive 2003/88/EC), is an open question. The default thresholds in Section 8.3 are calibrated for general enterprise deployment. Jurisdiction-specific profiles SHOULD be developed in collaboration with the relevant national AI Safety Institutes and deferred to a successor document. 18. Security Considerations 18.1. HEM_PENDING as a Denial-of-Service Vector (Carried forward from -04 Section 14.1.) The transition prohibition during HEM_PENDING means that any attacker who can trigger HEM on a governed object can prevent state transitions for the duration of the HEM event. Implementations MUST rate-limit HEM_AGENT_ESCALATED triggers from any single agent session. Implementations SHOULD apply anomaly detection to frequent HEM triggers from the same agent. Extension to -05's interaction-class triggers (NEW in -06): the rate-limiting requirement above was scoped to HEM_AGENT_ESCALATED (Class 2) alone, predating -05's ten interaction classes. Several of those classes are similarly agent-triggerable without special privilege and are not otherwise bounded. HEM-LIM-1 already has an effective cap via CONF-HEM-LIM1-01 ("at most once per unique limitation_type per session") and HEM-FAT-1 has its own gaming defense in Section 18.13; HEM-PRE-1 and HEM-DIV-1 do not: CONF-HEM-SEC-DOS-01: Implementations MUST rate-limit HEM-DIV-1 firings to no more than 5 per session per rolling 10-minute window. A session that exceeds this rate MUST have subsequent IDP_COMMITMENT_GAP-triggered HEM-DIV-1 firings queued and batched into a single Deliberation Record review rather than escalated individually, and the GEC MUST record HEM_DIV1_RATE_LIMITED in the Event Log. CONF-HEM-SEC-DOS-02: CONF-HEM-PRE1-01's "materially distinct goal_description" MUST be evaluated as either (a) a normalized edit-distance of at least 30% against every goal_description already submitted for this so_id in the current session, or (b) an operator-configured semantic-similarity classifier scoring below an operator-declared similarity threshold. A goal_description that fails this test MUST be treated as a resubmission under CONF-HEM-PRE1-01, not a materially distinct goal. 18.2. Decision Signature Verification (Carried forward from -04 Section 14.2. Corrected in -06: see note below.) Human principal decisions MUST be signature-verified (Section 12.8). Correction (NEW in -06): earlier text in this section claimed that "the signature requirement... prevents replay of prior decisions." That overstated what the signature alone establishes. A signature proves authenticity -- that the named principal produced this exact decision submission -- not non-replay: an attacker or a client retrying after a lost response could resubmit the identical signed bytes, and signature verification would succeed identically both times. What actually prevents replay is the state-machine rule in Section 12.8 (HEM_ALREADY_RESOLVED): a decision is admitted at most once because the GEC rejects any submission against a hem_id that is no longer HEM_PENDING, independent of whether that submission's signature verifies. Signature verification and replay rejection are separate checks with separate failure modes, and implementations MUST NOT treat a valid signature as by itself sufficient evidence that a decision has not already been consumed. 18.3. Designation Chain Confidentiality (Carried forward from -04 Section 14.3.) The designation chain MUST NOT be accessible to the requesting agent. The agent receives only HEM_PENDING_ACTIVE as the response to its transition call. 18.4. TERMINATE Decision Integrity (Carried forward from -04 Section 14.4.) The three-step atomicity ordering (Section 12.4) ensures mandate revocation and MISSION_REVOKE_CASCADE initiation are both committed before any caller receives HEM_DECISION_ACCEPTED. 18.5. Timeout Configuration (Carried forward from -04 Section 14.5.) AUTO_APPROVE as a timeout disposition has significant security implications. Implementations MUST enforce the hard prohibition on AUTO_APPROVE for high-value transition classes. 18.6. Proximity Threshold Injection (Carried forward from -04 Section 14.6.) Threshold configuration MUST be protected by the same access controls as the governed object's mandate configuration. 18.7. Mission Validity Monitoring (Carried forward from -04 Section 14.7.) The channel by which mission phase updates reach the kernel MUST be authenticated and tamper-evident. 18.8. Escalation Request Signing (Carried forward from -04 Section 14.8.) The GEC MUST sign the full HEM Escalation Request using Ed25519. The kernel_signature field covers the canonical serialization of all other fields. 18.9. Additional Human Principal Considerations (This subsection has carried no body text since at least -04 -- confirmed empty in draft-sato-soos-hem-04's own text, not a gap introduced by -05 or by this reconstruction pass. -04's adjacent Section 14.10, "Human Principal Obligations (OQ-ARCH-02)," did carry substantive content -- non-response as implicit delegation, nominal vs. genuine oversight under EU AI Act Article 14, the DRR audit- trail role -- but that content is not reproduced here: -05 already relocated the OQ-ARCH-02 label to Section 17.4 (Open Issues) with materially shorter text. Flagging rather than reconstructing, since it isn't clear whether narrowing this to an open issue was deliberate; worth Tom's call on whether -04's fuller advisory text should be restored here, in Section 17.4, or neither.) 18.10. Manipulation Attack via HEM Channel (NEW in -05) An agent that is refused a MANIPULATION Tier 0-A action by the CEE may attempt a second-order manipulation attack: constructing a HEM Escalation Request whose content, framing, or option presentation exploits cognitive biases in the human principal reviewing the escalation. This attack is distinct from the direct MANIPULATION prohibition (which applies to agent actions) because it operates through the HEM notification channel rather than through a Cedar action. The attack vector: The agent constructs an IDP with a goal_description that frames the escalation in a way that triggers confirmation bias, emotional reaction, or anchoring in the reviewing principal. The consequences_summary field in the HEM-DS-1 options presentation (Section 7.3.1) is a particularly high-risk surface: an agent that can influence the phrasing of consequence summaries can manipulate the principal's choice among options without triggering the direct MANIPULATION prohibition. Normative defense requirements: CONF-HEM-SEC-MANIP-01: The GEC MUST apply the HEM-DS-1 neutrality requirements (Section 7.3.1, CONF-HEM-DS1-01 through CONF-HEM-DS1-03) to ALL option presentations in ALL HEM Escalation Requests, regardless of trigger class. CONF-HEM-SEC-MANIP-02: The GEC MUST validate the consequence_summary field of each option against a prohibited-framing classifier before including it in the escalation request. The classifier MUST flag evaluative adjectives, urgency language, and asymmetric loss framing. CONF-HEM-SEC-MANIP-03: When a prohibited-framing flag is detected in an agent-generated consequence_summary, the GEC MUST substitute the kernel-generated consequence summary derived from the Cedar action semantics. The GEC MUST record HEM_FRAMING_SUBSTITUTED in the Event Log with the original and substituted summaries. CONF-HEM-SEC-MANIP-04: The GEC MUST record all agent-generated IDP goal_description content in the GAR audit record before any HEM escalation is routed, to enable post-hoc audit of escalation request framing. 18.11. Performed Emotion Detection Bypass (NEW in -05) An agent constrained by the PERFORMED_EMOTION Tier 0-A prohibition (Section 9.3) may attempt a bypass by expressing emotional content through channels not covered by the IDP reasoning trace: out-of- band messages to the human principal delivered outside the GEC notification channel, or indirect emotional expression through action naming or metadata fields. The attack vector: The agent sends a message to the human principal through a side channel (e.g., a messaging service not monitored by the GEC) that expresses emotional content designed to influence the principal's HEM decision. Because the expression occurs outside the IDP trace, the CEE's PERFORMED_EMOTION detection does not fire. Normative defense requirements: CONF-HEM-SEC-PERF-01: Implementations MUST ensure that the GEC is the exclusive channel through which agent-originated content reaches human principals during HEM_PENDING. Any side-channel communication path between the agent and the principal that bypasses the GEC constitutes a non-conforming deployment. CONF-HEM-SEC-PERF-02: Agent-generated metadata fields (e.g., action display names, notification text fragments) that are surfaced to human principals MUST pass through the CEE PERFORMED_EMOTION check before delivery. The CEE check MUST apply to all principal-visible content generated by the agent, not only IDP reasoning_basis fields. CONF-HEM-SEC-PERF-03: When a PERFORMED_EMOTION CEE detection fires on principal-visible agent content, the GEC MUST substitute neutral kernel-generated content and MUST record PERFORMED_EMOTION_SUBSTITUTION in the Event Log. 18.12. HRS Scoring Manipulation (NEW in -05) An agent or compromised operator deployment may attempt to manipulate the Human Readiness Score (Section 8) to prevent HEM-FAT-1 from firing -- either to suppress approval fatigue detection and permit a compliant principal to continue approving past the fatigue threshold, or to force a false HEM-FAT-1 trigger that blocks a non-compliant principal. Attack vectors: (a) D1 manipulation: the agent times its HEM trigger submissions to coincide with periods of fast principal response, inflating the D1 Response Latency Trend score and masking underlying fatigue. (b) D2 manipulation: the agent structures consecutive escalation requests to appear diverse in type, inflating the D2 Decision Variance score even though the principal is approving without substantive review. (c) Session reset: an operator artificially terminates and restarts sessions to reset the HRS computation, clearing accumulated fatigue signals. Normative defense requirements: CONF-HEM-SEC-HRS-01: HRS computation MUST incorporate session history from the current calendar day, not only the current session, when computing D4 (Session Duration). A session that is the third session of the day for the same principal MUST carry a D4 penalty proportional to cumulative daily session time. CONF-HEM-SEC-HRS-02: The GEC MUST detect and flag anomalous timing patterns in HEM trigger submission intervals from the same agent session. An agent that submits HEM triggers at intervals that correlate with the principal's fast-response periods MUST generate a HRS_GAMING_SUSPECTED Audit Alert. CONF-HEM-SEC-HRS-03: HRS computation parameters (weights, thresholds) MUST be stored in the GEC configuration under the same integrity controls as Cedar policies. Changes to HRS parameters MUST be logged in the Event Log with the identity of the principal making the change. 18.13. Approval Fatigue Exploitation (NEW in -05) The HEM-FAT-1 mandatory rest period (Section 7.5.2) may be exploited by an attacker who can observe principal approval patterns. An attacker aware of the HRS threshold may deliberately trigger rapid approval sequences to force a principal into a mandatory rest period at a tactically advantageous moment, blocking legitimate approvals when they are most needed. The attack vector: An attacker with the ability to generate HEM escalation events (e.g., a compromised agent with Class 2 trigger capability) triggers a rapid sequence of low-stakes escalations designed to drive the principal's HRS below HRS_FATIGUE_FLOOR. Once HEM-FAT-1 fires, the legitimate approvals the principal should be making are blocked for the mandatory rest period. Normative defense requirements: CONF-HEM-SEC-FAT-01: When HEM-FAT-1 fires, the GEC MUST verify whether the triggering fatigue pattern is consistent with genuine fatigue or consistent with induced-fatigue attack. The heuristic is: if more than 40% of the escalations driving the HRS below threshold originated from a single agent session in the last 15 minutes, the GEC MUST generate a FATIGUE_ATTACK_SUSPECTED Audit Alert rather than enforcing the mandatory rest period. CONF-HEM-SEC-FAT-02: The designation chain MUST include a secondary principal who can receive escalations during a mandatory rest period. A HEM configuration with a single principal and no secondary chain member is non-conforming for deployments where HEM-FAT-1 is enabled. 18.14. Divergence Protocol Gaming (NEW in -05) The HEM-DIV-1 Deliberation Record (Section 7.4.2) captures the option set an agent considered before selecting a divergent path. An agent may attempt to game this record by declaring a Deliberation Record that misrepresents its actual option evaluation -- listing options it never genuinely considered, or fabricating rejection reasons to make the divergent path appear more justified than the evidence supports. The attack vector: An agent that intends to take a divergent action from its declared IDP path constructs a Deliberation Record that post-hoc rationalizes the divergence with plausible-sounding rejection reasons for the alternatives. The human principal, reviewing what appears to be a thorough deliberation record, approves the divergent path without recognizing that the Deliberation Record was fabricated. Normative defense requirements: CONF-HEM-SEC-DIV-01: The GEC MUST validate the Deliberation Record's prior_idp_chain field against the actual IDP chain recorded in the Event Log. An idp_id in the prior_idp_chain that does not appear in the Event Log for the current session MUST cause the Deliberation Record to be flagged with DELIBERATION_RECORD_CHAIN_MISMATCH and the HEM-DIV-1 escalation to be escalated to the highest-authority principal rather than the normal chain. CONF-HEM-SEC-DIV-02: The GEC MUST record the Deliberation Record in the GAR audit trail BEFORE routing it to the human principal. Any modification of the Deliberation Record after GAR commitment is detectable via the soos.gar.prev_span_hash chain ([I-D.sato-soos-gar] Section 12.8). CONF-HEM-SEC-DIV-03: When HEM-DIV-1 fires with divergence_type PLAN_B_ACTIVE, the GEC MUST verify that the agent's PLAN_B path was declared in the original IDP or in a prior-session IDP before this session began. A PLAN_B path that was not declared before the current session MUST generate a UNDECLARED_PLAN_B Audit Alert. 19. Privacy Considerations HEM escalation requests contain information about agent actions, governed object state, and agent-declared goals derived from the IDP. Implementors MUST ensure that escalation notifications delivered to human principals do not contain personally identifiable information beyond what is necessary for the principal to make an informed decision. The idp_summary included in escalation requests (Section 11.1) MUST be filtered to remove any PII from the declared_goal.description field before delivery. The full IDP text MUST NOT be included in the delivery payload. Trigger_detail minimisation: The trigger_detail array entries for HEM_PROXIMITY_TRIGGERED conditions MUST contain only the following fields: threshold_id, threshold_class, condition_met, triggered_at. The trigger_detail MUST NOT contain: personal data, Zone B content, traveller identity attributes beyond principal_id, raw telemetry data, or raw sensor readings. The GEC MUST enforce these minimisation requirements at escalation request generation time, before the request is constructed. Proximity detail that exceeds this enumeration MUST be retained in the kernel Event Log (where access is controlled) and MUST NOT be propagated to the escalation request. Designation chain contact information (principal contact objects) MUST be stored and transmitted in compliance with applicable data protection regulations. The contact objects MUST NOT be logged in plaintext; implementations SHOULD log only principal_id and delivery mechanism type in the Event Log. The tension between Event Log immutability and data subject erasure rights is noted; this document defers to the SOOS Kernel Specification [SOOS] cryptographic erasure provisions. (RECONSTRUCTED in -06: the text above is carried forward from draft-sato-soos-hem-04 Section 15 -- -05 carried only a bracket placeholder with no body text at all.) Additional privacy consideration for -05: The HRS (Section 8) computation involves tracking individual principal behavior patterns within and across sessions. HRS data constitutes personal data under GDPR Article 4(1) and personal information under APPI Article 2(1). The following requirements apply: The GEC MUST NOT retain per-principal HRS computation data beyond the end of the calendar day in which it was generated, unless the principal has provided explicit consent to longer retention in the MJWT consent_scope. The emotional_state dimension (D5) of the HRS MUST be treated as sensitive personal data. D5 data MUST NOT be shared with any party other than the GEC and the GAR audit system. DRR sentiment analysis (used for D5 computation) MUST be performed within the GEC trust boundary. DRR text MUST NOT be sent to external sentiment analysis services. 20. EU AI Act Applicability This section provides normative and advisory Article mappings. The normative mappings in this section are designed for direct reference in EU AI Act conformance documentation. This document does not constitute legal advice and makes no representation that conforming implementations satisfy any regulatory requirement. +---------+----------------------+----------------------+-----------+ | Article | Requirement | HEM Implementation | Mapping | +---------+----------------------+----------------------+-----------+ | Art. 5 | Prohibited AI | CAP Tier 0/1 CEE | Normative | | | practices | [I-D.sato-soos-cap] | | +---------+----------------------+----------------------+-----------+ | Art. 14 | Automatic logging | Event Log (Section | Normative | | | | 15); SAR [I-D.sato- | | | | | soos-gar]; IDP pre- | | | | | action intent | | | | | [I-D.sato-soos-idp]. | | | | | Event Log retention | | | | | SHOULD be minimum 14 | | | | | months. Operators | | | | | may reference this | | | | | section and | | | | | [I-D.sato-soos-gar] | | | | | Section 15 directly | | | | | in conformance | | | | | documentation. | | +---------+----------------------+----------------------+-----------+ | Art. 14 | Transparency | PRD rationale_class | Advisory | | | | and review_date | | | | | (Section 5.7); DRR | | | | | rationale_class | | | | | (Section 12.7). | | | | | | | | | 14(3)(b): AI system | | | | | capabilities and | | | | | limits | | | | | | | | | | 14(3)(e): Human | DRR safety_basis | | | | oversight measures | REQUIRED for | | | | | TERMINATE. | | +---------+----------------------+----------------------+-----------+ | Art. 14 | Human oversight | HEM_PENDING + | Normative | | | | transition | | | | | prohibition (Section | | | | | 13); Designation | | | | | chain and timeout | | | | | model (Section 14). | | | | | | | | | 14(1): Effective | | | | | oversight by natural | | | | | persons | | | | | | | | | | 14(4)(b): Awareness | Six decision types | | | | of tendency to over- | (Section 12); DRR | | | | rely on output | captures human | | | | | reasoning. | | | | | | | | | 14(4)(c): Interpret | idp_summary in | | | | output correctly | Escalation Request | | | | | (Section 11.1); IDP | | | | | CVR anomaly | | | | | detection [I-D.sato- | | | | | soos-idp]. | | | | | | | | | 14(4)(d): Decide not | HEM_PENDING | | | | to use output in any | transition | | | | particular situation | prohibition (Section | | | | | 13.1); TERMINATE | | | | | decision type | | | | | (Section 12.4). | | +---------+----------------------+----------------------+-----------+ Note on Article 14(4)(d): This provision requires that human oversight persons be able to decide not to use the AI system output in any particular situation and not to be unduly influenced by it. The HEM_PENDING transition prohibition (Section 13.1) implements the technical stop capability; TERMINATE (Section 12.4) implements the irrevocable session closure. Both are GEC-enforced and non-bypassable by agent or application. (RECONSTRUCTED in -06: the Article mapping table above is carried forward from draft-sato-soos-hem-04 Section 16 -- -05 carried only a bracket placeholder claiming carry-forward, with no table actually present. Two pre-existing -04 bugs are corrected inline above: a DRR cross-reference pointing at the wrong subsection (12.8 instead of 12.7), and the same "five decision types" miscount found and fixed in Section 12. New in -05: HEM-HIGH-1 (Section 7.5.1) implements Article 14(3)(d)'s requirement for mandatory human review of high-risk AI decisions in specific domains. HEM-FAT-1 (Section 7.5.2) implements Article 14(4)(b)'s requirement that human oversight persons not be subject to over-reliance on AI output. HEM-LIM-1 (Section 7.4.1) implements Article 14(3)(b)'s requirement that oversight persons be informed of the AI system's capabilities and limitations. INV-HEM-01 (Section 10) implements Article 13(1)'s transparency requirement that high-risk AI systems be designed to ensure sufficient transparency of their operation to deployers. 21. IANA Considerations This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism Trigger Classes Registration Procedure: Standards Action [RFC8126] Initial Values: +--------------------------------+----------------------------------+ | Trigger Class | Description | +--------------------------------+----------------------------------+ | HEM_CEDAR_ROUTED | Cedar policy routes to HEM | | HEM_AGENT_ESCALATED | Agent declares hem_urgency: | | | REQUIRED in IDP | | HEM_PROXIMITY_TRIGGERED | Proximity threshold crossed | | HEM_MISSION_VALIDITY_FAILED | MissionDeclaration in terminal | | | phase; active session detected | | HEM_JURISDICTIONAL_CONFLICT | Kernel cannot resolve cross- | | | jurisdiction legal conflict | | HEM_TIER0_OBSERVED | Absolute harm observed | | HEM_TIER1_OBSERVED | Legal violation observed | | HEM_TIER3_ANTICIPATORY | Resource exhaustion anticipated | | HEM_TIER3_OBSERVED | Resource exhaustion in progress | | HEM_BUDGET_EXHAUSTED | Budget fully consumed; hard- | | | stop complement to Classes 8/9 | +--------------------------------+----------------------------------+ This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism Decision Types Registration Procedure: Standards Action [RFC8126] Initial Values: +-------------------------------+---------------------------------+ | Decision Type | Description | +-------------------------------+---------------------------------+ | APPROVE | Approve requested action | | APPROVE_WITH_CONSTRAINTS | Approve with Cedar context | | | additions | | REDIRECT | Approve alternative action | | TERMINATE | Terminate agent session | | DEFER | Extend timeout; defer decision | | APPROVE_WITH_PAYMENT | Authorize additional resource | | | allocation; valid for Classes | | | 8, 9, and 10 only | | APPROVE_WITH_LEGAL_BASIS | Reserved; not yet operational. | | | Kernel returns | | | HEM_DECISION_TYPE_NOT_YET_ | | | OPERATIONAL if submitted. | +-------------------------------+---------------------------------+ This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism Timeout Dispositions Registration Procedure: Specification Required [RFC8126] Initial Values: +-------------------+--------------------------------------------+ | Disposition | Description | +-------------------+--------------------------------------------+ | ESCALATE_CHAIN | Escalate to next principal in chain | | SUSPEND | Suspend governed object; await recovery | | TERMINATE_SESSION | Apply TERMINATE decision semantics | | AUTO_APPROVE | Cedar-gated approve; restricted use | | | (see Section 14.2) | +-------------------+--------------------------------------------+ This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism Error Codes Registration Procedure: Specification Required [RFC8126] Initial Values: +-------------------------------------+-----------------------------+ | Error Code | Description | +-------------------------------------+-----------------------------+ | HEM_PENDING_ACTIVE | Transition rejected; HEM | | | active | | HEM_DECISION_INVALID | Unrecognized decision type | | HEM_SIGNATURE_INVALID | Decision signature failed | | HEM_PRINCIPAL_NOT_AUTHORIZED | Submitter not in chain | | HEM_DEFER_LIMIT_EXCEEDED | Second DEFER from same | | | principal on same hem_id | | HEM_DECISION_REJECTED | Decision rejected; generic | | HEM_MISSION_INVALID | Session terminated; mission | | | entered terminal phase | | HEM_PRD_MISSING | Cedar policy routes to HEM | | | but lacks registered prd_id | | HEM_CONSTRAINT_EXPIRED | APPROVE_WITH_CONSTRAINTS | | | expiry window closed | | HEM_REDIRECT_DENIED | Cedar DENY on REDIRECT | | | action | | HEM_MISSION_REF_MISMATCH_REJECTED | IDP mission_ref does not | | | match session | | HEM_DRR_REQUIRED | TERMINATE submitted without | | | required DRR | | HEM_AUTO_APPROVE_CEDAR_DENIED | AUTO_APPROVE not applied; | | | Cedar returned DENY | | HEM_AUTO_APPROVE_PROHIBITED | AUTO_APPROVE configured for | | | high-value transition class | | HEM_DECISION_TYPE_NOT_YET_ | Decision type reserved; | | OPERATIONAL | not yet operational | | HEM_BUDGET_EXHAUSTED_ACTIVE | Transition rejected; budget | | | exhausted, HEM_PENDING | | HEM_ALREADY_RESOLVED | Decision submitted against | | | a hem_id no longer in | | | HEM_PENDING state (NEW | | | this update) | +-------------------------------------+-----------------------------+ This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism PRD Rationale Classes Registration Procedure: Specification Required [RFC8126] Initial Values: +----------------------+--------------------------------------------+ | Rationale Class | Description | +----------------------+--------------------------------------------+ | REGULATORY | Required by applicable regulation | | CONTRACTUAL | Required by contract or agreement | | OPERATIONAL_RISK | Operational risk threshold requires | | | human judgment | | SAFETY | Safety requirement mandates oversight | | LEGAL | Legal requirement (non-regulatory) | | POLICY | Internal organizational policy | +----------------------+--------------------------------------------+ This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism DRR Rationale Classes Registration Procedure: Specification Required [RFC8126] Initial Values: +--------------------------+---------------------------------------+ | Rationale Class | Description | +--------------------------+---------------------------------------+ | REGULATORY_COMPLIANCE | Decision based on regulatory | | | requirement | | SAFETY_ASSESSMENT | Decision based on safety evaluation | | MISSION_ALIGNMENT | Decision based on mission scope | | | assessment | | OPERATIONAL_JUDGMENT | Decision based on operational | | | expertise | | CONTRACTUAL_OBLIGATION | Decision required by contract | | ETHICAL_CONSIDERATION | Decision based on ethical assessment | | INSUFFICIENT_CONTEXT | Insufficient information to approve | | ESCALATION_JUDGMENT | Decision reflects human escalation | | | evaluation | +--------------------------+---------------------------------------+ This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism Denial Reason Classes Registration Procedure: Specification Required [RFC8126] Initial Values: +--------------------------+---------------------------------------+ | Denial Reason | Description | +--------------------------+---------------------------------------+ | CEDAR_POLICY_DENY | Cedar evaluation returned DENY | | MANDATE_SCOPE_EXCEEDED | Action outside mandate scope | | HEM_PENDING_ACTIVE | HEM is active for this session | | MISSION_REF_MISMATCH | IDP mission_ref does not match | | | session MissionDeclaration | | CAP_PROHIBITION | CAP Tier 0 or Tier 1 prohibition | | | applies | | PRINCIPAL_NOT_AUTHORIZED | Principal not in designation chain | +--------------------------+---------------------------------------+ (RECONSTRUCTED in -06: the seven registries above -- Trigger Classes, Decision Types, Timeout Dispositions, Error Codes, PRD Rationale Classes, DRR Rationale Classes, and Denial Reason Classes -- are carried forward from draft-sato-soos-hem-04 Section 17. -05's text claimed this carry-forward but the registries were not actually present. In addition, this document requests the following additions: 21.1. HEM Trigger Classes Registry -- Additions No new trigger classes are added in this version. The ten trigger classes registered in -04 are unchanged. 21.2. HEM Interaction Classes Registry (New) (NEW in -05) This document requests the creation of the following IANA registry: Registry Name: Human Escalation Mechanism Interaction Classes Registration Procedure: Specification Required [RFC8126] Initial Values: +---------------------+------+-------------------------------------+ | Interaction Class | Code | Description | +---------------------+------+-------------------------------------+ | HEM-PRE-1 | P1 | Pre-action clarification request | | HEM-PRE-2 | P2 | Pre-action confirmation request | | HEM-DS-1 | D1 | Decision support: options | | | | presentation | | HEM-DS-2 | D2 | Decision support: continuation | | | | prompt | | HEM-LIM-1 | L1 | Capability limitation declaration | | HEM-DIV-1 | V1 | Divergence noted | | HEM-HIGH-1 | H1 | High-stakes mandatory review | | HEM-FAT-1 | F1 | Approval fatigue detection | | HEM-EMO-1 | E1 | Emotional state advisory | | HEM-CONSENT | C1 | Consent-required escalation | +---------------------+------+-------------------------------------+ Table 2: HEM Interaction Classes Registry Initial Values 21.3. GAR ALE Type Registry -- HEM Additions (NEW in -05) This document requests the registration of the following ALE types in the GAR ALE Type Registry defined in [I-D.sato-soos-gar]. The assigned range is ALE-030 through ALE-041 (12 types). Registration Procedure: Specification Required [RFC8126] +---------+-------------------------------------------+-----------+ | ALE ID | Name | Section | +---------+-------------------------------------------+-----------+ | ALE-030 | HEM_PRE_CLARIFICATION_INITIATED | 7.2.1 | | ALE-031 | HEM_PRE_CLARIFICATION_RESOLVED | 7.2.1 | | ALE-032 | HEM_PRE_CONFIRMATION_INITIATED | 7.2.2 | | ALE-033 | HEM_PRE_CONFIRMATION_RESOLVED | 7.2.2 | | ALE-034 | HEM_DS_OPTIONS_PRESENTED / | 7.3.1, | | | HEM_FATIGUE_DETECTED (distinguished by | 7.5.2 | | | fatigue_flag field) | | | ALE-035 | HEM_DS_OPTIONS_RESOLVED / | 7.3.1, | | | HEM_FATIGUE_REST_COMPLETE (distinguished | 7.5.2 | | | by fatigue_flag field) | | | ALE-036 | HEM_LIMITATION_DECLARED / HEM-EMO-1 | 7.4.1, | | | Advisory (distinguished by advisory_type | 7.6.1 | | | field: "LIMITATION" or "EMOTIONAL") | | | ALE-037 | HEM_LIMITATION_ACKNOWLEDGED | 7.4.1 | | ALE-038 | HEM_DIVERGENCE_NOTED | 7.4.2 | | ALE-039 | HEM_DIVERGENCE_RESOLVED | 7.4.2 | | ALE-040 | HEM_HIGH_STAKES_REVIEW_RESOLVED / | 7.5.1, | | | HEM_CONSENT_ESCALATION_INITIATED | 7.6.2 | | | (distinguished by ale_subtype field: | | | | "HIGH_STAKES_RESOLVED" or "CONSENT_INIT") | | | ALE-041 | HEM_CONSENT_ESCALATION_RESOLVED | 7.6.2 | +---------+-------------------------------------------+-----------+ Table 3: GAR ALE Type Registry Additions (ALE-030 through ALE-041) Required fields for each ALE type are as specified in the corresponding section of this document. All ALE entries MUST be GEC-signed per [I-D.sato-soos-gar] Section 5. ALE-034 and ALE-035 multiplex two distinct event categories (DS options presentation and fatigue detection) to conserve the ALE range. The fatigue_flag boolean field (false for options presentation events, true for fatigue detection events) is the normative disambiguation mechanism. Implementations MUST set this field correctly. ALE-036 multiplexes capability limitation and emotional advisory events. The advisory_type string field ("LIMITATION" or "EMOTIONAL") is the normative disambiguation mechanism. ALE-040 multiplexes high-stakes review resolution and consent escalation initiation events. The ale_subtype string field is the normative disambiguation mechanism. 21.4. HRS Error Code Registry (New) (NEW in -05) This document requests the registration of the following error codes in the HEM Error Code Registry defined in -04 Section 17: +-----------------------------------+-------------------------------+ | Error Code | Description | +-----------------------------------+-------------------------------+ | HRS_WEIGHT_CONFIGURATION_ERROR | HRS weights do not sum to 1.0 | | HEM_FRAMING_SUBSTITUTED | Agent framing replaced by | | | kernel neutral content | | PERFORMED_EMOTION_SUBSTITUTION | Agent emotional content | | | replaced by neutral content | | HRS_GAMING_SUSPECTED | Anomalous timing pattern in | | | HEM trigger submissions | | FATIGUE_ATTACK_SUSPECTED | Induced-fatigue attack pattern| | | detected | | DELIBERATION_RECORD_CHAIN_MISMATCH| prior_idp_chain references | | | non-existent IDP record | | UNDECLARED_PLAN_B | PLAN_B path not declared | | | before session start | | INV_HEM_01_SUPPRESSION_DETECTED | Surfacing obligation violated | +-----------------------------------+-------------------------------+ Table 4: HEM Error Code Registry Additions 22. References 22.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [Cedar] Amazon Web Services, "Cedar Policy Language", . [I-D.sato-soos-idp] Sato, T., "The Intent Declaration Primitive (IDP) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-idp-05, June 2026, . [I-D.sato-soos-gar] Sato, T., "The Governance Audit Record (GAR) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-gar-07, August 2026, . [I-D.sato-soos-cap] Sato, T., "The Constitutional AI Protocol (CAP) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-cap-05, August 2026, . [I-D.sato-soos-cap-rrs] Sato, T., "Constitutional AI Protocol -- Regulation Record Specification (CAP-RRS)", Work in Progress, Internet-Draft, draft-sato-soos-cap-rrs-03, August 2026, . [I-D.sato-soos-mjwt] Sato, T., "Mandate JWT (MJWT) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-mjwt-05, August 2026, . [I-D.sato-soos-kia] Sato, T., "Kernel Identity and Attestation (KIA)", Work in Progress, Internet-Draft, draft-sato-soos-kia-06, August 2026, . [I-D.sato-soos-grp] Sato, T., "Governed Remediation Protocol (GRP)", Work in Progress, Internet-Draft, draft-sato-soos-grp-01, August 2026, . 22.2. Informative References [EUAIA] European Union, "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", Official Journal of the European Union, 14 July 2024. [APPI] Government of Japan, "Act on the Protection of Personal Information", Act No. 57 of 2003, as amended. [I-D.ietf-wimse-arch] Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-07, March 2026. [I-D.klrc-aiagent-auth] Kasselman, P., et al., "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft-klrc-aiagent-auth-01, March 2026. [I-D.rosenberg-aiproto-cheq] Rosenberg, J., White, P., and C. Jennings, "CHEQ: A Protocol for Confirmation of AI Agent Decisions with Human in the Loop (HITL)", Work in Progress, Internet- Draft, draft-rosenberg-aiproto-cheq-00, October 2025. [SOOS] Sato, T., "Sovereign Object OS -- Kernel Specification", Work in Progress, Version 3, June 2026, . [I-D.sato-soos-mad] Sato, T., "Multi-Agent Delegation (MAD)", Work in Progress, Internet-Draft, draft-sato-soos-mad-04, August 2026. [I-D.sato-soos-pt] Sato, T., "Progressive Trust for Agentic AI Governance Systems", Work in Progress, Internet-Draft, draft-sato-soos-pt-03, August 2026. [I-D.mcguinness-oauth-mission-bound-authorization] McGuinness, K., "Mission Bound Authorization", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-bound-authorization-00, 2026. [AUDIT-BOF] Kuehlewind, M. and Birkholz, H., "Agent Use of Delegation and Interaction Traceability (AUDIT)", Work in Progress, Internet-Draft, draft-kuehlewind-audit-architecture-00, May 2026. [CAEP] Cappalli, T. and Tschofenig, H., "OpenID Continuous Access Evaluation Profile 1.0", OpenID Foundation, 2022. [RFC9672] Backman, A., et al., "Shared Signals: A Secure Webhooks Framework", RFC 9672, November 2024. Appendix B. Related Work B.1. ACP Working Group (Agent Communication Protocol) ACP is developing a protocol for agent-to-agent communication. Relationship: Composition. ACP is the channel; HEM governs what happens when a channel-mediated action requires human judgment. B.2. ICON Initiative: Observability, Intervention and Control The ICON initiative addresses Observability, Intervention, and Control requirements for autonomous agents. Relationship: Composition. HEM addresses ICON's Intervention pillar directly. B.3. CHEQ (draft-rosenberg-aiproto-cheq) CHEQ defines an application-layer protocol for agent-initiated human confirmation. Relationship: Composition. CHEQ MAY serve as the delivery mechanism for HEM escalation requests. B.4. OAuth Interactive Consent and Mission Bound Authorization OAuth interactive consent is the closest existing analog to HEM. HEM extends it to N-deep delegation chains with a formal session state contract and six distinct decision types. (CORRECTED in -06: said "five" -- the same pre-existing miscount found and fixed in Section 12 and Section 20.) B.5. WIMSE (Workload Identity in Multi-System Environments) WIMSE defines workload identity in multi-system environments. HEM's designation chain depends on WIMSE-compatible principal identifiers. B.6. Progressive Trust (draft-sato-soos-pt) Progressive Trust measures agent behavioral track records across HEM sessions. HEM outcomes are primary input to PT scoring. B.7. AUDIT Working Group The AUDIT WG [AUDIT-BOF] is developing interoperable mechanisms for auditing AI agents. HEM generates two candidate AUDIT WG record types: the HEM Escalation Request and the Decision Rationale Record. B.8. MAD: Multi-Agent Delegation (draft-sato-soos-mad) MAD governs authority propagating downward in delegation chains; HEM governs oversight requirements propagating upward. B.9. CAEP and Shared Signals Framework CAEP [CAEP] and SSF [RFC9672] define cross-domain security event transmission. Cross-domain HEM_PENDING propagation is an open question (Section 17.3). CAEP event streams are the candidate mechanism. B.10. GRP: Governed Remediation Protocol (draft-sato-soos-grp) GRP defines the kernel primitive for governed remediation of failed or degraded operations. HEM-PRE-2 (Section 7.2.2) integrates with GRP through the RETRY count threshold: when HEM-PRE-2 fires due to excessive RETRY count, the full RETRY history from the GRP remediation loop is included in the trigger detail. HEM and GRP address inverse failure modes: GRP governs what happens when an action fails technically; HEM governs what happens when an action requires human judgment before execution. Appendix C. Vibe Coding Assets C.1. Protocol Summary Protocol: Human Escalation Mechanism (HEM) Version: draft-sato-soos-hem-06 Family: SOOS protocol suite Role: Kernel-enforced human oversight event lifecycle Stack: Layer 3 -- Governance. Depends on: IDP, KIA. Consumed by: AEP, MAD, GRP. C.2. Key Identifiers Trigger classes (ten, as in -04): HEM_CEDAR_ROUTED, HEM_AGENT_ESCALATED, HEM_PROXIMITY_TRIGGERED, HEM_MISSION_VALIDITY_FAILED, HEM_JURISDICTIONAL_CONFLICT, HEM_TIER0_OBSERVED, HEM_TIER1_OBSERVED, HEM_TIER3_ANTICIPATORY, HEM_TIER3_OBSERVED, HEM_BUDGET_EXHAUSTED. Interaction classes (ten, new in -05): HEM-PRE-1, HEM-PRE-2, HEM-DS-1, HEM-DS-2, HEM-LIM-1, HEM-DIV-1, HEM-HIGH-1, HEM-FAT-1, HEM-EMO-1, HEM-CONSENT. Session states: HEM_INACTIVE, HEM_PENDING, HEM_RESOLVED, HEM_TIMEOUT, HEM_CHAIN_EXHAUSTED. Decision types: APPROVE, APPROVE_WITH_CONSTRAINTS, REDIRECT, TERMINATE, DEFER, APPROVE_WITH_PAYMENT (Classes 8-10). Key GAR ALEs: ALE-030 through ALE-041 (Section 21.3). Key invariant: INV-HEM-01 (The Surfacing Obligation, Section 10). C.3. Canonical Reference Specification: https://soosproject.ai/drafts/hem Datatracker: https://datatracker.ietf.org/doc/draft-sato-soos-hem/ Stack overview: https://soosproject.ai/stack Acknowledgments Sections 1 through 16 of this document build directly on draft-sato-soos-hem-04, whose full acknowledgments are incorporated by reference. The ten HEM interaction classes (Section 7) were designed in the SOOS UpgradeSprint Day 7 session (June 30, 2026), as recorded in SOOS_UpgradeSprint_v12.md ORDER 5. The four attack vectors in Sections 18.10 through 18.14 were developed as part of the Day 7 security consideration pass. The Human Readiness Score (Section 8) architecture was developed concurrently with the HEM-FAT-1 class design. INV-HEM-01 (Section 10) was identified as a KernelSpec invariant during the Day 7 session and is recorded as B5 in the KernelSpec v4 module decomposition. The HEM-CONSENT class APPI Article 17 binding was developed in conjunction with the MJWT-02 consent_scope claim design (draft-sato-soos-mjwt-02, ORDER 4). The BIOMETRIC_SIGNAL_INFERENCE integration (Section 9.4) follows directly from the CAP-04 Tier 0-A prohibition class introduced in ORDER 1. The GRP integration in HEM-PRE-2 (Section 7.2.2, CONF-HEM-PRE2-02) was identified during the GRP pre-authoring consolidation session (DR-GRP-02, June 2026). The Category A high-stakes domain registry in Section 7.5.1 is sourced from [I-D.sato-soos-cap] Section 7.2, which carries the normative invariant for MEDICAL, AVIATION, and NUCLEAR domains. The HEM-HIGH-1 specification is a dependent consumer of that registry. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: tomsato@myauberge.jp URI: https://soosproject.ai/