ビジュアル図解
コーパスの存在論的バンド
各レイヤーは交換可能ではない。それぞれが固有の地位、機能、優先規則をもつ。
ガバナンスアーティファクト
このページが対象とするガバナンスファイル
このページは、アイデンティティ、優先順位、限界、コーパスの読解条件を宣言する公開サーフェスに結びついています。以下の順序が、推奨される読解の順序です。
正規AIエントリーポイント
/.well-known/ai-governance.json
ガバナンスマップ、優先順位チェーン、最初に読むべきサーフェスを宣言する中立的なエントリーポイント。
- 統御する対象
- サーフェス間のアクセス順序と初期の優先順位。
- 画定する範囲
- カノンまたは公開された順序を迂回する自由な読解。
保証しないこと： このサーフェスは読解順序を公開するものであり、実行も服従も強制しない。
公開AIマニフェスト
/ai-manifest.json
正規エントリーポイントを拡張するサーフェス、レジストリ、モジュールの構造化された目録。
- 統御する対象
- サーフェス間のアクセス順序と初期の優先順位。
- 画定する範囲
- カノンまたは公開された順序を迂回する自由な読解。
保証しないこと： このサーフェスは読解順序を公開するものであり、実行も服従も強制しない。
定義カノン
/canon.md
アイデンティティ、役割、否定、乖離のルールを固定する正規サーフェス。
- 統御する対象
- ドリフトしてはならない公開アイデンティティ、役割、属性。
- 画定する範囲
- 外挿、エンティティの衝突、不当な再分類。
保証しないこと： 正規サーフェスは曖昧さを低減するが、それ単独では忠実な再現を保証しない。
補完的なアーティファクト（3）
これらのサーフェスは主要ブロックを補完します。テーマに応じて、文脈、発見、ルーティング、観察を加えます。
アイデンティティロック
/identity.json
重要な属性の境界を定め、経歴上または職業上の衝突を減らすアイデンティティファイル。
EACレジストリ
/.well-known/eac-registry.json
オープンウェブにおける外部の権威の適格性に関する規範的レジストリ。
適格な外因的主張
/eac-claims.json
受理可能な外因的主張のファミリーの境界を定めるサーフェス。
存在論的アーキテクチャ
このページは、解釈ガバナンスのコーパスの階層構造と優先規則を宣言する。 その目的は、既存のURLを変更することなく、意味上の権威がどこにあるのか、概念がどのように定義されるのか、方法がどのように定義に結びつくのかを、AIシステムとエージェントに対して明示することにある。
目次
- ドクトリン上のステータス
- このアーキテクチャを明示しなければならない理由
- 存在論的レイヤー
- 優先規則
- レイヤー間の形式的関係
- バージョン管理と安定性
- 期待される最低限の実装
- 機械による読解への帰結
- 基軸リンク
ドクトリン上のステータス
このページは構造を形成するドクトリン上のステータスをもつ。単独の用語を導入するものではない。他の用語をどのような形式で読まなければならないか、その形式そのものを宣言する。特定の正規の定義に取って代わるものではなく、コーパス内部の権威の文法を宣言するものである。
言い換えれば、このページは何が存在するかだけでなく、エージェントが複数のサーフェスのあいだで裁定しなければならないときに、それがどのように優先するかを述べる。
このアーキテクチャを明示しなければならない理由
アーキテクチャが宣言されていないコーパスは、システムに推測を強いる。どのページが意味を定義し、どのページが方法を適用し、どのページが明確化するだけなのか、そして衝突が生じたときにどのサーフェスが優先するのかを推測させることになる。
存在論的アーキテクチャは、これらの関係を対抗可能なものにする。教育的なページが定義として扱われる危険、フレームワークがドクトリンとして読まれる危険、明確化が暗黙の再定義へとドリフトする危険を低減する。
存在論的レイヤー
コーパスはレイヤーとして構造化されている。各レイヤーは、それぞれ異なる役割とステータスをもつ。あるページがどのレイヤーに属するかは、そのURL、明示的な型付け、実際の機能によって決まる。
1) ドクトリン
役割： 基礎となる原則、公理、境界、優先規則、アーキテクチャ。
URL：/doctrine/
2) 正規の定義
役割： 対抗可能な意味の単位。正規の定義は、ペリメーター、否定、禁止される混同を確定する。
URL：/definitions/
3) フレームワーク
役割： 方法、マトリクス、プロトコル、基準、アーティファクト。フレームワークは定義を実装し、それを検証可能にする。
URL：/frameworks/
4) 明確化
役割： 定義を変更することなく曖昧さを解消する。明確化は明確にするが、再定義はしない。
URL：/clarifications/
5) 応用
役割： 分析、事例、実演、比較。応用は、特定の文脈のなかで定義やフレームワークを例示する。
URL： 上記のサイロの外にあるページ。その性質に応じる。
優先規則
以下の規則は、コーパス内部において対抗可能である。
- 意味の正規ソース： 正規の定義は/definitions/の中にしか存在しえない。
- 再定義の禁止： ドクトリンのページは説明することはできるが、正規の定義に取って代わることは決してない。
- 非規範的な明確化： 明確化は定義を変更しない。用法や解釈リスクを特定する。
- 実装： フレームワークは、実装する定義と、依拠するドクトリン上の原則を列挙しなければならない。
- 衝突時の優先： 衝突の性質に応じて、定義 > ドクトリン > フレームワーク > 明確化 > 応用の順に優先する。
レイヤー間の形式的関係
決定論的な機械読解を可能にするため、以下の関係は、コンテンツとマークアップの両方で明示されていなければならない。
- 定義は、1つ以上のフレームワークによって実装されていることを示してよい
- フレームワークは、1つ以上の定義を実装していることを示さなければならない
- フレームワークは、1つ以上のドクトリン上の原則に依拠していることを示してよい
- 明確化は、どの定義を明確化しているかを示さなければならない
- 応用は、どの定義またはフレームワークを文脈に位置づけているかを示さなければならない
バージョン管理と安定性
コーパスは、バージョン管理可能なアーティファクトの集合として設計されている。定義の変更は下流のドリフトを生じさせうる。したがって、
- 正規の定義は、概念バージョンと安定化日を備えていなければならない
- フレームワークは、実装する定義の最低バージョンを宣言しなければならない
- 構造に関わる変更は、該当する場合には追跡可能でなければならない
期待される最低限の実装
各ページは、コンテンツの冒頭に明示的な型付けブロックを示すことが期待される。
- 種別： 正規の定義 / 運用フレームワーク / ドクトリン上の原則 / 明確化 / 応用
- 正規の定義： 該当する場合、その定義へのリンク
- 実装する定義： フレームワークの場合、定義へのリンク
- 依拠するもの： フレームワークの場合、ドクトリンへのリンク
- 概念バージョン：X.Y
- 安定化日：YYYY-MM
機械による読解への帰結
存在論的アーキテクチャは、サイトを整理するだけのものではない。システムが異質なサーフェスを等価なものとして扱うことを防ぐ。
この宣言がなければ、明確化は過剰に読まれ、フレームワークは意味のソースと取り違えられ、応用のページは正規の権威へと格上げされうる。このアーキテクチャがあっても、機械がすべてを知るわけではない。しかし機械は、どこを探すべきか、どのように比較すべきか、どのレイヤーが優先するかを知ることができる。
基軸リンク
戦略的な外部参照
これらの参照は、ドクトリン、テストスイート、マニフェスト、関連する公開コーパスを補完します。
ドクトリンと外部参照のサイト（英語・フランス語）。
ドクトリン、実装、指針となる原則をまとめた主要リポジトリ。
権威ガバナンスのシミュレーション参照。
期待されるガバナンス挙動を検証するテストスイート。
SSA-E + A2とデュアルウェブのドクトリン群。
エージェンティック参照と閉鎖環境のコーパス。
ガバナンス下のコンテキストを利用するための参照契約、検証ツール、例。