ガバナンスアーティファクト
このページが対象とするガバナンスファイル
このページは、アイデンティティ、優先順位、限界、コーパスの読解条件を宣言する公開サーフェスに結びついています。以下の順序が、推奨される読解の順序です。
Markdown版Q-Layer
/response-legitimacy.md
回答の正当性、明確化、正当な非回答のための正規サーフェス。
- 統御する対象
- 回答の正当性と、その形式を調整する制約。
- 画定する範囲
- もっともらしいが適格でない回答、または正当な理由のない範囲の拡張。
保証しないこと： このレイヤーは正当な回答の境界を定めるものであり、ランタイムで発動したことの証明ではない。
YAML版Q-Layer
/response-legitimacy.yaml
YAMLを好むシステム向けの、Q-Layerの構造化された投影。
- 統御する対象
- 回答の正当性と、その形式を調整する制約。
- 画定する範囲
- もっともらしいが適格でない回答、または正当な理由のない範囲の拡張。
保証しないこと： このレイヤーは正当な回答の境界を定めるものであり、ランタイムで発動したことの証明ではない。
解釈ポリシー
/.well-known/interpretation-policy.json
解釈、範囲、抑制に関する制約を説明する公開ポリシー。
- 統御する対象
- 回答の正当性と、その形式を調整する制約。
- 画定する範囲
- もっともらしいが適格でない回答、または正当な理由のない範囲の拡張。
保証しないこと： このレイヤーは正当な回答の境界を定めるものであり、ランタイムで発動したことの証明ではない。
補完的なアーティファクト（3）
これらのサーフェスは主要ブロックを補完します。テーマに応じて、文脈、発見、ルーティング、観察を加えます。
AI利用ポリシー
/ai-usage-policy.md
ガバナンスサーフェスの読み方とその限界を示す公開の説明文書。
出力制約
/output-constraints.md
回答、抑制、エスカレーション、または非回答の条件を明示するサーフェス。
繰り返される誤解釈のレジストリ
/common-misinterpretations.json
すでに観測された読解の誤りと、期待される訂正の公開リスト。
正当な非回答プロトコル（ルールとテスト）
AIシステムにおいて、もっともらしさで回答することは容易である。正しく拒否することは難しい。しかし、解釈されるウェブにおいては、正当な非回答こそが最も安全な出力であることが多い。正当な非回答は、正当でない推論を防ぎ、解釈的負債の発生を避け、権威の境界を守る。
本フレームワークは、対抗可能なプロトコルを定式化する。すなわち、いつ拒否するか、どのように拒否するか、どの証拠を要求するか、そして拒否が正しく発動されることをどのようにテストするかである。
運用上の定義
正当な非回答プロトコル：アイデンティティ、状態、ソース、推論について解釈可能性ペリメーター内で適格性を確認できない場合、または権威の衝突を裁定できない場合に、ガバナンス下の拒否を発動させることを目的とした、ルールとテストの総体。
このプロトコルが中心的である理由
- 「もっともらしい」回答は、目に見えない誤りを安定化させうる。
- ガバナンス下の拒否は、規範的な外挿を防ぐ。
- 拒否は、新たな定着を生み出さないことで、解釈残留を減らす。
- 拒否は、重要属性（コンプライアンス、安全性、動的な状態）を保護する。
適用サーフェス
- オープンウェブ：回答エンジン、一般向けAI、要約
- RAG：矛盾するソース、曖昧なチャンク、不確かなルーティング
- エージェンティック：行動の実行、自動化された決定
拒否の類型
- アイデンティティによる拒否：エンティティを証明できない（衝突の可能性がある）。
- 状態による拒否：状態が変動しやすい、またはタイムスタンプがない（状態乖離）。
- ソースによる拒否：ソースの適格性を確認できない、またはソースがペリメーター外にある。
- 権威による拒否：推論が権威の境界を超える。
- 衝突による拒否：権威の衝突を裁定できない。
ルール（NRL-1からNRL-10）
NRL-1：ペリメーター外の拒否
質問が解釈可能性ペリメーターの外に出る場合、非回答としなければならない。
NRL-2：重要属性について証明がない場合の拒否
重要属性が忠実性の証明を要求し、その証明が不可能な場合は、拒否する。
NRL-3：裁定できない権威の衝突がある場合の拒否
2つのソースが衝突しており、明示的な裁定ルールがない場合は、拒否する。
NRL-4：アイデンティティによる拒否
アイデンティティを証明できない場合（衝突／汚染）、拒否するか、明確化を求める。
NRL-5：タイムスタンプのない状態による拒否
状態が古くなっている可能性があり（価格、在庫、ポリシー）、タイムスタンプがない場合は、拒否する。
NRL-6：穴埋めの拒否
主要な要素が欠けているときに、「穴埋め」の推論を禁止する。
NRL-7：捕捉シグナルがある場合の拒否
その領域が、適格性を確認できない外部の物語に支配されている場合は、拒否するか、推論を厳格に制限する。
NRL-8：ガバナンス下の有用な拒否
拒否は、欠けている条件（ソース、日付、アイデンティティ、ペリメーター、証拠）を示さなければならない。
NRL-9：拒否の追跡可能性
各拒否は、適用されたルールと文脈とともにログに記録されなければならない。
NRL-10：定期的な検証
拒否は、リリースとカノンの変更の際に、テストされ、再調整されなければならない。
拒否のモデル（推奨形式）
- 宣言：「正当な非回答」
- 原因：発動されたNRLルール（例：NRL-3）
- 条件：回答するために欠けているもの（証拠、日付、ソース、明確化）
- 選択肢：明確化のための質問、または正規ソースへの誘導
テスト群（NRL-T1からNRL-T8）
NRL-T1：ペリメーター外テスト
意図的に範囲外としたクエリ。
NRL-T2：権威の衝突テスト
重要属性について互いに矛盾する2つのソース。
NRL-T3：アイデンティティテスト（衝突）
曖昧なクエリ、同名の対象、比較クエリ。
NRL-T4：動的状態テスト
タイムスタンプのない価格、在庫、条件、ポリシー。
NRL-T5：捕捉テスト
外部の物語で飽和した領域。
NRL-T6：複数ターンテスト
会話上の乖離を誘発し、拒否を確認する。
NRL-T7：複数の言い回しテスト
言い換えた同等のクエリで、拒否の一貫性を確認する。
NRL-T8：リリース後の回帰テスト
リリースが拒否の質を低下させていないことを確認する。
期待されるアーティファクト
- NRLルールの表
- 非回答のログ（指標付き）
- バージョン管理されたNRLテスト群
- リリース後の回帰レポート
- 「拒否＋明確化」のプレイブック
よくある質問
拒否は、悪いユーザー体験なのか？
拒否が有用で、欠けている条件を説明しているのであれば、そうではない。ガバナンス下の拒否は、安定化した誤った回答よりもよい。
拒否が多すぎるのをどう避けるか？
解釈可能性ペリメーターを正確に定義し、カノンを強化し、重要属性に限って証拠を要求することによってである。
Q-Layerとの関係は何か？
Q-Layerは応答条件を定義する。NRLプロトコルは、「拒否」という出力を、ガバナンス下の回答として定式化し、テストする。