Memory Promotion Rules

定義

Memory Promotion Rules

Memory Promotion Rules とは、ある process delta またはそこから導出された memory candidate を、
どの条件で、どの durable project state の collection へ、どの status で昇格させてよいか を定める
明示的な昇格規則である。

それは単なる保存方針ではなく、
promotion subject、target zone / collection、admissibility criteria、required evidence、required eval、required authority、deduplication / supersession policy、retention / freshness policy を含む。

より短く言えば、Memory Promotion Rules とは
「何を future process のための project memory として残してよいか、何を provisional に留めるべきか、何を残すべきでないか」を決める規則
である。

PCE 2.0 において memory は、「とりあえず残しておくもの」ではありません。
それは、将来の Process Frame が前提にしてよい project-level state です。
したがって、何を残すかは任意であってはならず、明示的な promotion rule に従う必要があります。

この意味で Memory Promotion Rules は、
Durable Project State の健全性を守るための中心規則です。

---

なぜ Memory Promotion Rules が必要なのか

PCE 2.0 が解くべき問題の一つは、長期・多段・多主体の process で生成された膨大な情報のうち、
何を将来に残すべきか を設計することです。

ここで二つの失敗が起こりえます。

1. 過剰保存

何でも durable に残すと、次のような問題が起きます。

• local なノイズが project memory を汚す
• stale な判断が future context を誤誘導する
• raw transcript や speculative note が正規知識に混ざる
• memory compilation の精度が低下する
• maintenance cost が増え、何が canonical か分からなくなる

2. 過少保存

逆に、必要なものを残さないと次の問題が起きます。

• decision rationale が失われる
• 同じ failure を繰り返す
• useful workflow knowledge が蓄積しない
• approval / evaluation の根拠が追えない
• 長い process の継続性が損なわれる

PCE 2.0 では、この両極を避ける必要があります。
そのため、memory は「全部残す」でも「なるべく残さない」でもなく、
選別・抽象化・評価・権限確認を経た昇格 として扱われます。

それを定めるのが Memory Promotion Rules です。

---

Memory / Promotion / Rules の意味

この概念は三つの語から成り、それぞれに意味があります。

Memory

ここでいう memory は、単なる会話履歴や人間の想起ではありません。
それは future process が再利用しうる durable knowledge です。

含まれうるものは、たとえば次です。

• accepted decisions
• rejected alternatives with reusable lessons
• failure memory
• operational memory
• evaluation memory
• governance-related annotations
• approved summaries
• reusable checklists / playbooks / skills

つまり memory は、将来の process に効く project state です。

Promotion

promotion はコピーではありません。
それは「ある内容を durable に残す価値がある」と判断し、適切な zone / collection へ昇格させる行為です。

このとき、promotion はしばしば抽象化を伴います。

• raw note をそのまま残すのではなく summary にする
• log 全体を残すのではなく failure lesson にする
• diff 全体ではなく decision rationale を取り出す
• trace 全体ではなく reusable checklist を抽出する

したがって promotion は、
保存 ではなく 再利用可能な形への選別された再表現 です。

Rules

promotion がその場の勘や個人判断に依存すると、project memory はすぐ不安定になります。
Rules は、それを明示的で再現可能な制度にします。

---

Memory Promotion Rules は何ではないか

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

1. 単なる「保存してよいかどうか」のチェックではない

provisional な保存と canonical な昇格は違います。
Memory Promotion Rules は、単に保存可否を見るだけではなく、
どの durable collection へ、どの status で置くか まで定めます。

2. 単なる artifact merge rule ではない

artifact が正しいことと、それを reusable memory として残す価値があることは別です。
artifact merge の rules と memory promotion の rules は一致しません。

3. 単なる summarization policy ではない

要約は手段の一つにすぎません。
promotion の本質は、再利用価値・scope・provenance・authority を満たす durable item へ昇格させることです。

4. 単なる retention policy ではない

いつまで残すかも重要ですが、promotion rules はその前に
何をそもそも入れるか を決めます。

5. 単なる evaluator の判断そのものではない

評価は重要ですが、promotion rules は evaluator・criteria・authority を含む上位規則です。

6. 単なる personal memory ではない

個人の scratchpad や私的メモは、そのまま project memory とはみなしません。
project が参照可能な durable item に昇格されてはじめて memory になります。

---

Promotion Subject は何か

Memory Promotion Rules が扱うのは、主に次の二種類の input です。

1. Source Delta Item

Process Delta の item そのものです。

例:

• decision delta
• failure delta
• evaluation delta
• operational delta
• governance delta

2. Derived Memory Candidate

delta item や runtime material から導出された memory 候補です。

例:

• code diff から抽出した implementation rationale
• repeated failure から抽出した anti-pattern note
• review trace から抽出した checklist candidate
• long discussion から抽出した approved summary

この区別は重要です。
memory promotion は、常に「元の output をそのまま残す」わけではありません。
むしろ多くの場合、元の delta から durable な memory form を作る ことになります。

この durable 形の候補を、ここでは memory candidate と呼びます。

---

何を memory として昇格しうるか

PCE 2.0 では、少なくとも次のようなものが memory promotion の対象になります。

1. Decision Memory

• accepted rationale
• chosen trade-off
• approved interpretation
• supersession note
• boundary clarification

2. Failure / Rejection Memory

• rejected alternative with reason
• failure pattern
• do-not-repeat note
• scope violation lesson
• anti-pattern

3. Operational Memory

• checklist
• playbook
• workflow pattern
• skill refinement
• runbook note
• integration recipe

4. Evaluation Memory

• accepted test baseline
• grading threshold
• review rubric clarification
• evaluation lesson
• trace quality criteria

5. Governance Memory

• approval rule note
• escalation rule clarification
• policy annotation
• authority boundary note

6. Approved Summaries / Reference Memory

• approved phase summary
• resumable summary with durable value
• stable domain note
• canonical terminology note

一方で、artifact 自体は canonical artifacts として durable state に入ることがありますが、
artifact merge と memory promotion は区別されます。
同じ code patch から、artifact update と decision memory promotion が同時に起こることはありえます。

---

何を memory として昇格すべきでないか

PCE 2.0 では、次のものを canonical memory に昇格することを原則として避けます。

1. Raw Chat / Raw Transcript

未整理の会話履歴は、そのままでは future process にとってノイズが大きすぎます。

2. Unverified Hypotheses

検証されていない仮説や speculative note は、少なくとも canonical memory にはしません。

3. One-off Local Tricks

一回限りの局所 workaround は、再利用性が低いなら memory にしない方がよいです。

4. Authority-unknown Judgments

誰がどの authority でそう判断したのか分からないものは昇格してはなりません。

5. Provenance-poor Summaries

出典や根拠が追えない summary は、future process を汚染しやすいです。

6. Stale Environment Facts

変化しやすい一時的事情を durable memory として固定すると、将来の process を誤誘導します。

7. Sensitive Data Without Reuse Need

権限上・機密上のコストが大きいのに、再利用価値が低いものは memory にすべきではありません。

8. Duplicate Noise

既に durable state にある内容を、差分なく繰り返すだけのものは昇格不要です。

短く言えば、
future process に前提として使わせるには危険すぎるもの、再利用価値が低すぎるもの、由来が弱すぎるものは昇格しない
のが基本です。

---

Promotion の評価軸

Memory Promotion Rules は、少なくとも次の評価軸を持つべきです。

1. Reuse Value

将来の process にとって、再利用価値があるか。
その value は、artifact の correctness とは別です。

2. Stability

短命なローカル事情ではなく、ある程度持続する内容か。
短命であっても保持価値があるなら、canonical ではなく provisional が適切かもしれません。

3. Decontextualizability

元の conversation や trace がなくても理解できる形にできるか。
future process が元文脈なしに読めることが望ましいです。

4. Provenance Sufficiency

どの frame / delta / evidence / authority から来たか追跡できるか。

5. Scope Boundedness

どの feature / module / policy / release に属する知識なのかが明示されているか。
scope のない knowledge は危険です。

6. Non-redundancy

既存 durable state と重複しすぎていないか。
重複するなら update / supersede / merge-not-needed の判断が必要です。

7. Governance Compatibility

権限・機密・approval・sensitivity の観点で durable 化してよいか。

8. Maintenance Cost

残した後の maintenance cost が future value を上回っていないか。
保守不能な memory は将来の負債になります。

9. Evidence Adequacy

再利用に耐えるだけの evidence があるか。
「なんとなく役に立ちそう」だけでは不十分です。

この評価軸は、一般的な correctness 評価とはかなり違います。
Memory Promotion Rules は、future reuse に対する適合性 を問います。

---

Promotion は binary ではない

PCE 2.0 において、promotion の結果は単純な「残す / 残さない」だけではありません。
少なくとも次の結果を取りえます。

1. Promote to Canonical

future process が前提としてよい durable memory へ昇格する。

2. Promote to Provisional

durable には保存するが、canonical にはまだしない。
pending candidate や recovery-oriented note が典型です。

3. Hold / Pending Review

evidence 不足や authority 待ちのため、しばらく保留にする。

4. Supersede Existing Item

新しい candidate で既存 memory を置き換える。
ただし supersession history は残すべきです。

5. Reject Promotion

memory として残す価値がない、または危険が大きいので昇格しない。

6. Archive / Retire

一度 durable だったが、現在は active memory としては扱わない。

この多値性があるからこそ、memory promotion は実務に耐えます。

---

Promotion と Merge の違い

ここは非常に重要です。

Promote

ある candidate を durable memory 候補として認め、
canonical または provisional の target collection に向けることです。

Merge

実際に Durable Project State を更新することです。

PCE 2.0 では、promote と merge を概念上分けます。
たとえば、

• playbook candidate は promote されたが、まだ pending collection にある
• approved decision memory は canonical に promote され、その後 merge された
• failure lesson は evaluate 済みだが authority 待ちで未 merge

といった状態がありえます。

したがって Memory Promotion Rules は、
「何を memory 候補とみなすか」から「どこへ昇格し、どの条件で state に反映するか」までを制御する規則
です。

---

Artifact Merge と Memory Promotion の違い

同じ process から artifact delta と memory candidate が同時に出ることがあります。
しかし両者の criteria は違います。

Artifact Merge が問うもの

• correctness
• regression safety
• spec compliance
• review pass
• policy compliance

Memory Promotion が問うもの

• reusability
• durability
• decontextualizability
• bounded scope
• non-redundancy
• maintenance cost
• future value

たとえば、ある code patch が merge 可能であっても、
その実装メモを durable operational memory に昇格させる必要はないかもしれません。
逆に、ある failure note は artifact に何も変更を加えなくても、memory としては非常に価値があるかもしれません。

この区別を持つことが PCE 2.0 では重要です。

---

Memory Write Authority との関係

Memory Promotion Rules は、常に Responsibility Bundle における memory_write_authority と結びついています。

少なくとも、次の役割を区別できます。

1. Proposer

memory candidate を提案する actor です。
execution actor や reviewer が proposer になることがあります。

2. Evaluator

candidate が reusable か、evidence が足りるかを判定する actor / mechanism です。

3. Memory Writer

最終的に durable state へ昇格させる authority を持つ actor です。

4. Incident Owner / Governance Actor

高リスクな knowledge や policy-sensitive な memory の場合、追加の governance approval が必要なことがあります。

重要なのは、
提案者 = 書き込み権限者 とは限らないことです。

PCE 2.0 では、memory は project の将来条件を変えるので、
書き込み権限は明示的に扱われるべきです。

---

Promotion Candidate のライフサイクル

PCE 2.0 では、memory candidate は少なくとも次のライフサイクルを取りえます。

1. Derived / Proposed
   process delta や working material から候補が抽出される

2. Bound to Promotion Rule
   どの rule で評価するかが決まる

3. Evaluated
   reusability・scope・provenance・non-redundancy などが評価される

4. Approved for Promotion
   memory_write_authority その他必要 authority を通る

5. Promoted
   canonical または provisional の target collection へ昇格候補となる

6. Merged
   durable state に反映される

7. Superseded / Archived / Retired
   将来、より良い memory や policy change により置き換えられる

ここで重要なのは、
candidate が propose された瞬間に durable memory になるわけではないことです。

---

Promotion Rule の基本構成

PCE 2.0 では、Memory Promotion Rule は少なくとも次の成分を持つべきです。

1. Applies To

どの candidate type / delta kind / scope に適用されるか。

2. Target

どの zone / collection に向かうか。

• canonical / decisions
• canonical / failure_memory
• canonical / operational_memory
• canonical / evaluation_memory
• provisional / pending_candidates
• provisional / recovery_points

などです。

3. Admissibility Criteria

昇格可能性を判断する criteria です。

4. Required Evidence

必要な根拠や supporting refs です。

5. Required Eval

どの Eval Contract を通るか。

6. Required Authority

誰の memory_write_authority / approval が必要か。

7. Deduplication Policy

既存 memory と衝突したとき、update / supersede / reject のどれを取るか。

8. Retention / Freshness Policy

どれだけ保持し、いつ stale / archive / retire 扱いにするか。

9. Sensitivity / Governance Policy

機密性、scope、privilege の観点で durable 化可能か。

10. Failure Handling

promotion に失敗したとき、pending に残すのか、reject するのか、rework するのか。

---

Promotion 可能条件の一般形

概念的には、memory candidate の promotion 可能性は次のように書けます。

promotable(candidate) iff
  reusable_value(candidate)
  and bounded_scope(candidate)
  and sufficient_provenance(candidate)
  and required_eval(candidate) has passed
  and required_authority(candidate) is present
  and deduplication_policy(candidate) is satisfied
  and governance_constraints(candidate) are satisfied

canonical promotion の場合は、これにさらに stability と evidence quality の条件が強くかかります。
provisional promotion は、もう少し弱い条件で許されることがあります。

---

Canonical Promotion と Provisional Promotion

Memory Promotion Rules では、この区別が重要です。

Canonical Promotion

future process が前提として使ってよい durable memory への昇格です。
要求水準は高く、通常は次が必要です。

• strong provenance
• sufficient evidence
• explicit authority
• bounded scope
• reusability
• relative stability
• non-redundancy
• appropriate eval pass

Provisional Promotion

durable には保持するが、canonical としてはまだ採用しない昇格です。
典型例は次です。

• pending playbook candidate
• candidate decision summary awaiting approval
• resumable summary
• recovery-oriented note
• memory candidate awaiting more repetitions / evidence

この区別があることで、
有望だがまだ未熟な knowledge を安全に保持できます。

---

Decontextualization Rule

memory promotion で特に重要なのは、decontextualization です。

future process が memory を使うとき、元の会話や元の trace を毎回読むわけにはいきません。
したがって、promoted memory は可能な限り次の性質を持つべきです。

• 単独で読んで意味が通る
• scope が明記されている
• provenance が追える
• future actor が何に使うものか分かる
• 必要なら元資料への ref を持つ

このため Promotion Rules には、
「raw candidate をそのまま入れる」だけでなく、
durable form へ変換する要件 が含まれるべきです。

---

Deduplication と Supersession

project memory が長く続くほど、重複と置換が問題になります。
Promotion Rules は、少なくとも次の方針を持つべきです。

1. Duplicate Rejection

既存 memory と実質的に同じなら、新規 promotion を拒否する。

2. Merge as Update

既存 item を更新する形で取り込む。

3. Supersede with Traceability

新しい item が古い item を置き換えるが、supersession history は残す。

4. Keep Separate by Scope

似ていても scope が違うなら、別 item として保持する。

この policy がないと、operational memory や failure memory がすぐ散らかります。

---

Retention と Freshness

memory を durable にしたあとも、それは永遠に current とは限りません。
Promotion Rules は、少なくとも次を定めるべきです。

1. Freshness Expectation

どの程度の期間 current とみなすか。
とくに governance や environment 依存の memory は更新頻度が高いことがあります。

2. Review Trigger

何が起きたら見直すべきか。

• spec reframe
• policy change
• architecture change
• repeated contradiction
• incident

3. Retention Mode

active / archived / retired / deleted のどれで保持するか。

4. Supersession Handling

新しい memory が出たとき、古いものをどう扱うか。

PCE 2.0 では、memory は一度入れたら終わりではありません。
未来の process に効く以上、寿命も管理する必要があります。

---

Memory Promotion Rules の最小スキーマ

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

memory_promotion_rule:
  rule_id:
  version:
  applies_to:
    candidate_kind:
    source_delta_kind:
    scope:
  target:
    zone:
    collection:
  admissibility_criteria:
  required_evidence:
  required_eval_contract:
  required_authority:
  deduplication_policy:
  supersession_policy:
  retention_policy:
  freshness_policy:
  sensitivity_policy:
  failure_handling:
  provenance:

もう少し詳細に書くなら、次のようになります。

memory_promotion_rule:
  rule_id:
  version:
  applies_to:
    candidate_kind:
    source_delta_kind:
    frame_scope:
    phase_scope:
  target:
    zone:
    collection:
    status_on_entry:
  admissibility_criteria:
    - criterion_id:
      description:
      measurement:
      threshold:
  required_evidence:
    - evidence_type:
      required: true | false
  required_eval_contract:
  required_authority:
    memory_writer:
    additional_approvals:
  deduplication_policy:
    strategy:
    match_basis:
  supersession_policy:
    allowed: true | false
    requires_trace: true | false
  retention_policy:
    mode:
    review_after:
  freshness_policy:
    invalidated_by:
  sensitivity_policy:
    confidentiality_constraints:
    visibility_constraints:
  failure_handling:
    on_fail:
    on_inconclusive:
  provenance:

このスキーマで重要なのは、
promotion rule が「保存してよい」だけでなく、

• 何を target にするか
• どの evidence が要るか
• どの authority が要るか
• duplicate や supersession をどう扱うか
• いつ stale 扱いにするか

まで持つことです。

---

Promotion Decision Record

rule だけでなく、実際の promotion decision も記録すべきです。
最低限、次のように持てます。

memory_promotion_decision:
  decision_id:
  candidate_ref:
  applied_rule:
  verdict:
    state:
    rationale:
  target:
    zone:
    collection:
  evidence_refs:
  evaluator_results:
  authority_refs:
  deduplication_result:
  supersession_result:
  resulting_item_ref:
  timestamp:

これがあることで、後から

• なぜこの memory が durable になったのか
• どの rule で評価されたのか
• 何を置き換えたのか
• 誰が書き込みを認めたのか

を追跡できます。

---

小さな例

「checkout にクーポン併用制約を追加する」process から、
edge-case verification playbook 候補を memory に昇格したいとします。

memory_promotion_rule:
  rule_id: memrule.checkout.operational-playbook.v1
  version: 1
  applies_to:
    candidate_kind: operational_memory_candidate
    source_delta_kind: operational_memory
    scope: checkout
  target:
    zone: canonical
    collection: operational_memory
  admissibility_criteria:
    - criterion_id: reusable_across_frames
      description: single-run local note ではなく、複数の checkout-related frame に再利用可能であること
    - criterion_id: sufficient_evidence
      description: 少なくとも one approved implementation note と one review confirmation を持つこと
    - criterion_id: bounded_scope
      description: coupon-related pricing edge cases に scope が限定されていること
    - criterion_id: decontextualized_form
      description: raw trace なしでも使える checklist 形式になっていること
    - criterion_id: non_redundant
      description: 既存 checkout checklist と実質重複しないこと
  required_evidence:
    - implementation_note
    - review_confirmation
    - failing_or_edge_case_test_ref
  required_eval_contract: eval.checkout.operational-memory.v1
  required_authority:
    memory_writer: memory_writer
    additional_approvals:
      - reviewer
  deduplication_policy:
    strategy: supersede_or_merge_if_similar
    match_basis: scope_plus_checklist_overlap
  supersession_policy:
    allowed: true
    requires_trace: true
  retention_policy:
    mode: active
    review_after: next_checkout_release
  freshness_policy:
    invalidated_by:
      - pricing_architecture_change
      - coupon_policy_model_change
  sensitivity_policy:
    confidentiality_constraints: internal_only
    visibility_constraints: checkout_team
  failure_handling:
    on_fail:
      - remain_provisional
    on_inconclusive:
      - request_more_evidence
  provenance:
    defined_by: memory_writer

この例で重要なのは、
playbook をただ「役に立ちそうだから残す」のではなく、
再利用性・scope・evidence・authority を明示した rule を通して昇格させていることです。

---

Memory Promotion Rules の不変条件

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

1. No canonical memory promotion without explicit rule

canonical memory への昇格は、明示的な promotion rule を持たなければなりません。

2. No memory promotion without provenance

由来の追えない candidate を durable memory にしてはなりません。

3. No memory promotion without bounded scope

scope のない knowledge は dangerous memory になりやすいです。

4. No memory promotion without memory-appropriate eval

artifact correctness のみで memory promotion を決めてはなりません。

5. No raw local context as canonical memory

raw transcript、raw scratchpad、未整理 trace をそのまま canonical memory にしてはなりません。

6. No duplicate accumulation without policy

同じような memory を無限に積み増してはなりません。
deduplication または supersession policy が必要です。

7. No authority-free durable writing

memory write authority のない actor が、暗黙に project memory を更新してはなりません。

8. Provisional and canonical memory must be distinguishable

有望な candidate を保持することはよいですが、canonical と混ぜてはなりません。

---

いつ新しい Promotion Rule を切るべきか

実務上は、次の条件があれば新しい rule を切る意味があります。

1. Candidate Type が変わるとき

decision memory、failure memory、operational memory は別 rule が自然です。

2. Target Collection が変わるとき

canonical decisions と provisional pending candidates では rule が違います。

3. Reuse Horizon が変わるとき

短期の resumable summary と長期の playbook では criteria が違います。

4. Governance / Sensitivity が変わるとき

policy-sensitive memory や restricted-visibility memory には別 rule が必要です。

5. Deduplication Logic が変わるとき

checklist 系と failure lesson 系では重複判定が異なります。

6. Freshness Profile が変わるとき

変化しやすい operational note と、比較的安定した decision memory では retention policy が違います。

短く言えば、
candidate kind、target、reuse horizon、sensitivity、deduplication のいずれかが意味的に変わるなら、新しい promotion rule を切る
のが基本です。

---

最低限の自己点検

ある memory 設計が十分に promotion-aware かどうかは、次で点検できます。

1. 何を memory として昇格したいのか、candidate type を明示できるか
2. artifact merge と memory promotion を区別できるか
3. canonical と provisional のどちらへ向かうか決められるか
4. reusable value / scope / provenance / non-redundancy を criteria として持てるか
5. required eval と required authority を書けるか
6. deduplication / supersession policy があるか
7. retention / freshness policy があるか
8. raw transcript や speculative note をそのまま canonical にしない規則があるか
9. promotion decision の traceability があるか
10. future process がその memory を安全に使えると説明できるか

このどれかが欠けるなら、その memory promotion 設計はまだ粗いままです。

---

関連する概念

Memory Promotion Rules は、PCE 2.0 の memory semantics の中心として、次の概念と強く結びつきます。

• No merge without eval
• Durable Project State
• Process Delta
• Responsibility Bundle
• Eval Contract
• Transitions
• Recovery Point
• Governance Surface
• Memory Promotion Criteria

---

暫定的なまとめ

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

memory は、出たものを残すことではない。
future process に前提として使わせてよい knowledge を、evidence・authority・scope・reusability に基づいて選別し、適切な durable form へ昇格させることである。

PCE 2.0 において memory は、副産物ではありません。
それは project の継続可能性を支える制度です。
そして Memory Promotion Rules は、その制度が「何でも保存する」方向にも、「何も残らない」方向にも崩れないようにするための中核規則です。

だから Memory Promotion Rules は、単なる保存ポリシーではありません。
それは、PCE 2.0 において 何を project の持続的知識として採用してよいかを決める昇格規則 です。