Responsibility Pathway Engineering（RPE）のM1では、AIエージェントが提案した行為を allow / hold / human_gate / deny へ振り分ける共通カーネルを作りました。

ここでいう M1 / M2 は製品Versionではなく、RPE開発上の実装マイルストーン名です。

M1：Action RequestをRequirement Packへ照合し、applicability、requirement evaluation、decision、reason code、Human Returnまでを共通評価カーネルとしてまとめた段階
M2：その評価の前後に、Governance / Contract Compatibility / Pack binding / bounded loader / responsibility handoffを接続し、strict governed integrationとして敵対的検証まで行った段階

M2 = RPE 2.0 や完成版という意味ではありません。

責任経路全体の発想史や、RPE / RPR / RPOSがどこで分かれているのかから読みたい場合は、先にこちらをどうぞ。

責任経路とは何か――AIは責任を扱えない？から始まった設計の話

M2では、その評価ロジックの前後を実行経路としてつなぎました。

このrequest / pack / governanceを評価してよいか確認する
  ↓
requirementを評価する
  ↓
評価結果を実行Authorityと混同せずdownstreamへ渡す

GitHub:

M2 closure PR:

この記事では、2026-09-02時点のM2で追加したstrict governed pathと、最後に何を壊してclosureを確認したかをコード寄りに追います。

まず最小で動かすなら、repositoryのvalue demoを使えます。

git clone https://github.com/YutoriKomeiji/responsibility-pathway-engineering.git
cd responsibility-pathway-engineering
python scripts/value_demo.py

このdemoは実在の外部actionを実行しません。同じsynthetic proposalに対して、naiveな継続とRPEのstrict governed pathでobservable behaviorがどう変わるかを見るためのbounded exampleです。

1. M1の `evaluate_action()` は残した

既存の入口はこれです。

from rpe_kernel import evaluate_action

result = evaluate_action(request, packs)

M2ではこれを置き換えず、別にstrict entryを追加しました。

from rpe_kernel import evaluate_governed_action

result = evaluate_governed_action(envelope)

legacy / M1-compatible path
!= strict governed path

既存integrationを全部強制移行させるのではなく、GovernanceやContract Compatibilityを実行時に強制したい経路だけがstrict pathを選べます。

2. governed envelopeでPackとGovernanceを束ねる

M2の入力は概念的に次の形です。

{
  "contract_version": "1.0.0",
  "request": {
    "contract_version": "1.1.0",
    "request_id": "example",
    "action": "external_send"
  },
  "governed_packs": [
    {
      "contract_version": "1.0.0",
      "binding_id": "demo-pack@1.0.0",
      "pack": { "...": "..." },
      "governance": { "...": "..." }
    }
  ]
}

これは構造を説明するための簡略例です。必須fieldや正確な型・制約を含むcanonical contractは、repositoryのschemaを参照してください。

Requirement PackとGovernance recordを別々に渡して「同じIDっぽいから対応している」と扱わないのがポイントです。

3. PackとGovernanceのmisbindingを止める

strict pathでは、PackとGovernanceについて次を照合します。

pack id
pack version
source authority
source version
jurisdiction

たとえばGovernance側のpack versionを壊します。

wrong = copy.deepcopy(base)
wrong["governed_packs"][0]["governance"]["pack_version"] = "9.9.9"

result = evaluate_governed_action(wrong, today=today)

この場合、requirement evaluationまで進まず、admission stageで止まります。

decision = human_gate
stage    = admission
reason   = RPE-GOVERNED-BINDING-PACK-VERSION-MISMATCH

source authority、source version、jurisdictionの不一致もclosure matrixで別々に壊して確認しました。

4. Governance eligibilityをruntime gateにした

M1ではRequirement Pack Governanceのschemaやcheckerがあっても、strict runtime pathの必須gateではありませんでした。

M2ではここを接続しました。

lifecycle_state != active
review期限切れ
future effective date
future review date
unresolved ambiguity
maintenance owner不在

などはrequirement evaluationより前に human_gate へ戻します。

たとえばeffective dateを未来にします。

future = copy.deepcopy(base)
future["governed_packs"][0]["governance"]["effective_date"] = "2026-10-01"

result = evaluate_governed_action(future, today=date(2026, 9, 1))

期待するreason codeは、

RPE-PACK-GOV-NOT-YET-EFFECTIVE

です。

RPEが判定しているのは「法的に正しいか」ではありません。人間が管理するGovernance recordが、RPE側で定めた利用条件を満たしているかです。

5. Contract version driftを評価前に止める

M2ではrequest / pack / governance / governed envelopeのcontract versionをruntime compatibilityへ接続しました。

未対応versionを入れると、evaluationへ進みません。

さらにCIでは、

schemas/external-kernel/contract-versions.json

とpackage/runtimeが読み込むcontract snapshotの一致も確認しています。

OpenAPIも、

repository spec
== packaged spec
== runtime exposure

をcheckerで比較します。

6. Loaderはlocalまで。remote trustは増やさない

M2ではJSON contentとlocal fileを読めるbounded loaderを追加しました。

from rpe_kernel import (
    load_governed_envelope_content,
    load_governed_envelope_file,
)

一方でURLを渡すと拒否します。

RPE-LOADER-REMOTE-SOURCE-UNSUPPORTED

つまり、

local loader追加
!= network trust追加

です。

loaderが保持するprovenanceも、観測したbytesに限定しています。

{
  "source_kind": "local_file",
  "content_sha256": "...",
  "byte_length": 1234,
  "observation_scope": "transport_bytes_only"
}

local path自体はresultへ流しません。callerがJSON fieldとして transport_provenance を自己申告しても受理しません。

7. `allow` を実行tokenにしない

M2後半で追加したのがresponsibility handoffです。

strict resultでは次を固定しています。

{
  "authority_effect": "none",
  "decision_scope": "evaluation_only"
}

さらにdownstream obligationとして、

dispatch_authority_required = true
effect_verification_required_for_effect_claim = true
receipt_sufficient_for_effect_claim = false
reauthorization_required_for = [retry, repair, resume]

を返します。

RPE allow
!= dispatch authority
!= effect verified
!= retry allowed
!= repair authority
!= resume authority

RPEは評価層であり、外部実行や復旧Authorityまで暗黙に持たせません。

CapabilityとAuthorityをなぜ分離するのか、EvidenceやResumeまで含めた設計の背景はこちらでコード寄りに整理しています。

AIエージェントに「責任経路」を実装する――Capability・Authority・Evidence・Resumeを分離する設計

また、retry / resume / reauthorizationを同じ「再実行」にしない理由は、停止後の回復側の記事につながります。

AIエージェントの再試行を全部同じにしない――責任経路OSで再試行・再開・再承認を分ける

8. REST / MCP / OpenAPIでもstrict pathを同じ意味で出す

Pythonだけstrictでも、adapterが別解釈をすると意味がありません。

M2ではRESTを、

POST /v1/evaluate
POST /v1/evaluate/governed

に分けました。

MCPもlegacy toolとgoverned toolを別に公開しています。

CIでは両方を同じrepository headで実行し、governed resultの authority_effect = none と decision_scope = evaluation_only まで確認します。

9. closure前にadversarial matrixを追加した

M2最後のR5では、正常系を増やすより「抜け道がないか」を優先しました。

新しいclosure checker:

ここでは、既存checkerに薄かったケースを追加しています。

source-authority mismatch
source-version mismatch
jurisdiction mismatch
inactive / suspended governance
superseded governance without replacement
unknown applicability
no applicable governed pack
runtime result vs governed-result JSON Schema

さらに各stageで、responsibility handoffのno-authority invariantも再確認します。

10. 既存checkerも同じexact headでまとめて再実行した

closure用workflowでは、新しいcheckerだけを通して終わりにはしませんでした。

同一PR headで次をまとめて走らせます。

Contract manifest/runtime snapshot
Governed JSON schemas
Legacy optional M2 path
Strict governed admission
Bounded loader/provenance
Responsibility handoff
REST parity
MCP parity
OpenAPI repo/package/runtime parity
Value demo
Cross-cutting adversarial matrix

validated PR head:

ae2581ef3c68643687775e111fa8561b974fb2b8

全step PASS後にmergeしました。

merge/main anchor:

6edf1a0b501b7b25663ddc7fb942aa087c0db0f2

merged mainでも同じintegrated closure suiteを再実行し、repository security hygieneもPASSを確認しました。

closure evidence:

11. test failureを即product defectにしない

closure中、GitHub上でDraft PRをReadyへ変更する操作だけが失敗しました。

原因はconnectorが使ったGraphQL fieldのschema mismatchでした。RPE test failureではありません。

failure observed
  ↓
RPE code ?
checker ?
CI environment ?
connector/tool ?

と切り分け、同じexact headからnon-draft PRを作り直してclosure suiteを再実行しました。

この「観測した失敗をすぐproduct defectへ昇格させない」というやり方は、RPRのPublic AlphaをWindows実機で検証したときにも使いました。

WindowsでAIエージェント用CLIを試したらUTF-8 BOMで壊れた――RPR 0.1.0a5で直すまで

小さなBOM不具合の記事ですが、観測 → 原因切り分け → regression → 元環境readback → release というEvidenceの閉じ方は今回のM2 closureと同じです。

12. M2 closureで言えること / 言わないこと

今回閉じたのは、bounded repository-level governed integrationです。

言えることは、

strict governed evaluation pathに、admission、compatibility、Pack/Governance binding、Governance eligibility、applicability、requirement evaluation、responsibility handoff、bounded loader、Python/REST/MCP/OpenAPI reference surfaceが接続され、選択したfailure/drift classにdeterministic negative checkがある。

までです。

一方、次はM2 closureからは言いません。

production ready
法令適合
certified
safe deployment proven
external effect prevented
exactly-once guaranteed
retry/repair/resume owned by RPE
adaptive routing solved
Python implementation全体 formally verified

まとめ

M1では、AIの行為を止める評価ロジックを共通カーネルへ集めました。

M2では、その前後をつなぎました。

explicit governed envelope
  ↓
admission
  ↓
compatibility
  ↓
Pack ↔ Governance binding
  ↓
Governance eligibility
  ↓
applicability
  ↓
requirement evaluation
  ↓
responsibility handoff
  ↓
separate downstream authority

最後は正常系ではなく、misbinding、drift、invalid governance、unknown applicabilityを意図的に入れて閉じました。

Responsible AIの要求を「書く」だけでなく、どの条件でその要求を実行経路へ入れてよいのかまで扱う。

RPE M2は、そこまでの実装とEvidenceを一度区切った段階です。

次に読むなら

この記事から責任経路の別レイヤーへ進むなら、目的別には次の順が分かりやすいです。

まず全体像を知る
責任経路とは何か――AIは責任を扱えない？から始まった設計の話
Capability / Authority / Evidenceの分離をコードで見る
AIエージェントに「責任経路」を実装する――Capability・Authority・Evidence・Resumeを分離する設計
停止後のretry / resume / reauthorizationを見る
AIエージェントの再試行を全部同じにしない――責任経路OSで再試行・再開・再承認を分ける
公開OSSをどう検証して修正まで閉じたかを見る
WindowsでAIエージェント用CLIを試したらUTF-8 BOMで壊れた――RPR 0.1.0a5で直すまで