外部フレームワークはカノンを統御しない

この立場のステータス

このページは、提案段階にあるアーキテクチャ上の立場の公開プロジェクションである。このページは、規範的なドクトリンのリポジトリで仕様化される予定の境界を説明するものであり、その仕様に取って代わるものではなく、外部統合のメカニズムがすでに本番環境で稼働していると主張するものでもない。

立場は次のとおりである。

外部フレームワークは、リスク、緩和策、義務、またはマッピングを判定することができる。外部フレームワークは内部のカノンを直接統御せず、カノンから導かれる権限を拡大することもできない。

このルールは、リスク分類体系、標準、規制フレームワーク、緩和策データベース、Codebook、ブランドマニュアル、その他の取り込まれた形式体系に適用される。

1. もはや混同してはならない三つの権威

ガバナンス下のアーキテクチャは、少なくとも三つの平面を区別しなければならない。

1.1 外部の参照権威

この権威は、外部の機関、標準、著者、組織に由来する。この権威は、自らの文書、すなわちその語彙、カテゴリー、バージョン、ライセンス、宣言された範囲について権威をもつ。

この権威は、たとえば次の目的に用いることができる。

• 認知されたリスクの種類を名指すこと
• 複数のフレームワークを比較すること
• 管理策のファミリーを特定すること
• 義務や慣行を文書化すること
• 監査人やパートナーとの共通語彙を確立すること

この権威は、別の組織の内部の主張に自動的に及ぶものではない。

1.2 内部の正規の権威

この権威は、組織のアイデンティティ、主張、用語、制約、優先ルールについて、どのソースが統御するかを決定する。

この権威は、異なる問いに答える。

• どのエンティティが対象か
• どのClaimが受け入れられるか
• どのソースがそのクラスについて権威をもつか
• どの限界や除外が適用されるか
• どのルールが衝突を裁定するか
• 特定の状況において、どの情報を投影してよいか

公式のソースは、アイデンティティ、公開されたドクトリン、または宣言された限界について正規でありうる。だからといって、評判、外部からの批判、客観的な真実についての絶対的な裁定者になるわけではない。

1.3 運用上の決定権威

この権威は、コンパイルされたルールを具体的なインタラクションに適用するメカニズムに属する。この権威は、新たな権限を作り出さない。上位のレイヤーがすでに承認したものの中から選択するだけである。

この権威は、次のことを決定しうる。

• 情報を受け入れる
• 情報を限定する
• 制約を付す
• 明確化を求める
• 正当な非回答を生成する
• その事象を証拠チェーンに記録する

したがって、ランタイムは自らのポリシーの裁判官になってはならない。ランタイムは、事前にコンパイルされた権威とルールから生成された決定論的なプロジェクションを実行する。

2. Coreは五つのオブジェクトに閉じたままである

v0.1の提案は、次の五つのオブジェクトのみで構成される。

1. Entity（エンティティ）
2. Claim（主張）
3. Term（用語）
4. Constraint（制約）
5. Precedence（優先）

その数が少ないことは管理上の特性であり、偶然の制約ではない。

外部フレームワークは、Coreの中にRisk、Control、Framework、Codebook、Profileといった追加のオブジェクトを作らない。これらの概念は、外部の登録簿、マッピングのマトリクス、またはプロジェクションの中には存在しうるが、正規のモデルを変更するものではない。

この閉鎖性によって、新たな統合のたびに次のものが押しつけられることが防がれる。

• その統合のオントロジー
• その状態
• そのライフサイクル
• その優先順位のルール
• その曖昧さ
• その技術的な依存関係

マッピングの内部的な効果は、五つのオブジェクトで表現できなければならない。

例：ある外部リスクが、提供の前に認証日を求める候補としてのConstraintを正当化することがある。外部リスクはConstraintそのものではない。それは参照される正当化の根拠である。Constraintは、権威による決定と内部ルールに基づく受け入れを経て初めてCoreに入る。

3. Coreの状態を汚染してはならない

正規の状態は次のとおりのままである。

• allowed
• conditional
• forbidden
• deprecated

外部マッピングは、「提案」「レビュー済み」「承認」「却下」「置き換え済み」といった独自のワークフロー上の状態をもちうる。その状態はマッピングの登録簿に属するものであり、Coreに属するものではない。

この区別は重要である。

満たされていない条件、または評価できない条件は、そのClaimをその状況において適格でないものにする。それによってClaimが自動的にforbiddenになるわけではない。forbiddenの状態は、所管する権威が発した明示的な禁止のために留保されなければならない。

同様に、高リスクのカテゴリーがあるからといって、それに結びつくすべてのClaimが自動的にforbiddenになるわけではない。それによって、より強い証拠、留保、エスカレーション、または非回答が必要になることはある。判断は文脈と内部ルールに依存する。

4. マッピングは派生的なプロジェクションである

外部フレームワークとCoreとの関係は、バージョン管理され、可逆的なマッピングとして表現されなければならない。

マッピングは次のものを宣言しうる。

• 外部の名前空間
• リスクまたは管理策の識別子
• スナップショットのバージョンまたは日付
• ソースとそのライセンス
• 対象となる内部の失敗モード
• 影響を受けるCoreのオブジェクト
• マッピングを承認した権威
• 適用条件
• 期待される証拠
• 残存する限界

マッピングは、次のことも宣言しなければならない。

canonical: false

このフィールドは、外部フレームワークが信頼できないことを意味するものではない。このフィールドが述べているのは、そのフレームワークが内部のカノンを定義する権威をもたないということである。

承認されたマッピングは、ガバナンスのポリシーやプロジェクションの構築に影響を与えうる。それでもマッピングは、それが参照するCoreのオブジェクトを書き換えることなく、削除または置き換えが可能なままである。

5. 非拡大のルール

非拡大の公理は、チェーン全体に適用される。

下位のレイヤーは、上位のレイヤーが付与した権限を決して拡大してはならない。

したがって、次のことが成り立つ。

• 外部フレームワークは、カノンが承認していないClaimを承認することはできない。
• マッピングのマトリクスは、Constraintを無効化することはできない。
• プロジェクションは、受け入れられたオブジェクトにない意味を付け加えることはできない。
• ランタイムは、満たされていない条件を補完することはできない。
• 流暢な再現出力を、事後的に正当な回答として再分類することはできない。
• 集計された指標は、満たされていない必要条件を消し去ることはできない。

例外は、明示的かつ局所的で、上位のルールによって承認されたものでなければならない。暗黙の例外は、ガバナンス外の拡大である。

6. Codebookとの関係

Codebookは二つの正当な役割を果たしうるが、それらを同時に果たすことはできない。

6.1 ブートストラップのソース

Codebookは分析され、Coreの五つのオブジェクトへと正規化される。取り込まれた各要素には、来歴、権威、ステータス、そして必要な場合には人間によるレビューが付与される。

この段階の後、Codebookはランタイムの運用上の依存先としては残らない。その後の変更は、Coreの権威プロセスに従う。

6.2 再生成されたビュー

Codebookは、Coreから生成される可読な表現となる。Codebookは、人間による参照、枠づけられた編集、または交換に役立ちうるが、自らの出力を新たな真実として自動的に再投入してはならない。

裁定されない双方向ループは禁止される。どちらのサーフェスがもう一方を統御するのかを判断できなくなるからである。

同じルールはリスク登録簿にも適用される。外部の名前空間への管理された取り込みを行い、その後に承認されたマッピングを行う。決定なしにCoreを変更しうるライブ同期は、決して行わない。

7. 認識論的ステータスはあらゆる変換に付随する

フレームワークを取り込み、モデルによる分類を用いることのできるアーキテクチャは、それぞれの知識の性質を保持しなければならない。

アーキテクチャは、少なくとも次のものを区別する。

• ソースによる宣言：引用された権威によって明示的に公開されたもの
• 決定論的な導出：再現可能なルールによって生成されたもの
• モデルによる分類：確率的な出力
• 人間によるレビュー：特定された人物によって検討されたもの
• インタラクションにおける観察：定められた期間内の事象または再現出力を記述するもの

一つの項目が複数のステータスを順に帯びることはありうるが、その連鎖は保持されなければならない。

モデルによる分類は、少なくとも次のものを記録しなければならない。

• プロバイダーとモデル
• 利用可能なバージョン
• プロトコルまたは指示
• 日付
• 使用されたコーパス
• スコアまたは関連性の水準
• 人間によるレビューのステータス
• 既知の不一致

いかなる信頼度スコアも、分類を自動的に正規の事実へと変換することはない。

8. フレームワークは取り込まれるものであり、ランタイムがライブで照会するものでは決してない

本格的な統合は、ローカルでバージョン管理されたスナップショットを用いる。

最小限のフローは次のとおりである。

selected external source
        ↓
dated snapshot
        ↓
hash
        ↓
licence and attribution
        ↓
external normalization
        ↓
mapping review
        ↓
compilation
        ↓
authorized projection

ランタイムは、回答を提供する時点で外部データベースを直接照会してはならない。そのような依存関係は、管理されない変更を許し、状態の再現を妨げ、実際に適用されたバージョンについての曖昧さを生むことになる。

フレームワークの新しいリリースは比較を引き起こす。それがアクティブなバージョンを自動的に置き換えることは決してない。

9. ガバナンスと証拠のサイクル

外部フレームワークは、より大きなループの中に関与する。

Authority
    → admissibility
    → projection
    → delivery
    → restitution
    → deviation
    → conformance
    → ledger

このサイクルのトークンは歴史的な識別子であり、そのまま保持される。deliveryは、プロジェクションの利用者への配布を指す。deviationはΔを生成する比較の段階を指し、conformanceはQを生成する判定の段階を指す。したがって、deviationというトークンは、それだけでは確定したギャップを指すものではない。

プロジェクションは次のように表すことができる。

P = f(A, G, I, C)

ここで、

• Aは権威と、受け入れられた正規のオブジェクトである。
• Gは適用されるガバナンスのポリシーである。
• Iはインテントまたはリクエストのクラスである。
• Cは、オーディエンス、チャネル、管轄、時間を含む文脈である。
• Pは承認されたプロジェクションである。

外部フレームワークはGに情報を与えることができる。外部フレームワークはAに取って代わるものではない。

再現出力Rは、検討のために実際に保持された出力を指す。これを次にPと比較する。

Δ = g(P, R)

Δは、PとRを比較した結果を文書化したものである。その結果は、それだけでは不適合の判定ではない。Qは、適用されるガバナンスと利用可能な証拠に照らして、その適合性を判定する。

Q = h(Δ, G)

「カノンと出力のギャップ」という表現は、内容または範囲について確定した不適合のために留保されている。適合的な言い換え、文体の違い、正しく位置づけられた批判は、それが存在するというだけでは、そのようなギャップを構成しない。

判定は、検討されたオブジェクト、バージョン、ルール、観察に限定される。それらの要素から結論を導けない場合、結果は、適用される契約のもとで不確定または未確定のままである。それは暗黙の適合にも、立証されたギャップにも変換されない。

これらの関係は概念上の表現にとどまる。gは普遍的な数値上の距離ではなく、hはすでに存在する普遍的な分類器ではない。

台帳に記録された観察は、ポリシーやマッピングの見直しを引き起こしうる。それが五つのオブジェクトを直接変更することはない。

10. 矛盾とコンパイルの失敗

外部フレームワークが内部の権威と衝突する場合、システムは、テキスト上の近接性や平均化によってその問題を解決してはならない。

最低限のルールは次のとおりである。

• 外部の権威は、それ自身の対象に限定されたままである。
• マッピングは、該当する主張クラスを特定しなければならない。
• 明示的なPrecedenceのルールが、比較可能な権威の間を裁定しなければならない。
• 同じ権威水準にある二つの矛盾するルールは、コンパイルの失敗を引き起こす。
• 適用可能性を評価できないマッピングは、非アクティブのままである。
• 作り出された権限よりも、非回答のほうが望ましい。

コンパイルの失敗は安全のためのメカニズムである。それは、矛盾がランタイムにおける恣意的な判断になることを防ぐ。

11. この立場が禁止すること

この立場は、次の導出を禁止する。

1. 外部の分類体系を、デフォルトで内部の権威として扱うこと
2. 取り込まれたフレームワークごとに、新たなCoreのオブジェクトを作ること
3. レビューなしに、モデルによる分類を正規の事実に格上げすること
4. ランタイムをライブの外部ソースに接続すること
5. 観察にカノンを直接変更させること
6. 宣言された緩和策を、有効性の証拠として用いること
7. 部分的なマッピングから、全体的な適合を主張すること
8. 下位のレイヤーに、上位レイヤーの権限を拡大させること

12. アーキテクチャ上の帰結

相互運用可能なシステムとは、あらゆるフレームワークを自らの中核に吸収するシステムではない。それは、次のことができるシステムである。

• フレームワークのバージョンを取り込む
• 出典表示を保持する
• フレームワークを外部の名前空間に保つ
• マッピングを明示する
• そのマッピングを内部の権威に付託する
• 権限を拡大することなく管理策をコンパイルする
• 観察とアテステーションを混同することなく結果を測定する
• Coreを不安定にすることなくマッピングを削除または置き換える

外部フレームワークの価値は保たれるが、その管轄は限定されたままである。

最終ルール

カノンは、組織が何を主張することを承認されているか、そしてどの制約のもとでそうするかを宣言する。外部フレームワークは、なぜ特定の失敗が重要なのか、あるいはどのような管理策のファミリーが存在するのかを説明する。マトリクスはその二つを結びつける。ランタイムはコンパイルされた決定を実行する。監査は再現出力を測定する。台帳は限定された証拠を保持する。

これらの平面のいずれも、他の平面を吸収してはならない。

ラボでの展開

このページは、引き続き正規のドクトリン上のソースである。リスク、管理策、証拠に関する公開プログラム（英語）は、研究上の問い、プロトコル、証拠の状態を別個に限定している。プログラムが存在すること自体は、成果ではない。