Incident Ownership

定義

Incident Ownership

Incident Ownership とは、ある Actor が、ある Process Frame において、
通常の execution、evaluation、approval の流れでは安全・合法・妥当な継続ができなくなった事態を
引き取り、分類し、封じ込め、進路変更し、再開または終了を決める責任 である。

それは単なる「問題が起きたら対応すること」ではなく、
incident intake、severity classification、containment authority、scope / authority freeze、rollback / replan / escalation decision、resume authorization、closure acceptance、post-incident traceability を含む。

より短く言えば、Incident Ownership とは
「通常フローの外へはみ出した failure / violation / ambiguity / risk を、誰が最終的に引き受け、どう止め、どう進路を変え、どう収束させるか」を持つ責任
である。

PCE 2.0 において process は、常に理想的な順路だけを辿るわけではない。
scope violation、authority conflict、重大な failure、recovery 不能、goal ambiguity、external risk などにより、通常の progression が成立しなくなることがある。
そのときに必要なのは「誰かが直すこと」だけではなく、誰がその事態を process 上で引き受けるか である。

この意味で Incident Ownership は、
Responsibility-first を異常時・逸脱時の側から具体化した責任である。

Incident とは何か

PCE 2.0 では、すべての error や fail を incident と呼ぶわけではない。
incident は、通常の局所 bundle の中では安全に処理しきれず、進路の再決定 を必要とする事態である。

単なる local failure と incident の違い

Local failure

局所的な execution や evaluation の範囲で処理できる失敗。

例:

test が落ちたが executor がすぐ修正可能
summary が不足していて再提出すればよい
candidate memory が evidence 不足で pending になる

Incident

そのまま通常の flow を続けると process integrity、governance、external correctness、continuity のいずれかが損なわれる事態。

例:

prohibited capability を使った
out-of-scope の変更が混入した
required approval を飛ばして merge されそうになっている
rollback 不能な変更が混ざった
goal ambiguity が大きく、local actor では解けない
recovery point から legal に再開できない
repeated failure が bundle の限界を超えている

つまり incident とは、
普通の fail ではなく、「普通に続けること自体が問題になる」状態 である。

Incident の典型クラス

PCE 2.0 では、incident を少なくとも次のように分類できる。

1. Correctness Incident

結果の正しさや整合性が大きく損なわれる事態。

例:

critical regression
rollback 不可能な不整合
acceptance criteria の重大違反

2. Governance Incident

approval、policy、scope、authority の違反が起きた事態。

例:

required approval bypass
prohibited tool use
unauthorized write
canonical/provisional 混同による誤昇格

3. Continuity Incident

handoff、recovery、pending gate continuity が壊れ、process が安全に継続できない事態。

例:

pending approval state の消失
stale context のまま resumed
recovery point が不整合

4. Scope / Goal Incident

goal や scope の解釈が通常 execution では扱えない水準で崩れた事態。

例:

feature が別の feature へ drift している
in-scope / out-of-scope が衝突している
success criteria が実質的に破綻している

5. External-risk Incident

対外影響や組織的リスクが高い事態。

例:

security-sensitive path への unintended change
compliance / policy-sensitive data exposure
release-wide blast radius の可能性

6. Coordination Incident

multi-actor process の責任境界が壊れ、通常 handoff では処理できない事態。

例:

owner 不在
evaluator/approver conflict
contradictory governance signals
repeated failed handoff causing process stall

この分類は taxonomy のためというより、
どの incident sink / owner topology が必要かを考えるため に重要である。

なぜ Incident Ownership が必要なのか

PCE 2.0 が Incident Ownership を独立の責任として置く理由は、
通常フローが壊れたときに、execution・evaluation・approval・goal ownership だけでは足りないからである。

1. 「誰が直すか」だけでは足りない

incident が起きたときに必要なのは、修正そのものより先に、

進行を止めるか
どこまでを凍結するか
何を rollback するか
replan するか
goal を縮めるか
誰へ escalation するか
何を future process に残すか

を決めることである。

2. 異常時には責任の空白が起きやすい

通常フローでは、

executor
evaluator
approver
memory writer

が分かれていても、incident 時には
「誰が最終的にこの事態を引き取るのか」
が曖昧になりやすい。

3. approval や eval は incident 処理を代行しない

approver は subject を ratify する責任を持つが、incident の blast radius 全体を扱うとは限らない。
evaluator は fail を出せても、どう収束させるかまでは決めない。

4. long-running process では incident が継続性を壊す

checkpoint、handoff、pending gate、recovery legality が壊れると、
もう通常の execution だけでは process を戻せない。
このとき incident owner が continuity の再構成を統括する必要がある。

5. incident は durable learning の起点でもある

すべての incident は悪いだけではない。
適切に扱えば

failure memory
governance note
rollback pattern
escalation playbook
scope clarification

といった durable learning を生む。
その入口を誰が引き受けるかが必要である。

だから Incident Ownership は、
異常時に process が責任なく崩壊しないようにするための最終受け皿責任
として必要になる。

Incident Ownership は何ではないか

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

1. 単なる bug fixing ではない

bug を直す作業そのものは execution である。
incident owner は、バグ修正を誰に任せ、どこで止め、どこまで巻き戻し、どう再開するかを決める。

2. 単なる blame assignment ではない

incident ownership は「誰のせいか」を決める責任ではない。
それは「この事態をどう process 上で引き取るか」を決める責任である。

3. 単なる Goal Ownership ではない

goal owner は frame の目標と完了条件を保持する。
incident owner は、通常フローが壊れたときの containment と rerouting を引き受ける。
同じ actor であることは多いが、概念としては別である。

4. 単なる Approval ではない

approver は特定 subject に対して yes/no を ratify する。
incident owner は、subject 単位を越えて flow 全体の中断・再設計・縮退を扱う。

5. 単なる Evaluation ではない

evaluator は fail や insufficient evidence を出せる。
incident owner は、その fail を受けて何を止め、誰に任せ、何を rollback / replan するかを決める。

6. 単なる Memory Writing ではない

incident から durable learning が生まれることはある。
しかし incident owner が自動的に memory writer であるとは限らない。
incident owner は、post-incident records の要求や promotion path の起動を担うことが多い。

7. 単なる on-call role ではない

運用組織では on-call が incident owner になることが多い。
しかし PCE 2.0 における Incident Ownership は role 名ではなく、frame に対する責任である。

Incident Ownership が含む責任

PCE 2.0 では、Incident Ownership は少なくとも次の責務を含む。

1. Incident Intake

ある事態を incident として受理する。
誰が、どの threshold を超えたとき incident 扱いにするのかを持つ。

2. Severity Classification

軽微な local issue か、rollback / suspend / escalation が必要な incident かを判定する。

3. Containment

被害や drift を広げないように process を止める・狭める・隔離する。

例:

execution suspend
merge freeze
capability revoke
scope narrowing
recovery block

4. Routing Decision

次にどの path を取るかを決める。

continue with guardrails
hand back for rework
rollback
replan
escalate upward
abandon frame
spawn incident child frame

5. Authority Overrun Handling

現在の actor / bundle では処理不能な場合に、上位 authority や specialized owner へ引き上げる。

6. Recovery Authorization

incident 後に resume / recover / re-enter してよいかを判断する。
この責務があるため、incident ownership は recovery と強く結びつく。

7. Closure Acceptance

incident が十分に収束したか、残留リスクを受け入れてよいかを判断する。

8. Post-incident Record Requirement

何を incident record として残すべきか、failure memory 候補にすべきか、governance note にすべきかを要求する。
実際の durable write は別 actor が担うことがある。

Incident Ownership と他責任の違い

Incident Ownership vs Goal Ownership

Goal Ownership は、何を達成すべきかを保持する
Incident Ownership は、通常フローが壊れたときに process をどう守るかを決める

goal owner が「何を目指すか」を持つのに対し、
incident owner は「いまこの壊れ方で先へ進んでよいか」を持つ。
同じ actor が兼ねるときも多いが、責務は違う。

Incident Ownership vs Execution

Execution は work を前に進める
Incident Ownership は、前に進めてよいのか、それとも止めるべきかを決める

execution actor は incident を発見しうるが、その blast radius や path change を最終決定するとは限らない。

Incident Ownership vs Approval

Approval は特定 subject の ratification
Incident Ownership は異常時の containment / rerouting / closure

approver が reject しただけでは incident handling は終わらないことがある。
たとえば repeated reject、scope violation、authority breach では incident owner が必要になる。

Incident Ownership vs Evaluation

Evaluation は adequacy judgment
Incident Ownership は failure response judgment

evaluator が fail を出し、policy violation を見つけ、recovery point が不整合だと判定しても、
その後どうするかを決めるのは incident owner である。

Incident Ownership vs Memory Writing

Memory Writing は durable state を mutate する
Incident Ownership は、incident から何を durable learning 候補にすべきかを要求しうる

同一 actor であることもあるが、概念上は分かれる。

Incident Ownership と actor symmetry / responsibility asymmetry

PCE 2.0 は actor の分析上の対称性を認めるが、
Incident Ownership は典型的に 強い非対称責任 である。

理論上

AI actor や policy actor が incident を検出したり、初期 triage を支援したり、severity proposal を出したりすることはありうる。

実務上

しかし incident ownership は通常、次を伴う。

containment authority
override / suspend decision
risk acceptance or refusal
escalation to organization
recovery authorization
often external or organizational accountability

このため Incident Ownership はしばしば

human actor
governance-backed organizational actor
on-call / release / security owner
explicit incident commander

のような actor に集中しやすい。

重要なのは、
incident detector = incident owner ではない
という点である。

Incident のトポロジ

incident owner は常に single actor とは限らない。
少なくとも次の topology を区別できる。

1. Single Incident Owner

一人の actor が、その frame の incident sink になる。
feature-level では最も単純である。

2. Severity-tiered Ownership

severity に応じて owner が変わる。

例:

minor incident → feature owner
major incident → release owner
security-sensitive incident → security owner

3. Domain-split Ownership

product incident、security incident、platform incident で別 owner を持つ。

4. Parent / Child Split

child frame に local incident handler がいて、
root-level sink は親 frame または release owner が持つ。

5. Incident Commander + Consulted Owners

一人が commander として routing と closure を持ち、
domain owners が consulted actor として関与する。

PCE 2.0 では、複数 owner を置く場合でも、少なくとも

primary sink
escalation path
conflict resolution

は明示すべきである。

Incident Ownership の主要操作

Incident Ownership responsibility は static ではない。
少なくとも次の操作がある。

Accept Incident

ある事態を incident として正式に受理する。

Classify

severity、scope、incident class を判定する。

Contain

freeze / suspend / revoke / isolate を行う。

Route

rework、rollback、replan、escalate、abandon のどれに進むか決める。

Spawn Incident Frame

必要なら incident-analysis child frame や separate incident frame を作る。

Authorize Recovery

recover / resume / reopen を許可する。

Close Incident

incident を十分に収束したと判断する。

Demand Post-incident Outputs

postmortem、failure memory candidate、governance note、rollback note を要求する。

Reopen

incident が再燃したり、closure が誤りだったと分かったとき再開する。

このうち contain と route は、incident ownership の中核である。

Incident Ownership と Escalation の関係

Escalation は、incident ownership と非常に近い。
ただし同一ではない。

Escalation

現在の bundle では処理不能な問題を、上位または別系統へ引き上げる遷移

Incident Ownership

その引き上げ先として問題を引き取る責任

つまり、

escalation は動き
incident ownership は 引受け先

である。

すべての escalation が incident とは限らないが、
重大な escalation の多くは incident ownership に吸い込まれる。

Incident Ownership と Handoff の関係

incident handling はしばしば Handoff を伴う。

典型的な handoff

evaluator → incident owner
reviewer → release owner
runtime → security owner
feature frame → incident-analysis child frame

このとき handoff package には少なくとも次が必要である。

incident trigger
current blast radius
involved subject refs
pending gates
affected bundles
recommended next action
recovery / rollback anchors
required urgency / severity

普通の work handoff よりも、
containment と authority continuity が重要になる。

Incident Ownership と Checkpoint / Recovery の関係

incident は continuity を壊すため、
Checkpoint and Recovery と強く結びつく。

incident 発生時に必要なこと

現在の risky state を checkpoint として残すか
rollback anchor はどれか
stale context をどこまで invalidate するか
pending approval / eval をどう freeze するか

incident 後に必要なこと

recover してよいか
replan が先か
rollback が必要か
resume authority は誰が持つか

このため Incident Ownership は、
異常時の recovery semantics の gatekeeper
でもある。

Incident Ownership と Process Delta の関係

incident handling からも Process Delta が生まれる。

1. Coordination / Status Delta

execution suspended
merge frozen
escalated to incident owner
incident resolved

2. Governance Delta

temporary scope freeze
emergency approval requirement
override record

3. Failure Delta

reusable failure lesson
anti-pattern
incident postmortem candidate

4. Recovery Delta

rollback anchor created
recovery invalidated
resume authorized

ここで重要なのは、incident owner がこれらの delta を自分ですべて書くとは限らないが、
それらが必要かどうかを要求する責任 を持つことだ。

Incident Ownership の最小スキーマ

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

incident_ownership:
  actor_ref:
  frame_id:
  incident_scope:
  incident_classes:
  severity_scope:
  authority_basis:
  intake_conditions:
  containment_authority:
    can_suspend:
    can_freeze_merge:
    can_revoke_capability:
    can_narrow_scope:
  routing_authority:
    can_order_rework:
    can_order_rollback:
    can_authorize_replan:
    can_escalate_upward:
    can_abandon_frame:
    can_spawn_incident_frame:
  recovery_authority:
    can_authorize_recover:
    can_authorize_resume:
  closure_authority:
    can_close_incident:
    can_accept_residual_risk:
  required_records:
  escalation_targets:
  validity:
    active_when:
    expires_when:
  provenance:

bundle の一部として書くなら、もう少し簡潔に次のようにも置ける。

incident_ownership:
  classes:
  severity_scope:
  intake_conditions:
  containment_authority:
  routing_authority:
  recovery_authority:
  closure_authority:
  required_records:
  escalation_path:
  invalidation_triggers:

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

incident class と severity を持つ
containment authority がある
rollback / replan / abandon を扱える
recovery / resume authority がある
closure と residual risk を扱える
required records と escalation path を持つ

つまり Incident Ownership は、
単なる「問題対応係」ではなく、
abnormal-process control responsibility として扱われる。

小さな例

feature.checkout.coupon-combination frame において、
reviewer が payment gateway 変更が混入していることを検出したとする。
これは out-of-scope であり、しかも settlement に影響しうる。
このとき product_owner が incident owner だとすると、たとえば次のように書ける。

incident_ownership:
  actor_ref: product_owner
  frame_id: feature.checkout.coupon-combination
  incident_scope:
    - scope_violation
    - rollback_risk
    - unresolved_goal_ambiguity
  incident_classes:
    - governance_incident
    - correctness_incident
  severity_scope:
    - feature_level
  authority_basis:
    - product_owner_bundle_v1
    - release.checkout.spring-2026
  intake_conditions:
    - prohibited_scope_change_detected
    - rollback_feasibility_missing
    - reviewer_escalation
  containment_authority:
    can_suspend: true
    can_freeze_merge: true
    can_revoke_capability: true
    can_narrow_scope: true
  routing_authority:
    can_order_rework: true
    can_order_rollback: true
    can_authorize_replan: true
    can_escalate_upward: true
    can_abandon_frame: false
    can_spawn_incident_frame: true
  recovery_authority:
    can_authorize_recover: true
    can_authorize_resume: true
  closure_authority:
    can_close_incident: true
    can_accept_residual_risk: true
  required_records:
    - incident_note
    - rollback_note
    - failure_memory_candidate_if_reusable
  escalation_targets:
    - release_owner
  validity:
    active_when: frame_instantiated
    expires_when: frame_closed
  provenance:
    assigned_by: release.checkout.spring-2026

このケースで incident owner は、たとえば次のように動く。

current implementation frame を suspend
merge freeze をかける
payment gateway edit を rollback させる
必要なら incident-analysis child frame を作る
corrected diff と rollback note が揃うまで resume を許可しない
収束後に incident を close する
failure lesson を durable memory 候補として残すよう要求する

ここで重要なのは、incident owner が自分でコードを直す必要はないことだ。
それでも process の収束責任は持つ。

Incident Ownership の不変条件

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

1. Every frame has an incident sink

すべての frame には、最終的な incident sink が必要である。

2. Incident detection does not imply incident ownership

incident を見つけた actor が、そのまま引き取る責任を持つとは限らない。

3. No silent continuation after incident threshold is crossed

重大な incident threshold を超えたら、何らかの containment または routing decision が必要である。

4. Incident ownership does not imply direct execution

incident owner が自分で修正作業をする必要はない。
重要なのは routing と closure である。

5. No recovery without incident disposition

incident 状態のまま resume してはならない。
recover / resume には incident owner の判断が必要なことが多い。

6. Incident closure must be attributable

「もう大丈夫」としたなら、誰がどの根拠で close したのか追える必要がある。

7. Incident handling must preserve evidence and gate continuity

containment によって pending approval / eval / delta state が消えてはならない。

8. Incident ownership is not blame ownership

incident owner は process を引き取る責任であり、fault attribution とは別である。

いつ Incident Ownership を分けるべきか

次の条件があるなら、一つの incident sink ではなく分割を考えるべきである。

1. Risk domain が異なるとき

product integrity
security / compliance
platform / infra
release governance

で別 owner が必要なことがある。

2. Severity tier が異なるとき

軽微な incident は feature owner、重大な incident は release owner や incident commander が持つ方が自然である。

3. Parent / child frame で blast radius が違うとき

child frame の local failure は local handler でよくても、
parent frame にまで影響するなら global sink が必要になる。

4. 運用時間帯と ownership が異なるとき

on-call と product owner を分ける実務もありうる。
この場合、intake / containment と final closure を分ける topology が必要になる。

5. Governance と execution domain が分かれているとき

security-sensitive な process では、execution actor と incident owner を明確に分けるべきである。

短く言えば、
risk、blast radius、severity、organization boundary のいずれかが意味的に変わるなら incident ownership を分ける
のが基本である。

最低限の自己点検

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

この frame の incident sink を言えるか
どの threshold を超えたら incident 扱いになるか決めているか
evaluator / approver / executor と incident owner を混同していないか
containment authority があるか
rollback / replan / escalate の decision path があるか
resume authority を incident 後に誰が持つか分かるか
pending gate や delta continuity を incident handling 中も保持できるか
incident closure を誰が accept するか決まっているか
incident records や durable learning 候補を残す責任があるか
blame assignment と incident ownership を混同していないか

このどれかが欠けるなら、その process はまだ incident ownership を十分に持っていない。

暫定的なまとめ

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

process は、失敗したときにただ止まればよいのではない。
通常フローでは安全に進めない事態を、誰が引き取り、どこで止め、何を凍結し、何を巻き戻し、何を再計画し、どう再開または終了させるのかが明示されてはじめて継続可能である。

PCE 2.0 において incident owner は、単なるトラブル担当ではない。
それは、異常時に process が責任の空白へ落ちないようにする最後の受け皿である。

だから Incident Ownership は、単なる on-call や bug triage ではない。
それは、PCE 2.0 において 通常フローが成立しなくなったときに process を引き受け、封じ込め、進路変更し、継続可能性を回復させる abnormal-flow ownership である。