状態を上書きせず、事実を複製する：hoshi-data の Commit DAG

hoshi-data の中心にある考え方は、ノードが不変の事実を複製し、明示的な規則から現在の状態を導くことです。この記事は 2026 年 9 月 12 日時点の成果と用途をまとめます。アルゴリズム、具体例、参考文献は英語の技術本文：Replicate Facts, Not Overwritesに掲載しています。

実装したこと

Operation log に対応したデータセットでは、現在の値だけでなく、操作と因果関係を Commit DAG に記録します。ノードは重複コミットや履歴の欠落を識別し、必要な依存関係が揃った後に deterministic replay で検索可能な projection を再構築できます。永続化と検索は引き続き PostgreSQL が担います。

操作の意味も区別します。安全にマージできる操作は毎回グローバルな順序を取得する必要がなく、数量の制約には escrow、排他条件には必要な coordination を使います。結果の finality を明示し、provisional な結果を取り消し不能の約束として扱わないようにします。

同じ結果を要求できる条件は、同じ有効な起点、依存関係が揃った同じ有効なコミット集合、同じ意味を持つ規則が揃うことです。

何に役立つか

不変の履歴があれば、同期を「不足する事実を補う」問題として扱えます。障害後の状態確認、投影の再構築、問題の追跡にも利用できます。データの現在の形だけでなく、その状態に至った記録を保持するためです。

書き込み済み、収束済み、確定済みを区別することは、外部への副作用にも重要です。投影は再構築できますが、送信済みのメールや引き渡した資源は replay だけでは取り戻せません。Outbox と受信側は、一度の append の成功だけでなく、結果の保証に従って処理する必要があります。

結論と保証の範囲

収束は業務上の正しさを意味せず、全レプリカやバックアップへの永続化完了も意味しません。 DAG は任意の操作から協調を不要にするものではなく、エンドツーエンドの exactly-once を保証するものでもありません。すべてのコピーから失われたコミットは復元できず、独立したバックアップも必要です。

これらの能力は、対応する仕組みを導入したデータセットと操作ポリシーに限られます。Checkpoint があるだけで全履歴を安全に削除できるわけではありません。現在の新規ノードは履歴を取得し、自ら再実行して結果を照合するため、スナップショットだけで履歴を省略できるとは説明していません。

バージョンをまたぐ意味の維持、安全な履歴削減、検証可能な復旧は今後の研究課題です。完成済み機能や論文上の新規性として主張しているわけではありません。合意に基づく複製より高速だとも主張せず、性能比較には同等の保証の下で再現可能な実験が必要です。

設計の詳細、Commit DAG の例、finality と checkpoint の議論、関連研究の引用は英語の技術本文を参照してください。