Network Working Group T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 30 June 2026 Expires: 30 December 2026 The Human Escalation Mechanism (HEM) for Agentic AI Systems draft-sato-soos-hem-05 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. Section 7 (Human Readiness Score) and Section 8 (Tier 0-A Integration) are new normative sections. 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 30 December 2026. 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_PENDING Propagation (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. [Sections 5.1 through 5.12 are carried forward from -04. Full normative text for each class is as specified in draft-sato-soos- hem-04, Sections 5.1 through 5.12.] 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. [Sections 6.1 through 6.5 are carried forward from -04 without modification. Full normative text is as specified in draft-sato-soos-hem-04, Sections 6.1 through 6.5.] 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 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. The HRS does not persist across sessions. 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_ADVISORY_ | 0.35 | 0.20/0.50| HEM-EMO-1 advisory | | FLOOR | | | | | HRS_WARNING_THRESHOLD | 0.55 | 0.35/0.70| GEC logs HRS_WARNING| | 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. 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 [Sections 11.1 through 11.5 carry forward the content of draft-sato-soos-hem-04 Sections 7.1 through 7.5, renumbered, with the following additions:] The HEM Escalation Request structure defined in -04 Section 7.1 is extended in -05 to include three 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. [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 [Sections 12.1 through 12.8 carry forward the content of draft-sato-soos-hem-04 Sections 8.1 through 8.8 without modification, renumbered. The following additions apply:] 12.7. Decision Rationale Record (DRR) In addition to the DRR requirements in -04 Section 8.8, 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. 13. Transition Prohibition During HEM_PENDING [Carried forward from draft-sato-soos-hem-04 Section 9 without modification, renumbered. The following addition applies:] 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 [Carried forward from draft-sato-soos-hem-04 Section 10 without modification, renumbered.] 15. Event Log Requirements [The event sequence specification in draft-sato-soos-hem-04 Section 11 is carried forward. The following additions apply:] The following events 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 [Carried forward from draft-sato-soos-hem-04 Section 12 without modification. The following addition applies:] 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_PENDING Propagation (OQ-HEM-XDOMAIN) Cross-domain HEM_PENDING propagation through delegation chains crossing administrative boundaries is not fully specified. CAEP event streams are the candidate mechanism. Deferred. 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. 18.2. Decision Signature Verification [Carried forward from -04 Section 14.2.] Human principal decisions MUST be signature-verified (Section 12.8). The signature requirement over hem_id + principal_id + decision + timestamp prevents replay of prior decisions. 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 [Carried forward from -04 Section 14.9.] 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 [Carried forward from draft-sato-soos-hem-04 Section 15 without modification.] 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 [The Article mapping table in draft-sato-soos-hem-04 Section 16 is carried forward. The following additions apply:] 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 carries forward all IANA registry requests from draft-sato-soos-hem-04 Section 17 without modification. 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 | 7.5.2 | | | (distinguished by fatigue_flag field) | | | ALE-035 | HEM_DS_OPTIONS_RESOLVED / | 7.3.1, | | | HEM_FATIGUE_REST_COMPLETE | 7.5.2 | | | (distinguished by fatigue_flag field) | | | ALE-036 | HEM_LIMITATION_DECLARED / | 7.4.1, | | | HEM-EMO-1 Advisory | 7.6.1 | | | (distinguished by advisory_type 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-03, June 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-04, June 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-02, June 2026, . [I-D.sato-soos-mjwt] Sato, T., "Mandate JWT (MJWT) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-mjwt-02, July 2026, . [I-D.sato-soos-kia] Sato, T., "Kernel Identity and Attestation (KIA)", Work in Progress, Internet-Draft, draft-sato-soos-kia-03, June 2026, . [I-D.sato-soos-grp] Sato, T., "Governed Remediation Protocol (GRP)", Work in Progress, Internet-Draft, draft-sato-soos-grp-00, July 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-03, June 2026. [I-D.sato-soos-pt] Sato, T., "Progressive Trust for Agentic AI Governance Systems", Work in Progress, Internet-Draft, draft-sato-soos-pt-02, May 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. [RFC8417] Hunt, P., et al., "Security Event Token (SET)", RFC 8417, July 2018. 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 five distinct decision types. 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 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 and SSF 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-05 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/