P2-t：Provenance の activity の符号と revision の entity の実装と内部評価

作成日：2026-10-21。状態：P2-q の上に、宣言した活動の符号と、訂正の関係（revision の entity）を足す合成の専用 R5 を実装し、両 Python 版の全体回帰を通過。設計79・手指定期待80 に従いました（利用者の指示：2026-10-21「revision の entity と activity の符号着手して」。設計の確認事項 U1〜U3 は推奨どおり）。79・80 の「未実装」という記載は設計時点の記録として保持します。独立確認・評価用正解の凍結は未実施で、independent_review / evaluation_frozen は false のままです。数値・識別子はすべて架空です。外部資料は、HL7 FHIR R5 v5.0.0 の provenance-entity-role の符号系ページを1つ追加で取得しました（Git 管理外、台帳に記録、符号の名前と定義の読み取りに限る）。

1. 行ったこと

項目	内容
新しい拡張	provenance_coding.py↗ と 仕様↗（p2-provenance-coding、draft-1）。P2-q を固定版で一度だけ実行し、出せた行（observation.state＝projected）の Provenance の項目に、宣言した活動の符号と、訂正の関係の entity を足す。行に coding＝{state, entries, revision} を足し、P2-q の行の欄は一つも書き換えない
活動の符号	宣言 coding[].activities（creation・correction・confirmation）の {system, code} を、項目の種類ごとに使う。内容は検査しない（束縛は Example）。宣言のない種類は null のままで、別の種類の符号で代用せず、失うものに activity:<種類> を残す
revision の entity	宣言 revision＝真のとき、選ばれた記録が訂正で、生成側の項目がある（agent が分かる）ときだけ、その項目に {role: revision, what: {type: Observation, record_ref, record_sha256}} を訂正された記録ごとに昇順で付ける。向きは、target＝新しい版、entity＝古い版。ハッシュは P2-i の記録のハッシュ関数で計算し、選ばれた記録のハッシュを同じ関数で再計算して P2-q の値と照合する
運べない理由	revision.state：not_applicable／not_requested／no_provenance／no_agent／carried
実行例	73 JSON・1,533必須パス（V 系列20条件、N 系列15条件、B 系列3条件）
宣言	義務17（共通4＋R5の3＋PT-1〜10）。宣言の数は24になった
検査	test_provenance.py↗ 15テスト、独立な別計算 provenance_oracle.py↗（ハッシュは JSON を正規化して独立に計算）、変異24件、検査器の変異 B21 を追加（B17〜B20 の目印を更新）
取得	provenance-entity-role の符号系ページ（21,969バイト、SHA-256 1c038151…）。台帳と検証器の資源表に各1項目を足した

P2-q 以下の実装・仕様・宣言・旧実行例は一つも変えていません。実装の変更は host.py の import と登録の各1行だけです。

2. 予測の結果（設計79の T1〜T10）

ID	予測	結果
T1	P2-q 以下を変えずに実装できる。変更は host.py の2行、手で持つ一覧（P2-q と同じ11か所）、台帳と検証器の1行だけ	成立。既存の仕様・宣言・旧実行例・旧モジュールに差分なし。手で持つ一覧は11ファイル（support.py、p2_checks.py、evaluate-p1-d.py、evaluate-p2.py、repin_specs.py、mutrun_checkers.py、gen_extension_manifests.py、test_extension_contract.py、test_inheritance.py、test_p2_tools.py、host.py）で、P2-q と同じ。台帳（1項目）と検証器（資源表に1行）を足した
T2	P2-t の各行から coding を除くと P2-q 単独の行と一致する	成立。全 fixture と乱数250要求で、P2-q が報告したこと（保持・失う・足す）を取り除いた行もなく、出せた行の流れだけが宣言した差で増えた
T3	符号は宣言した種類のものだけ。代用なし。使われなかった宣言は痕跡を残さない	成立。部分集合8×場合の全数で、符号は種類ごとの宣言と一致し、activity:<種類> は付けられなかった種類と一致した。使われない宣言（生成の符号だけの宣言など）は流れを変えない（V02・V17）
T4	entity は carried の行だけ。記録ごとに一つ、昇順。ハッシュは独立に計算した値と一致。連鎖では直接の前の版だけ	成立。V04・V08・V09・V10・V20 で、結果の台帳の記録を正規化して独立に計算したハッシュと一致し、選ばれた記録のハッシュとは異なる。連鎖（V10）では B だけで A は現れない。訂正された記録の内容を変えるとハッシュが変わる
T5	確認済みの訂正でも、観察者が不明で出自が AI でないなら no_agent。観察者を足すと運べる	成立。V06 と全数（576要求のうち16）。確認の項目に entity を付けて埋め合わせることはない
T6	出自が AI の訂正は観察者が不明でも carried。人の観察者で型の宣言がなければ P2-q の依頼で止まる	成立。V08、観察者×出自の6通り（carried はそのうち5通り）。型の宣言がない場合は P2-q の行が needs_information で coding は not_evaluated
T7	料金 M＝2＋M_q＋2N。標準 M＝46（M_q＝42）、二問い合わせ79（73）	成立。46・51・56・49・79 のすべてが、P2-i の計画の料金の式から手で導いた値と一致した。子の予約は M_q を使い切る
T8	許容外の宣言は静的に拒否される	成立。種類 revision・derivation・removal・amend、revision が文字列・整数・null、role の宣言、符号の形の誤りが、すべて予算に依らず同じ理由で拒否される
T9	義務は R5 と必須欄で足りる。PT-10 は既存の主題に収まらない。24宣言・335義務・517防護例、独立な組 209／253	成立。24宣言・335義務・517防護例、独立な組 209／253、証拠は checked_native_template 210・finite_check 117・hand_derivation 8。主題の外の義務は5つ目（P2-m の LC-12、P2-o の CL-9、P2-p の GR-9、P2-q の QR-11 に続く PT-10）
T10	affected()：P2-q の仕様の変更は P2-q と P2-t を列挙し、他の列挙は P2-t を1つ加える	成立。測定・時間・表示・期間つき数量・数量・予測・縦断・ライブラリ・写像の可否・P2-q の各変更が、それぞれ P2-t を加えた集合を列挙する（measurement.py の変更は8→9件）。P2-t の変更は自分だけ

設計79の10件の予測は、すべて成立しました（初回の実行で外れた予測はありません）。期待の食い違いはなく、実装の誤りもありません。これは、設計・手指定の期待・実装・検査を同じ作成者が書いたことの限界を含みます（§7）。

3. 反例の結果（設計79の Z1〜Z12）

ID	内容	結果
Z1	観察者が人の訂正、revision 真	V04：生成側の項目に revision の entity が1つ（what＝A）。活動の符号 correction
Z2	訂正が二つの記録を訂正する	V09：entity が2つ、record_ref の昇順（A、A2）
Z3	連鎖 A→B→C、C が選ばれる	V10：entity は B だけ。revision_history は失うものに残る
Z4	観察者が不明の訂正	V06：no_agent。確認の項目に entity を付けない。predecessors＝[A] は台帳の事実として出る
Z5	出自が AI の訂正	V08：carried。生成側の項目の agent は Device
Z6	revision が偽	V05：not_requested。失うものに revision:predecessor_identity
Z7	確認者の型の宣言がない	V07：Provenance が出ないので no_provenance
Z8	訂正の符号だけ宣言がない	V12：訂正の項目の符号は null（生成の符号で代用しない）、entity は付く、失うものに activity:correction
Z9	過去の時点で訂正より前の記録が選ばれる	V11：not_applicable
Z10	宣言のない出力先／P2-q の行が出せない	V13・V14〜V16：not_declared／not_evaluated
Z11	使われない種類の符号だけを宣言	V02・V17：仮定は足されず、付かなかった種類は失うものに残る
Z12	許容外の宣言	N08・N10・N14：静的に拒否

4. 分かったこと

1. 訂正の関係は、下位を変えずに運べた。 P2-q の行を書き換えず、coding を足すだけで、向き（target＝新しい版、entity＝古い版）・同一性（記録の参照と独立に計算したハッシュ）・多重度（記録ごとに一つ）を保てた。連鎖は直接の前の版だけを運び、全体と訂正の理由は運ばない。
2. 訂正の関係を運べるかは、訂正者が分かるかに依る。 Provenance は agent が必須（1..*）なので、観察者を不明と明示した（P2-s）訂正は、人が確認していても関係を運べない。これを黙って落とさず no_agent と区別し、確認の項目に付けて埋め合わせもしなかった。576要求の全数では、訂正を含む384要求のうち、revision を求めて確認者の型を宣言した96要求で、運べたのが80、運べなかったのが16（観察者が不明で出自が AI でない場合）だった。
3. 活動の符号は、構造の検査の外にある。 束縛が Example なので、符号の集合は限られず、内容を検査できない。検査できるのは、種類ごとに宣言が使われたか、代用されなかったか、運べなかった種類が報告されたかの規則だけである。一方、entity.role の符号は必須の束縛で、R4→R5 で derivation が消え instantiates が加わった。役割を宣言に預けず、拡張が事実の表（出典のハッシュと目印の語）に結んだ revision に固定したので、R4 の語は静的に拒否される。

新しい発見

ID	発見	根拠	限界
F35	記録の観察者を「不明」と明示できること（P2-s）と、訂正の関係を運べることは両立しない。 agent が必須の Provenance では、訂正者が不明な訂正の関係は、確認済みでも表せない。関係を運ぶには、訂正の操作の入口で訂正者を求める（P2-o の依頼として「誰が訂正したか」を足す）か、不明の訂正は関係を運べないものとして受け入れる必要がある。この拡張は後者を、理由つきで報告した	V06・全数（no_agent 16件）・T5	前者（入口での依頼）は未実施。P2-o の依頼の語彙と宛先が変わる
F36	合成の層が下位の結果に前の版のハッシュがないとき、下位の私有の関数を再利用して自己検証する形になった。 結果の台帳には訂正された記録の内容はあるが、そのハッシュはない。P2-t は P2-i の記録のハッシュ関数を使い（P2-o が確認のために使うのと同じ）、選ばれた記録のハッシュを再計算して P2-q の値と照合する。一致しなければ停止する（注入で検査）	provenance_coding._coded・test_child_failure_and_mismatch_are_atomic_and_refused	下位の私有の関数への依存。代案は下位に前の版のハッシュを出させること（版の更新を伴う）
F37	向きの読みは二つの定義の組み合わせで、一つのページに書かれていない。 target＝「活動が生成・更新した参照」（Provenance のページ）、revision＝「その実体の新しい版を作るために使った実体」（符号系のページ）から、訂正された記録を entity、訂正記録を target と読んだ。別の読み（source など）もあり得る	事実 F-E4・F-E5	設計79の「判断の分かれる点」。role は宣言できない
F38	fixture は、ハッシュを手で書けず、項目の数も確かめられないので、1件の変異（前の版でなく選ばれた記録のハッシュを入れる）は別計算でしか検出できなかった。 24変異のうち、期待の確認で検出したのが22、別計算が1、例外（内部の前提の崩れ）が1	変異の検出経路の記録	F22 と同じ構造。例外による検出は粗い
F39	検査器の「未完了行の値」の欄の一覧が1つ増えるたびに、検査器の変異の表の目印を5行直す必要がある。 合成を足すたびに起きる（P2-q でも起きた）。B17〜B20 の目印を書き換え、B21 を足した	mutrun_checkers.py	一覧を1か所に持つ設計に変えれば減る
F40	共有の語彙を数える探索は、新しい独立な組の多くを疑いに挙げる。 独立な組は 201→218（+17、手で導いた値どおり）、疑いは 147→161（+14）で、新しい17組のうち14組（82%）が疑いに入った。語彙の共有を数えない探索（排他的な共有の語）では、P2-t に疑いは挙がらなかった	test_counting_the_shared_vocabulary_makes_almost_everything_a_suspect	測定値であり、予測ではない

実装の最中に直した誤り

• 実装の誤り：0件。手指定の期待（V 20、N 15、B 3 条件の73ファイル）と手で導いた料金は、すべて初回に満たされた。ただし 79・80 は、実装と同じ作業で書いたので、履歴では実装より前に固定したことを示せない（設計時点の文書のハッシュは作業中に控えた：79 は f0cd2ecd…、80 は 3dccf007…。これは検証できる証拠ではなく、作成者の記録）。
• 検査側の調整：（1）継承の検査の2つの数（measurement.py の変更が列挙する拡張の数、探索の疑いの数）を測定値に更新した。予測できたのは前者の増加（P2-t を1つ加える）と独立な組の増加（17）で、疑いの数 161 は測定である。（2）検査器の変異 B17〜B20 の目印を更新した。（3）fixture の期待を実行結果に合わせて直した箇所はない。

5. 検査の強さ

• 全数：記録の場合（原本／訂正1件／訂正2件）×観察者（不明／人／装置）×出自（観察／AI）×確認者の型の宣言（あり／なし）×活動の宣言の部分集合（8）×revision（真／偽）＝576要求を、別計算と全行で照合した。revision の状態は not_applicable 192・not_requested 192・no_provenance 96・carried 80・no_agent 16。
• 独立な計算：訂正された記録のハッシュは、結果の台帳の記録を JSON で正規化して別に計算し、実装の値と照合した（V04・V08・V09・V10・V20）。
• 差分：P2-q 単独の実行との差分を乱数250要求で確かめた（coding を除くと一致、流れは P2-q が報告したことを取り除かない）。
• 乱数：観察者・出自を乱数で替えた250要求（出力先の宣言の有無、符号の部分集合、revision を含む）を別計算と比べた。
• 変異：24件を検出（期待の確認22、別計算1、例外1）。
• 検査器の変異：B21 を追加し、B17〜B20 の目印を更新した。

6. 検証

Python 3.14.4 と 3.11.17 で、全テスト系列と統合評価を実行しました（実装・検査・文書を加えた作業ツリーで実行。コミット前）。

系列	件数	Python 3.14.4	Python 3.11.17
開発	231	通過	通過
追加レビュー系列	52	通過	通過
保存監査	8	通過	通過
P2	475（P2-s の460に、P2-t の15テストを追加）。スキップなし	通過	通過
統合評価	P1/P0・拡張・全P2・予算・版比較（3記録）	通過	通過
P1-d の CLI 照合・保存監査・登録検査	P1 20条件・80 JSON・417必須パス、別枠 P0 の37 JSON・221必須パス、監査600＋256＋32＋1、登録24／拒否0	通過	通過

統合評価の対象	P2-t 追加後の分母
登録・義務・防護例	24宣言・335義務・517防護例参照（P2-s の23・318・500から、1宣言・17義務・防護例17を追加）。防護例のない義務は3（変更なし）
証拠の強さ	checked_native_template 210、finite_check 117、hand_derivation 8
独立な拡張の組	209／253（P2-s の192／231から、17組が独立に増えた）
実行例の系列	P2-t 73 JSON・1,533必須パス。他は変更なし
予算	1,525要求・掃引33,555回、違反0（P2-s は1,453要求・31,198回）。掃引の回数は実測で、予測ではない。両 Python 版で一致

予測した分母（義務・防護例・独立な組・例と必須パスの数・要求の数・各要求の料金）は、実行の前に手で導いた値が全て一致しました（掃引の回数と、共有の語彙を数える探索の疑いの数161だけは実測）。旧い挙動の digest（22,052件）の回帰と、生成器による全例・宣言のバイト一致の検査は P2 系列に含まれ、通過しました。固定対象に、設計79・期待80・新しい実装・仕様・宣言・検査・道具・実行例を加えました。作成者 snapshot で、independent_review / evaluation_frozen は false です。

• 新 native 仕様 hash（先頭8桁）：P2-t d1eb04ac…。他の仕様は変更なし（P2-q 062efe75…、P2-p 34f88aa6…、P2-o 58abe63f…、P2-i 5de7893a…、数量 f52ea526…）
• 追加前（c229c5c、P2-s の結果の追加後）：1,744ファイル、manifest 0bbefd61…、束 4b4b83d4…
• 追加後（この作業のコミット）：1,827ファイル、manifest 94d5eabe…、束 e2cd5929…（完全な値は examples/p1-evaluation/manifest.json とその hash）。この文書と概要文書の更新で固定対象は変わらない（再スナップしても同じ束）

7. 限界と次

• 活動の符号は不透明です。符号の系の妥当性、符号が示す活動の意味、第三者の符号系の内容は扱いません。
• revision は作成者の読みです（F37）。source など他の役割、entity.agent、訂正の理由（自由文）と連鎖の全体の運搬、署名は扱いません。
• entity の同一性はライブラリの記録の参照とハッシュで、FHIR の資源の id や Reference ではありません。出力先の参照への変換は範囲外です。
• 訂正者が不明な訂正は関係を運べません（F35）。入口で訂正者を求める設計は未実施です。
• 下位の私有の関数（P2-i の記録のハッシュ）に依存します（F36）。
• 期待・別計算・実装・検査を同じ作成者が書き、読みも共有しているため、読み違いは一緒に入っている可能性があります。独立確認はありません。
• 次の候補は、訂正者を訂正の操作の入口で求めること（F35）、CPC の版の監査、複数の出力先への射影の拡張です。着手前に利用者の確認を取ります。独立確認は将来の英語の別リポジトリで行います。