開発ログ

復旧した出馬情報を正規化し、レース・馬・騎手などのID整合と欠損理由を確定する

30秒でわかる概要

Canonicalのrace_entryと既存出馬情報を比較し、欠けていた1,742組を特定しました。依存する132 race masterと226 horse masterを先に解決し、最終的に1,742 / 1,742組をPROJECTED READYまで整理しています。

実測結果

  • source出馬情報:420,611行
  • source race:30,159
  • source horse:53,043
  • race_entry復旧候補:1,742
  • 不足race master:132
  • 不足horse master:226
  • race master READY:132 / 132
  • horse master READY:226 / 226
  • race_entry PROJECTED READY:1,742 / 1,742
  • HOLD:0
  • Hard Fail:0

どう解決したか

最初のPromotion Gateでは、1,742組すべてがrace master不足でHOLDでした。

horse masterは226件すべて復旧候補にできましたが、race master 132件はvenue_code不足で止まりました。

ここで表示名から推測せず、既存正本のJRA race_id規則を使いました。JRA race_idに埋め込まれたvenue_codeを明示Authorityとして使い、132件すべてをREADYにしています。

Identity Safety

  • display name → ID推測:PROHIBITED
  • source-specific ID:そのまま保持
  • cross-source mapping:NOT PERFORMED
  • provenance:保持
  • available_at:未解決0

DBは変更していない

今回作ったのはderived artifactだけです。

  • Database write:NO
  • Production mutation:NO
  • Network reacquisition:NO

つまり、Canonicalへ実際に書き込む前の「安全に反映できる候補セット」までを固定した段階です。

次工程

次はwrite authorityを独立させ、race master → horse master → race_entryの順でCanonical反映を設計します。その後、前日予想で使える特徴量再構築へ進みます。

Evidence

reports/revenue_first/task_substance_evidence/rf_dev_129_24b_race_entry_canonical_recovery_and_id_integrity_v1_substance_evidence_v1.json

Safety

  • Database access:NONE_FOR_FREEZE
  • Database write:NO
  • Production mutation:NO
  • Identity inference from display name:PROHIBITED

全体ロードマップを見る →

← 開発ログへ戻る

掲載内容は、その時点の開発・検証記録です。将来の利益や的中を保証するものではありません。