Escalation

定義

Escalation

Escalation とは、ある actor または child frame が、
現在の responsibility bundle、authority scope、goal slice、governance constraints の内部では
合法・安全・妥当な continuation を確定できない と判断したときに、
その subject、evidence、pending gates、local state、requested decision を、
より適切な authority を持つ actor または frame へ
継続可能な形で引き上げる transition である。

それは単なる「助けを求めること」ではなく、
authority overflow、goal ambiguity、scope conflict、policy conflict、incident, recovery illegality, join conflict などに対して、
containment、decision transfer、rerouting、replan / rollback / closure judgment を行うための governed transition である。

より短く言えば、Escalation とは
「この先を自分の bundle では決めてはいけない、または安全に進められない」と分かったときに、その判断をより上位または別系統の authority へ引き上げること
である。

PCE 2.0 において escalation は、失敗の印や弱さの告白ではない。
それは bounded autonomy の限界を process 上で正しく扱うための正規遷移である。
長時間・多主体・高統治の仕事において、escalation がない process は、たいてい hidden override か silent drift を生む。

この意味で Escalation は、
Transitions の中でも、責任の非対称性をもっとも明示的に表す遷移の一つである。

なぜ Escalation が必要なのか

PCE 2.0 では、すべての actor が同じ authority を持つわけではない。
むしろ process が壊れないためには、持たないこと が重要である。
その結果、局所 actor はしばしば「ここから先は自分では決められない」という境界にぶつかる。
Escalation は、その境界を正しく扱うために必要である。

少なくとも、次の理由がある。

1. bounded autonomy を破らずに進行を維持するため

child frame や local executor は、局所的には自律していてよい。
しかし global goal、scope 変更、exception 承認、incident closure まで持つべきではないことが多い。
Escalation がないと、local actor は

勝手に決める
進行を止めたまま凍る
暗黙の authority smuggling をする

のいずれかに流れやすい。

2. goal ambiguity や trade-off conflict を local に閉じ込めないため

次のような状況は、local execution の範囲を越える。

in-scope / out-of-scope が衝突する
speed と correctness の優先順位が決められない
current goal slice が実質的に別の仕事へ広がっている
reframe が必要そうだが local actor にその権限がない

このとき escalation なしに進むと、goal drift が起きやすい。

3. governance failure を隠さないため

required approval bypass、policy conflict、unauthorized action、stale recovery などは、
local fail として握りつぶすより、governance-aware な path へ引き上げるべきである。
Escalation は hidden violation を visible exception に変える。

4. incident と normal work を切り分けるため

重大な failure や recovery illegality が起きたとき、
通常 execution をそのまま続けるのは危険である。
Escalation により、

stop する
authority を集める
blast radius を見積もる
replan / rollback / abandon を決める

という異常時フローへ移れる。

5. parent-child / branch-and-join を壊さないため

child frame や sibling branch が conflict を起こしたとき、
そのまま local に解こうとすると parent の retained authority が失われやすい。
Escalation は、階層構造のまま conflict を上位へ返すために必要である。

Escalation は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておく。

1. 単なる Handoff ではない

Handoff は continuity を別 actor に渡して work を続けてもらう遷移である。
Escalation は continuity を引き上げるが、中心は work continuation ではなく authority resolution にある。

2. 単なる Incident ではない

incident は状態または事態であり、escalation は遷移である。
incident がなくても escalation は起こりうる。
たとえば local actor が scope ambiguity を解けないだけでも escalation は起こる。

3. 単なる Approval ではない

approval は well-formed な subject に対する ratification である。
escalation は、そもそも local approval では解けない subject を引き上げる。

4. 単なる Evaluation ではない

evaluator は fail、insufficient evidence、conflict を示せる。
escalation は、その結果を受けて「誰が次を決めるか」を変える。

5. 単なる Replan ではない

replan は新しい path を設計することである。
escalation は、replan が必要かどうかを決める authority へ引き上げる遷移である。
escalation の結果として replan が起こることはある。

6. 単なる Rollback ではない

rollback は以前の状態へ戻す遷移である。
escalation は rollback を 命じるか / 許可するか / 必要と判断するか を扱う。

7. 単なる「質問」ではない

軽い clarification request は通常の coordination で済むことが多い。
Escalation は、現在の local bundle では正当な continuation が決められないときに起こる。

Escalation が扱う subject

PCE 2.0 において escalation の subject は artifact に限られない。
少なくとも次のような subject が引き上げられうる。

1. Goal / Scope Subject

in-scope / out-of-scope conflict
success criteria ambiguity
trade-off requiring owner decision
suspected need for reframe

2. Governance Subject

required approval bypass
policy violation
unauthorized action
capability overreach
conflicting governance rules

3. Evaluation Subject

conflicting evaluator verdicts
insufficient evidence with no local remediation path
disagreement between blocking and advisory signals that requires authority resolution

4. Recovery Subject

recovery point appears stale or invalid
resume legality is unclear
rollback anchor conflict
drift too large for local resume

5. Integration / Join Subject

sibling branch conflict
child returns inconsistent with parent constraints
comparative branch needs winner selection
all-of join blocked by one child’s failure

6. Incident Subject

severe failure
blast radius uncertainty
repeated local remediation failure
abnormal-flow decision requiring containment

つまり escalation は、
「current bundle では解けない decision burden」
を subject とする遷移である。

Escalation Trigger の主な型

Escalation を起こす trigger は、少なくとも次の family に分けられる。

1. Authority Overflow Trigger

現在の actor に、その subject を決める authority がない。

例:

executor が scope change を必要としている
reviewer が release-wide implication を発見した
child frame が parent-level merge authority を必要としている

2. Ambiguity Trigger

local execution や local evaluation では解けない曖昧性がある。

例:

spec ambiguity
conflicting design intent
unclear acceptance boundary

3. Governance Conflict Trigger

policy、approval、scope、permission の衝突がある。

例:

required approval path が contradictory
policy says stop but schedule pressure says continue
visibility boundary and required evidence conflict

4. Risk Threshold Trigger

同じ action でも、risk が一定閾値を超えたため local continuation が不適切になる。

例:

blast radius bigger than child frame scope
rollback path missing
security/compliance implications detected

5. Repeated Failure Trigger

local loop で何度もやり直しているが、改善していない。
この場合、単なる rework ではなく path decision の見直しが必要になる。

6. Recovery Invalidity Trigger

recover / resume が legal かどうか local actor では判断できない、または明らかに危険である。

7. Join Conflict Trigger

複数 branch や child return のあいだで contradiction が生じ、
local reducer では解けない。

Escalation Path と Escalation Sink

Escalation は「誰か偉そうな人に投げること」ではない。
PCE 2.0 では、可能なら 事前に path と sink を定義 すべきである。

Escalation Path

現在の actor / frame から、どの trigger で、どの sink へ引き上げるかを定めた routing である。

Escalation Sink

実際にその escalation を引き受ける actor または frame である。
多くの場合、次のいずれかになる。

goal owner
approver with wider scope
incident owner
release owner
governance-backed policy owner
dedicated incident-analysis child frame

ここで重要なのは、sink は「最終解決者」である必要はないということだ。
sink はさらに別の path へ reroute してもよい。
ただし、誰が受理したか は常に traceable でなければならない。

Escalation は何を移すのか

Escalation は everything transfer ではない。
多くの場合、移るのは decision burden であって、work 全体ではない。

典型的に target に移るもの

ambiguity resolution responsibility
exception decision responsibility
replan / rollback / abandon decision
risk acceptance / refusal decision
higher-scope approval decision

典型的に source 側に残るもの

source context の事実説明責任
evidence 供給責任
current local work state の保存責任
escalation 決定後の rework / continue execution responsibility
local rollback 実行責任（決定後）

つまり escalation はしばしば、
work transfer ではなく judgment transfer
として理解した方が正確である。

Escalation Package

PCE 2.0 では escalation は、曖昧な「助けてください」ではなく、
continuity-preserving package として渡されるべきである。

escalation package が持つべきもの

current frame / actor / bundle
escalation subject
trigger
why local resolution is insufficient
attempted local actions
relevant evidence refs
pending gates
affected deltas
blast radius estimate
rollback anchors
requested decision types
urgency / severity
retained responsibilities
next expected action after ruling

これは Handoff の特殊形だが、
通常 handoff よりも authority と abnormality の情報が厚い。

Escalation と他責任の関係

Escalation と Goal Ownership

goal ambiguity や reframe needs の escalation は、
しばしば goal owner に向かう。
ただし escalation 自体は goal ownership と同一ではない。
source は local ambiguity cannot be resolved を渡し、sink が goal-level decision を返す。

Escalation と Approval

approval は定義済みの subject を ratify する。
escalation は、そもそも通常 approval では解けない subject を引き上げる。
approval path の conflict や override request が escalation subject になることもある。

Escalation と Evaluation

evaluation は inadequacy / conflict / insufficient evidence を示せる。
escalation は、それを受けて local continuation から authority resolution path へ切り替える。

Escalation と Incident Ownership

incident owner は最も典型的な escalation sink の一つである。
しかしすべての escalation が incident ではない。
goal ambiguity や join conflict は incident でなくても escalation しうる。

Escalation と Memory Writing

memory writing 自体は escalation の中心ではないが、
sensitive memory promotion や governance memory conflict が escalated write decision になることはありうる。

Escalation と Lifecycle の関係

Escalation は lifecycle を大きく変える。
典型的には次のような遷移が起こる。

1. Active → Escalation Pending

通常進行中だった frame が、上位判断待ちの状態に入る。

2. Active → Suspended + Escalated Overlay

安全のため current execution を止め、authority resolution を待つ。

3. Pending Approval → Escalation Pending

approval だけでは解けない conflict となり、別 authority が必要になる。

4. Recovering → Escalation Pending

recover legality がローカルに判断できない場合。

5. Join Integrating → Escalation Pending

child returns の conflict が統合不能な場合。

つまり escalation は、
通常 progression を authority resolution phase に切り替える lifecycle transition である。

Lifecycle 上は、たとえば次のように表せる。

active
  -> escalation_pending
  -> resolved_to:
       active
       replan_pending
       rollback_pending
       suspended
       completed
       abandoned
       superseded

詳しくは Lifecycle を参照する。

Escalation Resolution の代表パターン

escalation sink が返しうる代表的な resolution は次のとおりである。

1. Clarify and Return

曖昧性を解き、source へ work continuation を返す。

2. Approve Exception

通常ルールからの例外を認める。
この場合、traceability が特に重要になる。

3. Order Rework

local rework で戻す。
source は execution を再開するが、前提条件が更新される。

4. Authorize Replan

frame や branch set を再設計する。

5. Order Rollback

以前の safe state へ戻す。

6. Spawn Incident / Analysis Child

局所では処理しきれないため、専用 child frame を切る。

7. Transfer Ownership

場合によっては goal owner、incident owner、integration owner が変わる。

8. Close / Abandon / Supersede

current path の continuation を止める。

ここで重要なのは、
escalation の結果は「答え」だけではなく、
次の合法遷移を再定義すること だという点である。

Escalation と Handoff の関係

Escalation はしばしば handoff を伴うが、通常の handoff とは違う。

通常 handoff

次の actor が continuation を進めるために渡す。

Escalation handoff

次の actor が continuation を決める ために渡す。

そのため escalation handoff では、特に次が重要になる。

local resolution attempts
why current bundle is insufficient
what decision is being asked for
what stays frozen until decision
what can continue speculatively and what cannot

つまり escalation handoff は、
work package よりも decision package に近い。

Escalation と Checkpoint / Recovery の関係

Escalation は、しばしば Checkpoint and Recovery を要求する。

Escalation 前

危険な local state を checkpoint しておくと、

source continuity を失わない
escalation rejection 時に戻れる
later audit が可能
rollback anchor を保持できる

Escalation 中

frame は suspended / blocked に入ることが多い。
pending escalation state は recovery-aware であるべきだ。

Escalation 後

resolution に応じて、

recover and resume
rollback and resume
replan then instantiate child
close

などへ進む。

したがって escalation は、
abnormal-flow recovery semantics と非常に近い。

Escalation と Parent-Child / Branch-and-Join の関係

Parent-Child

child frame は local bounded autonomy を持つが、
親の retained authority を越える判断は escalation によって parent へ返すべきである。

典型例:

child implementation frame が scope ambiguity を見つける
child evaluation frame が parent policy conflict を見つける
child incident が parent incident sink へ上がる

Branch-and-Join

sibling branch の conflict や all-of join blockage は、
しばしば integration owner や parent goal owner への escalation を必要とする。

典型例:

implementation branch と rollback-readiness branch が矛盾する
option A と option B の比較で local reducer が決められない
one required branch is failing repeatedly and parent decision is needed

つまり escalation は、
hierarchical topology を崩さずに authority overflow を上位へ戻す 手段である。

Escalation の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置ける。

escalation_transition:
  transition_id:
  frame_id:
  source:
    actor_ref:
    bundle_ref:
  escalation_subject:
    kind:
    refs:
    scope:
  trigger:
  severity:
  requested_decision:
  attempted_local_actions:
  retained_responsibilities:
  suspended_responsibilities:
  pending_gates:
  delta_refs:
  evidence_refs:
  rollback_anchor_ref:
  target:
    actor_ref:
    frame_ref:
    authority_basis:
  expected_resolution:
    - clarify_and_return
    - approve_exception
    - order_rework
    - authorize_replan
    - order_rollback
    - transfer_ownership
    - close
  lifecycle_effects:
  recovery_binding:
  audit_requirements:
  provenance:

もう少し package 指向に書くなら、次のようにも置ける。

escalation_package:
  escalation_id:
  source_ref:
    frame:
    actor:
    bundle:
  target_ref:
    actor:
    frame:
  subject:
  reason:
  why_local_resolution_fails:
  urgency:
  severity:
  affected_scope:
  evidence_refs:
  pending_gates:
  delta_state_refs:
  current_lifecycle_state:
  requested_resolution:
  retained_local_duties:
  frozen_actions:
  rollback_anchor:
  recompile_requirements_after_resolution:
  provenance:

このスキーマで重要なのは、次の点である。

subject と trigger がある
local で処理できない理由がある
retained と suspended を分けている
target sink と authority basis がある
requested resolution がある
lifecycle / recovery / audit に接続している

つまり escalation は、
単なる message ではなく authority-resolution package として扱われるべきである。

小さな例

feature.checkout.coupon-combination frame で reviewer が diff を確認したところ、
coupon logic の修正に payment gateway の変更が混入していたとする。
payment gateway は親 frame の out_of_scope であり、しかも rollback path も不十分である。

reviewer は local approval では解けないと判断し、product owner へ escalation する。

escalation_transition:
  transition_id: esc.feature.checkout.coupon-combination.scope-conflict.v1
  frame_id: feature.checkout.coupon-combination
  source:
    actor_ref: reviewer
    bundle_ref: reviewer_bundle_v1
  escalation_subject:
    kind: governance_conflict
    refs:
      - delta_item.code_patch
      - rollback_note_v1
    scope: feature.checkout.coupon-combination
  trigger: out_of_scope_change_detected
  severity: feature_high
  requested_decision:
    - clarify_if_scope_expansion_is_allowed
    - if_not_allowed_order_rework_or_rollback
  attempted_local_actions:
    - reviewer_checked_diff
    - reviewer_checked_required_evidence
    - reviewer_could_not_approve_with_current_scope
  retained_responsibilities:
    - review_context_preservation
    - evidence_traceability
  suspended_responsibilities:
    - code_review_approval
  pending_gates:
    - code_review_approval
  delta_refs:
    - delta.feature.checkout.coupon-combination.v3
  evidence_refs:
    - code_diff_ref
    - approved_spec_summary
    - rollback_note_v1
  rollback_anchor_ref:
    - rp.feature.checkout.coupon-combination.after-impl.v1
  target:
    actor_ref: product_owner
    frame_ref: feature.checkout.coupon-combination
    authority_basis:
      - goal_ownership
      - incident_ownership
  expected_resolution:
    - order_rework
    - authorize_replan
  lifecycle_effects:
    - frame_progression_to_escalation_pending
    - review_suspended
  recovery_binding:
    - pending_escalation_must_be_recoverable
  audit_requirements:
    - escalation_record
  provenance:
    created_by: reviewer

product owner は escalation を受理し、payment gateway 変更を out-of-scope と再確認し、
rollback 可能な差分へ戻すよう order_rework を出す。
その結果、

frame は replan_pending ではなく active に戻る
coding agent へ rework handoff が行われる
old review context は stale とされる
later failure memory candidate が生成されうる

この例で重要なのは、reviewer が勝手に scope を広げて approve しないこと、
また product owner が自分でコードを書かなくても escalation sink として process を reroute できることだ。

Escalation の不変条件

PCE 2.0 では、少なくとも次の不変条件を置ける。

1. No escalation without explicit subject

何について引き上げているのか曖昧な escalation は不完全である。

2. No escalation without explicit insufficiency claim

なぜ local bundle では解けないのかが必要である。
単なる「不安だから上げる」では足りない。

3. Escalation does not erase local responsibility

source は evidence、continuity、post-resolution execution などの責任を失わないことが多い。

4. No hidden authority transfer

escalation により target が何を決められるのか、source が何を retain するのかを明示すべきである。

5. Pending escalation must be recoverable

later session でも escalation pending state を失ってはならない。

6. Escalation resolution must change legal next transitions

resolution が process にどう効くかが明示されていなければならない。

7. Escalation is not approval by another name

通常 approval path で解けるものを、安易に escalation にしてはならない。

8. Escalation records must be attributable

誰が、何を、なぜ、どこへ引き上げ、どう解決されたか追える必要がある。

9. Branch / child conflicts must not silently self-resolve beyond delegated scope

親が retain した authority を child や local reducer が黙って越えてはならない。

10. Escalation should reduce abnormal uncertainty, not amplify it

良い escalation は、問題の blast radius と decision burden を整理して target に渡すべきである。

いつ Escalation すべきで、いつ local に解くべきか

これも実務上かなり重要である。

Escalation すべき典型条件

local authority を越える
goal / scope ambiguity が本質的である
policy / governance conflict がある
repeated local remediation failed
rollback / replan / abandon judgment が必要
recovery legality が不明
sibling / child conflict を local で解けない

Local に解くべき典型条件

local rework で十分戻せる
evidence を追加すれば evaluator が再判定できる
bounded scope 内の implementation choice にすぎない
normal approval path で解ける
temporary blockage であり higher authority を必要としない

短く言えば、
current bundle の範囲内で criteria / evidence / local rework により解けるなら local、
authority / risk / scope / continuity を越えるなら escalation
である。

最低限の自己点検

ある process が escalation-aware かどうかは、次で点検できる。

どんな trigger で escalation が起きるか定義しているか
escalation subject を明示できるか
local で解けない理由を示せるか
escalation sink が決まっているか
source が retain する責任を言えるか
resolution が next transitions をどう変えるか分かるか
escalation pending state を recovery 可能にしているか
escalation と approval / replan / rollback / incident を混同していないか
parent-child や branch conflict で retained authority を守れているか
escalation record を traceable に残せるか

このどれかが欠けるなら、その process はまだ escalation を十分に設計していない。

暫定的なまとめ

Escalation が言っていることは、最終的には次の一文に集約できる。

bounded autonomy は、全部を local に解くことではなく、local に解いてはいけない境界を知ることまで含む。
escalation は、その境界を越えたときに、仕事を壊さず、責任を空白にせず、より適切な authority へ判断を引き上げるための遷移である。

PCE 2.0 において escalation は、失敗の烙印ではない。
それは、非対称な責任構造を process の中で正しく使うためのメカニズムである。

だから Escalation は、単なる「相談」ではない。
それは、PCE 2.0 において 局所 bundle の限界を越えた判断・異常・競合を、上位または別系統の authority へ governed に移送する authority-routing transition である。