社名変更履歴エキスパート (Company Name Historian)

ARIA が「法人の名前の歴史」をどのように記録し、非時系列な書類取得（バックフィル）に対しても整合性を保つかを定義します。

1. 真実の源泉 (Source of Truth)

• 単一のソース: [documents_index.parquet]（カタログ）のみを情報源とする。
• 対象フィールド: カタログ上の company_name（漢字名）のみ。カナ・英名は追跡対象外。
• 識別子: JP:XXXXX 形式の証券コードを主軸とする。

2. 履歴再構成アルゴリズム (Reconstruction Logic)

バックフィル等により書類が日付順に届かない状況下でも、以下の手順で決定論的に履歴（NameEvent）を再構成します。

1. 全書類スキャン: 指定された証券コードに紐付く「全期間」の書類をカタログから抽出。
2. 時系列ソート: submit_at (提出日時) の昇順で物理的に並び替える。
3. 状態遷移の検知: ソートされたリストを順に走査し、隣接する書類間で company_name が変化した地点を「社名変更イベント」として抽出。
4. 重複排除: (code, old_name, new_name, change_date) の 4 項目が完全に一致するイベントは物理的に 1 つに集約する。

3. 具体的な挙動ケース (Factual Cases)

ケース: 非時系列な書類取得 (Backfill Scenario)

システム運用開始後、以下の順序 (1～6) で書類を取得した場合の内部挙動： ※社名変更の事実は「2020年: A -> 2025年: B -> 2027年: C」と仮定。

最終的に完成する履歴 (name_history.parquet):

1. 2020-01-01: ARIA総合(S) → ARIA株式会社(A)
2. 2025-01-01: ARIA株式会社(A) → ARIA商社(B)
3. 2027-01-01: ARIA商社(B) → ARIA銀行(C)

4. 物理的な掟 (Strict Rules)

• 非同期許容: 書類がどの順序でデータベースに登録されても、再構成ロジックにより常に「提出日時順のストーリー」が復元される。
• 推測の排除: 有価証券報告書だけでなく、各社が提出する全ての書類（四半期報、臨時報等）を判定対象とすることで、社名変更のタイミングを物理的に絞り込む。
• NULL 保護: カタログ上の company_name が欠落している書類は、遷移判定の計算から自動的に除外する。