SPEC-015: Escalation & Attention Policy

Document ID:      SPEC-015
Title:            Escalation & Attention Policy
Version:          1.0
Status:           RATIFIED
Layer:            L5 — Swarm Governance
Authoritative:    Human-Agent Coordination
Parent Specs:     SPEC-000 (System Manifesto), SPEC-003 (Invariant Register), SPEC-005 (Rulebook)
Date Ratified:    2026-03-19
Grounding:        post-flood/specs/SPEC-015/grounding.md
Risk Register:    post-flood/specs/SPEC-015/risk-register.md
Bibliography:     post-flood/specs/bibliography.bib
Principal Author: https://orcid.org/0009-0008-2007-3596

---

1. Attention as the Scarce Resource

SPEC-015 is fundamentally an attention-conservation system, not an information-routing system. Simon (1971) identified the foundational asymmetry: "A wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it."

Every escalation that reaches the human operator consumes irreplaceable attention. Unlike LLM tokens (which can be purchased) or CI minutes (which renew monthly), human attention is a fixed-capacity resource that degrades with fatigue, cannot be stockpiled, and regenerates only through rest. An escalation policy that routes every anomaly to the operator is a denial-of-service attack on the system's most critical resource.

ESCL-001: The Attention-Conservation Principle

Simon's criterion for a well-designed information subsystem: it "absorbs more information than it produces -- it listens and thinks more than it speaks." Applied to SPEC-015:

1. Each level of the escalation hierarchy MUST be a net attention absorber
2. Agents MUST exhaust their own resolution capacity before escalating
3. Escalation summaries MUST be pre-digested, not raw
4. The operator's response options MUST be pre-structured (approve/deny/modify), not open-ended

Operational test: Does the escalation hierarchy reduce net demand on the operator's attention? If the system without escalation would require monitoring all 112 repos continuously, and the system with escalation requires 5-10 escalation responses per session, the hierarchy is functioning. If the pipeline produces 50 escalation alerts per session, it has failed -- it is generating attention demand, not absorbing it.

---

2. Four-Level Triage

Escalation events are classified into four severity levels. Classification determines routing, presentation format, and required response.

ESCL-002: Triage Levels

Level	Name	Condition	Routing	Response Time
T1	Routine	Agent can resolve within scope; no governance impact	No escalation -- agent resolves autonomously	Immediate (agent handles)
T2	Elevated	Agent needs confirmation but situation is bounded; governance impact is local	Escalation to operator with recommendation	Next review session
T3	Critical	Invariant threatened or cross-organ impact; agent cannot resolve without authority	Immediate escalation with three-level SA summary	Within current session
T4	Emergency	System-wide invariant violation, data corruption risk, or constitutional breach	Immediate escalation with compressed summary; all agent operations paused	Immediate

ESCL-003: Triage Classification Criteria

Criterion	T1 (Routine)	T2 (Elevated)	T3 (Critical)	T4 (Emergency)
Governance scope	No governance change	Single-repo governance	Cross-repo or cross-organ governance	Constitutional or system-wide
Invariant impact	No invariant affected	Invariant preserved with care	Invariant at risk	Invariant violated or actively degrading
Reversibility	Easily reversible	Reversible with effort	Difficult to reverse	Irreversible (data loss, corruption)
Blast radius	Single file or function	Single repo	Multiple repos or organs	System-wide
Precedent	Routine operation	Known pattern	Novel situation	No precedent

ESCL-004: Classification Examples

Situation	Level	Rationale
Adding tests to a module	T1	No governance impact; fully within agent scope
Promoting a repo from LOCAL to CANDIDATE	T2	Governance change, but bounded and reversible
Promoting a repo to GRADUATED	T3	Cross-organ implications; effectively irreversible in practice
Dependency cycle detected in production registry	T4	INV-000-001 violated; system integrity at risk
Agent discovers registry-v2.json has < 50 repos	T4	Data corruption; save_registry guard would fire
Modifying governance-rules.json	T3	Constitutional impact; requires human confirmation
Agent finds conflicting instructions in two CLAUDE.md files	T2	Bounded ambiguity; agent should report and request clarification
Agent cannot determine whether a change violates AX-000-003	T3	Constitutional judgment required; agent cannot resolve

---

3. Three-Level Situation Awareness

Every escalation carries three levels of situation awareness information (Endsley 1995). An escalation providing only Level 1 forces the operator to reconstruct Levels 2 and 3 from scratch -- the most attention-intensive part of escalation handling.

ESCL-005: SA Level Requirements

SA Level	Content	Example (T3: GRADUATED promotion)
Level 1: Perception	What elements are involved? Which repos, agents, governance rules? What changed?	"Repo X in ORGAN-III has passed all SPEC-004 guard conditions. Claude session ABC is requesting promotion to GRADUATED."
Level 2: Comprehension	What does it mean? Which invariants are affected? What is the blast radius?	"Promotion would make repo X the 2nd GRADUATED repo in ORGAN-III. All soak-test criteria met for 30 days. Downstream dependency impact: repos Y and Z consume repo X's produces edges."
Level 3: Projection	What will happen next? If no action is taken, will the system degrade? Deadlines at risk?	"Omega criterion #14 (GRADUATED promotion) advances from 4/17 to 5/17. No negative trajectory detected. Deferring promotion has no deadline consequence."

ESCL-006: SA Error Prevention

Endsley's (1995) SA error taxonomy identifies three failure types that SPEC-015's escalation format must prevent:

SA Error Type	Agent Failure	Escalation Design Prevention
Level 1 failure (perception)	Escalation omits critical context	ESCL-005 mandates explicit element listing
Level 2 failure (comprehension)	Escalation provides numbers without meaning ("3 violations" without specifying which)	ESCL-005 mandates invariant identification and blast radius
Level 3 failure (projection)	Escalation lacks trend data or deadline context	ESCL-005 mandates trajectory projection and deadline impact

---

4. Escalation Presentation

ESCL-007: Structured Escalation Format

Every T2+ escalation follows this format:

ESCALATION [T2|T3|T4]
═══════════════════════
SITUATION (Level 1):
  Agent:       [agent handle and class]
  Scope:       [session scope declaration]
  Element:     [specific repo/organ/file involved]
  Trigger:     [what triggered the escalation]

ASSESSMENT (Level 2):
  Invariants:  [which invariants are affected, if any]
  Blast radius: [what else is impacted]
  Precedent:   [has this situation occurred before?]
  Rule refs:   [which RULE-NNN or INV-NNN apply]

PROJECTION (Level 3):
  If approved: [expected outcome]
  If deferred: [what happens if no action taken]
  If denied:   [consequences of denial]
  Deadline:    [relevant time constraints]

RECOMMENDATION:
  [Agent's recommended action with justification]

RESPONSE OPTIONS:
  [A] Approve recommendation
  [B] Approve with modification: ___
  [C] Deny with reason: ___
  [D] Request more information: ___

ESCL-008: Anti-Clumsy-Automation Requirement

Woods and Hollnagel (2005) identified "clumsy automation" as the design pathology where automation works well under normal conditions but increases human workload precisely during anomalies. SPEC-015's anti-clumsy-automation requirement:

Escalation presentations MUST be inversely proportional to situation severity. The worse the crisis, the more compressed the initial summary must be, with drill-down available on demand.

Level	Initial Presentation	Drill-Down Available
T2	Full structured format (ESCL-007)	Detailed context on request
T3	Compressed: 3-sentence summary + response options	Full format on request
T4	Single-line: "[EMERGENCY] INV-000-001 violated in registry-v2.json. All agent operations paused. [A] Investigate [B] Revert"	Full format + audit trail on request

A T4 emergency that presents 47 individual violation reports (rather than a single synthesized summary with drill-down) violates ESCL-008.

---

5. Dilemma Reports

Not all escalations involve governance violations. Some involve genuine normative ambiguity where the agent cannot determine the correct action because the governance rules produce competing obligations.

ESCL-009: Dilemma Report Structure

A Dilemma Report is generated when an agent encounters a situation where:

1. Two or more RULE-NNN obligations apply to the same entity in the same context
2. Satisfying one obligation prevents satisfying another
3. The agent cannot resolve the conflict through SPEC-005's defeasibility rules (priority ordering)
4. The conflict is not a rule error but a genuine normative tension

DILEMMA REPORT [T3]
════════════════════
CONFLICTING OBLIGATIONS:
  Rule A: [RULE-NNN] requires [action X]
  Rule B: [RULE-NNN] requires [action Y]
  Conflict: [action X] prevents [action Y]

DEFEASIBILITY ANALYSIS:
  Priority ordering: [result of SPEC-005 Section 5.1 analysis]
  Specificity: [result of specificity comparison]
  Resolution: [why SPEC-005's resolution mechanism fails here]

RECOMMENDED RESOLUTION:
  [Agent's recommended interpretation with justification]

GOVERNANCE CONSEQUENCE:
  [What precedent this resolution sets for future cases]

ESCL-010: Dilemma Resolution Authority

Dilemma Type	Resolution Authority	Governance Record
Operational (RULE vs. RULE within same level)	Human operator	Recorded as governance event in ontologia
Constitutional (RULE vs. invariant)	Human operator + adversarial review	Recorded as potential SPEC amendment trigger
Meta-governance (constraint about constraints)	Human operator + documented precedent	Recorded as constitutional interpretation

---

6. Situation Awareness Maintenance

ESCL-011: The Automation Paradox

As ORGANVM's agents handle more governance tasks autonomously, the operator has fewer routine interactions maintaining familiarity with system state. When an escalation arrives, the operator must reconstruct SA from a degraded baseline (Endsley 1995). SPEC-015 counteracts this with SA maintenance mechanisms independent of escalation events:

Mechanism	Frequency	Content	SA Level Maintained
Organism snapshot	On-demand via organvm organism	System-wide health state, organ density, gate status	Level 1 (perception)
Session review summary	End of each session	What changed, what was reviewed, what remains	Level 2 (comprehension)
Heartbeat report	Daily (when system is active)	Aggregate: promotions today, test results, staleness warnings	Level 1 + Level 2
Trajectory projection	Weekly or on-demand	Omega progress, deadline status, promotion pipeline forecast	Level 3 (projection)
Governance audit	On-demand via organvm governance audit	Full compliance report across all rules	All three levels

ESCL-012: SA Maintenance Is Not Escalation

SA maintenance mechanisms operate on a pull model (operator requests when ready) rather than a push model (system interrupts operator). The distinction is critical:

• Escalation (push): system interrupts operator because agent authority is insufficient
• SA maintenance (pull): operator queries system state to maintain mental model calibration

The only exception: T4 emergencies push notifications regardless of operator readiness, because system integrity is at stake.

---

7. Joint Cognitive System Design

ORGANVM is a joint cognitive system (Woods & Hollnagel 2005): the human operator and AI agents function as a coupled unit, not as separate entities exchanging data. The unit of analysis is the JCS, not the human or the machine in isolation.

ESCL-013: The Substitution Myth

When agents take over governance tasks that the operator previously performed, the operator's role does not diminish -- it transforms. The operator moves from "doing governance" to "monitoring agent governance and handling exceptions." This transformation changes cognitive demands:

Before (doing)	After (monitoring)	Cognitive Shift
Reviewing every code change	Reviewing agent-flagged changes	From generation to evaluation
Running governance audits manually	Reviewing automated audit results	From procedure execution to anomaly detection
Making promotion decisions case-by-case	Confirming or overriding agent recommendations	From deliberation to judgment
Tracking system state continuously	Reconstructing state from snapshots	From maintenance to reconstruction

SPEC-015 designs for the "after" cognitive demands, not the "before" demands.

ESCL-014: Coordination Cost Budgeting

Every transfer of authority between human and agent incurs coordination overhead (Woods & Hollnagel 2005). The structured handoff protocol minimizes this overhead:

1. Agent provides: Situation summary at all three SA levels (ESCL-005)
2. Operator selects: From pre-structured response options (ESCL-007)
3. Agent confirms: Selected option and resumes execution
4. System records: Handoff in governance audit trail

Coordination cost per handoff should decrease as agent and operator develop shared conventions. But since AI agents have no persistent state, the conventions must be encoded in context (CLAUDE.md), not in agent memory -- an asymmetry the JCS framework was not designed for (see Section 8.1).

---

8. Contestation Disclosures

8.1 JCS in Asynchronous Context

Status: ADAPTED (risk register claim #5)

Woods and Hollnagel (2005) developed JCS for tightly coupled, real-time human-machine systems (aviation cockpits, nuclear control rooms). ORGANVM's human-AI coupling is looser: asynchronous sessions, git-mediated state, multiple concurrent agents. The JCS principles (coordination costs, substitution myth, authority negotiation) apply, but the coupling dynamics differ. Real-time JCS requires split-second handoff protocols; ORGANVM's handoffs operate on the timescale of minutes to hours.

8.2 Single-Operator Assumption

SPEC-015 designs for a single human operator (AX-000-003). If ORGANVM ever acquires multiple operators (contributors, collaborators), the escalation architecture must handle multi-stakeholder attention allocation -- a fundamentally different problem from single-operator attention conservation. The current architecture is optimized for the solo-operator case and will require redesign for multi-operator governance.

---

9. Evolution Constraints

SPEC-015 may be amended through the following governed process only.

9.1 Amendment Types

Type	Definition	Requirements
Triage Adjustment	Modifies classification criteria or adds examples to triage levels	Adversarial review + creator sign-off
Format Revision	Modifies the escalation presentation format (ESCL-007)	Demonstrated attention-conservation improvement + adversarial review + creator sign-off
SA Mechanism Addition	Adds a new situation awareness maintenance mechanism	Evidence of SA gap + adversarial review + creator sign-off
Level Addition	Adds a 5th triage level or modifies the T1-T4 structure	New grounding narrative + adversarial review + human spot-check + creator sign-off

9.2 Permanent Identifiers

ESCL identifiers (ESCL-001 through ESCL-014) are permanent. Removed items have their identifiers retired, not reassigned.

9.3 Versioning

The original SPEC-015 is never overwritten. Amendments are versioned: SPEC-015-v1.1, v1.2, etc.

---

10. Traceability

10.1 Upward Traceability (to SPEC-000)

SPEC-000 Element	SPEC-015 Grounding
AX-000-003 (Individual Primacy)	ESCL-001 -- escalation conserves the operator's irreplaceable attention
AX-000-004 (Constitutional Governance)	ESCL-002/003 -- triage levels ensure governance violations reach appropriate authority
AX-000-005 (Evolutionary Recursivity)	Section 9 -- escalation policy evolves through governed amendment
INV-000-004 (Constitutional Supremacy)	ESCL-010 -- dilemma resolution respects constitutional hierarchy
INV-000-005 (Observability)	ESCL-011 -- SA maintenance mechanisms ensure system state is observable to the operator

10.2 Lateral Traceability

Peer Spec	Connection
SPEC-003 (Invariant Register)	Triage classification (ESCL-003) references invariant impact as key criterion
SPEC-005 (Rulebook)	Dilemma Reports (ESCL-009) invoke SPEC-005 defeasibility analysis
SPEC-013 (Swarm Topology)	Supervisory hierarchy (SWARM-006) defines the escalation chain
SPEC-014 (Resource Constraints)	Human attention budget (RSRC-011) motivates attention conservation
SPEC-016 (Epistemic Routing)	SA maintenance (ESCL-011) routes knowledge queries for state reconstruction
SPEC-017 (Authority Matrix)	Triage routing (ESCL-002) respects authority level requirements

10.3 Downward Traceability (to implementation)

SPEC-015 Element	Current Code Location	Alignment
Organism snapshot (ESCL-011)	metrics/organism.py, CLI: organvm organism	ALIGNED
Session review (ESCL-011)	session/debrief.py, session/analysis.py	ALIGNED
Governance audit (ESCL-011)	governance/audit.py, CLI: organvm governance audit	ALIGNED
Triage classification (ESCL-002/003)	Not implemented	MISSING
Structured escalation format (ESCL-007)	Not implemented	MISSING
Dilemma Reports (ESCL-009)	Not implemented	MISSING
Anti-clumsy-automation (ESCL-008)	Not implemented	MISSING
Heartbeat reports (ESCL-011)	Not implemented	MISSING
Trajectory projection (ESCL-011)	omega/scorecard.py (partial -- omega status only)	DRIFT

10.4 Academic Lineage

SPEC-015 Element	Traditions	Key Sources
Attention conservation (ESCL-001)	Information economics	Simon 1971
Triage levels (ESCL-002/003)	Human factors engineering	Endsley 1995
Three-level SA (ESCL-005/006)	Situation awareness theory	Endsley 1995
Anti-clumsy-automation (ESCL-008)	Cognitive systems engineering	Woods & Hollnagel 2005
Automation paradox (ESCL-011)	Human factors	Endsley 1995, Woods & Hollnagel 2005
JCS design (ESCL-013/014)	Joint cognitive systems	Woods & Hollnagel 2005

Full grounding narrative: post-flood/specs/SPEC-015/grounding.md (4,200+ words) Full risk register: post-flood/specs/SPEC-015/risk-register.md (5 classified claims) Full bibliography: post-flood/specs/bibliography.bib