DM-20260815-002RI #1 Article Production（記事制作）のFormal Runtime Verification（正式実行検証）では、Contract（契約）、Configuration（構成）、Human Decision（人間判断）、Repository Verification（リポジトリ検証）が存在していても、それだけでは実行時の正しさを保証できない事例が連続して観測された。
今回のEvidence（証拠）では、次の問題が確認された。
War Diaryでは一連の出来事をWD-20260814-001として記録し、Bug Zooでは再発可能な障害パターンをBZ-20260814-020〜023として分離した。
Configuration Management Notesでは、Human Decision Boundary（人間判断境界）とMechanical Continuation（機械的継続）、Dependent Currentization（従属現在化）とBinding Synchronizationを実務ルールとして整理した。
本メモでは、それらをさらに一段上げて、Human-Directed Foundry（人間主導Foundry）のDevelopment Model（開発モデル）として何が成立しつつあるかをWorking Model（作業仮説）として整理する。
ここで扱う名称・構造は採用済みArchitecture（設計）ではない。
Formal Test ID RV-01にはHuman-defined Exact Input（人間定義済み固定入力）が存在していた。
しかし修正前のLauncherでは、Formal Run（正式実行）でgeneric E2E fixture（汎用E2E入力）を選択できた。
Human Decisionそのものは存在したが、
Human Decision
↓
Execution Point
の間にMachine-enforced Binding（機械強制ひも付け）が無かった。
その結果、Humanが一度決めた値をAI / CODEXが再選択できた。
Conclusion Retry（結論再試行）では、Gate（判定ゲート）が初回出力623文字を計測できていた。
有効範囲は240〜420文字であり、最低203文字の削減が必要だった。
しかしRetry Prompt（再試行指示）には、実測623、上限420、必要削減203というDeterministic Fact（決定論的事実）が十分に渡されていなかった。
モデルは前回出力を約370文字と誤認した。
その後、240〜420という範囲自体はreasoning（推論）で導けたにもかかわらず、最終出力は698文字となった。
ここでは、LLMのInstruction Following Failure（指示追従失敗）だけでなく、Machineが知っている事実をSemantic Model（意味生成モデル）へ再推定させたControl Design（制御設計）側の問題も存在した。
Deterministic Retry Correction Payload（決定論的Retry修正Payload）はRepositoryへ実装され、Test（テスト）もPASSした。
しかしDify Draft / Publishedは旧状態のままだった。
Repository上の正しさは、Live State（実環境状態）への反映を意味しない。
Human-approved Live Apply / Publish後、Repository / Draft / PublishedのSemantic Graph（意味構造）は一致した。
それでもCanonical Launcherは旧Published Workflow IDを参照していた。
このため、
Semantic Equivalence
≠
Execution Binding
が実例として確認された。
Live Apply / PublishはHuman Decisionが必要だった。
一方、Humanが承認済みのPublished ResultへLauncherを同期することは、Targetを新しく選ぶ判断ではなかった。
既決定Targetへの一意なBinding SynchronizationまでHumanへ戻すと、HumanはMeaning / Risk / Authority（意味 / リスク / 権限）の判断者ではなく、Workflow Continuation（作業継続）を許可するボタンになる。
HumanまたはCanonical Contract（正式契約）が一意に値を決定した後、その値を下流のAI / CODEX / Agent（エージェント）が再探索・再推論・再選択しない。
Working Name（仮称）：
Fixed Decision Binding
AIは曖昧さを補完する能力を持つ。
これはSemantic Work（意味作業）では強みだが、すでに決定されたID、Target、Test Input、Threshold（閾値）等については誤動作要因になる。
一度決定済みの値に候補探索を残すと、AIが「より自然」「より一般的」「より妥当」に見える別値を選べる。
Decision required
→ Human / Canonical Contract
Decision completed
→ Machine-readable Binding
Execution
→ Bound value only
Mismatch
→ Pre-Execution STOP
Fixed Decision Bindingは、AIに判断させないという意味ではない。
候補生成、分析、Comparison（比較）、Recommendation（推奨）はAIが行える。
HumanまたはContractが値を確定した後のExecution Stage（実行段階）で、同じ判断を再度AIへ委譲しないという境界である。
Contractは正本へ記述された時点では完了していない。
そのContractを参照すべきConsumer（利用側）へ同じ意味が伝播し、Execution Pointで実効値として確認されるまでを一つのControl Concern（制御関心事）として扱う。
Working Name：
Contract Propagation
Contract Definition
↓
Decision Binding
↓
Propagation
↓
Consumer Binding
↓
Execution Point
↓
Runtime Observation
AI Workflowでは、同じContractが複数層へ投影される。
例：
Definition Source（定義元）が正しくても、Consumerの一つが古ければ実際のRuntime Behavior（実行時挙動）は古いContractで動く可能性がある。
Configuration SynchronizationはContract Propagationを実現する手段の一部である。
Contract Propagationはより広く、
HumanまたはCanonical Sourceで成立した意味が、実行地点まで失われず届いているか
というDevelopment Model上のConcernを指す。
Count（計数）、Compare（比較）、Hash（ハッシュ）、Threshold判定、ID Binding、Range Calculation（範囲計算）、Delta Calculation（差分計算）、State Synchronization（状態同期）等、Machineが正確に処理できるControl FactをLLMへ推定させない。
Working Name：
Deterministic Control Boundary
Semantic Plane（意味面）
Human / LLM
- Purpose
- Meaning
- Writing
- Analysis
- Recommendation
- Meaning-preserving Rewrite
Deterministic Control Plane（決定論的制御面）
Code / Machine
- ID
- Hash
- Count
- Threshold
- Range
- Delta
- Binding
- Retry Count
- Authorization State
- Currentization
- Exact Input
Local AI Foundryには既に、
意味は自由。構造は厳格。
という原則がある。
Deterministic Control Boundaryは、この原則をExecution Control（実行制御）へ広げるWorking Hypothesisと見ることができる。
ただし、すべてをCodeへ固定することを意味しない。
意味の質、文章表現、分析、代替案生成等は非決定性を活用する。
構造とControl Factだけを決定論側へ置く。
今回採用したDeterministic Retry Correction Payloadでは、
Count / Compare / Delta / Direction
→ Machine
Meaning-preserving Rewrite / Compression / Expansion
→ LLM
と分離した。
これはDeterministic Control Boundaryの具体例として扱える。
既存DM-20260808-001では、Human Responsibility Boundary（人間責任境界）とRisk-based Authorization（リスク比例承認）がCapability Gap（能力不足）として挙げられていた。
今回のRI #1 Evidenceにより、少なくとも一つの追加観測が得られた。
Human Gateは多いほど安全になるわけではない。
Humanが保持するのはAuthority（権限）であり、すべてのStep（工程）の実行操作ではない。
Candidate Boundary：
Purpose / Meaning / Risk / Adoption / Publish / Runtime Authorization
→ Human Decision Boundary
Approved Scope内の
Explore / Implement / Test / Correct / Verify / Currentize
→ Mechanical Continuation
Human-Directed FoundryはHumanが全操作を打鍵する方式ではない。
Humanが、
を決定し、その範囲内をAIが自律的に完遂できることを目指す。
Humanが毎StepのContinueを押す構造は、Human Responsibility BoundaryではなくHuman Bottleneck（人間ボトルネック）を作る可能性がある。
CM-20260815-002では、Publish等でCurrent Identity（現在識別子）が変わった場合に、Launcher、Current Source、Derived View（派生表示）等のDependent Consumer（従属利用側）をCurrentizeする手順を整理した。
Development Model上では、Dependent Currentizationを独立したPrinciple（原則）というより、Contract PropagationとFixed Decision Bindingを成立させるOperational Mechanism（運用機構）の一つとして扱う方が現時点では自然である。
Human-approved Meaning
↓
New Current Identity
↓
Dependent Currentization
↓
Binding Verification
↓
Execution
この位置付けはWorking Modelであり、将来別Capabilityとして独立する可能性を否定しない。
今回のEvidenceを一つの上位概念で見ると、Contractには「定義する」以外の成立条件が存在する。
Candidateとして次のClosure（収束）を考えられる。
Contract Definition
↓
Decision Binding
↓
Propagation
↓
Execution Binding
↓
Runtime Observation
↓
Evidence Freshness
Working Name：
Contract Closure
意味は、
Contractが書かれているだけでなく、決定値が固定され、必要Consumerへ伝播し、Execution Pointで拘束され、実Runtimeで実効値が観測され、そのEvidenceがCurrent Candidateへ正しくBindingされている状態
である。
今回のRI #1だけでFoundry Coreとして採用するには早い。
RI #2 Documentation Production（文書制作）等、別Reference Implementation（参照実装）でも同種の問題が観測されるか確認する必要がある。
特に、
がRI #2でも同じ形で有効かを見ることで、RI #1固有のRuntime Engineering Pattern（実行工学パターン）なのか、Foundry横断のControl Pattern（制御パターン）なのかを判定できる。
既存DM-20260808-001の4 Layer（層）へ対応させると、今回のWorking ModelはLayer 1〜3を横断する。
今回のEvidenceは、Layer 1〜3が別々の問題ではなく、一つのExecution Chain（実行連鎖）として接続される必要があることを示している。
既存DM-20260808-001では、Local AI FoundryはControl Plane（制御面）が比較的強く、Evaluation（評価）、Observability（可観測性）、Recovery（復旧）等が不足すると整理していた。
今回のEvidenceにより、Control Plane自体にも追加のGapが見えた。
Human DecisionまたはCanonical ContractをExecution Pointへ一意に固定する能力。
Definition SourceからConsumer、Execution Pointまで同一Meaningが届いたことを検証する能力。
Machineが扱うControl Factと、LLMが扱うSemantic Workを分離する能力。
Human Decisionが必要なRisk Boundaryと、AIが自律継続すべきMechanical Workを過不足なく分離する能力。
これらは既存Control Planeの否定ではない。
Control Planeを「正本を管理する」「Gateを置く」段階から、
DecisionからExecutionまで閉じる
段階へ成熟させる追加Capability候補である。
現時点では次を結論として扱わない。
Contract Closureが正式なFoundry Coreである。Fixed Decision Bindingが正式Architecture用語として採用された。特にFresh Formal RV-01は、このメモ作成時点でCurrent Candidate RuntimeがNOT EXECUTEDであり、成功結果を先取りしない。
このWorking ModelをFoundry横断の正式なArchitecture / Development Profile候補へ昇格するには、少なくとも次を確認する。
DM-20260808-001のRisk-based Authorization、Execution Provenance、Runtime Observabilityと矛盾なく統合できる。Season 2では、今回のPatternを抽象論から始めるより、実際に起きたIncident（事象）から説明する方が適している。
候補テーマ：
Season 2では具体的なRI #1 Evidenceを中心に扱い、Foundry全体の理論として断定しない。
Season 3では、RI #1 / RI #2を横断してEvidenceが揃った場合、
をHuman-AI Development Operating Modelとして一般化する候補になる。
Season 2が「何が壊れ、どう運用を直したか」であるなら、Season 3は「HumanとAIの責任をどう設計すると、その運用が成立するか」を扱う。
今回のRI #1 Evidenceから、Local AI FoundryのControl Planeには次の追加課題が見えた。
Contractを定義するだけでは足りない。
Humanが決めた値をExecution Pointへ固定し、必要なConsumerへ伝播し、Machineが扱えるControl FactをLLMへ再委譲せず、Human Decisionが不要な範囲ではAIが自律継続し、実Runtimeで有効値を観測する必要がある。
現時点のWorking Modelを最も短く表すと、次になる。
Human
→ Purpose / Meaning / Risk / Authority
Machine
→ Binding / Count / Compare / Synchronize / Verify
LLM
→ Semantic Generation / Analysis / Rewrite
Runtime Evidence
→ 実際に何が使われ、何が起きたかを証明
これは既存原則、
意味は自由。構造は厳格。
を、Human-Directed FoundryのExecution Model（実行モデル）へ拡張する候補と見ることができる。
ただし、Foundry Coreへの昇格はRI #2を含む横断Evidenceを待つ。