VCDesign の芯
芯の6つ
Value Continuity を判断と責任の面から実装するために、VCDesign が定めるのは Δ・責任・境界・判断・宣言・指標の6つです。
規範：core.yaml、policies.yaml、metrics.yaml、axioms.yaml。読解補助：implementation.md、glossary.md。
1. 芯の6つ
| 芯 | VCDesign が定めること |
|---|---|
| Δ | 宣言した期待（前提と価値）との差。向きを持つ。Negative Δ は伝播させず、Positive Δ は伝播可能にする |
| 責任 | owner、人間の最終判断者、担当交代をまたぐ継続保有（点の責任は開始、線の責任が維持） |
| 境界 | 損失は止め（containment）、根拠は通し（basis_flow）、結論は確かめ直す（revalidation） |
| 判断 | 6語（Proceed / Expand / Limit / Reframe / Defer / Retire）だけを使い、判断ゲート1つで閉じる |
| 宣言 | 案件ごとに、残すもの（保有者付き）、広がりの兆候、最大損失、可逆性、依存先 |
| 指標 | 5原則（残す・見つける・閉じる・試す・伝える）の順に並ぶ芯の17件 |
2. 基本の流れ（PDΔD）
VCDesign では、価値を続けるための責任の置き場所を章（chapter）と呼び、章の中で扱う一件一件を案件（case）と呼びます。案件は次の順に進みます（core.yaml flow）。
3. Δ
Δ は、正本の一般的な意味（期待との差）を受けたうえで、VCDesign が基準線・向き・扱いを定めた実装概念です。期待は、前提（precondition：章の成立条件と責任配置を含む）と価値（value_intent）として宣言し、両方の向きを同じ基準線で観測します。
Δ として扱う条件
- 観測は
observation→candidate→confirmedの3段階で進む - 一時的なノイズは Δ ではない。持続する逸脱であること
- 責任への影響があること（Negative Δ ではどの責任配置が崩れるか、Positive Δ では誰が保有するか）
向き（polarity）
| Negative Δ | Positive Δ | |
|---|---|---|
| 伝播 | 伝播させない | 伝播可能にする。広げるのは Expand 判断（自動では広げない） |
| 扱い | 局所化する・緩和する・必要なら閉じる | 観測する・意味づける・再利用可能にする |
| 経路 | 境界の guard（unknown は止めて上げる）→ containment → 判断 | 観測 → value_intent に照らした意味づけ → 保有者付きで記録。広げるときは Expand |
| 止めるか | 止める対象になる | 観測と保有は止めない。Expand の前提が欠けていれば、止めるのは Expand の方 |
- 上下が混ざった観測は、Positive Δ と Negative Δ に分けて記録する
- 向きが記録されていない Δ は Negative Δ として扱う
確定した Δ は、判断で閉じるまで責任の下にある
確定した Δ を、責任者のいない状態や未解決のまま放置しません。確定から判断までの間も保有は途切れません。設計時の未定義（定義の空白）も Δ として扱い、実装を始める前に判断で閉じます（core.yaml closure_loop）。
4. 責任
章と案件には、必ず owner（いま保有している主体）と final_decider（判断を閉じる人間）がいます。final_decider は必ず人間です。supervisor は責任の最終収束点で、責任が消えるのを防ぎます。
点の責任と線の責任
| 点の責任（Gate） | 線の責任（Tenure） | |
|---|---|---|
| 問い | 今これは正しいか | 誰がこれを持ち続けるか |
| 場所 | 承認の一点 | 承認の後の毎日。担当交代、無人の自律運用、時間経過 |
| 役割 | 責任の開始 | 責任の維持 |
線の責任は次の4つで記録します。
custody_chain— 担当交代の追記記録。後任が判断を再導出できると確認したかを含むre_derivation_basis— 後任が判断を再導出できる根拠review_triggers— 何が変われば見直すか（カレンダーではなく事象で書く）last_reaffirmed— 今も有効だと、名前のある人間が確認した記録
自律化が進むほど人はループの外に出るので、継続保有の必要は減らずに増えます。また、責任を保有する力には限りがあります。一人に持たせすぎると、その人が持つすべての判断が劣化します（公理 A5）。
5. 境界
境界は、越境を検査し、損失を止め、根拠を通し、上流の結論を確かめ直す点です（boundary-pattern.yaml）。
| 働き | 対象 | 既定 |
|---|---|---|
| guard | 越境そのもの | pass / deny / unknown で判定。unknown は止めて上げ、pass として扱わない |
| containment | 失敗・指令 | 通さない（deny） |
| basis_flow | 根拠・残るもの | 通す（allow） |
| revalidation | 上流の結論 | 引き継がず、確かめ直す |
このほか、境界の定義そのものを誰が持ち続けるか（tenure）と、別の組織やエージェントをまたぐときに識別・境界・権限を先に宣言すること（external_crossing、Continuity Claim Protocol）も境界パターンに含まれます。
境界での判定（pass / deny / unknown）は、一回ごとの越境に対する検査で、案件の Δ を閉じる判断とは別のものです。deny や unknown が繰り返される場合や、責任に影響する場合は、Δ として観測し、判断の6語で閉じます。
「境界」という語の使い分け
- 責任境界（B1〜B17） — 責任を明示しなければならない点の型（taxonomy.md）
- 境界の構造 — 責任境界を実装する形。上の guard、tenure、containment、basis_flow、revalidation
- 障害区画（failure domain） — 失敗を外へ伝播させない区画。責任境界と一致するとは限らない
- 連続と離散の境界 — AI の推論が現実の実行と出会う点（AI 拡張）
6. 判断
Δ を受けて、人間が Proceed / Expand / Limit / Reframe / Defer / Retire の6語のいずれかで閉じます。ほかの語彙は使いません。すべての判断は一つの判断ゲートを通ります。Expand と Limit は宣言の更新として記録します。詳しくは判断のページへ。
7. 宣言
案件ごとに、開始時に次を宣言します（フィールドの定義は schema_case.yaml）。
| 面 | 宣言 | 意味 |
|---|---|---|
| Upside （残す・見つける） | value_intent | 生み出そうとしている価値 |
residual_assets | 業務・担当・技術が変わっても残るもの（記録、標準、根拠、接続、技能）。保有者（holder）が必須。保有者がいなければ残らない。空の案件は点の改善として扱う | |
spread_signals | 広がりの兆候（二回目が安くなる、頼んでいない所から引き合いが来る、別の判断の材料になる、接続するほど一件あたりの価値が上がる）。expected として先に宣言し、observed と unexpected で記録する。平均的な効果（average_outcome）とは別に評価する | |
| Downside （閉じる・試す） | blast_radius | 失敗の上限を先に宣言する。範囲（scope）と大きさ（max_loss）。未宣言なら影響が大きいものとして扱う |
reversibility | 撤回・縮小・修正できるか。不可逆な案件では max_loss の宣言が必須 | |
failure_domain | 失敗を外へ伝播させない区画 | |
depends_on | 依存先。同じ依存先への集中を見るために使う | |
| Continuity （残す・伝える） | owner | いまの保有者 |
custody_chain | 担当交代の追記記録 | |
re_derivation_basis | 後任が判断を再導出できる根拠 | |
review_triggers | 何が変われば見直すか |
8. 指標
指標は Δ の観測装置であり、判断の入力です。判断を置き換えません。芯の指標は5原則の順に並びます（metrics.yaml）。
| 原則 | 指標 | 捉えるもの |
|---|---|---|
| 残す | owner_missing | 章の owner が不在、未割当、または事実上機能していない |
custody_gap | 担当が交代したのに引き渡しの記録がない。または再導出の確認なしに保有が始まった | |
one_shot_improvement | 業務・担当・技術の変化で改善が無効になり、何も残らなかった | |
positive_delta_without_holder | Positive Δ を観測したが、保有者が決まっていない | |
| 見つける | spread_signal_observed | 宣言した兆候、または宣言していなかった兆候を観測した（Positive Δ の検知） |
success_without_spread_signal | 平均的な効果は出たが、宣言した兆候が一つも観測されない | |
reuse_cost_trend | 残したものを別の場所に適用するコストの推移 | |
| 閉じる | precondition_broken | 宣言した成立条件・禁止条件・引き受け条件が破られた |
blast_radius_undeclared | 不可逆または高コストの判断が、最大損失の宣言なしに実行・承認された | |
blast_radius_exceeded | 実際の損失や影響範囲が、宣言した上限を超えた | |
transitive_trust | 上流の結論が、境界で確かめ直されないまま下流の前提になっている | |
concentration | 多くの案件・境界が、同じ依存先や同じ判断経路を共有している | |
| 試す | expand_beyond_recovery | 適用範囲の拡大に、復旧・撤回の能力が追いついていない |
halt_readiness | 停止命令、人間の介入、安全退避が実際に発動できる状態にあるか | |
| 伝える | decision_without_basis | 判断の根拠が記録されていない。または結論だけが渡されている |
review_trigger_missing | 長く続く案件が、事象による見直し条件を持っていない | |
| 運用 | stagnation | 閉じられるべき案件が止まっている（未解決の Δ、期限を過ぎた Defer、終わらない Retire） |
Positive Δ を捉える指標は、停止や blocking を引き起こしません。最大でも warning です。
9. 5原則ごとの実装
正本の5原則を、VCDesign がどの仕組みで実装しているかの対応です（implementation.md §2 より）。
| 原則 | VCDesign の仕組み | 指標 |
|---|---|---|
| 残す | residual_assets（保有者付き）。点の責任と線の責任：custody_chain、re_derivation_basis、review_triggers、last_reaffirmed | owner_missing、custody_gap、one_shot_improvement、positive_delta_without_holder |
| 見つける | Positive Δ を異常として扱わず、観測 → 意味づけ → 保有者付きで再利用可能にする。spread_signals を開始時に宣言し、平均的な効果と分けて評価する。原因が特定できない上振れは guard で unknown とし、拡大の根拠にしない | spread_signal_observed、success_without_spread_signal、reuse_cost_trend |
| 閉じる | 分布を予測せず、増幅を下の4つで切る。致命的な下振れは、責任者の有無によらず停止する（judgment_gate.hard_stops） | precondition_broken、blast_radius_undeclared、blast_radius_exceeded、transitive_trust、concentration |
| 試す | reversibility を宣言する。状態は戻せるが、責任記録は追記のみ。Expand は拡大後の範囲でも復旧できることが条件。すべての運用経路に停止責任者を置く（haltability） | expand_beyond_recovery、halt_readiness |
| 伝える | 境界は損失を止め、根拠は通す（basis_flow）。結論は受け手の境界で確かめ直す（revalidation）。判断ごとに Upside / Downside / Continuity / Asymmetry の観点で根拠を残す（decision.basis） | decision_without_basis、review_trigger_missing |
閉じる：増幅を切る4つの機構
極端な下振れは、連鎖・再利用・集中・フィードバックによって、一つの失敗が次の失敗を生むことで起きます。VCDesign はその増幅を次の4つで切ります。
| 機構 | 何を切るか | 宣言・仕組み |
|---|---|---|
| 区画を分ける | 区画をまたぐ伝播 | failure_domain、境界の containment |
| 上限を宣言する | 損失の大きさ | blast_radius（scope と max_loss） |
| 境界で確かめ直す | 上流の誤りの増幅 | 境界の revalidation、upstream_basis_refs |
| 集中を避ける | 共通原因による同時故障 | depends_on、指標 concentration |
外から来る極端な事象は消せません。扱うのは、それが内部でどこまで広がるかです。
10. 公理 A1〜A5
公理は適合判定の起点です。いずれかに反する実装は、ほかの仕様を満たしていても適合しません（axioms.yaml）。
| 公理 | 内容 |
|---|---|
| A1 責任を消さない | すべての Δ（負・正とも）に名前のある owner を付ける。Negative Δ は owner が閉じ、Positive Δ は owner が生まれたものを保有する。責任は移したり解放したりできるが、黙って無所有にはならない |
| A2 実行は人間の判断が許可した範囲の中 | 人間が閉じた判断で許可された範囲を越える実行は行わない。範囲の内側では、ループは必要なだけ自律的に動いてよい。範囲を越える変化は Δ として観測し、判断し直す。越えた境界ごとに guard の判定があり、unknown は止めて上げる |
| A3 AI は最終責任を持たない | AI は提案・分析・検知をしてよいが、最終責任を持ったり割り当てたりしない。すべての判断の final_decider は人間 |
| A4 時間の分離 | 速いループ（物理・意味）は、遅いループ（価値・責任）が定めた制約を、しかるべき層での明示的な再判断なしに書き換えない |
| A5 責任は希少な資源 | 責任を保有し果たす力には限りがある。過負荷は、その人が持つすべての判断を劣化させる |
公理が衝突して見えるときの優先順位は A2 > A3 > A1 > A4 > A5 です。衝突は supervisor か final_decider が解き、どちらかを黙って上書きしません。
公理の原文は英語です。上の表は要約で、判定には原文を使います。適合チェックの一覧は conformance.md にあります。