Context Selection

定義

Context Selection

Context Selection とは、ある actor が、ある process frame のある局面において、
自らの responsibility bundle を遂行するために必要な source material の中から、
何を active context に含め、何を by-reference に外出しし、何を除外し、何を pending / unresolved として保持するかを決める選択操作 である。

それは単なる検索や ranking ではなく、
purpose binding、subject binding、safety-floor preservation、governance-aware inclusion/exclusion、freshness filtering、counterevidence retention、continuity preservation、expansion path definition を含む。

より短く言えば、Context Selection とは
「この actor は、この局面で、何を最低限見ていなければならず、何を補助的に持ち、何を参照だけに回し、何を見せてはいけないか」を決めること
である。

PCE 2.0 において context は与えられるものではなく、compile されるものである。
その compile の最初の重要操作が selection である。

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

selected_inputs(actor, frame, t, purpose) =
  select(
    process_frame,
    responsibility_bundle(actor, frame, t),
    runtime_state(t),
    durable_project_state,
    governance_surface(frame, t),
    candidate_materials
  )

その後で、選ばれた input が Compaction を経て、
Actor-local Compiled Context になる。

つまり、

selection = 何を入れるか
compaction = どう畳むか
context = actor が実際に使う局所視界

である。

なぜ Context Selection が必要なのか

PCE 2.0 が Context Selection を独立に扱うのは、
豊富な資料や広い context window があっても、それだけでは process quality が上がらないからである。

少なくとも、次の問題がある。

1. 何でも入れると relevance が壊れる

大量の資料を active に並べると、

low-salience detail が混ざる
stale note が current truth に見える
branch 差分や unresolved issue が埋もれる
required evidence と optional background が同列になる

といった問題が起こる。

2. 何でも削ると safety floor が壊れる

逆に雑に減らすと、

pending approval を見失う
required evidence refs が落ちる
rollback note が消える
scope boundary が抜ける
prohibited action が見えなくなる
provenance がなくなる

という governance failure が起こりうる。

3. actor ごとに必要な view が違う

同じ frame でも、

coding agent
reviewer
evaluator
memory writer
incident owner
checkpoint / recovery actor

では必要な active context が違う。
だから selection は actor-relative でなければならない。

4. purpose ごとに selection は変わる

同じ actor でも、

実装を続ける
review する
evidence を再確認する
recovery から再開する
memory candidate を昇格判断する

では selection の正解が変わる。

5. 選択は判断そのものを形づくる

何を見せるかは、何を判断できるかを決める。
つまり selection は中立ではない。
特に approval、evaluation、memory promotion では、
「何を含めなかったか」がそのまま corrupt success の原因になりうる。

だから Context Selection は、
単なる retrieval 技法ではなく、
責任・統治・判断の前提を構成する process 操作 として扱われる必要がある。

Context Selection は何ではないか

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

1. 単なる Retrieval ではない

検索で候補を集めることは selection の前段になりうる。
しかし retrieval は candidate acquisition であり、
selection は その候補を active context に入れるかどうかを決める 操作である。

2. 単なる Ranking ではない

類似度の高い順に並べるだけでは不十分である。
governance、freshness、required evidence、pending gate を考慮しなければならない。

3. 単なる Compaction ではない

短く畳む前に、そもそも何を残すかを決める必要がある。
selection と compaction は概念上分けるべきである。

4. 単なる Context Budget ではない

Context Budget は floor と ceiling を与える。
selection は、その budget の中で何を実際に active にするかを決める。

5. 単なる Summary 作成ではない

summary は selection の結果として作られることがある。
しかし summary があることは、required evidence や pending gate が保存されたことを意味しない。

6. 単なる visibility policy ではない

visibility policy は selection の一部条件である。
selection 全体は、それに加えて relevance、evidence、continuity まで扱う。

7. 単なる “大事そうなものを入れる” ことではない

大事そうに見えるものだけでは不十分である。
approval や evaluation では、不利な evidence や unresolved issue も選ぶ必要がある。

Context Selection の中心命題

PCE 2.0 における selection の中心命題は次のとおりである。

良い context は、関連しそうなものをたくさん集めた結果ではない。
ある actor が、ある局面で、自分の責任を legal かつ adequate に遂行するために、
必要な core を落とさず、不要なノイズを active から外し、
かつ future recovery や audit に耐えるように選ばれた view である。

この命題から、selection は少なくとも次を同時に満たさなければならない。

actor-relative である
purpose-bound である
governance-aware である
freshness-aware である
continuity-aware である
ref への expansion path を持つ

何から選ぶのか

Context Selection が扱う source pool は一つではない。
少なくとも次の source から選びうる。

1. Process Frame Core

goal
success criteria
scope
constraints
stop conditions
approval points
recovery strategy

2. Responsibility and Governance State

current responsibility bundle
allowed / prohibited actions
visible / hidden collections
required gates
escalation path

3. Runtime State

current lifecycle state
pending approvals
pending evals
pending promotion
unresolved issues
current active subject

4. Durable Project State

canonical artifacts
decision memory
failure memory
operational memory
evaluation memory
governance records
recovery points

5. Process Delta Layer

emitted delta refs
candidate decisions
current artifact diffs
branch returns
pending candidates

6. Continuity Packages

handoff package
recovery package
join package
approval submission package

7. External / Retrieved Materials

documents
code search results
logs
specs
ADRs
datasets
issue records

重要なのは、これら全部が「自動的に active に入るわけではない」ということだ。
selection は、この全体を selection universe として扱い、
そこから target-relative に必要なものだけを選ぶ。

何を選ぶのか

PCE 2.0 では、selected context inputs は少なくとも次の層に分かれると考えるとよい。

1. Mandatory Core

その actor が current responsibility を遂行するために絶対に必要な core である。

典型的には次を含む。

goal slice
current scope constraints
current stop conditions
applicable allowed / prohibited actions
required pending gates
required output contract

これは Context Budget の safety floor に対応する。

2. Decisive Subject and Evidence

いま評価・承認・実行・記憶更新の中心にある subject と、
それに必要な decisive evidence である。

例:

current diff
required test report
approved spec summary
candidate provenance refs
rollback note
branch comparison summary

3. Active Risks and Counterevidence

「成功に見える」ことだけを補強するのではなく、
それを疑うために必要な材料も選ぶ。

例:

unresolved issues
failure note
conflicting evaluator result
scope ambiguity
branch conflict note
known caveat

これは Corrupt Success を防ぐうえで非常に重要である。

4. Local Working Support

今の actor にとってあると useful な補助情報。

例:

recent deltas
nearby decisions
current checklist
limited prior history

5. By-reference Reserve

active には載せないが、必要時に開けるように保持するもの。

例:

full diff
full logs
full discussion
old branch traces
complete ADR

6. Explicit Exclusion

この actor / purpose には見せない、または active にしないもの。

例:

unrelated module notes
hidden governance materials
stale summaries
internal-only sensitive data
raw local scratchpad

つまり selection は、「何を入れるか」だけでなく、
何を active にしないか まで含む。

Selection Criteria Family

Context Selection は勘でやるべきではない。
PCE 2.0 では、少なくとも次の criteria family を持つとよい。

1. Necessity Criteria

その actor が current responsibility を遂行するのに本当に必要か。

これは floor を決める criteria である。

2. Decision Relevance Criteria

今の subject に対して判断や行為を変えうる情報か。
似ているだけ、関連していそうなだけでは足りない。

3. Governance Admissibility Criteria

その actor に見せてよいか、active にしてよいか。
visible であることと useful であることは別だが、
visible でないものは selection の対象から外れる。

4. Freshness Criteria

その情報は current state に対してまだ有効か。
古い approval、古い spec、古い summary は current truth とは限らない。

5. Evidence Sufficiency Criteria

判定や handoff のために required evidence か。
required なら optional support より優先される。

6. Continuity Relevance Criteria

handoff、recovery、join、approval pending などの continuity を保つうえで必要か。

7. Counterevidence / Risk Salience Criteria

成功や完了の narrative に対して、
重要な caveat や disconfirming evidence を持っているか。

8. Non-redundancy Criteria

active view の中で同じ意味を繰り返していないか。
同じことを言う複数の source は compaction や by-reference に回せる。

Selection は inclusion だけでなく exclusion である

PCE 2.0 において selection は、単に「入れるものを選ぶこと」ではない。
何を active にしないかを決めること も中心である。

典型的な exclusion 対象

1. Governance-inadmissible items

その actor に見せるべきでないもの。

2. Scope-irrelevant items

いまの goal slice と関係が薄いもの。

3. Freshness-invalid items

current state に対して stale なもの。

4. Raw local traces

future actor に直接渡すにはノイズが大きすぎるもの。

5. Duplicate support

同じ論点を重ねるだけの冗長資料。

6. Confidence-inflating noise

look convincing だが required evidence ではないもの。

selection において exclusion を明示しないと、
「なぜこれが見えていないのか」「なぜこれが見えてはいけないのか」が曖昧になる。
それは hidden governance や silent omission を生みやすい。

Counterevidence selection が必要である

PCE 2.0 の selection で特に重要なのは、
不利な evidence や unresolved issue も選ばれるべきことがある という点である。

なぜ必要か

もし selection が常に

良く見せる summary
成功を支持する evidence
問題のない部分だけ

を選ぶなら、approval、evaluation、promotion は簡単に腐る。
これは Corrupt Success の温床になる。

典型例

reviewer には unresolved edge case を見せるべき
approver には rollback risk note を見せるべき
memory writer には duplication risk を見せるべき
incident owner には blast radius uncertainty を見せるべき
join owner には branch conflict note を見せるべき

つまり selection は、supportive material だけでなく
decision-relevant counterevidence を含めるべきである。

Selection Pipeline

PCE 2.0 では、selection は少なくとも次の順で考えると整理しやすい。

1. Bind actor, purpose, subject

誰のための、何のための selection かを固定する。
これがない selection は曖昧すぎる。

2. Materialize safety floor

goal slice、scope、gates、required evidence、stop conditions などの mandatory core を確保する。

3. Select decisive evidence

current subject の判断・行為に必要な decisive evidence を入れる。

4. Select active risks and unresolved issues

成功 narrative を壊しうる情報、pending 問題、counterevidence を加える。

5. Add bounded support

floor と decisive evidence を満たした上で、
予算に応じて useful support を追加する。

6. Apply exclusion and freshness filters

hidden / stale / irrelevant / duplicate なものを active から外す。

7. Mark by-reference reserve

必要時に戻れる refs を明示する。

8. Hand off to compaction

選ばれた素材を、target modality に合わせて畳む。

ここで重要なのは、selection と compaction は often 反復するが、
概念上は「選ぶこと」と「畳むこと」を分けるべきだという点である。

Context Selection と Context Budget の関係

Context Budget は、

どこまでを floor として保つか
どこまでを hard ceiling とするか

を定める。
selection は、その envelope の中で何を active にするかを決める。

関係

budget は境界条件
selection はその境界内での選択
compaction は選ばれたものをその境界内に収める変換

重要な原則

もし mandatory core を選ぶだけで ceiling を超えるなら、
selection や compaction で押し込むのではなく、process を変えるべきである。

child frame に切る
branch を切る
staged review にする
checkpoint して later pass に回す
escalation / reframe する

つまり budget overflow は selection failure というより
framing failure のシグナル である。

Context Selection と Compaction の関係

selection と Compaction は密接だが、異なる。

Selection が答える問い

何を active に入れるか
何を by-reference にするか
何を見せないか

Compaction が答える問い

選んだものをどう畳むか
冗長性をどう減らすか
どんな形式に整えるか

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

actor_local_context =
  package(
    compact(
      select(...)
    )
  )

この区別が重要なのは、
「選ぶべきものを選ばずに compaction でごまかす」
のを防ぐためである。

Context Selection と Governance Surface の関係

selection は governance-neutral ではない。
Governance Surface は、selection の境界条件を与える。

例

visible collections だけが selection universe に入る
prohibited action を持つ actor に、それに関わる control surface を表示する必要があることもある
pending approval は approver には floor だが executor には by-reference でよいかもしれない
hidden policy note は local executor の active context に入れてはならない

つまり selection は、
governance を通した active visibility shaping
として理解できる。

Context Selection と Eval Contract の関係

Eval Contract は、required evidence と criteria を定める。
selection は、それを evaluator / approver / reviewer の active context に反映する。

重要な点

required evidence は floor になる
counterevidence も selection 対象になりうる
contract version や applicability が current かどうかも見なければならない
stale eval result を current evidence として選んではならない

evaluation-aware な selection が弱いと、
required eval を通ったように見えて実際は evidence が足りない、という corruption が起こりやすい。

Context Selection と Memory Promotion の関係

memory writing / memory evaluation の selection は、
execution や review とは異なる。

memory writer に必要なもの

candidate itself
source delta ref
provenance
target collection semantics
duplication context
prior related durable items
required eval result
scope note
freshness / supersession context

してはいけないこと

candidate の useful-looking 部分だけを見せる
raw transcript をそのまま active にする
provenance や scope note を落とす
current durable state との重複関係を見せない

このため memory promotion selection は、
artifact review selection より often 厚い evidence floor を持つ。

Context Selection と Handoff の関係

Handoff は target actor が work continuity を受け取るための transition である。
selection は、その target actor に何を active に渡すべきかを決める。

良い handoff selection

transferred responsibility を見せる
retained responsibility も見せる
pending gates を保持する
relevant evidence を限定して示す
unresolved issues を落とさない
next action を一意に近づける

悪い handoff selection

source local context を丸ごと渡す
raw transcript 全部を渡す
success を支持する情報だけ選ぶ
target に不要な authority-conferring detail を見せる
pending approval / pending eval を落とす

つまり handoff quality は、selection quality にかなり依存する。

Context Selection と Checkpoint / Recovery の関係

recovery では、selection が通常時よりさらに重要になる。
recover 時に raw past を全部 active に戻すのは unsafe である。

recovery selection で特に必要なもの

current lifecycle state
pending gates
emitted delta refs
stale context markers
rollback anchors
legal next transitions
resume authority conditions

recovery selection で避けるべきこと

old active context を current truth として丸ごと戻す
pre-reframe summary を current に見せる
already-invalid branch return を active に戻す

recover selection は、
continuity-preserving and drift-aware selection
でなければならない。

Context Selection と Branch-and-Join の関係

複数 branch や child return を比較するとき、selection は join の質を大きく左右する。

join selection で必要なもの

required branch returns
comparison criteria
conflicting assumptions
unresolved join conflicts
branch-specific risk notes
integration owner が必要とする evidence

危険な選び方

“一番良さそうな結果” だけ選ぶ
失敗 branch の lesson を消す
sibling conflict を compact 前に消す
branch ごとの差を flatten する

selection の時点で比較軸が失われると、
join は process corruption を起こしやすい。

Context Selection は stale になりうる

selection の結果は固定ではない。
次のような変化が起きると再選択が必要である。

1. Phase change

analysis → implementation → review → promotion で必要な core が変わる。

2. Actor change

executor → reviewer、child → parent、incident owner などで selection は変わる。

3. Gate change

approval / eval / promotion pending 状態が変わる。

4. Reframe / Rollback / Escalation

goal や scope や lifecycle が変わる。

5. Recovery

recover 後は stale context を前提にできない。

6. New decisive evidence

新しい failing test、new branch conflict、new provenance issue などが出る。

7. Memory path entry

candidate が promotion subject になったとき、selection core が変わる。

したがって selection は、
current state にだけ有効な active-choice である。

Context Selection の failure modes

PCE 2.0 では、少なくとも次の failure mode を意識すべきである。

1. Safety-floor omission

必要な goal / scope / gate / evidence を選んでいない。

2. Gate evaporation

pending approval / eval / promotion が active view から消える。

3. Evidence starvation

required evidence refs が落ち、judgment が unsupported になる。

4. Counterevidence suppression

都合の悪い unresolved issue や failure note が見えない。

5. Scope laundering

out-of-scope change や policy conflict が selection で消える。

6. Authority leakage

本来見せるべきでない authority-sensitive material を見せる、
または retained authority を曖昧にする。

7. Staleness contamination

古い summary、古い verdict、古い branch return を current として選ぶ。

8. Branch flattening

alternative branches の差や conflict を active view から潰してしまう。

9. Over-selection

必要以上に多くの資料を active に入れ、salience を壊す。

10. Silent omission

何を外したか、なぜ外したかが traceable でない。

これらはすべて、later な Corrupt Success や bad handoff や unsafe recovery の原因になりうる。

Context Selection の最小スキーマ

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

context_selection:
  selection_id:
  actor_ref:
  frame_id:
  phase:
  purpose:
  subject_refs:
  source_pools:
    process_frame:
    runtime_state:
    durable_refs:
    delta_refs:
    handoff_refs:
    recovery_refs:
    external_refs:
  mandatory_core:
    goal_slice:
    scope_constraints:
    pending_gates:
    required_evidence_refs:
    stop_conditions:
    expected_output:
  selected_support:
  selected_counterevidence:
  exclusions:
  by_reference_reserve:
  authority_filters:
  freshness_policy:
    source_epoch:
    invalidated_by:
  budget_ref:
  compaction_policy_ref:
  invalidation_triggers:
  provenance:

selection result を record として持つなら、次のようにも書ける。

context_selection_record:
  selection_ref:
  selected_active_items:
  selected_by_reference_items:
  omitted_items:
  floor_preserved: true | false
  pending_gates_preserved: true | false
  evidence_floor_preserved: true | false
  current_freshness:
  notes:

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

actor / phase / purpose がある
mandatory core を独立に持つ
support と counterevidence を分けられる
exclusions と by-reference reserve を持つ
freshness と invalidation を持つ
budget / compaction と接続している

小さな例

feature.checkout.coupon-combination frame の reviewer 用 selection を書く。

context_selection:
  selection_id: sel.review.checkout.coupon-combination.v1
  actor_ref: reviewer
  frame_id: feature.checkout.coupon-combination
  phase: review
  purpose: artifact_and_process_review
  subject_refs:
    - delta_item.code_patch
  source_pools:
    process_frame: feature.checkout.coupon-combination
    runtime_state: runtime.feature.checkout.coupon-combination.review_pending
    durable_refs:
      - artifact.spec.coupon-combination.v1
      - decision.no-payment-gateway-change
      - adr.coupon-precedence
    delta_refs:
      - delta.feature.checkout.coupon-combination.v3
    handoff_refs:
      - handoff.feature.checkout.coupon-combination.impl-to-review.v1
    recovery_refs:
      - rp.feature.checkout.coupon-combination.after-impl.v1
    external_refs:
      - ci_run_554
  mandatory_core:
    goal_slice: >
      code change が approved spec と scope に整合しているかを判断し、
      merge readiness を approve / reject / request_changes する
    scope_constraints:
      - payment_gateway_changes_are_out_of_scope
    pending_gates:
      - code_review_approval
      - required_regression_confirmation
    required_evidence_refs:
      - code_diff_ref
      - ci_report_ref
      - approved_spec_summary_ref
      - rollback_note_ref
    stop_conditions:
      - missing_required_evidence
      - scope_violation_detected
    expected_output:
      - approval_verdict
      - review_comments
  selected_support:
    - implementation_note_summary
    - changed_files_summary
    - precedence_adr_excerpt
  selected_counterevidence:
    - unresolved_issue.edge_case_stacked_discount_rounding
    - failure_note.naive_threshold_regression
  exclusions:
    - coding_agent_internal_iteration_notes
    - unrelated_marketing_rule_notes
    - production_credentials
  by_reference_reserve:
    - full_diff_ref
    - full_ci_log_ref
    - full_precedence_adr_ref
  authority_filters:
    visible_collections:
      - current_diff
      - relevant_decisions
      - required_evidence
    prohibited_actions:
      - direct_code_edit
  freshness_policy:
    source_epoch: review_package_generated_at_2026_03_09T10_30_00Z
    invalidated_by:
      - code_diff_changes
      - approved_spec_changes
      - ci_report_changes
  budget_ref: reviewer_review_budget_v1
  compaction_policy_ref: comp.review-package.checkout.coupon-combination.v1
  invalidation_triggers:
    - new_scope_conflict_found
  provenance:
    selected_from: feature.checkout.coupon-combination

この selection で重要なのは、

reviewer に必要な floor は落ちていない
unresolved issue と failure note も選ばれている
coding agent の raw local notes は active にない
full diff や full log には ref で戻れる
stale になる条件が明示されている

という点である。

Context Selection の不変条件

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

1. No selection without explicit actor and purpose

誰のための、何のための selection かが必要である。

2. No selection below the safety floor

goal / scope / gate / required evidence / stop condition を落としてはならない。

3. Governance-relevant exclusions must be respected

見せてはならないもの、見せると authority leakage になるものを active にしてはならない。

4. Counterevidence must not be systematically suppressed

成功 narrative に不利な情報を一律に落としてはならない。

5. Freshness must be declared

selected view がいつ stale になるか明示されなければならない。

6. By-reference must remain reachable

外に出したものは、必要時に戻れる必要がある。

7. Selection does not imply approval or truth

選ばれて active に入ったことは、それが canonical truth であることを意味しない。

8. If mandatory core cannot fit, redesign the process

unsafe omission ではなく、frame / branch / review topology を変えるべきである。

9. Same source may require different selections for different actors

one-size-fits-all selection をしてはならない。

10. Selection should preserve accountability

誰が何をもとに判断したかを後から追えるようにすべきである。

最低限の自己点検

ある context selection が十分かどうかは、次で点検できる。

target actor と purpose を言えるか
mandatory core を列挙できるか
pending gates を落としていないか
required evidence refs が残っているか
counterevidence や unresolved issues を不当に消していないか
hidden / stale / irrelevant なものを active から外しているか
by-reference reserve を持っているか
freshness / invalidation を持っているか
budget と compaction に接続できるか
selected view をそのまま durable truth と誤認していないか

このどれかが欠けるなら、その selection はまだ PCE 2.0 の意味で安全ではない。

暫定的なまとめ

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

context は「関連しそうなものを集めること」では成立しない。
ある actor が、ある局面で、必要な core を失わず、不要なノイズや不適切な情報を active から外し、必要なら ref で戻れ、しかも pending gate と evidence を保ったまま判断できるように、source material を選び直してはじめて成立する。

PCE 2.0 において selection は、検索の後処理ではない。
それは、責任・統治・継続性に適合した local view の入り口を決める操作である。

だから Context Selection は、単なる検索でも ranking でもない。
それは、PCE 2.0 において 何をいまの active context として成立させてよいかを決める governed inclusion / exclusion operation である。