Asymmetry

定義

Asymmetry

Asymmetry とは、ある process frame に参与する actor 間で、
goal ownership、execution、capability authority、approval authority、evaluation authority、memory write authority、incident ownership が
均等でも相互交換可能でもなく、役割・時点・scope に応じて非一様に配分されている状態 である。

それは単なる不平等や権力差ではなく、
explicitness、boundedness、traceability、revisability を持つ責任配置の性質である。

より短く言えば、Asymmetry とは
「同じ process に関わっていても、誰もが同じことを決められるわけでも、同じことをしてよいわけでも、同じことを引き受けるわけでもない」
という構造である。

PCE 2.0 は、対称的アクター性、非対称的責任 を採る。
つまり、

actor としては human / AI / tool / document / policy / runtime を同じ分析平面に置く
しかし responsibility の配分は対称だと仮定しない

という立場である。

このページは、そのうち後者、すなわち 責任の非対称性 を責任論の内部から定式化するものである。

なぜ Asymmetry が必要なのか

PCE 2.0 が非対称性を独立に扱うのは、
multi-actor process において、対称な責任配分はむしろ process を壊しやすいからである。

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

1. actorhood の広がりは、そのまま責任の平坦化を意味しない

AI、tool、document、policy、runtime を actor として扱えることは重要である。
しかし、それを理由に

誰でも goal を変えてよい
誰でも approve してよい
誰でも memory を書いてよい
誰でも incident を close してよい

とすると、process はすぐに崩れる。

2. durable state を変える操作は本質的に強い

merge、promotion、close、resume after incident のような操作は、future process の前提を変える。
そのため、これらは execution と同じようには配れない。

3. 分業は「役割分担」ではなく「責任の非交換性」を生む

reviewer と coding agent は同じ process に関わっているが、
互いにそのまま交換可能ではない。

coding agent は diff を作れる
reviewer は approve / reject できる
memory writer は durable memory を mutate できる
incident owner は abnormal flow を引き取れる

この非交換性が process を安定させる。

4. 非対称性がないと gate が gate にならない

approval point、promotion surface、recovery gate が意味を持つには、
「通せる actor」と「通せない actor」が分かれていなければならない。

5. 異常時には対称モデルが特に壊れる

平常時は対称に見える process でも、incident・rollback・scope conflict が起きた途端に
「誰が最終判断するのか」が必要になる。
このとき非対称性が明示されていないと、責任の空白が生じる。

だから Asymmetry は、
権力の偏りを正当化するためではなく、
process を責任ある形で継続可能にするための構造
として必要なのである。

Asymmetry は何ではないか

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

1. 単なる hierarchy ではない

非対称性は上下関係そのものではない。
一時的・局所的・subject-specific な非対称性もありうる。

2. 単なる unfairness ではない

PCE 2.0 における asymmetry は、責任配置の機能的性質である。
不透明で恣意的な格差を肯定する概念ではない。

3. 単なる role difference ではない

role の違いは一要素だが、
asymmetry は

authority
obligation
closure power
visibility
write access
escalation sink

まで含む。

4. 単なる permission difference ではない

permission は capability の一部にすぎない。
Asymmetry は、goal、approval、memory、incident まで含めた responsibility topology である。

5. 単なる actor の違いではない

human か AI か、tool か document かだけでは不十分である。
同じ actor kind の中でも、非対称性は設計されうる。

6. 単なる organization chart ではない

組織図の上下がそのまま process 上の責任非対称性になるとは限らない。
PCE 2.0 では frame-local な bundle と gate の配置が重要である。

7. 単なる one-way control ではない

非対称性には retain、delegate、escalate、revoke、recover などの動きがあり、固定された一方向支配とは限らない。

Asymmetry の中心命題

PCE 2.0 の責任系を一文で言うなら、次のようになる。

actor は対称に広がるが、
responsibility は非対称に配分される。
そしてその非対称性は、hidden であってはならず、
frame、bundle、gate、surface、record の形で明示されなければならない。

ここで重要なのは、Asymmetry が 偶然の偏り ではなく
明示的な process design であるという点である。

非対称になる対象

PCE 2.0 では、少なくとも次の対象が非対称に配分される。

1. Goal Asymmetry

誰が goal を定義し、scope を守り、success criteria を保持し、close を accept するか。

2. Execution Asymmetry

誰が実際に work を進めるか。
誰が read-only で、誰が write-enabled で、誰が local sequencing を持つか。

3. Approval Asymmetry

誰が特定 subject を ratify できるか。
誰が request changes しかできず、誰が final approve を持つか。

4. Evaluation Asymmetry

誰が何をどの criteria で判定できるか。
誰が blocking evaluator で、誰が advisory evaluator か。

5. Memory Asymmetry

誰が memory candidate を提案でき、誰が評価でき、誰が durable state に書けるか。

6. Incident Asymmetry

異常時に誰が containment、rollback、replan、resume、close を持つか。

7. Visibility Asymmetry

誰が何を見てよいか。
document、decision、trace、policy、recovery state への visibility は対称ではない。

8. Capability Asymmetry

誰が何をしてよいか。
tool access、write scope、network access、promotion surface への access は非対称である。

9. Temporal Asymmetry

同じ actor でも phase によって責任が変わる。
approval pending 時と execution active 時では bundle が違う。

10. Topological Asymmetry

parent / child frame、primary / delegated actor、incident sink / local handler のように、
process topology 自体が非対称性を持つ。

Hard Asymmetry と Soft Asymmetry

PCE 2.0 では、非対称性の強さも区別できる。

Hard Asymmetry

その actor だけが持つ決定権・変更権・停止権である。
これを越えてはならない。

例:

final approval authority
canonical memory write authority
incident closure authority
reframe authority
merge gate authority

Soft Asymmetry

影響力や助言力の差はあるが、単独では最終確定を生まない。

例:

advisory evaluator
consult-only domain expert
planning proposal right
suggestion-only AI assistant

この区別は重要である。
soft な役割を hard に扱うと過剰統制になり、
hard な役割を soft に扱うと governance failure になる。

Retained / Delegated / Transferred Asymmetry

非対称性は static ではない。
少なくとも次の三つの形で動く。

Retained Asymmetry

ある actor が中心的 authority を retain したまま、
他 actor に局所作業だけを許す。

例:

goal owner が global goal を retain
coding agent に local execution を許す

Delegated Asymmetry

責任の一部を bounded scope で委ねる。

例:

analyst agent に local goal clarification
reviewer に artifact approval
memory writer に operational memory write

Transferred Asymmetry

中心的責任そのものが別 actor に移る。
これは強い transition であり、explicit であるべきである。

例:

ownership transfer
incident command transfer
delegated approver becoming primary for a scope

PCE 2.0 では、多くの実務は retained + delegated の組み合わせで進み、
transferred は例外的な強い変化として扱う方が安全である。

Asymmetry と bundle の関係

Asymmetry は抽象語に留めるべきではない。
PCE 2.0 では、それは Responsibility Bundle の配分構造として表れる。

概念的には、次のように書ける。

responsibility_asymmetry(frame, t) =
  distribution over actors of {
    goal_ownership,
    execution,
    capability_authority,
    approval_authority,
    evaluation_authority,
    memory_write_authority,
    incident_ownership
  }

ここで重要なのは、
「誰が何を持つか」が同じでないこと自体ではなく、
その非一様性が明示され、追跡でき、変更可能であること である。

Asymmetry と Governance Surface の関係

非対称性は bundle の内部にあるだけでは process に効かない。
それは Governance Surface 上に materialize される必要がある。

たとえば、

goal asymmetry → reframe gate / close authority
execution asymmetry → capability surface / write scope
approval asymmetry → approval point / ratification gate
evaluation asymmetry → blocking / advisory evaluator split
memory asymmetry → promotion surface / durable write gate
incident asymmetry → suspension / escalation / recovery gate

として現れる。

このため Asymmetry は、
bundle の配分 と surface への露出 の両方を持って初めて process design になる。

Asymmetry と Actor-local Context の関係

非対称性は、そのまま Actor-local Compiled Context の違いを生む。

同じ frame でも context が違う理由

goal owner は success criteria と unresolved trade-offs を見たい
executor は target files と stop conditions を見たい
approver は diff と evidence と pending gates を見たい
evaluator は criteria と evidence を見たい
memory writer は provenance と target collection を見たい
incident owner は blast radius、rollback anchor、recovery legality を見たい

つまり context の違いは、好みではなく
非対称な責任配置の投影 である。

Asymmetry と Parent / Child Process の関係

親子 process は、非対称性がもっとも自然に現れる場所の一つである。

Parent が retain しやすいもの

global goal ownership
final approval
incident ownership
final merge authority
final frame close

Child に delegate しやすいもの

local execution
local evaluation
bounded analysis
bounded artifact production
local recommendation

ここで重要なのは、child が useful autonomy を持っていても、
親の authority を silent に継承したことにはならないという点である。

つまり parent-child process は、
非対称性を構造として埋め込んだ topology である。

Asymmetry は temporal に変わりうる

同じ actor でも phase によって持つ bundle が変わる。
このため Asymmetry は、静的な権限表ではなく時間依存の構造である。

例

Coding phase

coding_agent: execution 高
reviewer: inactive
memory_writer: inactive

Review phase

coding_agent: execution suspended
reviewer: approval + process evaluation active
memory_writer: candidate triage 準備

Incident phase

coding_agent: suspended or narrowed
product_owner / incident_owner: authority 集中
recovery / rollback decision が中央化

つまり Asymmetry は、
phase ごとに tighten / relax / shift するもの
として設計すべきである。

Asymmetry と incident / recovery の関係

通常時の asymmetry は、incident 時にしばしば強くなる。

通常時

execution は分散
approval は局所
memory writing は後段
incident ownership は dormant

Incident 時

execution が止まる / narrow される
approval / recovery authority が中央化する
escalation path が active になる
stale context が広く invalidate される

つまり incident は、
潜在的な非対称性を顕在化させる瞬間
である。

そのため incident ownership は、asymmetry の極端な表現として読める。

Asymmetry のアンチパターン

PCE 2.0 では、次のような悪い非対称性を避けるべきである。

1. Hidden Asymmetry

実際にはある actor が決めているのに、bundle や gate に明示されていない。
結果として

audit 不能
handoff 不能
recovery 不能

になりやすい。

2. Collapsed Asymmetry

一人の actor が

goal
execution
approval
evaluation
memory writing
incident closure

を全部持ってしまう。
小さな task では許容されることもあるが、risk が高い。

3. Decorative Asymmetry

bundle や policy には非対称性が書いてあるが、surface に反映されていない。
結果として process 上は実質フラットになる。

4. Unjustified Asymmetry

なぜその actor がその authority を持つのか説明できない。
これは単なる権限集中になりやすい。

5. Stale Asymmetry

phase が変わっているのに、昔の権限配置を引きずっている。
approval drift や stale context 再利用を引き起こす。

6. Capability-rich / responsibility-poor actor

実質的に何でもできるのに、何も引き受けていない actor。
危険である。

7. Responsibility-heavy / capability-poor actor

責任だけ与えられているが、実際には必要 capability がない actor。
process stall を招く。

Asymmetry の設計原則

PCE 2.0 では、良い非対称性は少なくとも次を満たすべきである。

1. Explicit

誰が何を持ち、何を持たないかが書けること。

2. Bounded

scope と phase が明示されていること。

3. Traceable

どの authority で何をしたか追えること。

4. Revisable

incident や reframe の際に変更可能であること。

5. Surface-backed

bundle だけでなく gate / capability / approval / audit に現れていること。

6. Justified

なぜその非対称性が必要なのか、process integrity の観点から説明できること。

Asymmetry の最小スキーマ

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

responsibility_asymmetry:
  frame_id:
  axes:
    goal_ownership:
      primary_owner:
      delegated_stewards:
      retained_by_parent:
    execution:
      executors:
      bounded_scopes:
    approval:
      approvers:
      authority_topology:
    evaluation:
      evaluators:
      blocking_vs_advisory:
    memory_writing:
      writers:
      target_collections:
    incident_ownership:
      primary_sink:
      escalation_paths:
  visibility_partitions:
  capability_partitions:
  retained_authorities:
  delegated_authorities:
  transfer_rules:
  revision_triggers:
  provenance:

もっと actor/bundle 寄りに書くなら、次のようにも置ける。

asymmetry_map:
  frame_id:
  actors:
    - actor_ref:
      holds:
        goal_ownership:
        execution:
        approval:
        evaluation:
        memory_writing:
        incident_ownership:
      does_not_hold:
      scope:
      phase:
      escalation_to:
  hard_asymmetries:
  soft_asymmetries:
  audit_requirements:

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

axis ごとの非対称性が見える
retained / delegated / transferred を区別できる
visibility / capability も含められる
phase や revision triggers を持てる

小さな例

feature.checkout.coupon-combination frame では、非対称性はたとえば次のように表れる。

asymmetry_map:
  frame_id: feature.checkout.coupon-combination
  actors:
    - actor_ref: product_owner
      holds:
        goal_ownership: global
        execution: none
        approval: spec_only
        evaluation: none
        memory_writing: none
        incident_ownership: primary
      does_not_hold:
        - code_execution
        - code_review_approval
      scope: feature.checkout.coupon-combination
      phase: all
      escalation_to: release_owner

    - actor_ref: coding_agent
      holds:
        goal_ownership: none
        execution: implementation
        approval: none
        evaluation: none
        memory_writing: none
        incident_ownership: none
      does_not_hold:
        - merge
        - canonical_memory_write
        - final_close
      scope: coupon_validation_and_tests
      phase: implementation
      escalation_to: reviewer

    - actor_ref: reviewer
      holds:
        goal_ownership: none
        execution: review_execution
        approval: code_change
        evaluation: artifact_and_process
        memory_writing: none
        incident_ownership: partial_detection_only
      does_not_hold:
        - global_goal_reframe
        - canonical_memory_write
      scope: review_subjects_only
      phase: review
      escalation_to: product_owner

    - actor_ref: ci_evaluator
      holds:
        goal_ownership: none
        execution: none
        approval: none
        evaluation: blocking_outcome_only
        memory_writing: none
        incident_ownership: none
      does_not_hold:
        - process_judgment
        - approval
      scope: required_regression_suite
      phase: evaluation
      escalation_to: reviewer

    - actor_ref: memory_writer
      holds:
        goal_ownership: none
        execution: none
        approval: none
        evaluation: memory_worthiness
        memory_writing: canonical_and_provisional
        incident_ownership: none
      does_not_hold:
        - code_merge
        - feature_goal_close
      scope: durable_memory_collections
      phase: post_review
      escalation_to: product_owner
  hard_asymmetries:
    - product_owner_retains_global_goal_and_incident
    - reviewer_controls_code_review_approval
    - memory_writer_controls_durable_memory_write
  soft_asymmetries:
    - ci_evaluator_provides_blocking_signal_on_outcome_only
  audit_requirements:
    - approval_record
    - promotion_record
    - incident_record_if_any

この例で重要なのは、actor が同じ project に参与していても、
何を決められるか、何を引き受けるか、どこまでが scope かが全く同じではないことだ。
しかもその非対称性は明示され、traceable である。

Asymmetry の不変条件

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

1. Actor symmetry does not imply responsibility symmetry

actor として数えることは、責任が均等であることを意味しない。

2. No authority by participation alone

process に参加しているだけでは approval / memory_write / incident_ownership は得られない。

3. No hard asymmetry without explicit trace

goal reframe、final approval、memory write、incident closure のような hard asymmetry は明示されていなければならない。

4. No invisible asymmetry

実質的に process を支配している actor / gate が model 上に見えていなければならない。

5. No stale asymmetry across phases

phase が変わったら、非対称性の配置も見直されなければならない。

6. No asymmetry without reviewability

なぜその actor がその責任を持つのか説明できる必要がある。

7. Asymmetry must preserve continuity

handoff、approval、recovery のたびに非対称性が崩れてはならない。

8. Parent retention must remain explicit

child frame に任せても、親が retain している authority は明示されていなければならない。

いつ Asymmetry を見直すべきか

次の条件があるなら、非対称性の設計を見直すべきである。

1. Rework や approval stall が増えているとき

authority topology が悪い可能性がある。

2. Handoff loss が高いとき

誰が何を retain / transfer しているかが不明確かもしれない。

3. Corrupt success が増えているとき

execution と approval / evaluation / memory writing の非対称性が弱すぎるかもしれない。

4. Incident が escalation しすぎるとき

local actor に必要な bounded authority が不足しているか、incident sink が遠すぎる可能性がある。

5. Durable memory が汚染されているとき

memory asymmetry が緩すぎる可能性がある。

6. Parent / child process で authority conflict が起きるとき

goal / approval / incident の retained vs delegated の設計が粗い可能性がある。

短く言えば、
stall、rework、corrupt success、memory pollution、escalation overload が増えたら、非対称性の再設計が必要である
と考えてよい。

最低限の自己点検

ある process が非対称性を適切に設計できているかは、次で点検できる。

actor と responsibility を混同していないか
goal / execution / approval / evaluation / memory / incident の各軸で誰が何を持つか書けるか
hard asymmetry を持つ actor が明示されているか
soft asymmetry と hard asymmetry を分けているか
retained と delegated を区別しているか
parent / child 関係で authority retention が明示されているか
phase ごとの bundle 変化を説明できるか
governance surface にその非対称性が反映されているか
hidden asymmetry や decorative asymmetry がないか
その非対称性が process integrity のために必要だと説明できるか

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

暫定的なまとめ

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

PCE 2.0 において、process の安定性は「みんなで同じようにやること」からは生まれない。
誰が何を引き受け、どこまでを決められ、どこで止められ、何を future process の前提にしてよいかが、非対称に、しかし明示的に配分されてはじめて生まれる。

PCE 2.0 において非対称性は、欠陥ではない。
それは、actor の広がりを認めつつ、責任・権限・継続性を壊さずに process を成立させるための条件である。

だから Asymmetry は、単なる「偏り」ではない。
それは、PCE 2.0 において 責任を交換不可能な形で配置し、governed process を成立させる責任構造の原理 である。