P2-e：実装前の正例・反例と手指定の期待

作成日：2026-10-20。状態：設計用の手指定期待。実行用JSON・テスト・実測結果はまだない。意味設計 の受入条件を具体化します。記載するID・個体・述語は全て架空です。実装の出力から作った正解ではなく、覆り得る作成者側の内部判断です。

1. 表の読み方

日付 d は 2026-10-ddT00:00:00Z、d+½ は同日12:00:00Zです。期間 [1,10) は10月1日00時を含み、10日00時を含みません。k は参照時点、t は対象時点です。日単位に丸めるruntimeの仕様ではありません。

全例は単一文脈 c・単一原子 P(u)。文脈の subject_ref は u、effective_at は1日、purposeは架空の研究用途とし、いずれも変更しません。必要な能力は既知のP0と時間profileです。例外を明記しない主張はconfirmed、人の確認済み、originはobserved、訂正なし。各記録の記法は次です。

A: +[1,10), rec=2, rev=2
    Aは肯定、期間[1,10)、記録2日、人の確認2日。
B: -[4,6), rec=7, rev=8, revises=A
    Bは明示否定、記録7日、確認8日。Aを[4,6)内で訂正する。
rev=なし は人の確認なし。revisesを持つ主張には理由も明示する。

下表の「採用+ / 採用- / 除外」はPos / Neg / Sの主張ID集合です。∅ は空集合。— は停止しており、完成した集合を出さないことを意味します。判定は新型の literal_state で、旧P0の supported 等ではありません。

2. T：意味の条件20件

遡及記録・境界・全体訂正との差

ID	入力	k / t	手指定の期待	採用+ / 採用- / 除外
T01	A: +[1,5), rec=8, rev=9	6 / 3	neither。Aはまだ可視でない。阻害や根拠にも出さない	∅ / ∅ / ∅
T02	T01と同じ	8 / 3	neither。記録は見えるが確認は見えない	∅ / ∅ / ∅
T03	T01と同じ	9 / 3	positive_only。記録・確認がともに見える	A / ∅ / ∅
T04	T01と同じ	9 / 1	positive_only。開始ちょうどを含む	A / ∅ / ∅
T05	T01と同じ	9 / 5	neither。終了ちょうどは含まない	∅ / ∅ / ∅
T06	T01と同じ	9 / 6	neither。期間外を否定にしない	∅ / ∅ / ∅
T07	A: +[1,10), rec=2, rev=2。B: -[4,6), rec=7, rev=8, revises=A	8 / 3	positive_only。Bの訂正範囲外ではAが残る	A / ∅ / ∅
T08	T07と同じ	8 / 4	negative_only。開始境界でBがAを除く。Bの確認根拠を返す	∅ / B / A
T09	T07にC: +[5,6), rec=9, rev=9, revises=Bを追加	9 / 5	positive_only。Bは除かれてもB→Aが効き続ける。根拠にB→AとC→Bを含む	C / ∅ / A,B

T07の反例が方針を分ける理由です。A/Bの期間を消して旧P0の supersedes に翻訳すると、k=8でAは全体から除かれ、後からt=3で絞っても戻りません。この「期間を消す翻訳」は不適切な方法を示す反例で、実装する変換器ではありません。 新方針はt=3でAを残します。旧方式と同じ意味だという認定はできません。

T09について、t=4ではBのみ（Aを除外）、t=6ではAのみ（除外なし）となります。訂正された記録を一律に復活させる方法も、どの時点でも元記録を消し続ける方法も期待と一致しません。

否定・競合・期間情報の不足

ID	入力	k / t	手指定の期待	採用+ / 採用- / 除外
T10	A: +[1,5), rec=1, rev=1。B: -[5,8), rec=2, rev=2。訂正関係なし	9 / 5	negative_only。接する区間を競合させない	∅ / B / ∅
T11	A: +[1,6), rec=1, rev=1。B: -[5,8), rec=2, rev=2。訂正関係なし	9 / 5	both。重なった時点では双方と確認根拠を返す	A / B / ∅
T12	T11と同じ	9 / 6	negative_only。肯定側の終了境界	∅ / B / ∅
T13	A: +unknown, rec=2, rev=2	9 / 5	unassessed / validity_unknown、値null。全期間の肯定にもneitherにもしない	— / — / —
T14	A: +unspecified, rec=2, rev=2。B: +[1,10), rec=3, rev=3	9 / 5	unassessed / validity_unspecified。BがあってもAの影響を除外できない	— / — / —
T15	A: +unknown, rec=2, rev=なし、origin=ai_candidate。B: +[1,10), rec=3, rev=3	9 / 5	positive_only。未確認の期間不明は採用しない。Aは保留のまま	B / ∅ / ∅

訂正の可視性と能力の停止

ID	入力	k / t	手指定の期待	採用+ / 採用- / 除外
T16	A: +[1,10), rec=2, rev=9。B: -[4,6), rec=7, rev=8, revises=A	8 / 5 と 9 / 5	両方 negative_only。Aの確認が後から見えてもBを飛び越えて復活しない	いずれも ∅ / B / A
T17	T07のBをrev=9に変更	8 / 5	positive_only。未確認のBはAを除けない	A / ∅ / ∅
T18	A: +[1,10), rec=2, rev=2。X: -[7,8), rec=3, rev=なし。Xに未知能力を付す	9 / 5	unassessed / unknown_capability。Xは未確認かつ期間外でも阻害	— / — / —
T19	T18のXをrec=10に変更	9 / 5	positive_only。未来の未知能力をまだ阻害に使わない	A / ∅ / ∅
T20	A: +[1,10), rec=2, rev=2、未知能力あり。B: -[4,6), rec=7, rev=8, revises=A	9 / 5	unassessed / unknown_capability。Aが部分訂正済みでも能力を落とさない	— / — / —

全T条件で、clinical_assertions_added=[]、converted_to_base=false、認定なし、入力不変、全原記録を保持することを共通の期待にします。停止した行には部分的な採用集合を返しません。T01〜T20は20条件で、T09の補助時点やT16の複数viewを実行例に展開した後のJSON数・必須パス数はまだ確定していません。

3. N：不正入力・契約境界10条件

これらは意味の20条件と別に数えます。具体的な細分化エラーcodeはnative仕様で固定しますが、以下の処理状態・理由の区別は受入条件です。N01〜N07の検査は予算に依りません。

ID	反例・境界	手指定の期待
N01	旧P0要求を変更せずに新handlerを登録。旧要求へ期間欄を勝手に補う実装も試す	旧要求は旧経路・旧結果のまま。補完する変異を検出。certifierの差は別扱い
N02	新台帳から validity または必須の時間能力を落とす。unknownに境界を混ぜる	invalid_input。全期間を既定値にしない
N03	空区間・逆転区間・boundedの片端なし・無効な日付・秒未満・UTC以外	invalid_input。丸めたり並べ替えて修復しない
N04	{kind: open_end, start: ...}	unsupported_profile。期間不明や無限の肯定にしない
N05	訂正元[3,7)から対象[1,6)を訂正。別原子/文脈、同時刻/以前の訂正、対象不在、理由なしも別入力で試す	包含・参照・順序・理由に反するものは invalid_input。黙って共通部分だけを使わない
N06	unknown/unspecifiedを持つ主張から、またはそれを対象に訂正する	unsupported_profile。初回の区間比較の範囲外。包含失敗と区別
N07	旧方針・未知のprofile/操作・consumerの仕様hash不一致、未知の台帳schema	unsupported_profile。既知の旧handlerへ代用しない
N08	T01〜T20の配列順を変える。IDは同じで全項目を保持	完了した行・根拠・課金量が一致。出力の順序はID順
N09	複数view/queryを同じ要求に置く。unknownの行の次に完了可能な行を置く	未知能力は該当文脈・viewを止める。次のviewが自動的に完成扱いにはならず、残りの共通予算で評価される
N10	新結果を旧supportedに変換する変異。旧台帳を自動取込し、期間やrevisesを推測する変異	型の境界・自動取込なし・主張追加なしの検査で検出

N05では、初回の単一文脈・原子制約違反も検査します。複数の違反が同じ要求にある場合のエラーの優先順位は、nativeの構造検査順として固定し、各拒否例は原則一つの違反だけを含めます。

4. B：資源4条件

ここでも新しい分母を使います。予算不足を期間情報の不足と混ぜません。

ID	入力・予算	手指定の期待
B01	妥当な単一view/query、予算0	resource_limit、steps_used=0、未完了値null、認定なし
B02	T03の単一view/query。主張1・確認1・可視主張1・訂正辺0	仕様式の完了必要量は 6。予算5で完成値なし、6でpositive_only、7以上でも同じ完成値。steps_used=6
B03	T09の単一view/query。主張3・確認3・可視主張3・適格な訂正辺2	完了必要量は 14。13で完成値なし、14でCのみ。除外A/Bと両訂正辺の根拠を揃えて確定
B04	T03を同じview内でIDの異なる2queryとして置く	完了必要量は 9。予算6で先行行だけ完成し、後続は値null。全予算0〜10で上限内、完成済みの意味は不変

構造不正を含むN02〜N07は、予算0と十分な予算の双方で同じ拒否を確認します。B02〜B04は設計式を手計算した境界で、現在のruntimeを測った値ではありません。

5. 次に行う検査と判断の更新

まずこの表を新しい実行用fixtureへ展開し、native仕様と専用handlerを実装します。点を選ぶ実装と、区間を差し引く参照計算を分けて比較します。T09のような鎖に加え、同じ対象を訂正する分岐、同一極性の訂正、複数の人の確認、suspectedに確認が付いた場合、期間不明と未知能力の同居も生成系列に含めます。

各生成系列はT/N/Bの手指定条件と別の分母にし、乱数seed・有限の範囲・件数・不一致を記録します。runtime側を直すために期待を追随させるのでなく、仕様を変える必要がある場合は TE-D1〜6 の判断と反例を更新します。独立確認を現在の進行条件にはしません。

6. この文書を追加した時点の確認

2026-10-20、以下を確認しました。T20/N10/B4のruntime照合ではありません。

• 変更した6文書のローカルリンク、fenceの対応、T/N/BのIDと件数、B02〜B04の課金式の算術を検査しました。既存の資料整合テスト python3 -B -m unittest discover -s tests/p2 -p test_review_materials.py -v も8件通過しました。この8件の対象は旧P2-dの資料で、新しい時間意味の正しさを検査するものではありません。
• T07の不適切な翻訳の反例を旧runtimeで確認しました。既存の訂正例↗ のrequestをメモリ内で複製し、h1をconfirmed・記録/確認2日、h2を記録7日・確認8日、単一viewを8日、文脈の時点を3日にしました。期間を持たない旧経路はh1を除きh2だけを採用して opposed を返しました。元fixtureは変更していません。新方針の positive_only は手指定期待のままです。
• evaluate-p1-d.py の preflight() で、既存の固定対象356ファイルを照合しました。manifest hashは 4470acb4d1187dd34fb64ce18d5727d3d4e58acebde722ba15a13aae9848bf7d、束hashは aa89cf5f7fcf93de0cadf58308f59cc18685a7716ab58ea6010d8239371e2a1f のままです。独立確認・評価凍結のフラグはともにfalseです。

今回は文書のみの追加・更新なので、全runtime回帰やPython二版での新機能評価は実施していません。実装後に§5と設計の受入条件に沿って行います。