インターネットの協調システムにおける最小限の初期仕様、将来の意思決定の局所化、自発的な採用

接合部については合意し、設計の違いには余地を残す。Lu Hengは、共通ルールを相互運用に必要なものに絞り、その後の選択は参加者自身が行うことを提案する。

要旨

本書は、システムを運用する参加者の上に常設の権威を置くことなく、共通の技術的参照点を提供することを目的とした、インターネットの協調システムの設計パターンを述べる。相互に結びついた三つの原則、すなわち「最小限の初期仕様」「将来の意思決定の局所化」「自発的な採用」を定義する。

このモデルでは、初期仕様が定めるのは、一意性、相互運用性、共有される安全性、セキュリティに必要な、決定論的で各参加者が自らの環境で検証できるルールだけである。初期仕様を定めた後の変更を、中央の機関が承認することはない。コードを実行する参加者が、その変更を採用するか、無視するか、フォークするか、放棄するかを決める。

採用しないことは違反ではない。後の変更を採用しない参加者は、既存の互換集合にとどまる。ある参加者が、別の参加者の受け入れている決定論的ルールの下では有効でない状態を送出した場合、受信側の参加者は、自らの環境で、その状態を送出した参加者を無視できる。その結果として生じるのは、互換性に基づく選択、フォーク、隔離、あるいは選択的な相互運用であって、組織による処罰ではない。

本書はワイヤプロトコルを定義しない。恒久的な統治組織になってはならないプロトコル、レジストリ、識別子システム、協調の仕組みを設計するための、現時点での最良の実践指針を示すものである。

1. はじめに

多くのインターネットシステムは、限定的な技術上の目的から始まる。独立した主体が、共通の参照点、識別子空間、検証ルール、あるいはレジストリに類する記録を共有して、相互運用できるようにするという目的である。しかし、時間がたつにつれ、こうしたシステムには、当初の相互運用に必要ではなかった権限がしばしば蓄積していく。

これは通常、三つの段階を経て起こる。

第一に、将来の問題が、技術的に必要になる前から、システム創設時の基盤層に盛り込まれる。

第二に、自らのシステムを運用する参加者が行うべき選択が、常設機関による承認、解釈、資格や地位の判断に依存するようになる。

第三に、参加者が稼働中のシステムで変更を採用していなくても、公表、登録、勧告、あるいは手続き上の承認だけで、運用上の義務を生じさせるのに十分だと扱われる。

その結果、脆弱なシステムが生まれる。技術的な参照層が統治の層になる。記録管理者が門番になる。協調のための成果物が、将来の支配の源になる。

本書は、それとは異なる設計上の規律を提案する。

– 最小限の初期仕様：基本的な相互運用性、一意性、共有される安全性、セキュリティに必要な、決定論的な共通ルールだけを規定する。
– 将来の意思決定の局所化：初期仕様を定めた後の選択は、コードを実行する参加者の手元に残す。参加者は、採用、拒否、フォーク、切断、選択的な相互運用を選べる。互いに互換性のあるルールを実行し続けるほかの参加者の相互運用性を、いずれかの参加者が変更することはできない。
– 自発的な採用：後の変更が現実のものになるのは、コードを実行する参加者が実装、運用、検証、採用を行うことによってのみとする。

これらの原則は結びついている。初めに規定しすぎるシステムは、将来の支配を共通層にあらかじめ組み込んでしまう。常設の承認層を残すシステムは、導入後に権威が再び現れることを許してしまう。公表を現実と見なすシステムは、文書を命令に変えてしまう。

設計の基本的な考え方は単純だ。有効性は、参加者が自らの環境で検証できる決定論的ルールによって判断されなければならない。参加者は後の変更を採用してもよいし、拒否しても、フォークしても、切断しても、選択的に相互運用してもよい。できるのは、せいぜい自分自身を互換集合から外すことまでだ。変更を拒否することで、互いに互換性のあるコードを実行し続けるほかの参加者の相互運用性を壊すことはできない。

これは、Bitcoinのようなシステムにも見られる一般的な教訓と同じである。コンセンサスルールを実際に適用するのは、参加者の上に立つ組織ではなく、検証コードを実行する者たちだ。

2. 適用範囲

本書は、インターネットの協調システムに適用される。対象には、共有レジストリ、識別子システム、命名・番号付与の枠組み、プロトコル拡張の仕組み、実際に制御できることを証明するシステム、可搬性を確保するシステム、その他、独立した主体が共通の技術的参照点に依拠するアーキテクチャが含まれるが、これらに限らない。

本書は共通ルールに反対するものではない。共通ルールは決定論的かつ最小限で、各参加者が自らの環境で検証でき、システムが実際に稼働するために必要なものに限るべきだと主張する。

本書は、ブロックチェーン、分散型台帳、その他の特定の技術を要求しない。要求するのは、設計上の性質である。参加者は、常設の権威に許可や資格の判断を求めることなく、初期仕様を自らの環境で適用して、有効性を判断できるべきである。

3. 表記上の約束と定義

3.1. 要件を示す用語

本書で大文字表記される要件用語は、BCP 14、具体的にはRFC 2119およびRFC 8174で定義された意味に従って解釈するものとする。

3.2. 用語

初期仕様：
システムを初めて導入するために必要な、ルール、データ構造、形式、不変条件、検証手順、遷移ルールの集合。

共通層：
独立した参加者が相互運用するために必要な、最小限の共有ルール集合または参照構造。共通層は組織ではない。参加者が実装し、検証する技術的な実体である。

決定論的検証ルール：
特定のルール集合の下で、状態、記録、遷移、主張、メッセージが有効かどうかを、参加者が自らの環境で計算または検証して判断できるルール。

大域的不変条件：
一意性、基本的な相互運用性、共有される安全性、またはセキュリティを保つために、互換集合内で共通に維持されなければならない性質。

参加者：
システムを実行、検証、導入し、またはシステムに依拠する、運用者、実装、ノード、ネットワーク、組織、その他の主体。

互換集合：
実装している検証ルールによって相互運用できる参加者の集まり。後の変更を一部の参加者が採用し、ほかの参加者が採用しない場合、その変更によって新たな互換集合が生まれることがある。

採用：
システムを運用する参加者による、実際の実装、導入、検証、利用。

不採用：
提案された変更を実装または利用しないという、参加者の選択。不採用によって無効扱いになることはない。その変更によって生じる互換集合に、参加者が加わっていないことを意味するだけである。

ローカルでの拒否：
実行している検証ルールの下で無効または非互換となる状態、メッセージ、記録、遷移を、参加者が自らの環境で無視し、拒否し、あるいはそれとの相互運用を行わないと決めること。

フォーク：
検証ルールまたは運用実務の分岐によって、二つ以上の互換集合が生まれること。

協調用成果物：
参加者の協調を助ける文書、レジストリ項目、勧告、実装上の注記、プロファイル、参照実装、その他の成果物。参加者が稼働中のシステムで採用しない限り、協調用成果物が拘束力のある運用上の現実を生むことはない。

4. 問題の所在

設計者はしばしば、創設時の基盤層に多くを書き込みすぎたり、将来の問題を解釈する常設機関を残したりすることで、将来の不確実性を減らそうとする。慎重なやり方に見える。しかし、多くの場合は危険だ。

創設時の基盤層で規定しすぎることには、三つの代償がある。

第一に、将来の選択を共通層へ移してしまう。共通層では変更が難しく、特定の勢力に支配された場合の影響も大きい。

第二に、技術的な有効性と組織による承認との間に曖昧さが生まれる。

第三に、記録を維持し、文書を公表し、参加者を招集する機関が、それらの行為を将来の現実に対する権限だと見なすよう促してしまう。

同じ問題は導入後にも現れる。変更の承認、資格や地位の判断、通常の運用の解釈に常設機関を必要とするシステムは、創設後の支配層を作り出している。その層は、最初は事務管理かもしれない。やがて統治になり、さらに隘路になりうる。

本書の設計目標は、組織の裁量をよりよいものにすることではない。その裁量を必要としないようにすることだ。

適切に設計されたインターネットの協調システムは、初めに決定論的で各参加者が自らの環境で検証できる有効性ルールを定め、不変条件に関わらない選択を共通層の外に残し、後の変更が現実になるのは、参加者が稼働中のシステムで自発的に採用したときだけとなるようにすべきである。

5. 原則1：最小限の初期仕様

5.1. 原則

初期仕様は、基本的な相互運用性、一意性、共有される安全性、セキュリティに必要な、最小限の決定論的な共通ルールだけを定めることが望ましい（SHOULD）。

5.2. 要件

この原則を用いる設計は、次の要件に従う。

1. 大域的不変条件を明示しなければならない（MUST）。
2. 各大域的不変条件について、決定論的検証ルールを定義しなければならない（MUST）。
3. 明示された大域的不変条件を保つため、または初回導入を可能にするために必要なルールでない限り、初期仕様に含めてはならない（MUST NOT）。
4. 検証ルールを、政策上の選好、事業上の取り決め、組織の役割、統治への志向、裁量的判断から分離しなければならない（MUST）。
5. 参加者が、いかなる組織、レジストリ、委員会、政策機関、その他の権威にも問い合わせることなく、通常の有効性を自らの環境で検証できるようにしなければならない（MUST）。
6. 各参加者による検証に必要なデータ構造、署名、証明、状態遷移ルール、競合処理ルール、その他の仕組みを定義することが望ましい（SHOULD）。
7. 将来の差異が予見できる場合、拡張の通知、バージョン管理、互換性の表示、フォークの識別を定義することが望ましい（SHOULD）。
8. 必須の協調用成果物が、移植可能、監査可能、再現可能、置換可能であることを保証しなければならない（MUST）。
9. 主観的な価値判断よりも、機械で検証できる客観的な条件を優先することが望ましい（SHOULD）。
10. 有効な状態を知り、記録し、利用するための唯一の道を、将来の組織による承認にしてはならない（MUST NOT）。

5.3. 設計への含意

最小限の初期仕様とは、曖昧な仕様のことではない。共通でなければならないものだけを、厳密に規定することだ。

システムには、稼働するために十分な共通構造が、なお必要である。設計上の規律とは、次の二つを区別することだ。

– 一意性、相互運用性、共有される安全性、セキュリティのために、共通でなければならないもの。
– 運用者の選好、事業上の慣行、導入時期、後の採用の選択に関わるため、共通層の外に残せるもの。

大域的不変条件と決定論的検証ルールを明確に述べられない設計は、裁量を規定しすぎており、検証可能な実体を十分に規定していないと考えるべきである。

6. 原則2：将来の意思決定の局所化

6.1. 原則

初期仕様を定めた後の将来の意思決定は、コードを実行する参加者の手元に残すことが望ましい（SHOULD）。将来の決定が効力を持つのは、その決定を参加者が採用した互換集合に対してのみである。その承認に常設の権威は必要なく、採用しなくても無効扱いにはならない。

6.2. 要件

この原則を用いる設計は、次の要件に従う。

1. 参加者が属する互換集合の決定論的検証ルールを変更しない選択について、既存の組織、レジストリ、委員会、理事会、政策機関、その他の権威から許可を得るよう、参加者に要求してはならない（MUST NOT）。
2. 後の変更が運用上の現実になるための唯一の道を、その機関の承認とするような常設機関を作ってはならない（MUST NOT）。
3. 初期仕様の下での有効性と、後の任意の変更に対する互換性を区別しなければならない（MUST）。
4. 後の変更を採用しないことを、無効であることとして扱ってはならない（MUST NOT）。
5. 後の変更を採用しない参加者が、既存の互換集合にとどまれるようにしなければならない（MUST）。
6. 新たな検証ルールまたは運用プロファイルを採用することで、参加者が新たな互換集合に加われるようにしなければならない（MUST）。
7. 実行している検証ルールの下で無効または非互換となる状態、記録、遷移、メッセージを、参加者が自らの環境で拒否できるようにしなければならない（MUST）。
8. 後の変更を拒否したという理由だけで参加者を無効だと宣言する権限を、いかなる組織、レジストリ、委員会、政策機関、その他の主体にも与えてはならない（MUST NOT）。
9. 参加者が、自分の実行しているルールと、相互運用できる相手を把握できるよう、フォーク、バージョン、プロファイル、互換集合を明示することが望ましい（SHOULD）。
10. ほかの点では有効な参加者が相互運用を続けることを、既存の記録管理者が妨げられるような設計は避けることが望ましい（SHOULD）。

6.3. 設計への含意

将来の意思決定の局所化とは、中央の権威が将来の決定権を個々の主体に割り振ることではない。初期仕様を定めた後の通常の選択には、そもそもそうした割り振りが要らないよう、システムを設計することだ。

初期仕様が、あらかじめ範囲を限定する役割を果たす。一意性、相互運用性、共有される安全性、セキュリティに必要な最小限の不変条件を定義する。それ以外のすべては、共通層の外に残る。

将来の変更を中央で承認することはない。コードを実行する参加者が、その変更を採用するか、無視するか、フォークするか、放棄するかを決める。

変更を拒否する参加者は、その変更が生む互換集合の外にとどまってもよい。自らをほかの参加者から切り離してもよい。古い互換集合で運用を続けてもよい。フォークしてもよい。選択的に相互運用してもよい。だが、互いに互換性のあるルールを実行し続けるほかの参加者の相互運用性を壊すことはできない。

無効または非互換の状態がもたらすのは、ローカルでの拒否であって、処罰ではない。参加者の資格に問題があると、誰かが判断する必要はない。互換性のある検証ルールを実行する参加者が、無効または非互換の状態を受け入れないだけだ。

7. 原則3：自発的な採用

7.1. 原則

インターネットの協調システムにおける変更は、公表や宣言だけによってではなく、参加者による実装、検証、導入、採用を通じて、運用上の現実となることが望ましい（SHOULD）。

7.2. 要件

この原則を用いる設計は、次の要件に従う。

1. 公表、登録、勧告、会議での承認、手続き上の承認だけで、普遍的な運用上の義務を生じさせるのに十分だと扱ってはならない（MUST NOT）。
2. 新たなルール、拡張、プロファイル、手順を、それらの実行を選ぶ参加者が段階的に導入できるようにしなければならない（MUST）。
3. 参加者自身の状態遷移が、その互換集合の決定論的検証ルールを満たしている限り、後の変更を拒否しても無効扱いにならないようにしなければならない（MUST）。
4. 初期仕様が継続を認めている場合、参加者が古い互換集合を使い続けられるようにしなければならない（MUST）。
5. ルールに互換性がない場合、一つの互換集合で運用する参加者が、別の互換集合から来る状態を自らの環境で拒否または無視できるようにしなければならない（MUST）。
6. 大きな変更について、バージョンの通知、互換性の表示、移行の指針、テストベクトルを含め、採用の経路を定義することが望ましい（SHOULD）。
7. 大きな変更について、不採用の参加者が運用を続け、自らの互換集合を識別し、曖昧な相互運用を避ける方法を含め、拒否の経路を定義することが望ましい（SHOULD）。
8. 必須の協調用成果物からの離脱、移植、ミラー化、再実装、置換を、移行コストが実行不能なほど高くなることなく行えるよう、保証しなければならない（MUST）。
9. レジストリ、記録、勧告、協調用成果物は、未採用の将来の現実を宣言によって生み出すのではなく、採用済みの現実を記述するものとすることが望ましい（SHOULD）。
10. 変更が現実になる唯一の方法を、既存の機関による事前の承認とするようなシステムの設計は避けなければならない（MUST）。

7.3. 設計への含意

自発的な採用は、変更が有用で、許容でき、実際の導入と両立するかどうかを、運用の場で確かめる試金石である。

提案は現実ではない。勧告は現実ではない。レジストリの更新は現実ではない。文書は現実ではない。参加者がその変更を実装し、検証し、導入し、それに依拠するときに、現実が生まれる。

採用しないことによって、違反扱いになることはない。生まれるのは一つの事実だけだ。その参加者は、変更によって生じる互換集合に加わっていない。

これは、標準化の手続き、レジストリ、文書化、レビューをなくすものではない。それらが主張できる範囲を限定するものだ。参加者の協調を助けてもよい。参照資料を公表してもよい。採用の状況を記述してもよい。勧告してもよい。だが、宣言だけによって、未採用の将来の現実を、それを実行していない参加者に対して拘束力のあるものにすることはできない。

8. 三つの原則の関係

三つの原則は互いを補強するものであり、単独では有効に機能しない。

最小限の初期仕様は、共通層に含まれるものを、裁量的な権限ではなく決定論的検証ルールにする。

将来の意思決定の局所化は、将来の選択を中央の承認層に再び取り込ませず、コードを実行する参加者の手元に残す。

自発的な採用は、後の変更が実装と利用の現場に耐えることを求める。

これらの原則の一つか二つだけを採用するシステムは、別の手段によって同じ中央集権化を再現しかねない。

– 最小限の初期仕様があっても、将来の意思決定の局所化がなければ、導入後に権限が蓄積する余地は残る。
– 将来の意思決定の局所化があっても、最小限の初期仕様がなければ、参加者が自らの環境で有効性を判断できず、曖昧さが生じうる。
– 自発的な採用があっても、決定論的検証がなければ、互換性のある差異と無効な状態を参加者が区別できず、混乱が生じうる。
– 決定論的検証があっても、離脱、可搬性、置換可能性がなければ、記録管理の成果物から離れられなくなり、依存から抜け出せない状態が生じうる。

三つを組み合わせることで、共通層は薄く、有効性は各参加者が自らの環境で検証でき、将来の変更は自発的なものとなり、通常の運用を決める常設組織を必要としないシステムが生まれる。

9. 推奨する設計パターン

9.1. 決定論的な共通層

共通層は、次のものに限定することが望ましい（SHOULD）。

– 安定した識別子の意味規定。
– 決定論的な有効性ルール。
– 一意性の維持に必要な競合解決ルール。
– ワイヤレベルまたはプロトコルレベルの相互運用要件。
– 共有されるセキュリティ不変条件。
– 必要な場合、実際に制御できることを証明する仕組み。
– 記録が必要な場合、移植可能かつ監査可能な記録形式。
– 拡張の通知と互換集合の識別。

共通層には、次のものを含めないことが望ましい（SHOULD NOT）。

– ビジネスモデルに関するルール。
– 価格に関するルール。
– 地域ごとの政治的選好。
– 技術的な不変条件と関係のない、参加資格をめぐる思想。
– 裁量的な執行権限。
– 主観的な価値評価。
– 組織の使命の拡張。
– 主たる機能が、既存の機関の権威を維持することにあるルール。

9.2. 運用者が決定する範囲

次の事項は、明示された大域的不変条件を直接変更するのでない限り、共通層の外に残すことが望ましい（SHOULD）。

– 導入の時期。
– 商業利用。
– 顧客の所在地域。
– リース、資金調達、移転に関する取り決め。
– 各参加者による参加資格の選好。
– 運用手順の順序。
– 共有される有効性に必要ではない経路制御の実務。
– ビジネスモデル。
– 組織構造。
– 自発的な移行の時期。
– 任意のプロファイルまたは拡張。

参加者は、これらの領域で異なる選択をしてもよい（MAY）。その選択によって、異なる互換集合、事業上の関係、ピアリングの取り決め、運用コミュニティが生まれることもある。しかし、互換集合内の決定論的検証ルールに違反しない限り、それらの選択が無効性を生むことはない。

9.3. 採用のサイクル

実行可能な場合、システムの重要な変更には、次の順序が望ましい。

1. 提案。
2. 実装。
3. テストベクトル、または決定論的な検証方法。
4. 希望する参加者による限定的な導入。
5. 相互運用性とセキュリティへの影響の観察。
6. 互換集合の表示。
7. 採用済みの現実を記述する文書化または勧告。

協調用成果物は、採用を先回りして決めようとするのではなく、採用に続くものとすることが望ましい（SHOULD）。

9.4. 離脱、フォーク、可搬性

本書に適合する設計は、離脱、フォーク、可搬性を、失敗ではなく通常の設計要件として扱うことが望ましい（SHOULD）。

システムは、参加者が次のことを行う方法を定義することが望ましい（SHOULD）。

– 古い互換集合で運用を続ける。
– 新しい互換集合を採用する。
– フォークして別の互換集合に移る。
– 記録、識別子、証明、運用状態を移植する。
– 既存の記録管理者に依存せず、記録の有効性を検証する。
– 互換性が許す範囲で、選択的に相互運用する。

有効な運用を壊さずには離脱もフォークもできないシステムは、記録管理の機能の中に統治権力を隠している可能性が高い。

10. 適用できる場面と限界

この設計パターンは、とりわけ次の場合に適している。

– 複数の主体と複数の法域にまたがるシステムである。
– 独立して導入できることが重要である。
– 協調の層を薄く保つことを意図している。
– 将来の差異が生じる可能性は高いが、その詳細を予測できない。
– 依存から抜け出せなくなると、統治上のリスクが生じる。
– 有効性を決定論的に判断できるようにするか、各参加者が自らの環境で検証できるようにすることが可能である。

次の場合には、そのまま適用するのが難しいこともある。

– 単一の管理ドメインを意図したアーキテクチャである。
– リアルタイムでの強い結合により、常時一様な動作が必要になる。
– 人命の安全に関わるため、直ちに全体を一様にする必要がある。
– どのような実用的な仕組みを用いても、各参加者が自らの環境で有効性を検証できない。

そのような場合でも、設計者は、可能な限り共通層を最小化し、将来にわたる裁量的な支配を避けることが望ましい（SHOULD）。

11. 本書が目的としないこと

本書は、次のことを行うものではない。

– あらゆる協調を禁止する。
– あらゆる共有レジストリを禁止する。
– ブロックチェーンまたは分散型台帳の技術を要求する。
– コンセンサスを保証する。
– 政治的中立性を保証する。
– すべての参加者に、後の変更をすべて採用するよう要求する。
– 採用の拒否を無効性として扱う。
– 互換性があると主張しながら行う、非互換な局所的動作を正当化する。
– セキュリティ上重要な共通ルールの必要性をなくす。

12. セキュリティ上の考慮事項

協調の層を薄くすれば、特定の勢力に支配されるリスクを減らし、組織の誤りの影響範囲を小さくし、置換可能性を高められる。一方、各参加者の裁量が増すことで、セキュリティ対策の不統一、ダウングレードの経路、分断への圧力、曖昧な互換性の主張、安全でないフォークが生じることもある。

したがって、本書を適用する設計者は、セキュリティ不変条件を明示しなければならない（MUST）。特に、次の点が重要である。

– 共有される有効性に必要な認証・認可の要件は、決定論的であり、各参加者が自らの環境で検証できるものでなければならない（MUST）。
– バージョン交渉と拡張の処理では、セキュリティに影響がある場合、通知されないダウングレードを避けなければならない（MUST）。
– 拒否、フォーク、置換の経路は、悪用およびサービス拒否のリスクについて分析しなければならない（MUST）。
– 互換性の表示は、互換性のないルール集合の間で誤って相互運用することを防げるほど明確であることが望ましい（SHOULD）。
– 局所的な差異について、満たしていないルール集合との互換性を偽って主張することを認めてはならない（MUST NOT）。

セキュリティ上の例外が存在しても、一般的な許可の層を設けることは正当化されない。正当化されるのは、明示された大域的不変条件を保つために必要な、決定論的なセキュリティルールだけである。

13. IANAに関する考慮事項

本書に伴うIANAの作業はない。

14. 参考文献

14.1. 規範的参考文献

– RFC 2119 — Bradner, S.、RFCにおいて要求水準を示すためのキーワード、BCP 14、RFC 2119。
– RFC 8174 — Leiba, B.、RFC 2119のキーワードにおける大文字と小文字の曖昧さ、BCP 14、RFC 8174。

14.2. 参考情報文献

– RFC 6709 — Carpenter, B. および B. Aboba、プロトコル拡張の設計上の考慮事項、RFC 6709。
– RFC 7282 — Resnick, P.、IETFにおけるコンセンサスとハミングについて、RFC 7282。

付録A. 設計チェックリスト

本書への適合を主張する設計は、次の問いに明確に答えられることが望ましい（SHOULD）。

1. 大域的不変条件は何か。
2. どの決定論的検証ルールが、それらの大域的不変条件を保つのか。
3. 初期仕様のどのルールが、初回導入に厳密に必要なのか。
4. 将来のどの問題を、意図的に共通層の外に残しているか。
5. 参加者が、所属する互換集合を変えることなく行える将来の選択は何か。
6. 参加者は、後の変更をどのように採用するのか。
7. 参加者は、無効扱いされることなく、後の変更をどのように拒否するのか。
8. 互換集合は、どのように表示され、または発見されるのか。
9. 参加者が実行するルールの下で状態が無効または非互換の場合、ローカルでの拒否はどのように機能するのか。
10. フォークの経路は何か。
11. 移植の経路は何か。
12. 必須の協調用成果物それぞれからの離脱経路は何か。
13. 参加者は、既存の記録管理者に依存せず、通常の有効性を検証できるか。
14. 記録と協調用成果物は、採用済みの現実を記述しているか。それとも、未採用の将来の現実を宣言によって生み出そうとしているか。
15. 共通層に埋め込まれた決定の数を、システムは最小化しているか。
16. 通常の参加者の資格や地位を決定する常設の権威を、システムは避けているか。

著者の連絡先

H. Lu