YONAPO RESEARCH
研究記録
MedDSL(仮称)

RESEARCH / RECORD

MedDSL(仮称)P0P0-d

P0-d:比較機能と全22ケースの草案評価

原文 docs/research/10-p0-d-results.md

10 KB

GitHubで見る

版 be280c0

この文書の目次 6項目

実施日:2026-10-18。状態:compare を実装し、作成者草案の P01〜P22 を22/22ケース、37 JSON の指定チェックを221/221 照合しました。API と CLI の一致・再実行・入力の不変性も確認しました。独立確認後の正解による評価、R4 の比較実験、臨床性能、体系の永続性全体の証明は未完了です。

最終目標は 将来の変化に原理的に耐える医療コード体系 の確立です。P0 は、定義追加の十分条件、役割付き情報の結合、記録の訂正、未知能力・計算上限を区別する最初の実装です。外部体系の変換器は含みません。

後続で P1 の研究設計 を作成しました。P1 は未実装で、本書の実行結果・ハッシュは P0-d の記録です。

比較の動作

対象 実装した扱い
共通条件 同じ view・同じ Q を、二つの package/contexts/ledger snapshot に適用する
喪失・追加 完了した正の問い合わせの支持 binding だけを lost/added とする。両側で支持される binding は unchanged
比較不能 衝突・未知能力・計算打切りがある query は incomparable。差分・共通部分・差分根拠は null にする
根拠 喪失は before、追加は after の根拠を返す。ledger_ref を付け、異なる台帳の同じローカル h1 を混同しない
文脈 参照変更は明示的な context_map で対応し、対象者・時点・用途の一致と一対一性を確認する
不変な参照 同じ package/ledger/context 参照への異なる実体、同じ predicate 参照の役割・明示定義の変更を拒否する
推論の独立性 パッケージの参照は両側で検証するが、各側は自分の明示依存閉包だけで推論する
共有上限 max_steps を左右で共有し、before、after の順に使う。完了した比較は後続の打切り後も残す

比較は positive_query_bindings に限定します。根拠だけの変更や、opposed→undetermined のような否定支持の変更は、正の binding の追加・喪失とはしません。両側の状態・根拠は結果に保持します。入力に両側で解決できない語彙がある場合は入力不正とし、欠落から喪失を捏造しません。

同じ述語参照の明示定義は構造で照合し、任意の論理的同値を判定する機能はありません。定義の改訂や異なる意味プロファイル間で Q 自体を引き継ぐ仕組みは後続の研究です。詳細な JSON 形式と上限の単位は P0 契約 に追記しました。

固定した版と評価方法

実装・テスト・全37例・契約・評価スクリプトを 79ea88fd0286452123c4d9059bff71ecc5cd8b42 に固定してから評価しました。評価時の作業ツリーは clean です。P0-c 時点の27例の生バイトは変更していません。今回十例を追加し、その期待値を最初の一括照合前に記述しました。

python3 scripts/research/evaluate-p0.py --cli は次を実施します。

  1. 全22ケースが存在し、全ファイルの生バイト SHA-256 とサイズが manifest と一致することを、計算前に確認する。
  2. 各 request を API で二回実行し、指定パス・入力の不変性・再実行の一致を確認する。欠けた出力パスや JSON 型の違いを一致扱いにしない。
  3. --cli 指定時は各ファイルを CLI でも二回実行し、API との一致・再実行の一致・終了コードを確認する。
  4. P22 の異なる順序の二入力は入力ハッシュが異なり、そのハッシュ以外の結果が一致することを別に確認する。
  5. ケース・チェックの結果、全結果 JSON、実装版・環境・ハッシュを Git 管理外の data/research/p0-d/ へ記録する。

期待値は作成者草案のままです。このコミットとハッシュは実行用草案の版固定であり、独立確認・不一致裁定後の評価用正解の凍結ではありません。予算超過や入力不正のケースは、停止の仕方が草案どおりなら一致と数えています。正例も必須なので、全棄権で合格する評価にはしていません。

全ケースの照合結果

ケース JSON 数 指定チェック 確認したこと
P01 2 11/11 S1 の保存認定と連言からの導出
P02 2 8/8 S2 の保存認定と、所属を逆向きに作らないこと
P03 2 7/7 一般包含の追加の未認定と、旧結論が増える具体例
P04 1 2/2 共有する新記号の二重所有を拒否
P05 1 4/4 循環定義を未認定とし、危険とは断定しない
P06 1 4/4 指定依存ハッシュの不一致を拒否
P07 1 6/6 観察の役割と結合を保持
P08 1 12/12 全ての値が残る射影でも失われる結合を lost とする
P09 2 13/13 AI 候補の保留と、人の確認後の採用
P10 2 18/18 疑い・訂正後の否定・閉包の再計算・履歴保持
P11 2 13/13 家族と本人の分離、明示的な文脈対応
P12 3 20/20 直接・導出の衝突、比較不能と両根拠
P13 1 10/10 記録・確認時点の境界
P14 2 18/18 未知能力の停止元と、文脈ごとの比較不能
P15 2 11/11 必須方法の根拠と情報要求
P16 2 7/7 同じ参照・主張 ID の上書きを拒否
P17 1 4/4 未対応の意味プロファイルを区別
P18 2 10/10 予算0・binding 上限を正常な空回答から区別
P19 3 17/17 新しい所属データによる旧結論の追加と、その根拠
P20 1 2/2 同じ新記号への S1/S2 二重導入を拒否
P21 1 6/6 明示否定の検索と、未対応の対偶の分離
P22 2 18/18 再実行、入力の並べ替え、入力ハッシュの保持
合計 37 221/221 作成者草案22/22ケースの指定条件と一致

API/CLI の一致・各二回実行・入力の不変性は37/37例で確認しました。P22 の二例間の関係確認も通過しました。case 数、JSON 数、指定パス数、単体テスト数は別の分母です。

開発テスト

Python 3.14.4 で 116 件の unittest が通過しました。P0-c の85件を維持・更新し、比較28件と評価器3件を追加しました。以前の「compare は未実装」という能力境界の期待は、実装後の入力検査へ更新しています。Python 3.11 自体での実行は未確認です。

  • 二要素の関係について全16組の前後状態を直接の集合の計算と照合し、方向を反転すると喪失と追加が逆になることを確認した。
  • supported/opposed/undetermined/conflict/unassessed の全25組で、正常な空の支持差分と比較不能を区別した。
  • 同じローカル証拠 ID の台帳ごとの区別、根拠だけが変わる場合、包含の追加による旧結論の変化を確認した。
  • 文脈対応の欠落・参照不正・多対一・暗黙の同一参照との衝突・対象者/時点/用途の不一致を拒否した。
  • 参照の上書き、語彙の片側からの自動流入、左右を合わせた件数上限、入力検査より先に打ち切らないことを確認した。
  • 共有予算の境界、binding 上限、未完成の差分を返さないこと、後続の打切り前に完了した比較を保持することを確認した。
  • 評価器が変更されたファイルハッシュを計算前に拒否し、出力パスの欠落・真偽値と整数の違いを一致扱いにしないことを確認した。

比較の入力配列を並べ替えた試験では、入力全体と各 snapshot のハッシュの違いを除いて結果が一致しました。P22 の query 二例とは別の試験です。意味を持つ役割・引数の順やパッケージ実体は変えていません。

再現と記録

外部パッケージの追加はありません。リポジトリのルートで実行します。

PYTHONPATH=src python3 -m med_dsl --fixture examples/p0/projection-compare.json
PYTHONPATH=src python3 -m med_dsl --fixture examples/p0/unknown-compare.json
python3 -m unittest discover -s tests
python3 scripts/research/evaluate-p0.py --cli

評価スクリプトは各結果と evaluation.json を data/research/p0-d/ に出力し、ケースが不一致なら終了コード1、manifest 等の入力不正なら2で終了します。既定では API の二回実行、--cli で CLI も照合します。全件の照合に独立レビューは含みません。

116件のテストの全文ログも同ディレクトリの unittest.txt に保存しました。実測2.447秒は開発時の一回の記録で、性能合格値や優位性の評価にはしていません。

固定した記録 SHA-256
manifest の生バイト 467bdbd8a16077d68a6f4e3e6757705adef1f0de5f0cd4da77323410e78841a0
実行時の契約文書の生バイト f9c6dc7fdae0d55dfca9b1d1cd93d3c42cd9a0b44e6222f0e1e0af96ac1c3868
ソース・テスト・評価スクリプトの束 4f82b09ae691f8e3b0d59ec2f7dcbb459aee1f129c077439135c127016761cc7

束は src/med_dsl/*.py、tests/*.py、scripts/research/evaluate-p0.py の相対パス→生バイト SHA-256 を、P0 の正規化 JSON にして SHA-256 を計算したものです。契約文書のハッシュは受入実行コミット 79ea88f の実体です。その後の進捗表示・リンクの更新と、実行時に固定した契約を区別します。

次に確かめること

P0 の独立レビューを行い、S1/S2 の条件、合成の反例、未知能力の停止、比較不能・上限の扱いを別の目で確認する必要があります。確認者の割当と評価用正解の凍結は未完了です。

次の P1 は、意味能力を追加する場合とコアを改訂する場合の引き継ぎ契約を設計する段階とします。旧意味を保つ条件、移せない式、未知能力、合成の破綻例を先に具体化します。P0 の固定した断片を将来の全表現へ固定しません。R4 の実資料への接続・移行支援は別の中間用途の実証として進め、D03 の利用条件・保留範囲を維持します。