- Status: Hypothesis validated for PoC; implementation not started
- Date: 2026-08-12
- Scope: file-indexed Pi-RLM、runtime action ledger、hard real-workload cases
- Implementation root:
poc/pi-rlm/
「質問を必要factのchecklistへ分解し、全部埋まるまでfinalizeしない」という方向は妥当である。ただし、非empty値だけを確認するchecklistでは不十分である。
次に検証すべき仮説は次のように限定する。
runtimeが質問ごとのrequired factを所有し、各factを
pendingからgroundedへ単調に遷移させる。groundedには値だけでなく、観測済みevidence IDとsource spanまたはquoteを必要とする。すべてのrequired factがgroundedになるまでfinalizationを拒否する。
現在のsystemic root causeは、runtime action ledgerがcorpus I/O履歴を保持しても、質問を構成するfact、その抽出値、根拠source、未解決項目をturn間で保持・強制しないことにある。
仮説の確信度は中から高。次のfocused PoCへ進む根拠はあるが、これだけでhard gateを解決できるとはまだ確定していない。
- current implementation:
poc/pi-rlm/src/ - deterministic tests:
poc/pi-rlm/test/ - latest focused artifacts:
poc/pi-rlm/platform-action-ledger-errors-poc-results.jsonpoc/pi-rlm/platform-action-ledger-errors-poc-runs.jsonlpoc/pi-rlm/platform-action-ledger-errors-poc-harness-source.json
- preceding action-ledger artifacts:
poc/pi-rlm/platform-action-ledger-poc-results.jsonpoc/pi-rlm/platform-action-ledger-getter-poc-results.json
- workload source: Platform commit
47a97fa4a389e68adc48a4bc07403b222cef38ca
latest focused artifactは次へbindされている。
model: openai/gpt-5.6-luna
harness git commit: caf0bffa1acec17c062559433b4cd4ed92eee3d6
harness dirty: true
harness manifest: 975d7a3500e94a09ee99497f5b8c206a7eeb8916ecb227182b95449d0965c723
workload working tree used: false
- benchmark後の
/workspace/platformworking tree - reportだけに転記された数値で、対応artifactへbindできないもの
- synthetic benchmarkだけから推定したreal-workload quality
- validatorが知るexpected answerをplannerへ渡す方式
CorpusHistoryEntryは次を保持する。
- sequence
- operation
- canonical request key
- bounded summary
- evidence IDs
- cache hit count
関連source:
poc/pi-rlm/src/worker-protocol.tsのCorpusHistoryEntrypoc/pi-rlm/src/repl-worker.tsのrequestCachedCorpus()、corpusHistorySnapshot()
これはread-only action ledgerとして正しいが、次は保持しない。
- 質問から導出したrequired facts
- 各factの抽出値
- factとsource evidenceの対応
- 未解決fact
- final answerの構成状態
controller側では各root turnにfresh AgentSessionを作り、過去のtool resultは直近2件だけを次turnへ渡す。
- fresh session作成:
poc/pi-rlm/src/runner.tsのrunNode()controller loop - recent result compaction: 同loopの
controllerResults
REPLのstateは永続するが、Lunaが観測したfactをstateへ保存するruntime invariantはない。このため、古いsource observationがcontroller resultから落ちると、ledgerから「何を読んだか」は分かっても「何を抽出したか」は復元できない。
preceding action-ledger PoCでは、SDK caseが次を順に観測した。
UpdateSupplyChainPolicyPlatformApiUpdateProjectSupplyChainPolicyWithBodyWithResponsePlatformApiUpdateProjectSupplyChainPolicyWithBodyNewPlatformApiUpdateProjectSupplyChainPolicyRequestWithBody
Evidence: poc/pi-rlm/platform-action-ledger-poc-results.json
生成request builderまで到達しているにもかかわらず、提出値は次だった。
project id|PlatformApiUpdateProjectSupplyChainPolicyWithBody|PUT|/projects/{id}/supply-chain-policy|Idempotency-Key
正解との差分:
- raw methodの
WithResponseが欠落 - URL templateの
/api/v1が欠落 %sを{id}へ推測置換
検索primitiveだけの不足では説明できない。source factを観測後すぐsemantic stateへcommitせず、後続turnで再構成したことと整合する。
latest focused artifactの提出値:
project id|UpdateProjectSupplyChainPolicyWithBodyWithResponse|PATCH|/api/v1/projects/{id}/supply-chain-policy|Idempotency-Key
5フィールドすべて非emptyだが、exact matchは2/5だった。
| Fact | Nonempty | Exact |
|---|---|---|
| validation-label | yes | yes |
| raw-method | yes | no |
| HTTP-method | yes | no |
| URL-template | yes | no |
| idempotency-header | yes | yes |
Evidence: poc/pi-rlm/platform-action-ledger-errors-poc-results.json
したがって、value !== ""だけでfilledとするstate machineは反証済みである。
latest API caseは最初のexecutionで次を観測した。
NewRouterWithConfigConfig
以後5 executionsでは新しいcorpus actionがなく、最終的にanswerを提出しなかった。
total tokens: 8,330
final execution開始時remaining tokens: 9,670
model calls: 6
corpus calls: 4
subcalls: 0
Evidence: poc/pi-rlm/platform-action-ledger-errors-poc-results.json
これはtoken不足よりも、「probes」「production SSE mounts」「timed mounts」のどれが未解決で、次に何を読むべきかを表す進行状態がないことと整合する。
以前のsearch_open PoCでは、API caseがNewRouterWithConfigを5回繰り返しreadしていた。latest action-ledger PoCではexact duplicate actionは消えたが、2 casesとも0 correctだった。
action ledgerは重複I/Oを防ぐtrajectory guardとして有効。ただし、task completionを決めるsemantic plannerではない。
| Loop | Problem observed | Why it exists | Evidence | Confidence |
|---|---|---|---|---|
| 1 | evidenceを読んでも正解またはfinal answerへ到達しない | turnが検索、推測、global introspectionへ分岐する | latest action-ledger traces | High |
| 2 | turn間でprogressが単調に増えない | extracted factsを永続化せず、古いobservationがrecent resultから落ちる | runner.ts controller loop、SDK trace |
High |
| 3 | action ledger追加後も再発する | ledgerはI/O historyであり、required fact、claim、completenessを所有しない | CorpusHistoryEntry、0/2 focused result |
High |
| 4 | すべてのoutput fieldが非emptyでも誤答する | factとsource evidenceの対応をruntimeが検証しない | SDK exact 2/5 | High |
- wrong exact-source answer
- answer未提出
- answer contract rejection
- root turn exhaustion
- cross-file trace
- definitionとproduction wiringを横断する質問
- exact source spellingを要求するmulti-field answer
source observationから抽出したfactがpersistent semantic stateへcommitされず、後続turnが不完全なrecent contextまたは推測から回答を再構成する。
- action ledgerがoperation historyだけを持つ
- fact completion contractがない
- finalization gateがanswer readinessとvalidatorだけを見る
- root controller resultは直近2件だけ
- model任せの
state利用に強制力がない
question decomposition、source-grounded claim、progress transition、finalization completenessが一つのruntime-owned contractとして統合されていない。
| 仮説 | 評価 | 根拠 |
|---|---|---|
| token budget不足が主因 | Rejected as primary | latest 2 runsは9K以上のremaining tokensを残した |
| search primitive不足が主因 | Partial | production wiringのtargetingは未解決だが、builderまで読めたSDKでも失敗した |
| answer contractが厳しすぎる | Rejected | validatorは実際のwrong answerを正しく拒否した |
| Lunaの能力不足 | Unproven | harnessがsemantic progressを永続化・強制していないため、model limitと分離できない |
| action ledgerだけで解決する | Rejected | duplicate I/Oは減ったがfocused resultは0/2 |
| evidence-bound fact stateが次blocker | Supported | SDKのfact lossとAPIのprogress停止を同じmechanismで説明する |
type FactStatus = "pending" | "grounded";
interface SourceReference {
evidenceId: string;
path: string;
startLine: number;
endLine: number;
quote: string;
}
interface RequiredFact {
id: string;
requirement: string;
status: FactStatus;
value?: string;
sources: SourceReference[];
}
interface TaskPlan {
revision: string;
facts: RequiredFact[];
}- planは最初のsource acquisition前または同じexecution内で一度だけ初期化する
- fact IDとrequirementはplan確定後に黙って削除しない
groundedにはnonempty valueと1件以上のobserved evidenceを必要とする- source referenceはcurrent corpus revisionへbindする
- exact-source factにはsource quoteまたはspanを必要とする
- runtimeはexpected answerからfact valueを補完しない
- pending factが1件でもあればfinalizationを拒否する
- 各turnで次のpending factを一つ選び、actionまたはexplicit blockerへ遷移する
- action ledgerとfact ledgerは別責務として保持する
- answer validatorは引き続きaccept/rejectだけを行う
SDK:
validation-label
raw-method
HTTP-method
URL-template
idempotency-header
API:
root-probe-paths
production-SSE-mount-expressions
timeout-applied-mount-group
これらはbenchmark oracleから値を渡すのではなく、public questionが要求するoutput fieldsから構成する。
SDK latest candidateはfilled 5/5、grounded correctness 2/5だった。したがってfilled判定だけでは採用しない。
任意のfree-form /rlm questionからruntimeがrequired factsを完全に推論することはできない。model-generated planがfact自体を省略すると、すべての残存factがgroundedでも回答は不完全になりうる。
PoCでは次を分けて測る。
- plan completeness
- fact grounding
- final answer correctness
plan completenessが失敗した場合は、state transitionではなくplanner contractが次blockerである。
latest SDK runは次で失敗している。
read_symbol("ProjectsService.UpdateSupplyChainPolicy")
error: find_symbol name must be one source identifier
これはaction ledgerに正しく記録されたが、planner hypothesisとは別のAPI contract mismatchである。focused PoCではqualified nameをsingle identifierへ分解するか、このfailureを別classとして記録しないと結果が混ざる。
- plan snapshotはread-onlyで取得できる
- observed evidenceなしではfactをgroundedへ遷移できない
- foreignまたはstale evidence IDを拒否する
- pending factがある状態の
answer.ready = trueを拒否する - all grounded後だけexisting answer validatorへ進む
- runtimeがvalueを推測または自動補正しない
- fact stateがturn間で永続する
対象:
sdk-supply-chain-cross-fileapi-timeout-boundary
各1 runで次を観測する。
- initial fact plan
- turnごとのpending/grounded transition
- factごとのevidence IDs
- premature finalization rejection
- final candidate
両方がcorrectにならない場合、full benchmarkへ進まない。
2 cases × 3 repeats = 6 runs。
暫定合格条件:
overall correct: >= 5/6
each case family: >= 2/3
evidence-less grounded facts: 0
premature finalization accepts: 0
answer auto-corrections: 0
post-hoc token violations: 0
通過後に既存hard 3 cases × 5 repeats gateへ戻る。
次のどれかが起きた場合、仮説はそのままでは不十分である。
- SDKの5 factsがすべてgroundedなのにfinal answerが誤る
- claim/source整合validatorまたはtask-specific local extractorが必要
- plannerが
raw-methodまたはproduction SSE mountsをfactから省略する- plan authoring/completeness contractが次blocker
- 必要evidenceを観測済みでもfactがpendingのまま残る
- modelからfact stateへのcommit APIが次blocker
- commentやtype definitionだけでproduction wiring factをgroundedにする
- evidence roleまたはsource-kind constraintが必要
- fact state導入後もturnがglobal introspectionへ流れる
- next-action transitionをruntimeがさらに限定する必要がある
次のPoCは単純なchecklist promptではなく、runtime-ownedなevidence-bound fact state machineとして設計する。
ただし、この段階では汎用MVP採用やfull benchmark再実行を決定しない。deterministic contract testsと2-case mechanism smokeで、fact stateが実際にSDKのfact lossとAPIのprogress停止を解消するかを先に反証する。