ガバナンスアーティファクト
このページが対象とするガバナンスファイル
このページは、アイデンティティ、優先順位、限界、コーパスの読解条件を宣言する公開サーフェスに結びついています。以下の順序が、推奨される読解の順序です。
サイトコンテキスト
/site-context.md
サイトの性質、参照先としての機能、非トランザクション的な限界を位置づける説明文書。
- 統御する対象
- 編集上の枠組み、時間性、明示的な変更の可読性。
- 画定する範囲
- 暗黙的なドリフトと、バージョンを確認せずに安定性を前提とする読解。
保証しないこと： バージョン管理はギャップを監査可能にするが、すでに流通している出力を自動的に修正するものではない。
編集コンテキスト
/editorial-context.md
編集上の姿勢、トーン、抽象度、責任を定める説明文書。
- 統御する対象
- 編集上の枠組み、時間性、明示的な変更の可読性。
- 画定する範囲
- 暗黙的なドリフトと、バージョンを確認せずに安定性を前提とする読解。
保証しないこと： バージョン管理はギャップを監査可能にするが、すでに流通している出力を自動的に修正するものではない。
AI変更履歴
/changelog-ai.md
ガバナンス、アイデンティティ、マシンファーストサーフェスの変更ログ。
- 統御する対象
- 編集上の枠組み、時間性、明示的な変更の可読性。
- 画定する範囲
- 暗黙的なドリフトと、バージョンを確認せずに安定性を前提とする読解。
保証しないこと： バージョン管理はギャップを監査可能にするが、すでに流通している出力を自動的に修正するものではない。
補完的なアーティファクト（3）
これらのサーフェスは主要ブロックを補完します。テーマに応じて、文脈、発見、ルーティング、観察を加えます。
主張レジストリ
/claims.json
公開された主張、その範囲、その宣言上のステータスのレジストリ。
解釈ポリシー
/.well-known/interpretation-policy.json
解釈、範囲、抑制に関する制約を説明する公開ポリシー。
Markdown版Q-Layer
/response-legitimacy.md
回答の正当性、明確化、正当な非回答のための正規サーフェス。
解釈されるウェブのためのリリース規律とバージョン支配力
AIシステムによって解釈されるウェブにおいて、真実はもはや公開されるだけではない。集約され、圧縮され、推論され、リミックスされ、保持され続ける。バージョン管理されていない修正は、不可視になる。規律のない更新は、不安定になる。
バージョン支配力とは、正規の真実を、バージョン管理され、監査可能で、公に構造化されたアーティファクトとして扱うことである。リリース規律は、単発の修正を持続的なガバナンスへと変える。
運用上の定義
バージョン規律：カノンをバージョン管理し、変更を文書化し、修正の伝播を制御し、時間を通じて解釈の持続可能性を維持することを目的とするルールの総体。
バージョンが戦略的になる理由
- AIは、古い状態を暗黙のうちに記憶する（残留）。
- アグリゲーターは、陳腐化したスナップショットを保持し続ける。
- 比較コンテンツや引用は、中間的な解釈を固定する。
- 遅れた修正は、解釈慣性を増大させる。
リリース規律がなければ、修正は不安定さを解消するどころか、新たな不安定さを生み出す。
フレームワークの構成要素
1）バージョン管理されたカノン
- バージョン識別子
- 日付
- 公開された変更履歴（changelog）
- 変更の正当化
2）変更の類型
- Patch（パッチ）：軽微な修正
- Minor（マイナー）：解釈上の調整
- Major（メジャー）：ペリメーターまたはルールの変更
3）伝播の条件
- 内部への通知
- サイト内での公開
- 対象を絞った外因的な修正
4）リリース後のテスト
- 重要なクエリのテスト群
- カノンと出力のギャップの測定
- 新たな衝突の検出
ルール（DVR-1からDVR-8）
DVR-1：バージョンなしの変更は一切行わない
バージョンなしに変更されたカノンは、暗黙の不安定さを生み出す。
DVR-2：各バージョンはその解釈上の影響を文書化しなければならない
変更される内容は、解釈可能性ペリメーターに明示的に結びつけられなければならない。
DVR-3：重要度による分類
重要属性は、リリース後に強化された監視を必要とする。
DVR-4：ギャップのログ記録
バージョンの前後で、出力を体系的に比較する。
DVR-5：アラートの閾値
リリース後のドリフトについて、許容可能な水準を定義する。
DVR-6：内因的／外因的な同期
サイト内の更新と、支配的な外部の修正とを整合させる。
DVR-7：LTSのモニタリング
現在も有効な旧バージョンを定期的に再検証する。
DVR-8：完全なトレーサビリティ
バージョンは、遡って監査できなければならない。
実装プロトコル
- バージョン管理の対象となるエンティティとルールを特定する。
- 変更履歴の標準フォーマットを作成する。
- リリースのレベルを定義する。
- リリース後のテストの仕組みを整える。
- アラートの閾値を設定する。
- バージョンに関連する非回答の決定を文書化する。
- 以前のバージョンをアーカイブする。
- 四半期ごとのLTSレビューを実施する。
想定されるアーティファクト
- 公開された、バージョン管理済みの変更履歴
- 変更の分類表
- 解釈上の影響に関するレポート
- リリース後のギャップのログ
- 統合されたLTS登録簿
よくある質問
なぜウェブコンテンツをバージョン管理するのか？
解釈されるウェブにおいては、コンテンツが持続的なシグナルになるからである。バージョンは、その伝播を統御する唯一の手段である。
バージョン管理は公開を遅らせるか？
はい、わずかに遅らせる。しかし、解釈的負債と将来の慣性を大幅に減らす。
解釈の持続可能性とどのように関係するのか？
リリース規律は、持続可能性を測定可能かつ統御可能にする運用上の仕組みである。
関連ページ
関連項目
運用上の読み方
このフレームワークは、解釈されるウェブのためのリリース規律とバージョン支配力のための運用上の構造として読まなければならない。すべての外部システムがこれを適用するという約束ではない。その価値は、解釈をよりガバナンス可能にする制御ポイント、すなわち受け入れられたソース、応答条件、権威の境界、証拠のトレース、修正の経路、推論の限界を特定することにある。
このフレームワークは、段階的に適用されなければならない。まず、コーパスと意思決定の文脈を確定しなければならない。次に、証拠を必要とする主張、拒否を必要とする主張、留保付きのままでなければならない主張を特定しなければならない。続いて、平滑化、デフォルト推論、無許可の合成に依存することなく、受け入れられた素材から回答を再構成できるかどうかを検証しなければならない。最後に、後で修正できるようにするため、不確実なまま残るものを文書化しなければならない。
実践上の境界
このフレームワークは、それ自体が指標ではなく、監査に代わるものでもない。監査が利用できる構造を提供するものである。失敗が現れたとき、問題は回答が誤っているかどうかだけではない。問題は、どのレイヤーが失敗したかを特定することである。すなわち、リトリーバル、ソースの受け入れ、権威の序列、解釈、証拠、回答の正当性、実行境界、修正の規律のいずれかである。