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