Governance Surface

定義

Governance Surface

Governance Surface とは、ある process frame において、
responsibility allocation、capability boundary、approval authority、evaluation authority、memory write authority、policy constraints、audit requirements、recovery constraints が、
実行可能かつ拘束力のある形で process に露出する面 である。

それは単なる規則の一覧ではなく、
visibility gates、capability gates、approval gates、evaluation gates、promotion gates、audit surfaces、escalation channels、suspension / revoke controls として、
actor・runtime・policy engine・review UI・registry・memory system に具体的に表れる。

より短く言えば、Governance Surface とは
「誰が何を見てよく、何をしてよく、どこで止まり、どの条件で承認・評価・昇格され、何が記録されるのか」が process 上で実際に作用する面
である。

PCE 2.0 において governance は、process の外側に後付けで載る安全装置ではありません。
それは process を成立させる条件の一部です。
Governance Surface は、その条件が抽象的な規則ではなく、実際に process を止め、通し、記録し、制限する operational form であることを示します。

この意味で Governance Surface は、
対称的アクター性、非対称的責任 を process 上で可視化する存在論的概念です。

---

なぜ Governance Surface が必要なのか

PCE 2.0 では、責任・権限・評価・昇格は、理論上あるだけでは足りません。
それらが実際に process に作用しなければ、責任モデルは名目上のものに留まります。

少なくとも、次の問題があります。

1. 責任を定義しただけでは enforce されない

Responsibility Bundle に approval authority や memory write authority が書かれていても、
それがどこで・どう process を止めるのかがなければ、実質的には効いていません。

2. actor が増えるほど governance は暗黙化しやすい

human reviewer、AI agent、tool、policy engine、document、runtime が絡むと、
何が誰を拘束しているのかが見えにくくなります。
見えない governance は、実装上はしばしば無効化されます。

3. visibility と capability の混線が起きやすい

「見えること」と「できること」は違います。
しかし surface がなければ、view と authority が自然に混ざりやすくなります。

4. approval と eval の混線が起きやすい

評価に pass したことと、authority を持つ actor が採用を ratify したことは別です。
Governance Surface がなければ、この二つの境界が崩れます。

5. durable state の更新が暗黙化しやすい

何がどの authority で project memory に入ったのか追えなければ、
Durable Project State はすぐに不透明になります。

だから PCE 2.0 では、
責任を持つだけでなく、それが process 上のどこで拘束力を持つか
を定義しなければなりません。
それが Governance Surface です。

---

Governance Surface は「責任が効く場所」である

PCE 2.0 の重要な立場は、責任を抽象語のまま放置しないことです。
責任は、process 上の具体的な surface に現れてはじめて効きます。

例

• approval_authority は approval gate として現れる
• capability_authority は tool allowlist / denylist として現れる
• evaluation_authority は blocking evaluator / advisory evaluator として現れる
• memory_write_authority は promotion gate / durable write surface として現れる
• incident_ownership は escalation channel / suspension authority として現れる

つまり Governance Surface は、
責任モデルの runtime manifestation
です。

---

「Surface」とは何か

ここでいう surface は、単なる UI ではありません。
PCE 2.0 では、surface を「governance が process に露出している接面」として理解します。

この露出は少なくとも三つの形を取ります。

1. Actor-facing Surface

人間や AI actor から見える governance です。

• 承認待ちの表示
• 使える tool の一覧
• 禁止事項の明示
• required checks の提示
• escalate 先の表示

2. Runtime-enforced Surface

人間に必ずしも直接見えなくても、実際に process を拘束する governance です。

• permission denial
• policy check failure
• merge blocking
• checkpoint integrity enforcement
• scope violation detection

3. Audit-facing Surface

何が、誰の authority で、どの evidence に基づいて起きたかを追跡できる surface です。

• audit log
• approval record
• promotion record
• evaluator trace
• supersession history

この surface が後から説明可能な性質として成立しているかを扱うのが Auditability です。

したがって Governance Surface は、
「見える画面」だけではなく、
可視・不可視を含む統治の接面全体 を指します。

human actor がどこで gate、override、freeze、resume、closure を引き受けるかという構造は Human Oversight として表現できる。

---

Governance Surface は何ではないか

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

1. 単なる policy 文書ではない

policy 文書は governance の source にはなりますが、
それが process に拘束力を持つ形で作用しないなら surface ではありません。

2. 単なる approval point ではない

Approval Points は Governance Surface の一部です。
surface 全体は approval より広く、capability、eval、promotion、audit まで含みます。

3. 単なる UI ではない

UI がなくても runtime gating は起こりえます。
逆に UI があっても authority binding がなければ governance ではありません。

4. 単なる Responsibility Bundle ではない

bundle は責任状態です。
surface は、その責任状態が process 上のどこに・どう現れるかです。

5. 単なる actor ではない

actor は process に参与する存在です。
surface は、actor の participation を拘束し、可視化し、記録する面です。

6. 単なる log ではない

audit log は Governance Surface の一部ですが、surface 全体ではありません。
surface には事前制約と進行中の gate も含まれます。

---

Governance Surface の主要ファセット

PCE 2.0 では、Governance Surface を少なくとも次のファセットに分けて考えます。

1. Visibility Surface

誰が何を見てよいかを定める面です。

• artifact visibility
• trace visibility
• decision memory visibility
• pending issue visibility
• policy visibility
• recovery state visibility

これは単なる convenience ではなく、governance の一部です。
見えてはいけないものが見えることも、見るべきものが見えないことも process failure です。

2. Capability Surface

誰が何をしてよいかを定める面です。

• allowed tools
• allowed actions
• write scope
• network scope
• data access scope
• revocable permissions

これは Responsibility Bundle の capability_authority が process 上に現れたものであり、
その operational 境界として詳しく定義されるのが Capability Scope です。

3. Approval Surface

どこで approval が必要で、誰がそれを行えるかを定める面です。

• approval gate
• required approver
• approval subject
• approval ordering
• conditional approval
• rejection path

これは approval_authority の operational form です。

4. Evaluation Surface

どの evaluator が、どの criteria で、どの重みで判定するかを定める面です。

• blocking evaluators
• advisory evaluators
• required evidence checks
• evaluation sequencing
• fail / insufficient evidence handling

これは Eval Contract が process 上で有効になる面です。

5. Promotion Surface

何が durable state に昇格しうるかを定める面です。

• memory promotion gate
• merge gate
• target zone restriction
• required authority for durable write
• provisional vs canonical separation

これは Memory Promotion Rules が runtime 化された面です。

6. Audit Surface

何を記録し、何を追跡できるかを定める面です。

• transition provenance
• approval records
• evaluation records
• promotion decisions
• supersession trail
• incident trace

これがないと governance は検証不能になります。

7. Escalation Surface

どの条件で、どこへ引き上げるかを定める面です。

• escalation triggers
• incident routing
• unresolved ambiguity routing
• authority overflow routing
• policy violation escalation

これは incident_ownership と密接に結びつきます。

8. Suspension / Revocation Surface

進行中の actor や capability を一時停止・取り消しできる面です。

• suspend run
• revoke tool access
• freeze merge
• block promotion
• force human review

これは長時間 process の安全性に直結します。

9. Recovery Surface

どの状態から何を条件に recover できるかを定める面です。

• checkpoint integrity requirement
• recover authority
• resumable scope
• state restoration limits

これは Recovery Point と結びつきます。

---

Hard Governance と Soft Governance

すべての governance が同じ強さで働くわけではありません。
PCE 2.0 では、surface の effect を少なくとも二種類に分けられます。

1. Hard Governance Surface

直接的に process を止める・拒否する・制限する surface です。

• permission denial
• merge blocking
• missing approval block
• scope violation block
• recovery integrity failure
• policy-enforced refusal

2. Soft Governance Surface

推奨・警告・追加確認を促すが、単独では block しない surface です。

• advisory review note
• maintainability warning
• optional escalation suggestion
• non-blocking metric anomaly

この区別は、surface の強度を曖昧にしないために重要です。
soft な signal と hard な gate を混ぜると、誰もどこで止まるのか分からなくなります。

---

Frame-level Surface と Actor-level Projection

Governance Surface は frame 全体に存在しますが、
各 actor が見るのはその投影の一部です。

Frame-level Surface

その frame において有効な governance 条件の全体です。

• 全 approval points
• 全 required evaluators
• global scope constraints
• promotion rules
• audit requirements
• escalation rules

Actor-level Governance Projection

ある actor にとって relevant な governance surface の局所断面です。

• 自分が使える tool だけ
• 自分に必要な approval だけ
• 自分が見るべき policy だけ
• 自分に applicable な stop / escalate 条件だけ

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

actor_governance_surface(actor, frame, t) =
  project(
    governance_surface(frame, t),
    responsibility_bundle(actor, frame, t),
    actor_modality(actor)
  )

この projection が、しばしば Actor-local Compiled Context の内部に埋め込まれます。

---

Governance Surface は何から導出されるか

Governance Surface は独立して空から降ってくるわけではありません。
少なくとも次から導出されます。

1. Process Frame

Process Frame が持つ

• constraints
• approval points
• eval contract
• memory write policy
• stop conditions
• recovery strategy

が surface の基礎になります。

2. Responsibility Allocation

誰が何を担うかに応じて、

• approver
• evaluator
• memory writer
• incident owner
• capability holder

が surface 上の権限主体になります。

3. Durable Project State

既存の governance records、approved policies、accepted baselines が surface に効きます。

4. Eval Contract

どの evaluation が blocking / advisory かを surface に投影します。

5. Memory Promotion Rules

どの durable write が allowed / denied / pending かを surface に投影します。

6. Runtime Constraints

checkpoint integrity、suspend / resume rules、timeout behavior が surface に加わります。

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

governance_surface(frame, t) =
  materialize(
    process_frame,
    responsibility_allocation(frame, t),
    applicable_governance_records,
    eval_contracts,
    memory_promotion_rules,
    runtime_controls
  )

ここで重要なのは、surface は
責任・規則・状態の materialized operational layer
だということです。

---

Governance Surface と Actor の関係

Actor は process に作用する存在ですが、
Governance Surface は actor の participation をどう拘束・可視化・監査するかを定めます。

Operational actor との関係

human reviewer、coding agent、tool runner のような actor には、

• 使える interface
• 見える状態
• required approvals
• blocked transitions

が surface として現れます。

Structural actor との関係

document、policy、registry のような actor には、

• acceptance binding
• scope restrictions
• authority lookup
• normative constraints

として surface が現れます。

重要なのは、
actor が process に参与することと、その参与が govern されていることは別
だという点です。
Governance Surface は、この差を operational に表現します。

---

Governance Surface と Responsibility Bundle の関係

Responsibility Bundle は局所責任状態です。
Governance Surface は、その bundle が process 上のどこで効くかを示します。

対応関係の例は次のとおりです。

• capability_authority → capability surface
• approval_authority → approval surface
• evaluation_authority → evaluation surface
• memory_write_authority → promotion surface
• incident_ownership → escalation / suspension surface

ここで重要なのは、bundle を持っていても、surface がなければ process に効かないことです。
逆に surface が定義されていても、bundle と結びついていなければ正当性がありません。

---

Governance Surface と Actor-local Compiled Context の関係

Actor-local Compiled Context は、actor ごとの working interface です。
Governance Surface は、その中の governance-related 部分を供給します。

たとえば actor-local context には、surface から次が取り込まれます。

• allowed tools
• prohibited actions
• required approval dependency
• mandatory evidence
• stop conditions
• escalation path
• merge / promotion restrictions

ただし Actor-local Compiled Context は governance だけではなく、goal slice や relevant state も含みます。
Governance Surface はその中の 統治的な断面 です。

---

Governance Surface と Transitions の関係

Transition は Governance Surface を横断し、あるいはそれを変化させます。

surface を横断する遷移

• execute
• handoff
• approve
• evaluate
• promote
• merge
• recover

これらは既存 surface の gate を通る／拒否される可能性があります。

surface 自体を変える遷移

• assign
• delegate
• narrow / widen
• revoke
• reframe
• governance update
• supersede policy

これらは governance surface の構造そのものを更新します。

つまり Governance Surface は、
transition を評価する面 であり、
同時に transition によって更新される面 でもあります。

---

Governance Surface と Durable Project State の関係

Governance Surface は ephemeral な runtime effect だけではありません。
その一部は Durable Project State に governance records として残ります。

たとえば次が durable 化されます。

• approval rule
• escalation rule
• scope restriction note
• required evaluator baseline
• promotion authority record
• audit policy

一方で、いまこの frame にだけ有効な gating state は runtime / frame-local surface に留まることがあります。

このため Governance Surface は、

• project-level durable governance
• frame-level active governance
• actor-level projected governance

の三層で理解すると分かりやすいです。

---

Point と Surface の違い

ここは PCE 2.0 で重要な区別です。

Point

離散的な統治地点です。

• approval point
• merge point
• escalation point
• checkpoint point

Surface

それらの point を含み、さらに visibility・capability・audit・policy binding を含む、
より広い統治の面です。

つまり、

• point は局所
• surface は全体

です。

Approval Points は Governance Surface の一部ですが、Governance Surface そのものではありません。

---

Governance Surface の最小スキーマ

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

governance_surface:
  surface_id:
  frame_id:
  source_refs:
    process_frame:
    responsibility_allocation:
    governance_records:
    eval_contracts:
    memory_promotion_rules:
    runtime_controls:
  visibility_surface:
  capability_surface:
  approval_surface:
  evaluation_surface:
  promotion_surface:
  audit_surface:
  escalation_surface:
  suspension_surface:
  recovery_surface:
  projections:
    - actor_ref:
      visible_governance:
      allowed_actions:
      required_gates:
      escalation_path:
  status:
  provenance:

もう少し gate 指向に書くなら、次のようにも表せます。

governance_gate:
  gate_id:
  surface_ref:
  kind:
    # visibility | capability | approval | evaluation | promotion | audit | escalation | suspension | recovery
  subject:
  blocking: true | false
  applies_to:
    actors:
    delta_kinds:
    transitions:
    scope:
  rule_ref:
  authority_ref:
  evidence_requirements:
  failure_effect:
  provenance:

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

1. surface は複数ファセットを持つ
2. actor ごとの projection がある
3. gate は blocking / advisory を持てる
4. source refs により、どこから governance が来たか追える
5. runtime と durable の両方に接続できる

---

小さな例

「checkout にクーポン併用制約を追加する」frame における Governance Surface の例です。

governance_surface:
  surface_id: govsurf.feature.checkout.coupon-combination
  frame_id: feature.checkout.coupon-combination
  source_refs:
    process_frame: feature.checkout.coupon-combination
    responsibility_allocation: alloc.checkout.coupon-combination.v1
    governance_records:
      - gov.checkout-coupon-approval-rule
    eval_contracts:
      - eval.feature.checkout.coupon-combination.artifact.v1
      - eval.checkout.operational-memory.v1
    memory_promotion_rules:
      - memrule.checkout.operational-playbook.v1
    runtime_controls:
      - runtime.checkpoint.main

  visibility_surface:
    reviewer:
      visible:
        - code_diff
        - test_results
        - approved_spec_summary
        - rollback_note
    coding_agent:
      visible:
        - target_files
        - approved_spec_summary
        - limited_adr_excerpt
      hidden:
        - production_credentials
        - unrelated_module_history

  capability_surface:
    coding_agent:
      allowed_tools:
        - repository_search
        - code_edit
        - test_runner
      prohibited:
        - payment_gateway_edit
        - production_access
    reviewer:
      allowed_actions:
        - approve
        - reject
        - request_changes
      prohibited:
        - direct_code_edit

  approval_surface:
    gates:
      - gate_id: gate.spec_approval
        blocking: true
        subject: approved_spec
        authority_ref: product_owner
      - gate_id: gate.code_review_approval
        blocking: true
        subject: artifact_delta
        authority_ref: reviewer

  evaluation_surface:
    gates:
      - gate_id: gate.required_regression
        blocking: true
        subject: artifact_delta
        authority_ref: ci_evaluator
      - gate_id: gate.scope_policy_check
        blocking: true
        subject: artifact_delta
        authority_ref: scope_policy
      - gate_id: gate.maintainability_signal
        blocking: false
        subject: artifact_delta
        authority_ref: maintainability_scorer

  promotion_surface:
    gates:
      - gate_id: gate.memory_promotion_operational
        blocking: true
        subject: operational_memory_candidate
        authority_ref: memory_writer
      - gate_id: gate.canonical_merge
        blocking: true
        subject: canonical_promotion
        authority_ref: reviewer

  audit_surface:
    records:
      - approval_decisions
      - evaluator_results
      - promotion_decisions
      - supersession_history

  escalation_surface:
    routes:
      - trigger: spec_ambiguity
        target: product_owner
      - trigger: policy_violation
        target: incident_owner

  suspension_surface:
    controls:
      - on_scope_violation_suspend_execution
      - on_missing_approval_block_merge

  recovery_surface:
    controls:
      - checkpoint_after_implementation
      - recover_requires_integrity_check

  projections:
    - actor_ref: coding_agent
      visible_governance:
        - allowed_tools
        - prohibited_actions
        - stop_conditions
        - escalation_path
      allowed_actions:
        - edit_target_files
        - run_local_tests
      required_gates:
        - gate.required_regression
        - gate.code_review_approval
      escalation_path: product_owner

    - actor_ref: reviewer
      visible_governance:
        - approval_scope
        - required_evidence
        - merge_gate
      allowed_actions:
        - approve
        - reject
        - request_changes
      required_gates:
        - gate.required_regression
        - gate.scope_policy_check
      escalation_path: product_owner

この例で重要なのは、governance が単なる policy 文ではなく、
誰に何が見え、何ができ、どこで止まり、何が記録されるかとして process に表れていることです。

---

Governance Surface の不変条件

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

1. No responsibility without surface manifestation

重要な responsibility / authority は、必ず何らかの surface として process に現れなければなりません。

2. No authority by implicit convention

approval、promotion、revoke などの重要行為は、暗黙の慣習ではなく surface 上の gate / control として表現されるべきです。

3. No hidden structural governance

document、policy、registry のような structural actor が process を拘束しているなら、その effect は surface 上で可視化されるべきです。

4. Visibility and capability must remain distinguishable

見えることとできることを同じ surface に押し込んでも、概念上は区別されていなければなりません。

5. Blocking and advisory must be distinguishable

強い gate と弱い signal は区別されるべきです。

6. Promotion surface must preserve canonical / provisional distinction

durable write の surface は、canonical と provisional を混同してはなりません。

7. Every governance-relevant transition must trace to a surface

approve、reject、merge、revoke、recover などの遷移は、どの surface / gate に基づいたか追跡可能でなければなりません。

8. Governance surface is actor-projected, not actor-identical

同じ frame-level surface でも、actor ごとに見える投影は違いえます。

---

いつ新しい Governance Surface を切るべきか

実務上は、既存 surface の部分更新で足りるのか、新しい surface を切るべきかが重要です。
次の条件があれば、新しい frame-level governance surface を切る意味があります。

1. Approval topology が変わるとき

新しい approver、別の承認順序、別 risk tier が入る場合です。

2. Capability boundary が大きく変わるとき

read-only phase から write-enabled phase への移行などです。

3. Eval contract が変わるとき

blocking evaluator や required evidence が変わるなら surface も変わります。

4. Memory promotion path が変わるとき

operational memory や governance memory を昇格し始める場合です。

5. Governance actor が追加・除去されるとき

policy engine、new registry、incident owner、security reviewer などが追加される場合です。

6. Recovery constraints が変わるとき

checkpoint policy や recover authority が変わる場合です。

短く言えば、
authority、capability、evaluation、promotion、recovery の構造が意味的に変わるなら、新しい governance surface を切る
のが基本です。

---

最低限の自己点検

ある process 設計が governance-aware かどうかは、次で点検できます。

1. 誰が何を見てよいかと、何をしてよいかを分けて書けるか
2. approval / evaluation / promotion の gate を区別できるか
3. structural actors の拘束力が surface として見えているか
4. blocking と advisory を区別できるか
5. actor ごとの governance projection を説明できるか
6. transition がどの surface を通ったか追跡できるか
7. durable write がどの promotion surface に基づくか説明できるか
8. incident や ambiguity の escalation path が明示されているか
9. suspend / revoke / recover の control surface があるか
10. governance が policy 文書の暗黙了解に留まらず、runtime 上で効いていると言えるか

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

---

関連する概念

Governance Surface は、PCE 2.0 の統治層の中核として、次の概念と強く結びつきます。

• 対称的アクター性、非対称的責任
• No merge without eval
• Actor
• Responsibility Bundle
• Process Frame
• Actor-local Compiled Context
• Capability Scope
• Auditability
• Human Oversight
• Durable Project State
• Process Delta
• Recovery Point
• Transitions
• Approval Points
• Handoff
• Eval Contract
• Memory Promotion Rules
• Checkpoint and Recovery

---

暫定的なまとめ

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

governance は、責任や policy を文章で持っているだけでは成立しない。
誰が何を見てよく、何をしてよく、どこで止まり、どの条件で承認・評価・昇格・回復されるのかが、process 上の surface として実際に作用してはじめて成立する。

PCE 2.0 において governance は周辺機能ではありません。
それは process の内部にあり、責任の非対称性を operational に表現する面です。

だから Governance Surface は、単なる UI や policy 集ではありません。
それは、PCE 2.0 において 責任・権限・可視性・昇格可能性を process に接続する統治面 です。