30秒でわかる今回の進捗
何をした？
新しいCanonicalデータベースを作って終わりにせず、実際に切替判断へ進める状態かを確認しました。
受入れ・安全性・鮮度・ロールバックなど8項目を確認し、8件すべてが実装済みかつ対象テスト済みです。
なぜ必要？
「新しいDBがあること」と「安心して入力経路を切り替えられること」は別だからです。
競馬AIのモデルを比較する前に、入力データ側の条件を同じ基準で確認できるようにします。
何が変わった？
これまでは「Canonical DBができた」という状態でした。
今回は、
**「Canonical DBへ切り替えてよいかを判断できる」**
ところまで進みました。
現在地
今回対象とした8項目はすべて実装・対象テスト済みです。
次はCanonical入力経路そのものの完成確認へ進みます。
---
DBファイルができただけでは完成にしない
Canonicalデータベースに対して、read-onlyで受入れ確認を行えるようにしました。
確認対象は、
- 整合性
- 外部キー
- 主要テーブル
- 行数
などです。
単純に「DBファイルが存在する」だけでは、次工程へ進めません。
必要な条件を確認できることを、受入れ判断の前提にしています。
切替は複数条件をまとめて判断する
切替準備では、1つのチェック結果だけで判断しません。
受入れ、安全性、鮮度、継続観測、ロールバック、旧データベース側の準備状態をまとめて確認します。
条件を満たせばREADY。 不足があればHOLD。
「一部が通ったから切り替える」という判断を避けるための仕組みです。
Reject履歴と現在の問題を分離
Reject Ledgerには過去の問題も履歴として残ります。
そのため、
**累積Reject履歴** と **現在未解決の RETRY_PENDING**
を分けて扱います。
過去の問題を消さずに残しつつ、現在の未解決状態と混同しないようにしています。
検証結果
今回確認した8項目は、すべて
IMPLEMENTED_AND_TARGETED_TESTED
と判定されました。
Task Evidenceでは以下の確認がPASSしています。
task_substance_statustask_substance_coveragetask_substance_unresolvedtask_substance_evidence_refs
今回の意味
今回、モデル性能が改善したわけではありません。
精度・回収率・収益についても、この工程からは何も主張しません。
今回得られたのは、
**新しいデータベースを使ってよいか、同じ基準で確認できる土台**
です。
この土台を使って、次はCanonical入力経路を完成させられるかを確認します。
次の工程
次は、
**Canonical入力経路の完成確認**
へ進みます。
データベース単体の受入れから、実際に競馬AIへデータを届ける経路へ。
その過程も、結果だけでなく「なぜ次へ進めるのか」が分かる形で記録していきます。