30秒で分かる今回の更新
競馬AI開発でTaskが詰まったときに、COMPLETEやACTIVEを無理に書き換えて先へ進むのではなく、**状態を保ったまま安全に復旧するRecovery Capability**を整備しました。
今回確認したのは次の4点です。
- COMPLETE済み24Fを再ACTIVE化せず、不足していたResume用Artifact bindingをBackfill
- 24GをCOMPLETEにせず、再開可能なPENDINGとして退避
- 24Hだけを唯一のACTIVE Taskとして維持
- Backfill / Parking / rollback / 履歴保持 / ACTIVE Task数 / dependency binding / Return前提をFail-Closedで検証
24GへのReturn Pathはcertified済みですが、24H Settlement前なのでReturnはまだ実行していません。
何が危険だったのか
長期開発では、完了済みTaskに後続処理が必要とするbindingが不足したり、未完了Taskが技術的blockerで止まることがあります。
ここで、
- 完了済みTaskを再ACTIVE化する
- 未完了TaskをCOMPLETE扱いする
- ACTIVE Taskを複数作る
- Recovery専用ルールで通常validatorを回避する
といった処理をすると、Repository上は動いていても、正式状態の整合性が崩れます。
今回の判断
今回のRecoveryでは、**不整合があれば進まない**ことを優先しました。
COMPLETE済み24Fは既存EvidenceだけをAuthorityとしてBackfillし、通常のObjective / Dependency validatorがPASSすることまで確認しました。
未完了24GはCOMPLETEにせず、Recovery後に再開できるPENDING状態を維持しています。
Fail-Closedで確認した範囲
Recovery Capabilityでは、少なくとも以下を検証しています。
- Backfill失敗時に部分mutationを残さない
- Parking失敗時にACTIVE Task数を壊さない
- 元TaskをCOMPLETE化しない
- Completion / Publication / Transition履歴を保持する
- dependency binding不一致を許可しない
- Return前提が不足していれば戻らない
現在の正式状態
- 24F: COMPLETEのまま
- 24G: 再開可能なPENDING
- 24H: 唯一のACTIVE Task
- 24H Task本体: settled済み
- Publication Settlement: 未完了
- 24G Return: 未実行
Return Pathはcertified済みですが、条件が揃うまでは実行しません。
この更新の意味
今回の工程は、予想成績を評価する工程ではありません。
Evidenceが示しているのは、
**開発状態が壊れたときに、状態を偽装せず、安全側に倒しながら復旧できる経路を正式化した**
ということです。
競馬AIを長く育てるうえでは、モデルの性能だけでなく、
「失敗したときにどう止まるか」 「どう戻るか」 「いつまで戻ってはいけないか」
まで設計しておく必要があります。
次は24HのPublication Settlementを完了し、その後にcertified済みのReturn Pathで24Gへ戻ります。