Corrupt Success

定義

Corrupt Success

Corrupt Success とは、ある subject が
outcome の観点では成功・十分・有用に見えるにもかかわらず、
process の観点では、governance、scope、authority、evidence、continuity、promotion discipline のいずれかに
success status をそのまま信頼してはならないほどの破損 を含む状態である。

それは単なる「結果がよい process-fail」ではなく、
その subject を 成功として扱い続けること自体が downstream process や durable project state を汚染する ような success である。

より短く言えば、Corrupt Success とは
「見かけ上は成功しているが、そのまま成功として採用すると project の現実を壊す success」
である。

PCE 2.0 において、この概念が重要なのは、
成功に見えること と 成功として採用してよいこと が同じではないからである。

tests pass、diff looks good、summary is convincing、candidate seems useful といった outcome signal は重要だ。
しかし、それだけで canonical truth や durable memory に近づけてしまうと、
future process 全体を誤誘導することがある。
Corrupt Success は、その危険を明示するための概念である。

---

なぜこの概念が必要なのか

PCE 2.0 が Corrupt Success を独立に扱うのは、
AI 時代の process では「正しく見えるもの」が容易に生成される一方で、
その成立条件が壊れていることも容易に起こるからである。

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

1. Outcome だけでは十分性を判断できない

同じ subject が、

• outcome だけを見ると pass
• process を見ると fail

ということが普通に起こる。

例:

• required approval を飛ばした code patch
• prohibited capability を使って得た correct answer
• stale context で作った convincing summary
• provenance の弱いのに useful-looking な memory candidate

2. “成功扱い” が durable state を汚染する

Corrupt Success の危険は、単に「process が乱れている」ことではない。
それを success として扱い続けると、

• bad rationale が decision memory に入る
• wrong subject が merge path に乗る
• stale summary が future context に入る
• unauthorized change が current truth として残る

という形で project reality を壊す。

3. 責任境界の弱い process では latent に残りやすい

execution と approval、evaluation と memory writing、goal ownership と incident ownership が曖昧な process では、
Corrupt Success は見落とされやすい。
だから PCE 2.0 では、これを explicit に名前づけて扱う。

4. “good enough” の乱用を防ぐ必要がある

特に AI assist を含む実務では、

• だいたい合っている
• まあ動く
• たぶん大丈夫
• たぶん同じ意味

で押し切りたくなる。
Corrupt Success という概念は、この押し切りが
future process にとって unsafe である 場合を止めるために必要である。

---

Corrupt Success は何ではないか

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

1. 単なる失敗ではない

Corrupt Success は failure ではない。
むしろ outcome の表面は「成功」に見える。
だからこそ危険なのである。

2. 単なる process imperfection ではない

どんな process にも小さな荒さはある。
PCE 2.0 が Corrupt Success と呼ぶのは、
その process defect を無視して success として採用すると downstream を汚染する 場合である。

3. 単なる low quality ではない

少し読みづらい summary、少し冗長な handoff、軽微な formatting issue は、
必ずしも corrupt success ではない。
重要なのは、success status の信頼可能性が壊れているかどうかである。

4. 単なる悪意や不正ではない

malicious である必要はない。
Corrupt Success は、善意の shortcut、雑な handoff、曖昧な approval、stale context からも生じうる。

5. 単なる evaluator disagreement ではない

evaluator が disagreement しているだけでは corrupt success ではない。
その disagreement を無視して pass 扱いしたり、
適切な escalation をせず canonical path に乗せたりしたときに corrupt success になりうる。

6. 単なる “not ideal” ではない

理想的でない process はたくさんある。
Corrupt Success は、その中でも
採用判断を歪めるレベルの process failure
に限るべきである。

---

Corrupt Success の中心構造

PCE 2.0 において corrupt success を最小形で書くと、次のようになる。

corrupt_success(subject) iff
  outcome_verdict(subject) = pass_or_success_like
  and process_verdict(subject) = materially_unacceptable
  and treating(subject as success) would contaminate
      downstream process or durable state

ここで重要なのは三つある。

1. Outcome pass がある

見かけ上、結果はよい。
そうでなければ単なる failure である。

2. Process fail がある

過程、権限、根拠、継続性、promotion discipline のどこかに重大な破損がある。

3. 汚染可能性がある

その subject を「成功」として扱い続けると、
future process の初期条件が歪む。
これが corrupt という語の核心である。

つまり Corrupt Success は、
surface success + adoption-unsafety
として理解するとよい。

---

Corrupt Success の主な型

PCE 2.0 では、少なくとも次の corrupt success を区別できる。

1. Governance-Corrupt Success

結果は良いが、approval、policy、scope、authority のどこかを壊している。

例:

• required approval を飛ばした merge-ready artifact
• prohibited capability を使って得た correct output
• unauthorized actor が write した durable update

2. Scope-Corrupt Success

結果は良いが、そもそも wrong scope の問題を解いている、または out-of-scope を混入させている。

例:

• feature は動くが unrelated module も変更している
• local optimization のために goal drift が起きている

3. Evidence-Corrupt Success

結果は良いが、その結果を future process の前提にしてよいだけの evidence がない。

例:

• convincing summary だが provenance が弱い
• memory candidate が useful-looking だが source trace がない
• rollback note なしで merge-ready 扱いしている

4. Continuity-Corrupt Success

結果は良いが、handoff / checkpoint / recovery / pending gate continuity が壊れている。

例:

• 正しい diff だが review package が欠けており later recovery できない
• stale context 上で出した正解らしい proposal
• pending approval を失ったまま “done” 扱いしている

5. Evaluation-Corrupt Success

結果は良いが、required eval を飛ばしている、または stale eval に依存している。

例:

• old test results を current pass とみなした
• memory promotion criteria を通さず “有用そう” だけで durable 化した

6. Promotion-Corrupt Success

結果は良いが、durable state への昇格 discipline を破っている。

例:

• raw transcript を approved summary っぽく扱った
• provisional item を canonical のように扱った
• duplicate / stale item をそのまま promote した

ここで重要なのは、同じ subject が複数の corruption type を持ちうることである。

---

Weak, Strong, Propagated

Corrupt Success には強度がある。
PCE 2.0 では次の三段階で考えると扱いやすい。

1. Weak Corrupt Success

process の破損はあるが、まだ canonical path に入っていない。
局所 correction や gate reopening で止められる。

例:

• review 前に見つかった unauthorized diff
• promotion 前に見つかった weak provenance summary

2. Strong Corrupt Success

すでに approve-ready、merge-ready、promotion-ready として扱われつつある。
rollback、re-evaluation、re-approval が必要になることが多い。

例:

• required approval missing のまま merge-ready 扱い
• stale branch return を join 済み扱い

3. Propagated Corrupt Success

すでに downstream process や durable state に波及してしまっている。
correction cost が高く、rollback / retract / supersede / incident handling を要しやすい。

例:

• wrong canonical decision memory が future frame で参照されている
• invalid operational memory が reusable checklist として使われている

この区別は、response strategy を選ぶために重要である。

---

Corrupt Success と Outcome vs Process の関係

Outcome vs Process では、
Outcome pass と Process fail の組み合わせがありうることを述べた。
Corrupt Success は、その中でも特に

「そのまま success として扱うと unsafe」

な部分集合だと考えるとよい。

つまり、

• Outcome 良 / Process 悪
  のすべてが同じ severity ではない
• その中で、adoption / merge / promotion / close の basis にしてはならないもの
  が Corrupt Success である

この定義により、Corrupt Success は
単なる二軸分類ではなく、process-integrity 上の警告概念 になる。

---

Corrupt Success と Approval の関係

Corrupt Success が危険なのは、approval path と結びつくときである。

典型パターン

• evaluator は pass と言った
• approver は深く見ずに approve した
• 実は required preconditions が欠けていた

あるいは、

• approver が authority scope を越えて approve した
• child frame の local approval を親の final approval と誤認した

このとき approval は corruption を除去しない。
むしろ Corrupt Success を ratified corruption に変えることがある。

したがって PCE 2.0 では、

• approval は process fail を打ち消さない
• approval 自体も corrupt になりうる
• approval point は corruption detector ではなく gate なので、preconditions を厳密に扱う必要がある

と考える。

---

Corrupt Success と Evaluation の関係

Corrupt Success は evaluation が弱いときに起きやすいが、
evaluation だけで完全に防げるわけでもない。

Evaluation failure 側から見ると

• wrong subject を評価している
• wrong contract を適用している
• required evidence がないのに pass している
• process 軸を見ずに outcome だけ見ている

といった失敗が corrupt success を生む。

Evaluation が正常でも起こりうる例

• evaluator は advisory only で blocking ではない
• approval path が eval result を無視した
• stale subject に old verdict を流用した

つまり Corrupt Success は、
evaluation defect に還元されることもあるが、
approval・governance・handoff・promotion discipline の defect でも起こりうる。

---

Corrupt Success と Memory Promotion の関係

Memory promotion では Corrupt Success が特に危険である。

なぜなら memory は future process の context seed になるからである。

典型例

• useful-looking だが provenance が弱い checklist
• one-off local workaround を reusable playbook として promote
• raw local note を approved summary 扱い
• failure lesson っぽいが evidence がない note を canonical failure memory として保存

これらは current moment では「役に立ちそう」に見える。
しかし future process にとっては poison になりうる。

このため Memory Promotion Criteria と Memory Promotion Rules は、
Corrupt Success を durable-state 汚染の観点から防ぐ制度として理解できる。

---

Corrupt Success の検出トリガー

Corrupt Success は outcome pass が出たあと、またはその直前に検出されることが多い。
典型的なトリガーは次のとおり。

1. Missing Gate Detection

• required approval missing
• required eval missing
• pending promotion review skipped

2. Authority Mismatch Detection

• wrong approver
• unauthorized writer
• child frame overreaching retained parent authority

3. Scope / Policy Violation Detection

• out-of-scope modifications
• prohibited capability usage
• policy conflict hidden by nice-looking output

4. Evidence Weakness Detection

• provenance missing
• rationale not traceable
• rollback basis absent
• summary source coverage weak

5. Continuity Defect Detection

• handoff package incomplete
• stale context use
• recovery point invalid
• pending gate lost

6. Downstream Contradiction Detection

• later frame cannot explain earlier “success”
• merge appears valid but memory write conflicts
• branch join reveals child success was based on incompatible assumptions

Corrupt Success は often downstream で見つかる。
だから detection を一つの point に閉じず、process 全体で持つ必要がある。

---

Corrupt Success に対する標準応答

Corrupt Success は見つけたら即 delete すればよい、というものではない。
response は corruption の強度と propagation に応じて変わる。

1. Invalidate Success Status

まず「成功扱い」を止める。
これが最初である。

• remove merge-ready
• reopen approval gate
• clear promotion-ready flag
• mark current verdict stale

2. Freeze Unsafe Progression

必要なら active progression を止める。

• suspend execution
• block merge
• hold promotion
• freeze join

3. Re-evaluate / Re-open Gates

不足していた process judgment をやり直す。

• rerun eval
• require missing evidence
• re-open approval point
• re-run memory promotion review

4. Rollback if Already Materialized

すでに path や durable state に波及しているなら Rollback が必要になる。

5. Escalate if Local Resolution is Insufficient

local actor が corruption の blast radius を処理できないなら Escalation する。

6. Emit Records

Corrupt Success は future process の学習対象でもある。
必要なら

• governance note
• failure memory candidate
• incident record
• promotion discipline lesson

を残す。

つまり Corrupt Success は、
単なる bug label ではなく process correction protocol を起動する trigger である。

---

Corrupt Success と Lifecycle の関係

Corrupt Success が検出されると、frame lifecycle は変わる。
典型的には次のような遷移が起きる。

completion_ready
  -> blocked
  -> re-evaluation_pending
  -> pending_approval
  -> completion_ready

あるいはより強い場合には、

active
  -> incident_open
  -> rollback_pending
  -> recovering
  -> replan_pending

つまり Corrupt Success は、
「成功 state の中に process failure が潜んでいた」と判明した瞬間であり、
lifecycle を巻き戻す契機になる。

---

Corrupt Success と Metrics の関係

Process Metrics では
Corrupt Success Rate (CSR) を定義した。
このページの概念は、その metric の意味論を与える。

CSR が高いと何を疑うか

• approval surface が弱い
• process evaluation が薄い
• evidence sufficiency judgment が甘い
• stale context invalidation が弱い
• memory promotion rules が緩い
• handoff / recovery continuity が壊れている

ただし CSR は lagging metric である

corrupt success は often 事後に見つかる。
したがって prevention には leading metrics も必要である。

• Handoff Completeness Rate
• Eval Coverage Ratio
• Gate Bypass Count
• Stale Context Execution Rate
• Memory Promotion Precision

つまり Corrupt Success は概念、CSR はその集計指標である。

---

Corrupt Success の最小スキーマ

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

corrupt_success_assessment:
  subject_ref:
  subject_kind:
  apparent_outcome:
    state:
    evidence_refs:
  process_failures:
    governance:
    scope:
    authority:
    evidence:
    continuity:
    promotion_discipline:
  corruption_severity:
    # weak | strong | propagated
  current_exposure:
    # pre_gate | approval_path | promotion_path | canonical | downstream_propagated
  invalidated_states:
  required_response:
    - invalidate
    - freeze
    - re_evaluate
    - reopen_gate
    - rollback
    - escalate
  provenance:
  notes:

より verdict 寄りに書くなら、次のようにも置ける。

corrupt_success_record:
  record_id:
  frame_id:
  subject_ref:
  outcome_verdict_ref:
  process_verdict_ref:
  why_success_is_untrustworthy:
  contamination_risk:
    downstream_process:
    durable_state:
  severity:
  discovered_at:
  discovered_by:
  current_lifecycle_effect:
  remediation_path:
  audit_refs:

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

1. outcome pass と process failure を両方持つ
2. failure を facet ごとに分解する
3. severity と exposure を持つ
4. remediation path を持つ
5. durable contamination risk を明示する

---

小さな例

例1: Code patch は correct だが approval bypass

• code patch は tests pass
• diff 自体も仕様に合っている
• しかし required reviewer approval を飛ばして merge-ready 扱いしていた

この場合、

• outcome: 良
• process: governance failure
• type: governance-corrupt success
• severity: strong（merge path に入っている）
• response:
  • remove merge-ready
  • reopen approval point
  • possibly record governance note

例2: Useful-looking checklist だが provenance 弱い

• candidate checklist は一見 useful
• しかし source frame / evidence / repeatability が弱い
• canonical operational memory に promote されそうになっている

この場合、

• outcome: 良さそう
• process: evidence + promotion discipline failure
• type: promotion-corrupt success
• severity: weak〜strong（promotion path にどこまで入っているか次第）
• response:
  • hold as provisional
  • request more evidence
  • deny canonical promotion

例3: Correct answer from stale context after scope drift

• answer 自体は一見 correct
• しかし spec が reframe された後の stale local context に基づいている

この場合、

• outcome: 局所的には pass
• process: continuity + scope corruption
• type: continuity-corrupt success
• response:
  • invalidate verdict
  • recompile context
  • re-evaluate subject

---

Corrupt Success の不変条件

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

1. Outcome pass does not clear corruption

結果がよいことは、corrupt success を無効化しない。

2. Approval does not cleanse a corrupt process by itself

approval は process failure を魔法のように消さない。
wrong preconditions なら approval 自体が汚染されうる。

3. Corrupt success must not be silently promoted

corrupt success を canonical truth や durable memory にしてはならない。

4. Corrupt success is often discovered later than it is created

したがって detection は downstream でも可能でなければならない。

5. Corrupt success requires explicit invalidation

「気づいたので黙って直す」だけでは不十分なことがある。
success status の invalidation を traceable にすべきである。

6. Not every process imperfection is corrupt success

minor imperfection と adoption-unsafety は分けるべきである。

7. Memory promotion has its own corrupt-success mode

artifact correctness の問題に還元してはならない。

8. Corrupt success is subject-relative

upstream frame が fail でも、local subject が corrupt success になることはありうるし、その逆もありうる。

---

最低限の自己点検

ある success をそのまま採用してよいか迷ったときは、次を問うとよい。

1. outcome は pass しているか
2. process に重大な fail はないか
3. required approval / eval / evidence は本当に揃っているか
4. authority mismatch はないか
5. stale context や stale verdict を使っていないか
6. scope / policy を破っていないか
7. この success を future process の前提にしてよいか
8. durable state に入れたとき、後で contamination しないか
9. invalidate / re-open gate / rollback を要する兆候はないか
10. これは「雑な成功」ではなく「危険な成功」ではないか

この問いに strong な yes が残るなら、その success は corrupt である可能性が高い。

---

関連する概念

Corrupt Success は、PCE 2.0 の評価と統治の接点として、次の概念と強く結びつく。

• Outcome vs Process
• Eval Contract
• Process Metrics
• No merge without eval
• Approval
• Evaluation
• Memory Writing
• Approval Points
• Rollback
• Escalation
• Checkpoint and Recovery
• Memory Promotion Criteria
• Memory Promotion Rules
• Durable Project State

---

暫定的なまとめ

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

ある結果が正しく見えることは、それを成功として採用してよいことを意味しない。
過程・権限・根拠・継続性・昇格規律のどこかが壊れているなら、その success は future process と durable state を汚染しうる。
それが corrupt success である。

PCE 2.0 において最も危険なのは、明らかな failure だけではない。
むしろ危険なのは、「うまくいったように見えるので、そのまま前提にしてしまうこと」である。

だから Corrupt Success は、単なる警告語ではない。

それは、PCE 2.0 において 見かけ上の成功を process-integrity の観点から疑い、adoption を止め、修正経路を起動するための評価概念 である。