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がどこで分かれているのかから読みたい場合は、先にこちらをどうぞ。
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まで含めた設計の背景はこちらでコード寄りに整理しています。
また、retry / resume / reauthorizationを同じ「再実行」にしない理由は、停止後の回復側の記事につながります。
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実機で検証したときにも使いました。
小さな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で直すまで