Skip to content

sqlite canonical judgment graph

lipluscodex edited this page Aug 22, 2026 · 2 revisions

SQLite canonical judgment graph

Question

NGR 自身の Decision Structure を、人間向け Wiki entry ではなく machine-native な判断グラフとしてどこに保持するか。

Current resolution

NGR リポジトリ自身を先行実験対象とし、判断ノード、根拠、状態、provenance、typed relation の正本を NGR の SQLite へ移す。AI は raw SQL ではなく、判断追加、更新、置換、休眠、復元、削除候補を原子的に処理する domain-level write API を使う。

GitHub Wiki は正本から外し、必要に応じて SQLite から生成する人間向け view とする。今回の先行実験では Wiki 表示の完全互換を必須条件にしないが、SQLite の判断データ、関係、変更履歴を失わない backup、復旧、決定論的 export または再構築可能性は維持する。

Edges

Background

現行 Decision Structure は state-form entry と明示的 relation により、時系列ログより強い判断グラフを Wiki 上に表現している。一方、entry 数と relation が増えるほど、人間向けページ形式は機械処理にも人間の通読にも冗長になる。NGR はすでに SQLite に document node と typed edge を保持し、Decision Structure を検索対象として利用できるため、読取側より書込側と lifecycle 管理が残る境界になっている。

Constraints

  • AI に raw SQL を公開しない。
  • write API は node、relation、provenance、lifecycle state を一つの transaction boundary で更新する。
  • 物理削除と、通常検索から外す論理的忘却を分離する。
  • supersede は旧判断を暗黙上書きせず、後継への到達経路を維持する。
  • dangling edge、部分更新、二重 successor は fail closed にする。
  • 既存 retrieval、feedback、MCP contract の既定挙動を壊さない。
  • 既存 Wiki entry の本番移行は、fixture migration と round-trip integrity の検証後に行う。

Conclusion

NGR の判断構造は SQLite 内の machine-native graph を将来の正本とする。最初の変更は judgment lifecycle schema、domain write API、deterministic import/export、backup/restore、integrity tests を実装し、Wiki は optional generated view へ下げるための基礎を作る。

Related

Clone this wiki locally