YONAPO RESEARCH
研究記録
MedDSL(仮称)

RESEARCH / RECORD

MedDSL(仮称)P0P0-c

P0-c:主張・否定・未知能力の検証

原文 docs/research/09-p0-c-results.md

10 KB

GitHubで見る

版 be280c0

この文書の目次 5項目

実施日:2026-10-18。状態:主張の確認・訂正、否定の検索、未知能力による停止を JSON ケースとして具体化し、定義推論との組合せを検証しました。停止・衝突の根拠も出力へ追加しました。compare、P0 全 22 ケースの受入評価、独立確認、R4 の評価・臨床実証は未完了です。

最終目標 は、変化に原理的に耐えうる体系の確立です。今回は、知識・記録の訂正と意味の保存を区別し、AI と人が状態・根拠を共有するための有限の検証です。体系の永続性や臨床妥当性の証明ではありません。

後続の P0-d で比較と全22ケースの作成者草案による照合を完了しました。本書の件数・ハッシュ・次の作業は P0-c 時点の記録です。

実装と検証の範囲

採用・保留・訂正・未知能力の停止は P0-a に、正の閉包は P0-b に先行実装済みです。今回はそれらを組み合わせた具体例と開発テストを追加し、次の出力を具体化しました。既存の選択方針や保存認定の条件は変更していません。

状況 出力・判断
可視主張に未知の必要能力 missing_capabilities に加え blocking_assertion_refs を返し、どの主張の意味が解釈できず停止したかを示す
肯定閉包と明示否定の衝突 conflicts に ground atom と positive_evidence・negative_evidence を分けて返す。従来の集約 evidence も維持
未確認 AI 候補・疑い 保留して原情報を残す。別の人の確認後も生成元の情報は書き換えない
記録・確認・訂正の時間差 view ごとに採用と閉包を再計算。将来の確認を先取りせず、確認前の訂正では旧主張を外さない
家族・時点・用途・参照の違い 別文脈の事実を暗黙に結合しない
方法の新たな必須化 既存の記録から得られれば出典付きの回答、なければ needs_information。存在しない方法値を作らない
否定の限界 negative N は N の ground query の opposed を支えるが、定義から対偶を計算して negative A を作らない

未知能力による停止は、保留・訂正済みを含む全ての可視主張を対象にする既存契約です。未知修飾が訂正の意味まで変えるか判断できないため、訂正済みの記録でも必要能力を無視しません。未来の主張はその view を止めず、別文脈の回答も止めません。この制約を P0 契約 に明記しました。

JSON 草案と CLI の照合

P0-b 時点の 13 JSON は生バイトを変更せず、14 JSON を追加しました。追加例の期待値は最初の一括照合前に記述しました。作成者草案であり、独立確認後の正解の凍結ではありません。

ケース JSON 数 必須パスの一致 確認内容
P09 2 13/13 AI 候補の確認前の保留と、確認時点からの採用
P10 2 18/18 元の疑い・訂正例に加え、訂正後の閉包から過去の導出が消えること
P11 1 6/6 家族の肯定を本人の肯定・衝突にしない
P12 2 14/14 直接・導出された肯定と否定の衝突を、両側の根拠付きで返す
P13 1 10/10 記録前・記録直後・確認直前・確認時点の境界
P14 1 10/10 未知修飾のある文脈の停止と該当主張、他文脈の肯定回答
P15 2 11/11 方法が記録にある場合の肯定と、ない場合の情報要求
P17 1 4/4 存在証人を生成する対象外プロファイルを unsupported_profile とする
P21 1 6/6 negative N のみでは、N は opposed、A は未決
P22 2 18/18 二回実行と、集合として扱う入力配列の並べ替え
既存 P01〜P05・P07・P19・P20 12 48/48 定義認定・結合・新しい所属データ・二重導入の回帰
合計 27 158/158 18 ケースを具体化。P0 全 22 ケースの合格数とは別

P10 の二例には前段からの一ファイルを含みます。今回追加した分は 14 JSON・101 指定パスです。P15 の欠落例では、主張が保持する役割は事象・検体・結果だけで、方法値を記録していません。既に方法が含まれる記録を無視して欠落とする例にはしていません。

27 JSON を CLI から実行し、status に対応する終了コードと指定パスを確認しました。未知能力や衝突は正常に報告された意味上の停止なので終了コード 0、未対応 profile は 3 です。前段の入力不正は引き続き 2、未認定の認定操作は 0 です。

開発テストと再現性

Python 3.14.4 で 85 件の unittest が通過しました。P0-b の 62 件を維持し、23 件を追加しました。Python 3.11 自体での実行は未確認です。

  • 生成元 4 種、certainty 2 種、符号 2 種、確認の欠落・直前・一致・未来の 4 条件、計 64 入力を期待表で照合しました。生成元を理由に確認条件を緩めません。この 64 入力は一つの単体テスト内の条件数であり、85 件に加算しません。
  • 確認前の訂正が旧主張を消さず、後から旧主張が確認されても訂正済みを復活させないことを検証しました。分岐する訂正は明示的な解消が揃うまで衝突のままで、多数決・最新優先にはしません。
  • 別文脈を指す訂正を拒否し、文脈の対象者・対象時点・用途の違いを越えて連言を作らないことを検証しました。同じメタデータでも別参照を暗黙の同一文脈とはしません。
  • 直接・導出の衝突を atom ごとに分け、複数衝突・複数支持でも符号別の根拠を保持しました。未知能力の停止元も全ての該当可視主張から集計します。
  • 未知能力が必要な保留・訂正済みの主張、未来の主張、既知能力、依存先の未対応 profile を区別しました。
  • 必須問い合わせの supported・opposed・undetermined・conflict・unassessed を確認し、状態に応じた情報要求を検査しました。変数付き否定や結合の否定を、単一 ground atom の否定検索で代用しません。

P22 の二入力を同じ実装・profile・上限で照合しました。同じ入力の二回実行は全項目一致。別順序の入力は正規化入力ハッシュが異なり、そのハッシュを除いた結果全体が一致しました。CLI の再実行でも確認し、原入力も変更していません。予算 0・1・4 の打切り結果も入力順に依存しないことをテストしました。

並べ替えたのは contexts/views/queries/assertions/reviews と結合 atoms です。役割・引数の順とパッケージ実体は固定しました。パッケージの定義配列の順を変えると、ハッシュと根拠 pointer が変わるため同じ実体とは扱いません。今回の再現性を、異なる意味プロファイルや実装間の互換性としません。

再現と実験票

外部パッケージのインストールは不要です。リポジトリのルートで実行します。

PYTHONPATH=src python3 -m med_dsl --fixture examples/p0/ai-human-confirmation.json
PYTHONPATH=src python3 -m med_dsl --fixture examples/p0/unknown-capability.json
PYTHONPATH=src python3 -m med_dsl --fixture examples/p0/derived-conflict.json
PYTHONPATH=src python3 -m med_dsl --fixture examples/p0/negative-defined-symbol.json
python3 -m unittest discover -s tests

結果 JSON と環境・実行日時・チェック数・P22 の関係検証を Git 管理外の data/research/p0-c/execution.json および同ディレクトリの各結果ファイルへ記録しました。単体テストについてはコマンド・85 件・OK・実測 1.706 秒の実行結果要約を記録しており、全文ログの再取得を目的とする再実行はしていません。性能合格値・速度優位の評価ではありません。

束のハッシュは前段と同様、src/med_dsl/*.py と tests/*.py の相対パス→生バイト SHA-256 をキー順・空白なし JSON にして SHA-256 を計算しました。実装コミットはこの文書とコードを含む履歴で特定できます。

記録 SHA-256
草案 manifest の生バイト 09b6860d3aec58ce580fb5147fe64c4dfc0a7a5d59f21cd9218d4ff46f6fdbec
実行したソース・テストの束 a508787475ab6949801b7c9501768a2e310cda573907bb4d38faaaf2db794c16

残る作業

次は P0-d で compare を実装します。指定した view・Q の両側を評価し、支持 binding の喪失・追加と、衝突・未評価による比較不能を分けます。P06・P08・P16・P18 の残る四ケースも JSON 化し、P01〜P22 全体の作成者草案による受入評価へ進みます。P06/P16/P18 の一部は開発テスト済みですが、全体の受入評価の完了とはしていません。

確認記録の本人性・権限を認証する接続層、永続的な参照レジストリ、一般の古典論理の否定推論、新しい存在証人、臨床ライブラリ、独立した正解確認と R4 の評価は継続課題です。AI が原情報の生成者でも、人の確認記録を別に要求することと、確認者の実認証を備えることは別です。