Human Oversight

定義

Human Oversight

Human Oversight とは、ある human actor または human-backed organizational actor が、
ある process frame の進行に対して、
境界設定、介入、停止、ratification、例外判断、再開判断、収束判断を行う権限と責任を持つこと である。

それは単なる「人間が関与していること」ではなく、
oversight scope、intervention rights、trigger conditions、required evidence package、override / freeze / escalate / resume authority、audit trace を持つ。

より短く言えば、Human Oversight とは
「AI や tool が process を進めるとしても、人間がどこで境界を引き、どこで止め、どこで承認し、どこで例外を引き取り、どこで再開や終了を認めるのか」を明示した統治構造
である。

PCE 2.0 は、人間だけが actor だとはみなさない。
人間、AI、tool、document、policy、runtime は、同じ process network 上の actor として扱われる。
しかしそれは、責任や権限まで対称だという意味ではない。
Human Oversight は、その非対称性を process 上に明示する代表的な形である。

この意味で Human Oversight は、
対称的アクター性、非対称的責任 を governance の側から operational に具体化した概念である。

---

なぜ Human Oversight が必要なのか

PCE 2.0 が human oversight を独立に扱うのは、
AI / tool-driven process が成立するためには、人間が「何でも自分でやる」必要はないが、
何も引き受けない という設計も危険だからである。

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

1. actor の対称性は authority の対称性を意味しない

AI agent や tool は actor であり、execution、analysis、local evaluation を担いうる。
しかし、

• goal の再定義
• exception 承認
• residual risk の受容
• canonical durable state の高インパクト更新
• incident の最終収束

まで対称に扱うと、process の accountability が急速に弱くなる。

2. high-impact な transition には人間の介入点が必要なことがある

特に次のような遷移は、risk や blast radius が大きい。

• scope widening
• override / exception
• rollback / resume after incident
• canonical memory write
• release-facing approval
• final completion acceptance

これらは、通常の execution や automated evaluation だけに委ねると、
later correction cost が非常に高くなりやすい。

3. 異常時には判断が goal / governance / risk を横断する

failure や conflict が起きたとき、必要なのは局所的な修正だけではない。

• そのまま続けてよいか
• rollback すべきか
• replan すべきか
• scope を縮めるべきか
• close / abandon すべきか

といった判断は、goal ownership、incident ownership、approval、governance をまたぐ。
human oversight は、この跨りを引き受けるために必要になる。

4. human oversight がなければ “hidden human governance” が生まれやすい

表向きは automated に見えても、実際には

• チャット外で人間が判断している
• 誰かが暗黙に例外を許している
• 公式な approval point を通らずに人間が事実上決めている

という hidden governance が生まれやすい。
PCE 2.0 では、こうした暗黙の人間介入を避け、明示された oversight に変える必要がある。

5. Human Oversight は “全件人手レビュー” を意味しない

ここも重要である。
Human Oversight が必要だということは、
すべての step を人間が実行すべきだという意味ではない。
PCE 2.0 の立場はむしろ逆で、

• 通常 execution は AI / tool に委ねられることがある
• ただし certain thresholds, gates, and exceptions では human oversight が必要

という bounded な設計を志向する。

6. 問題は human retention そのものではなく、retained labor への崩壊である

PCE 2.0 が人間に残しがちなものには、

• goal ownership
• approval authority
• memory write authority
• incident ownership

がある。
しかしこれを bundle のまま運用へ落とすと、

• raw evidence を全部読む
• stale かどうかを毎回手作業で判定する
• memory candidate を分類・整形・重複排除する
• incident 時に生ログから状況を再構成する

といった retained labor へ変質しやすい。
その瞬間、人間は legitimacy-bearing actor ではなく、巨大な前処理・統合作業の受け皿になる。

したがって Human Oversight の失敗は、
「人間が責任を持っていること」ではなく、
人間に残した責任が、人間の不得意な監視・読解・統合作業へ崩れていること
として捉えるべきである。

---

Human Oversight は何ではないか

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

1. 単なる “human-in-the-loop” ではない

HITL は重要な実装パターンだが、PCE 2.0 の human oversight はそれより広い。

• framing 時の目標設定
• scope retain
• exception judgment
• rollback / resume authorization
• memory mutation oversight
• post-incident closure

まで含む。

2. 単なる manual execution ではない

人間が手を動かしていること自体は execution である。
Human Oversight は、実行そのものではなく 統治・介入・停止・再開・閉鎖 に関わる。

3. 単なる approval ではない

approval は human oversight の一形態ではあるが、その全体ではない。
human oversight は、approval に加えて、

• capability boundary design
• escalation sink
• incident containment
• reframe authority
• memory promotion gate
• closure acceptance

を含みうる。

4. 単なる blame assignment ではない

Human Oversight は「失敗したら人間が責任を負う」という事後責任の話だけではない。
むしろ process の途中で、

• どこで止めるか
• どこで人間に返すか
• どこで自動進行を許すか

を設計する事前・進行中の governance である。

5. 単なる rubber-stamp ではない

人間が approve ボタンを押しただけで、
required evidence も見ておらず、bundle も authority も曖昧で、
ただ flow を通すだけなら、それは oversight ではなく ornamental approval である。

6. 単なる “人間が見える位置にいること” ではない

ダッシュボードで observability があることと、
介入権と停止権を持つことは別である。
Human Oversight は、見ることではなく 介入可能であること を含む。

---

Human Oversight の中心命題

PCE 2.0 における human oversight は、次の一文に要約できる。

人間が process に参加していること自体が重要なのではない。
どの局面で、人間が、どの authority で、何を止め、何を認め、何を引き取り、何を future process の前提にしてよいと判断するのかが明示されていることが重要である。

ここで重要なのは、human oversight が
human exceptionalism ではなく
governed asymmetry だという点である。

---

Human Oversight の第一原則

human oversight を rubber-stamp や stall に崩さないために、少なくとも次の原則が必要である。

1. Retained authority != retained labor

人間に retain されるのは、責務全体ではなく decision core である。
たとえば retained されやすいのは、

• reframe authority
• trade-off legitimacy
• exception approval
• residual risk acceptance
• canonical write ratification
• incident closure

である。
一方で、

• evidence 収集
• 一次評価
• 差分整理
• 候補生成
• ログ整形
• low-risk triage

まで人間が毎回引き受ける必要はない。
これらは AI / tool / child frame / policy check に分解されるべきである。

2. Oversight Budget / Attention Budget を持つ

Human Oversight も Context Budget と同様に、Safety Floor と Hard Ceiling を持つ。
人間に渡す package がその actor の attention / time ceiling を超えるなら、 それは「もっと頑張って読め」ではなく、

• split
• stage
• reassign
• escalate

のシグナルである。

要約努力で ceiling 超過を押し込むのではなく、process topology を変えるべきである。

3. Human Decision Package を要求する

人間に渡すのは raw trace ではない。
少なくとも次を含む bounded package が必要である。

• subject
• 今求められている判断
• 許容される選択肢
• risk delta / blast radius
• strongest counterevidence
• unresolved uncertainty
• rollback path
• stale になる条件
• write scope
• provenance

これがない manual review は、実質的には material dump である。

4. Risk-tiered selective oversight を採る

human oversight は一律に強くすべきではない。
retain すべきなのは主に、

• scope widening
• override / exception
• incident 後の rollback / resume
• canonical memory write
• release-facing approval
• final completion acceptance

のような risk-bearing transition である。
逆に、

• read-only analysis
• bounded local execution
• low-risk provisional write
• deterministic check

まで全件人手 gate にすると bounded autonomy が壊れる。

---

Human Oversight の主な対象

PCE 2.0 では、少なくとも次の領域で human oversight が設計されうる。

1. Framing Oversight

• goal 定義
• scope 設定
• success criteria binding
• child frame 切り出しの承認
• major reframe の承認

2. Capability Oversight

• high-risk capability の付与
• capability widening の承認
• prohibited action の例外許可
• incident 時の capability freeze / revoke

3. Approval Oversight

• spec approval
• code review approval
• merge readiness approval
• release-facing signoff
• risky resume approval

4. Evaluation Oversight

• outcome/process の最終判断
• evaluator conflict 解消
• insufficient evidence 時の next action 決定
• automated evaluation の境界設定

5. Memory Oversight

• canonical memory write の承認
• high-value failure memory の採用判断
• governance memory の更新承認
• provisional → canonical の昇格判断

6. Incident / Exception Oversight

• escalation 受理
• rollback 指示
• residual risk acceptance
• branch / child conflict resolution
• abnormal-flow closure

7. Recovery Oversight

• risky recovery の許可
• stale path の再開拒否
• post-incident resume 判断
• rollback 後の continuation 承認

8. Closure Oversight

• frame completed の accept
• abandoned / superseded の確定
• postmortem / learning record の要求

Human Oversight は、単なる review step ではなく、
process の高インパクト境界を人間がどこで引き受けるかの設計 である。

---

Human Oversight と他概念の違い

Human Oversight と Approval の違い

• Approval は特定 subject に対する ratification responsibility
• Human Oversight は、どこで人間が gate / intervention / exception / closure を担うかという broader governance pattern

approval は human oversight の一部だが、全体ではない。

Human Oversight と Goal Ownership の違い

• Goal Ownership は frame の目標と完了条件を保持する責任
• Human Oversight は、それに加えて exception / capability / recovery / memory mutation などへの human介入の設計

goal owner が human oversight の中心 actor になることは多いが、同一ではない。

Human Oversight と Incident Ownership の違い

• Incident Ownership は abnormal-flow を引き取る責任
• Human Oversight は incident handling を含みつつ、平常時の gate や high-risk transition まで扱う

incident owner は human oversight topology の一ノードだと考えると分かりやすい。

Human Oversight と Auditability の違い

• Auditability は後から reconstruct できる性質
• Human Oversight は process 中に人間が介入・停止・承認できる構造

auditability は human oversight を支えるが、同一ではない。

Human Oversight と Capability Scope の違い

• Capability Scope は actor に何をしてよいかを bounded に定める
• Human Oversight は、その境界設定や widening / freeze / exception を human がどこで引き受けるかを定める

---

Human Oversight はどのように現れるか

PCE 2.0 では human oversight は一枚の policy 文ではなく、
複数の surface に分散して現れる。

1. Approval Points

もっとも明示的な形。
特定 subject を先へ進めるには human approver が必要になる。

2. Escalation Path

local bundle では解けない conflict や incident を human sink へ返す。

3. Capability Freeze / Widen Controls

human が capability scope を narrow / widen / revoke できる。

4. Recovery Gate

human が recover / resume を許可または拒否できる。

5. Memory Promotion Gate

canonical durable write に人間の承認が必要なことがある。

6. Close Authority

frame を completed / abandoned / superseded と確定するのが human であることがある。

7. Audit Review Surface

人間が process trace や mutation trace を review し、例外・逸脱・corruption を検出する。

つまり Human Oversight は、
Governance Surface の中で
human actor に結びついた gate / override / sink / closure として現れる。

---

Human Oversight の主要モード

PCE 2.0 では、human oversight の強度や形をいくつかのモードに分けられる。

1. Design-time Oversight

frame の起動時や reframe 時に人間が境界を決める。

例:

• goal 設定
• child frame 設計
• capability scope 初期化
• evaluation / approval topology の決定

2. Checkpointed Oversight

平常時は AI / tool が進み、人間は特定 checkpoint や gate でだけ介入する。

例:

• spec approval
• code review approval
• promotion review

これは高頻度の manual involvement を避けやすい。

3. Escalation-only Oversight

通常 flow には介入せず、異常・曖昧・高リスク時だけ人間が介入する。

例:

• scope ambiguity
• policy conflict
• incident
• risky recovery

bounded autonomy を最大化したいときに有効だが、
trigger 設計が弱いと見落としが起こりやすい。

4. Continuous Oversight

高リスク領域で、人間が継続的に process を monitor し必要時にすぐ止める。

例:

• security-sensitive branch
• high-blast-radius migration
• compliance-sensitive memory write

5. Post-hoc Oversight

遷移のたびに止めないが、later audit と correction に人間が入る。

例:

• retrospective audit
• post-incident review
• corruption detection

このモード単体では弱いことが多いが、他モードを補完する。

---

Risk-tiered Oversight

PCE 2.0 では、human oversight は一律で強くすべきではない。
重要なのは risk に応じて強度を変えること である。

Oversight を強めるべき典型条件

• canonical durable write
• external irreversible effect
• high blast radius
• weak rollback path
• policy / compliance sensitivity
• unresolved goal conflict
• incident / recovery / resume
• branch / child conflict affecting parent scope

Oversight を軽くできる典型条件

• low-risk local reversible execution
• read-only analysis
• bounded provisional writes
• fully deterministic low-impact checks
• optional advisory exploration

ここで重要なのは、
「AI に任せる / 人間が見る」の二択ではなく、
どの境界だけ human oversight を要するかを explicit に切る ことである。

---

Human Oversight と bounded autonomy

PCE 2.0 は、human oversight を増やせばよいとは考えない。
むしろ重要なのは、AI / tool / local actor に bounded autonomy を与えつつ、
その外側に human oversight を置くことである。

bounded autonomy がうまく設計されている状態

• local actor は通常の execution を自律的に進められる
• ただし goal / scope / exception / durable mutation の一部は human に retain される
• escalation path がある
• human は必要時にだけ入る
• approval や recovery の high-impact gate は明示されている

bounded autonomy が壊れている状態

• 人間が全部見ているが何も決めていない
• AI が全部進めているが人間が何も retain していない
• human gate が多すぎて ornamental review になる
• local actor が本来 human に返すべきものを silent に決めている

つまり Human Oversight は、
AI 自律性を潰すためのものではなく、
bounded autonomy を支える retain / intervene architecture として設計されるべきである。

このときの retained human role は、

• human-for-legitimacy
• AI-for-preparation
• tool-for-enforcement

という mnemonic で切るのが基本である。
人間が legitimacy を持つ判断核を retain し、AI が材料を整え、tool が deterministic enforcement を担う。

---

Human Oversight と accountability の関係

PCE 2.0 は actor symmetry を認める一方で、
responsibility asymmetry を明示する。
そのため human oversight は、accountability の重要な接点になる。

ただし重要なのは、
human oversight があるからといって すべての実務責任が常に無条件に一人の人間へ落ちる と単純化しないことだ。

PCE 2.0 では、少なくとも次を分けて考える。

• who executed
• who evaluated
• who approved
• who wrote durable memory
• who handled incident
• which of these were human-oversighted

つまり Human Oversight は accountability を支えるが、
それ自体が blame-shifting の言い換えではない。

---

Human Oversight と Human-in-the-Loop の違い

このページでは意識的に区別しておく。

Human-in-the-Loop

人間が特定の loop / step / decision point に入る具体的運用パターン。
多くの場合 approval、clarification、exception handling を指す。

Human Oversight

HITL を含みつつ、より広く

• framing
• capability governance
• escalation sink
• recovery authorization
• memory mutation gate
• closure acceptance
• retrospective audit

を含む。

つまり HITL は implementation pattern、
Human Oversight は governance design pattern と言える。

---

Human Oversight Package

人間に介入を求めるなら、単に “見てください” では足りない。
PCE 2.0 では、human oversight に入るとき、少なくとも次を package として渡すべきである。

1. Subject

何について人間に判断してほしいのか。

2. Requested decision

• approve / reject
• clarify
• reframe
• rollback / replan
• resume / deny
• promote / hold / reject

3. Allowed options

許容される選択肢と、その decision surface の境界。

4. Why now / Trigger

• missing approval
• scope ambiguity
• policy conflict
• risky resume
• canonical write candidate
• incident

5. Required evidence

どの evidence を見てほしいのか。

6. Risk delta / blast radius

この判断が何を動かし、どこまで影響するか。

7. Strongest counterevidence / unresolved uncertainty

賛成材料だけでなく、最も強い反証と、なお未解決な不確実性。

8. Current lifecycle / pending gates

いま frame がどこにいて、何が止まっているのか。

9. Rollback / recovery path

判断後に戻せるのか、戻すならどこが anchor か。

10. Staleness / invalidation conditions

何が変わったらこの package や approval が失効するのか。

11. Write scope / authority scope

どの write や mutation が許可対象で、どこから先は別 authority が必要か。

12. Provenance

どの frame / delta / evidence / policy に基づく package なのか。

これがない human oversight は、
結局「生の生産物をそのまま人間に丸投げする」ことになりやすい。

---

Oversight Collapse の典型 anti-pattern

人間保持があるだけでは良い設計にならない。
次の anti-pattern は、human oversight が retained labor に崩れているサインである。

1. Human-as-checksum

人間が全部見ることになっているが、実際には AI の提案を追認するだけで、独立した decision quality をほとんど加えていない状態。

2. Ornamental approver

承認者がいるが、

• bounded subject がない
• required evidence package がない
• stale invalidation が弱い
• rollback path が不明

ため、approval が単なる待ち行列になっている状態。

3. Memory janitor

memory writer が全候補の手動キュレーターになり、 subject classification、decontextualization、dedup、supersession、retention を一人の人間が抱えている状態。

4. Incident log sink

incident owner が containment / closure authority ではなく、生ログの再構成係に沈んでいる状態。

これらは bounded autonomy の完成形ではない。
責務の名を借りた認知負荷の押し付け である。

---

Oversight Metrics Candidates

Approval Burden や Human Oversight Load だけでは、良い oversight かどうかは判定しきれない。
少なくとも次の指標を合わせて見るべきである。

ここで挙げるものは oversight-specific metric candidates であり、
正式に運用指標として採用するなら Process Metrics の定義形式 (scope、formula、evidence source、paired metric) に落とし込む必要がある。

1. Rubber-Stamp Rate

人間の verdict が AI 推薦とほぼ同一で、かつ counterevidence や disagreement capture が乏しい割合。

2. Package Over-Ceiling Rate

Human Decision Package が、その actor の attention / time ceiling を超えていた割合。

3. Oversight Queue Saturation

pending approval / pending review / pending promotion が human queue に滞留している度合い。

4. Human-AI Disagreement Rate

AI の推奨と human verdict がどの程度ずれているか。
ゼロに近すぎる場合は rubber-stamp、過剰に高い場合は package quality や criteria mismatch を疑う。

5. Audit Sample Failure Rate

low-risk mass flow を sampling audit したとき、見逃していた violation や bad write が見つかる割合。

6. Canonical Write Churn

canonical write が後から supersede / retract / rollback される頻度。

7. Stale Invalidation Latency

new evidence や subject change が入ってから、古い approval / package / compiled context を失効させるまでの時間。

重要なのは burden の単独最小化ではない。
burden が下がっても dissent capture や audit quality が消えていれば、それは oversight の改善ではなく形式化である。

---

Human Oversight と Auditability の関係

Human Oversight が本当に oversight であるためには、
少なくとも次が audit 可能でなければならない。

• 誰が human oversight actor だったか
• 何に介入したか
• どの authority で介入したか
• どの evidence に基づいて介入したか
• 何を承認 / 拒否 / 停止 / 巻き戻し / 再開したか
• その結果何が current truth になったか
• 何が invalidated されたか

つまり human oversight は、
人間がいたこと ではなく
人間が何を変えたか が audit 可能であって初めて成立する。

詳しくは Auditability を参照。

---

Human Oversight の主要操作

PCE 2.0 では、human oversight は少なくとも次の操作として現れる。

1. Define / Frame

goal、scope、success criteria、child topology を定義する。

2. Approve / Reject

subject を次へ進めるかどうかを ratify する。

3. Clarify / Reframe

曖昧な goal や conflicting scope を再解釈する。

4. Freeze / Revoke

危険な progression を止め、capability を narrow / revoke する。

5. Escalate / Route

通常 path では解けない問題を別 sink へ回す。

6. Authorize Recovery / Resume

recover や resume を許可または拒否する。

7. Order Rollback / Replan

current path を戻すか、設計し直すかを決める。

8. Promote / Hold / Reject Memory

durable memory mutation の high-impact 部分に介入する。

9. Close / Abandon / Supersede

frame の終端意味を確定する。

このように Human Oversight は、
approval だけの narrow concept ではない。

---

いつ Human Oversight を強めるべきか

次の条件があるなら、human oversight を強めるべきである。

1. Irreversible or high-cost mutation

• canonical memory write
• production-affecting action
• high-impact merge

2. High ambiguity

• goal conflict
• acceptance ambiguity
• branch conflict
• reframe suspicion

3. Weak rollbackability

• rollback path unclear
• large blast radius
• recovery uncertainty

4. Governance sensitivity

• compliance-sensitive path
• restricted data
• cross-team authority boundary
• policy exception

5. Abnormal flow

• incident
• escalation
• stale recovery
• repeated failed remediation

6. Cross-boundary integration

• parent-child integration
• branch join with conflict
• cross-session recovery of important subject

---

いつ Human Oversight を弱めるべきか

逆に、次のような場合は強すぎる human oversight が process を重くしすぎることがある。

1. Low-risk local reversible work

小さく、戻しやすく、bounded な local execution。

2. Deterministic routine validation

形式的 check や deterministic tests。

3. Read-only exploration

read-only analysis や preliminary retrieval。

4. Provisional low-impact writes

strictly bounded な provisional artifacts や recovery-related local notes。

5. Clearly pre-authorized paths

goal owner や governance が前もって narrow rules を定めており、local autonomy で十分なケース。

重要なのは、人間を減らすことではなく、
どこに retain すべきかを正確に絞ること である。

---

Human Oversight の最小スキーマ

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

human_oversight_policy:
  policy_id:
  frame_id:
  human_actor_refs:
  oversight_scope:
    goal:
    capability:
    approval:
    evaluation:
    memory:
    incident:
    recovery:
    closure:
  modes:
    - design_time
    - checkpointed
    - escalation_only
    - continuous
    - post_hoc
  trigger_conditions:
  intervention_rights:
    can_approve:
    can_reject:
    can_clarify:
    can_reframe:
    can_freeze:
    can_revoke_capability:
    can_authorize_recover:
    can_authorize_resume:
    can_order_rollback:
    can_order_replan:
    can_close:
  required_packages:
    required_evidence:
    required_requested_decision:
    required_allowed_options:
    required_risk_delta_note:
    required_counterevidence:
    required_unresolved_uncertainty:
    required_rollback_or_recovery_path:
    required_staleness_conditions:
    required_write_scope:
    required_lifecycle_state:
    required_subject_binding:
  audit_requirements:
  validity:
    active_when:
    expires_when:
  provenance:

個別 event としては、次のようにも書ける。

human_oversight_event:
  event_id:
  frame_ref:
  human_actor_ref:
  trigger:
  subject_refs:
  requested_decision:
  allowed_options:
  evidence_refs:
  risk_delta_note:
  strongest_counterevidence_refs:
  unresolved_uncertainty_note:
  current_lifecycle_state:
  pending_gates:
  rollback_or_recovery_path_ref:
  write_scope:
  staleness_conditions:
  verdict:
  state_effects:
    lifecycle_changes:
    gate_changes:
    capability_changes:
    delta_changes:
    durable_state_changes:
  invalidations:
  timestamp:
  provenance:

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

1. 人間がどこに介入するか scope がある
2. trigger 条件がある
3. intervention rights がある
4. required package が、decision surface を bounded にする項目まで含んでいる
5. state effect と invalidation が記録できる

つまり Human Oversight は、
単なる「人間を入れる」ではなく、
bounded, trigger-based, stateful governance policy として表現されるべきである。

---

小さな例

feature.checkout.coupon-combination frame における human oversight は、たとえば次のように書ける。

human_oversight_policy:
  policy_id: hov.feature.checkout.coupon-combination.v1
  frame_id: feature.checkout.coupon-combination
  human_actor_refs:
    - product_owner
    - reviewer
    - memory_writer
  oversight_scope:
    goal:
      - global_goal_definition
      - scope_clarification
      - reframe_authorization
    capability:
      - prohibit_payment_gateway_widening_without_human_decision
    approval:
      - spec_approval
      - code_review_approval
    evaluation:
      - conflict_resolution_between_local_signals
    memory:
      - canonical_failure_memory_write
      - canonical_operational_memory_write
    incident:
      - scope_violation_escalation
      - rollback_decision
    recovery:
      - risky_resume_after_incident
    closure:
      - frame_completion_acceptance
  modes:
    - design_time
    - checkpointed
    - escalation_only
  trigger_conditions:
    - spec_candidate_ready
    - code_review_ready
    - scope_violation_detected
    - rollback_feasibility_unclear
    - canonical_memory_candidate_ready
    - recovery_after_incident_requested
  intervention_rights:
    can_approve: true
    can_reject: true
    can_clarify: true
    can_reframe: true
    can_freeze: true
    can_revoke_capability: true
    can_authorize_recover: true
    can_authorize_resume: true
    can_order_rollback: true
    can_order_replan: true
    can_close: true
  required_packages:
    required_evidence:
      - subject_ref
      - evidence_refs
      - strongest_counterevidence_refs
      - unresolved_issues
      - rollback_note_if_applicable
    required_requested_decision:
      - approve_or_request_changes
      - clarify_or_escalate
    required_allowed_options:
      - bounded_verdict_set
      - no_scope_widening_without_reframe
    required_risk_delta_note:
      - blast_radius_summary
      - residual_risk_note
    required_counterevidence:
      - strongest_counterevidence_refs
    required_unresolved_uncertainty:
      - unresolved_business_risk
      - unresolved_technical_risk
    required_rollback_or_recovery_path:
      - rollback_anchor
      - recovery_preconditions_if_applicable
    required_staleness_conditions:
      - invalidate_on_new_spec_delta
      - invalidate_on_new_incident_evidence
      - invalidate_on_scope_change
    required_write_scope:
      - canonical_memory_write_requires_memory_writer_only
      - no_external_write_beyond_checkout_scope
    required_lifecycle_state:
      - pending_approval
      - escalation_pending
      - recovery_requested
    required_subject_binding:
      - explicit_subject_scope
  audit_requirements:
    - approval_record
    - escalation_record
    - memory_promotion_record
    - recovery_authorization_record
  validity:
    active_when: frame_instantiated
    expires_when: frame_closed
  provenance:
    defined_by: release.checkout.spring-2026

この例で重要なのは、

• product owner は global goal / incident / recovery を引き受ける
• reviewer は code review approval の checkpointed oversight を担う
• memory writer は canonical memory mutation に対する human oversight を担う
• coding agent は通常 execution を担うが、scope widening や final mutation は human oversight の外にある

という非対称性が explicit になっていることだ。

---

Human Oversight の不変条件

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

1. Human presence does not imply oversight

人間が process に参加しているだけでは oversight ではない。
介入権・停止権・判断責任が必要である。

2. Oversight must be explicit

「必要なら人間が見るはず」という暗黙期待にしてはならない。

3. Oversight must be bounded

人間が何でも全部見る構造ではなく、どこに retain し、どこを local autonomy にするかが必要である。

4. High-impact transitions require stronger oversight design

canonical write、exception、rollback、resume、closure などは、弱い oversight にしてはならない。

5. Human oversight does not replace required eval

人間が見たことは、required evaluation を消す理由にはならない。

6. Human oversight actions must be auditable

誰が、何を、どの authority と evidence で変えたか追えなければならない。

7. Oversight should prevent, not just post-rationalize, corruption

後から「人間が見たから大丈夫」と言うための装置にしてはならない。

8. Oversight intensity should track risk

低リスク作業に過剰な manual gate を入れるべきではない。
一方、高リスク遷移で human oversight を省いてはならない。

9. Human oversight must survive phase changes

recovery、incident、reframe でどの human actor が何を retain するかが継続していなければならない。

10. Human oversight should not collapse bounded autonomy

すべてを人間が手動でやる構造に戻しては、PCE 2.0 の bounded autonomy は成立しない。

11. Retained authority must be packaged as a bounded decision surface

人間に retained authority を残すなら、raw labor bundle ではなく bounded decision surface として提供されなければならない。

12. If oversight floor exceeds human ceiling, change the process, not the person

人間に必要な oversight package が ceiling を超えるなら、manual review を増やすのではなく split / stage / reassign / escalate を行うべきである。

---

実装順のガイド

abstract な議論で止めないために、human oversight は次の順で設計するとよい。

1. high-impact transition を列挙する

どこが risk-bearing transition なのかを先に固定する。

2. 各 transition の Human Decision Package を定義する

subject、decision、counterevidence、rollback、staleness、write scope を明示する。

3. low-risk path を auto-gate と sampling audit に逃がす

全件 manual gate を避け、監査可能な mass flow を作る。

4. Oversight Budget と Oversight Metrics を計測する

ceiling 超過、queue 飽和、rubber-stamp、stale invalidation 遅延を観測する。

---

最低限の自己点検

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

1. どの局面で human oversight が必要か言えるか
2. どの human actor が何を retain するか言えるか
3. approval 以外の oversight（incident, recovery, memory, closure）を区別できるか
4. trigger 条件があるか
5. human に渡す package が定義されているか
6. human oversight action が next transitions をどう変えるか説明できるか
7. rubber-stamp になっていないか
8. low-risk path に過剰な gate を入れていないか
9. oversight event が audit 可能か
10. bounded autonomy と human retention の境界を説明できるか

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

---

関連する概念

Human Oversight は、PCE 2.0 の human governance layer の中核として、次の概念と強く結びつく。

• 対称的アクター性、非対称的責任
• Governance Surface
• Process Frame
• Responsibility Bundle
• Goal Ownership
• Approval
• Evaluation
• Memory Writing
• Incident Ownership
• Asymmetry
• Capability Scope
• Auditability
• Approval Points
• Escalation
• Rollback
• Checkpoint and Recovery
• Corrupt Success

---

暫定的なまとめ

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

AI や tool が process を進めることはできる。
しかし、どの境界で人間が止め、認め、引き取り、戻し、再開し、閉じるのかが明示されていなければ、その process は bounded autonomy ではなく、ただの暗黙統治になる。

PCE 2.0 において human oversight は、人間中心主義への逆戻りではない。
それは、actor symmetry を保ちながら、risk と accountability の高い境界だけを人間に retain するための統治設計である。

だから Human Oversight は、単なる HITL の別名ではない。
それは、PCE 2.0 において 人間がどの局面で process integrity の最後の境界を引き受けるのかを定める governance pattern である。

さらに言えば、良い human oversight とは
retained authority を retained labor に変換しないこと
である。
PCE 2.0 が目指すのは、human-in-the-loop の量を増やすことではなく、
human-for-legitimacy, AI-for-preparation, tool-for-enforcement へ process を組み替えることである。