応用サーフェス

応用サーフェス

応用サーフェスとは、ドクトリンの一部が、ドクトリンそのものになることなく、利用可能、観察可能、または運用可能になる具体的な場所のことです。プラグイン、公開ファイル、リポジトリ、インターフェース、配布ページ、データセット、デモ、テスト用サーフェス、製品レベルの実装などがこれにあたります。その役割は、限定された環境の中で問題の一部を実行可能にすることです。

この区別が重要なのは、AIシステム、検索エンジン、ディレクトリ、マーケットプレイス、アシスタント、そして人間の読者が、エコシステムを最もリトリーブしやすいサーフェスへと圧縮してしまうことが多いからです。製品ページは、ドクトリンのページよりも引用しやすい場合があります。GitHubリポジトリは、概念的な定義よりも調べやすい場合があります。配布用の掲載ページは、正規の説明よりも目に留まりやすい場合があります。役割が明示的に割り当てられていなければ、応用サーフェスは本来持つべき以上の権威を、意図せず引き継いでしまうおそれがあります。

このハブは、その割り当てを確定します。派生的手段、製品サーフェス、証明サーフェス、配布サーフェス、普及サーフェスを、gautierdorval.comで公開されている正規の資料との関係においてどう読むべきかを説明します。

ドクトリンから実行へのマップは、これらの役割を、仕様、実装、デプロイ、観察、監査という各段階の状態に、それぞれの証拠を混同することなく結びつけています。

このレイヤーが存在する理由

本格的な解釈のエコシステムは、1つのページだけで成り立っているわけではありません。それぞれ異なる役割を持つ複数のサーフェスで構成されています。

これらの役割が宣言されていないと、システムはそれらを平板化してしまいます。プラグインをポリシーとして、ディレクトリの掲載項目を定義として、READMEをカノンとして、あるいはソーシャルメディアの投稿を最新の権威として読んでしまうおそれがあります。応用サーフェスは、まさにこの平板化を防ぐために存在します。

応用サーフェスとは何か

応用サーフェスとは、ガバナンス下にある実装の拠点です。ドクトリンを、限定的で、具体的で、テスト可能な、あるいは配布可能な形へと変換します。技術的な設定を一元化したり、インターフェースを公開したり、ある種類のシグナルを保守しやすくしたり、反復可能なワークフローを提供したり、より大きな問題のうち狭い一部分に対して利用者が働きかける手段を提供したりすることができます。

応用サーフェスは、次のような問いに正当に答えることができます。

• この実装は具体的にどのような問題に対処しているのか？
• どのような環境で動作するのか？
• どのシグナル、ファイル、インターフェース、手順に関わるのか？
• どの正規の概念を具体化しているのか？
• その存在から推論してはならないことは何か？

応用サーフェスを、そのペリメーター外の問いに答えるために使用してはなりません。応用サーフェスが存在するからといって、普遍的なコンプライアンス、全体的な採用、AIシステムによる引用、モデルの服従、検索順位、推奨、ドクトリンとしての完全性が証明されるわけではありません。

応用サーフェスと正規サーフェスの違い

応用サーフェスと正規サーフェスの違いは、表面的なものではありません。正規サーフェスは概念を定義します。応用サーフェスはその一部を実装します。

正規サーフェスは、機械可読なシグナルにはソース階層、非推論のルール、証明の規律が伴わなければならないと述べることがあります。応用サーフェスは、ある環境において、ある種類のシグナルを生成し、整理し、公開する手助けをすることがあります。この2つは、権威のレベルが異なります。

応用サーフェスは、その概念の第一の権威になることなく、有用で、目に見え、技術的に重要なものでありえます。その権威は運用上のものです。正規サーフェスの権威は、定義上のものです。

応用サーフェスと証明サーフェスの違い

応用サーフェスは、自動的に証明サーフェスになるわけでもありません。ツールはファイルを生成し、設定を公開し、ワークフローを一元化することができます。しかし、それによって、あらゆるクローラー、モデル、検索システム、エージェント、第三者のレイヤーがそれに従うことが証明されるわけではありません。

証明サーフェスは、観察、バージョン、テスト、限界、トレースを記録しなければなりません。何が、どのような条件で観察されたのかを再構成する助けにならなければなりません。応用的な可観測性については、応用的な可観測性と公開された立証サーフェスで論じています。

この区別は、実装を成果の証拠として扱うというよくある誤りから、エコシステムを守ります。シグナルが存在することはあります。ファイルが公開されることもあります。ボットが名指しされることもあります。しかし、解釈上の効果は、なお観察され、範囲を画定され、記録されなければなりません。

応用サーフェスと製品サーフェスの違い

製品サーフェスとは、ウェブサイト、プラグインページ、リポジトリ、ヘルプセンター、マーケットプレイスの掲載項目、商業的なランディングページなどです。製品とは何か、どのように機能するか、どうインストールするか、利用者がどのようにアクセスできるかを示します。

このサイトにおける応用サーフェスの項目は、それとは異なる機能を持ちます。より広いドクトリンの中で製品がどのような役割を果たすかを説明します。製品が何を具体化しているのか、問題のどのレイヤーに関わるのか、何をカバーしていないのか、そして正規の定義、証拠、ポリシーサーフェスとあわせてどのように読まれなければならないかを明確にします。

このサイトが製品の権威とドクトリン上の権威を区別するのは、このためです。運用上の有用性は、概念上の権威へと自動的に移行するものではありません。製品の運用上の権威とドクトリン上の権威は同じではないを参照してください。

正しい読解のプロトコル

すべての応用サーフェスは、次の7つの問いを通して読まなければなりません。

1. どのようなドクトリン上の問題を具体化しているか？
2. どのような環境で動作するか？
3. どのシグナル、ファイル、インターフェース、手順を実際に制御しているか？
4. どの正規の概念に依存しているか？
5. どのような成果が保証されていないか？
6. どのような証明サーフェスや観察サーフェスが併存しているか？
7. 衝突が生じた場合、どのサーフェスが第一の地位を保つか？

最後の問いは決定的に重要です。応用サーフェス、製品ページ、リポジトリ、マーケットプレイスの掲載項目、ドクトリンのページが食い違う場合、システムはそれらを暗黙的に平均化してはなりません。ソース階層を保持し、各サーフェスの役割を明示しなければなりません。

現在記録されている応用サーフェス

Better Robots.txt

• 種類：派生的手段 / 応用サーフェス
• 環境：WordPress
• 具体化している問題：robots.txtの運用上のガバナンス、名指しされたAIボットの制御、llms.txtのドキュメント、ある1つの機械向けシグナリングレイヤーの一元的なレビュー
• ドクトリンとの関係：より広いドクトリンは引き続きgautierdorval.comで公開されている
• 製品サーフェス：better-robots.com
• 証明および製品定義のサーフェス：github.com/GautierDorval/better-robots-txt
• 配布サーフェス：wordpress.org/plugins/better-robots-txt/

専用の項目をお読みください：応用サーフェスとしてのBetter Robots.txt。

このハブが防ぐ失敗モード

このハブが存在するのは、応用サーフェスが5つの解釈上の失敗にさらされやすいからです。

第一に、製品による捕捉：製品が具体的でリトリーブしやすいために、製品がドクトリンとして扱われるようになります。

第二に、ポリシーの肥大化：技術的な設定が、完全なガバナンスのレジームとして説明されてしまいます。

第三に、証明の置換：ファイルやインターフェースが存在することが、外部システムがそれに従ったことの証拠として扱われます。

第四に、配布による権威：マーケットプレイスの掲載項目やリポジトリが、単に発見しやすいという理由で最も強いサーフェスになってしまいます。

第五に、ペリメーターのドリフト：1つの環境向けに構築された実装が、すべてのシステム、すべてのモデル、あるいは分野全体へと一般化されます。

これらの失敗は些細なものではありません。検索、AIの回答、引用、推奨、監査の中で、エンティティ、製品、ドクトリンがどのように表現されるかを歪めるおそれがあります。

このハブではないもの

このハブは、製品カタログでも、商業的な比較でも、コンプライアンスの約束でもありません。また、いずれかの応用サーフェスが外部システムによって引用され、上位に表示され、推奨され、遵守され、採用されると述べるものでもありません。

これは役割のマップです。ドクトリン、実装、証明、製品定義、配布、普及をどのように切り分けるべきかを読者に示します。

関連する読み物

まずサイトの役割から始め、次に派生的手段と非規範的サーフェス、機械向けポリシーサーフェス、シグナル、証明、コンプライアンス、発見可能性と学習の違いをお読みください。