> ## Documentation Index > Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # AdCP の設計思想 > AdCP の設計を支える中核原則 — それらが何を排除するのか、どんなときに反論するのが正しいのか、そしてサーフェスがまだ原則に従っていない箇所はどこか。 # AdCP の設計思想 AdCP を*使う*ためにこのページを読む必要はありません。AdCP を*拡張する*なら読む必要があります。 これはメタプロトコル — 私たちが下した判断の背後にある哲学的フレームワークです。各原則は、誰かが「このフィールドを 1 つ足すだけ」と提案した瞬間に立ち現れる、負荷を担う決定です。私たちはこれらの判断を意図的に下し、意図的に見直します。ここでの目標は、コントリビューターに十分な文脈を与え、既存の形状に適合する提案をするか、あるいは両足を地につけて形状そのものを変えることを論じられるようにすることです。 ワーキンググループに届く RFC の大半をはね返すのは 2 つの原則です: **スキーマが仕様である**、そして **タスクを追加する前に合成する**。これらが残りを支えるため、最初に置かれています。続いて 6 つの補助原則が並びます。末尾の「サーフェスがまだこれらに従っていない箇所」セクションは、私たちが認識している矛盾を挙げます — 原則は、それらについて正直である限りにおいてのみ信頼に足るからです。 各原則は同じ構造を持ちます: ルール、それを選んだ理由、それが排除するもの、そして例外パス — 原則に反論することが正しい一手となるとき。 *** ## The two principles that bounce most RFCs ### 1. The schema is the spec ドキュメントは記述し、スキーマは決定します。ドキュメントとスキーマが食い違ったとき、スキーマが勝ちます。スキーマに存在しないフィールドやタスクを拡張する提案は、2 つの主張を同時にしています — あるものが存在するという主張と、それを成長させるべきだという主張です。レビュアーは最初の主張だけではね返します。 **なぜ選んだか。** 生成される SDK はスキーマから来ます。適合性テストはスキーマから来ます。レジストリはスキーマから来ます。ドキュメントページは 1 リリース遅れても、プロトコルは依然として動きます。しかしスキーマの変更はあらゆる場所に出荷されます。スキーマはまた、AdCP が主張するクロス言語保証（TypeScript、Python、Go がすべて 1 つのソースからクリーンに生成される）を強制できる唯一の場所です。このルールの正準版については [仕様ガイドライン — 哲学](/docs/spec-guidelines#philosophy) を参照。 **これが排除するもの。** [`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) の `trusted_match` ケイパビリティオブジェクト内に `direct_sold_signals` フラグを提案すること — スキーマの実際のトップレベルキーが `adcp`、`supported_protocols`、`account`、`media_buy`、`signals`、`governance`、`sponsored_intelligence`、`brand`、`creative`、`request_signing`、`webhook_signing`、`identity`、`compliance_testing`、`specialisms` であるとき。`trusted_match` というトップレベルキーは存在せず、提案されたフラグの正しい形状は新しいバケットではなく `signals.features.signal_enforcement_on_guaranteed` です。レビュアーは、その根底にあるアイデア（完全に良いかもしれない）を評価する前に、形状が誤っているという前提だけでその issue をはね返します。 **反論が正しいとき。** スキーマに提案を置く場所が本当に欠けているとき。それを最初の主張として述べ、パス付きで新しいスキーマの位置を提案し、それからフィールドを提案してください。2 つの明確な主張は 1 つの曖昧な主張に勝ります。 → 新しいフラグを提案する前に [ケイパビリティエクスプローラー](/docs/protocol/capabilities-explorer) を使ってください。実際のスキーマツリーをたどれます。 *** ### 2. Compose with existing primitives before adding a new task すべての新しいトップレベルタスクは、それを使わない実装者でさえいずれ推論しなければならない恒久的なサーフェスです。提案する前に答えるべき問いはこうです: これは既存のタスクとその既存のモードで表現できるか？ できるなら、その提案は新しいタスクではなくドキュメントのギャップ（または欠けているフィールド）です。 **なぜ選んだか。** タスクはプロトコルの協調コストです。タスクの追加はコントリビューターが求められる最も高価なことです。なぜなら、それはすべてのセールスエージェント、すべてのバイヤーエージェント、すべての SDK、すべてのテストスイート、すべての適合性行に降りかかるからです。フィールドとモードは合成しますが、タスクはしません。リリースごとにタスクを追加して成長するプロトコルは、作者だけが頭の中に保持できるものへと老いていきます。 **これが排除するもの。** [`get_products`](/docs/media-buy/task-reference/get_products) と [`create_media_buy`](/docs/media-buy/task-reference/create_media_buy) の間に `get_price_quote` タスクを提案すること — バイヤーがターゲティングを送信しセラーが確定レートを返す、設定-価格-見積もりのステップ。その提案が求めるものの大半はすでに存在します: `account` によるアカウントスコープのレートカード、`pricing_options` による確定価格、コミット時の `pricing_option_id` ロック、反復ループのための `buying_mode: "refine"`。「新しいタスク」というフレーミングは、ターゲティングと価格がディスカバリーから欠けていると仮定しますが、欠けていません。 **反論が正しいとき。** どんな合成も望むセマンティクスに到達しないとき — 提案が、既存のどのタスクも運べない状態遷移や当事者ロールを要求するとき。ハードルは高く、それは意図的です。証拠を持ってきてください: どの既存タスクを拡張しようとしたか、なぜその拡張が機能しなかったか、拡張ではできない何を新しいタスクが加えるか。 *** ## Six supporting principles ### 3. The brief drives discovery; targeting is an input, not a step ターゲティングはバイヤーが望むものです。それは汎用カタログに対する下流のフィルターではなく、セラーがそれに*対して*キュレーションする対象です。バイヤーはブリーフ（または `wholesale + filters`）を [`get_products`](/docs/media-buy/task-reference/get_products) に送り、セラーはその意図に合わせてすでに形作られたプロダクトを、`account` パラメーター経由でバイヤーのアカウントにスコープされた価格とともに返します。反復は型付き変更配列を伴う `buying_mode: "refine"` を通じて起こります — 往復はディスカバリーに折り込まれ、後付けされません。 **なぜ選んだか。** ブリーフはバイヤーの意図の自然な単位です。パブリッシャーは、いかなる外部タクソノミーよりも自分のインベントリ、オーディエンス、レートカードを知っています。ブリーフに対してキュレーションすることで、セラーはそのすべてを 1 回の往復でレスポンスに持ち込め、その往復が価格も生み出します。ターゲティングと価格を 2 つのタスクに分割することは、1 つの専門家の判断を 2 つの過少仕様な判断に変えます。 **これが排除するもの。** プロダクトとバイ作成の間の別個の見積もりステップ。（原則 2 を参照 — 同じ RFC が両方のフィルターで落ちます。） **反論が正しいとき。** 価格が、バイヤーがまだコミットしていないフライト日程と総予算に依存するとき — 季節性、ボリュームティア、売り切り率駆動のイールド。あるいはセラーが、示唆的な価格オプションとは別に、コミットメント前に時間制限付きの確定レート（`valid_until`）を発行したいとき。あるいはバイヤーが価格を駆動したものの監査可能な説明（`rate_basis` フィールド）を必要とするとき。これら 3 つは本物のギャップであり、新しいタスクではなく `pricing_options` とディスカバリーフローへの拡張です。 → ブリーフファーストのモデルについては [ターゲティング](/docs/media-buy/advanced-topics/targeting) を参照。 *** ### 4. Capabilities are commitments, declared under existing buckets 2 つのこと、1 つの原則。**ケイパビリティがスキーマ内のどこに存在するか**: 新しいトップレベルキーではなく、既存のトップレベルドメイン（`signals`、`media_buy`、`creative`、`governance`）の下。**ケイパビリティを宣言することが何を意味するか**: アドバタイズメントではなく強制可能なコントラクト。セールスエージェントが `idempotency.supported: true` を宣言したら、適合性スイートがそれをプローブし、コントラクトはテスト可能です。宣言には作るコストがかかります。 **なぜ選んだか。** トップレベルキーはケイパビリティサーフェスの最も可視的な部分です。それぞれが、すべての読み取りですべての実装者がスキャンするカテゴリーです。サブ名前空間化は関連するケイパビリティを一緒に発見可能に保ち（`signals.features.X` は `signals.data_provider_domains` の近くに属する）、トップレベルをスキャン可能に保ちます。1 つのフラグのためにトップレベルキーを追加することは、1 枚の書式を扱うために部署を追加するようなものです。そして宣言は、有用であるために負荷を担う必要があります: プロトコルが強制もテストもできないフラグは、コントラクトではなく願望です。 **これが排除するもの。** シグナルが保証ラインアイテムとどう相互作用するかについてのフラグのために「`trusted_match` トップレベルケイパビリティキーを追加する」こと。そのフラグは `signals.features` に属します — 新しいバケットではなく `signal_enforcement_on_guaranteed: "enforced" | "best_effort" | "not_supported"` enum です。また: 誰もプローブしないことを願って、実際にはサポートしていないケイパビリティを宣言すること。適合性ランナーがプローブします。 **レビュアーテスト。** その提案は、今日スキーマにある実際のトップレベルキーを引用し、なぜそのどれも正しいホームでないかを説明したか？ 提案がその問いに答えられないなら、まだ準備ができていません。 → [ケイパビリティエクスプローラー](/docs/protocol/capabilities-explorer) は既存のツリーをレンダリングします。 *** ### 5. Trust is bilateral and `/.well-known`-rooted AdCP における信頼は双方向かつ検証可能であり、レジストリによって承認されるものではありません。オペレーターは組織アイデンティティ、エージェント、プロパティ関係、署名鍵ディスカバリーを `/.well-known/brand.json` の [`brand.json`](/docs/brand-protocol/brand-json) 経由で宣言します。パブリッシャーはどのエージェントがどのプロパティに認可されているかを [`adagents.json`](/docs/governance/property/adagents) 経由で宣言します。いずれの当事者も相手の宣言を解決し検証できます。[Registry](/docs/registry) はディスカバリーと解決を助けますが、参加をゲートしません。すべてのディスカバリーホップは決定的なパスに対する HTTP GET です — ads.txt と sellers.json が正しく捉えたモデルを、意図的に再利用しています。 **なぜ選んだか。** すべての中央集権的な信頼権威は、いずれ税になります。ads.txt と sellers.json はモデルを正しく捉えました: 宣言は公開かつ機械可読で、検証は双方向で、ネットワークは誰が数えられるかを決める単一のゲートキーパーなしに真実を発見します。AdCP は意図的にそのパターンに従います — 「well-known ブランドレジストリ」や「検証済みバイヤー」ティアを追加することは、プロトコルが置き換えようとしているまさにその ad tech 税構造を再創造します。 **これが排除するもの。** ブランド検証を中央集権的な検証問題としてフレーミングする提案 — 「どのブランドが well-known かを誰が決めるのか？」「AAO はレジストリに入れる前に brand.json 提出を検証すべきか？」。前提が誤りです: `/.well-known/` は [RFC 8615 の URI 慣例](https://datatracker.ietf.org/doc/html/rfc8615) であり、品質シグナルではありません。あるドメインの `brand.json` は、そのドメインを制御する者がそれを公開したことだけを証明します。信頼は、その証明を adagents.json、アカウントレベルの商業的関係、（必要なとき）署名付きリクエストと合成することで構築されます — 第三者がブランドリストを承認することによってではありません。 **反論が正しいとき。** 双方向宣言が*実証的に扱えない*信頼の失敗の証拠を持っているとき — 「詐欺師が自分を宣言したらどうする」ではなく、「双方向モデルが見逃す詐欺のクラスがここにあり、そのコストがここにあり、それを閉じる最小の中央集権化がここにある」。信頼の拡張は受け入れられますが、信頼の中央集権化には領収書が必要です。基盤についての未解決の問い（CDN 乗っ取り、DNS のゲーム、古い `/.well-known/` クロール）は本物です — AdCP が提供するものと明示的に提供しないものについては [Trust & Security](/docs/trust) を参照。 *** ### 6. Privacy is layered, not uniform [Trusted Match Protocol](/docs/trusted-match) は*構造的*プライバシーを持ちます — 分離されたコードパス、アイデンティティとコンテキストの結合に対するスキーマ上の禁止、独立に検証可能な相関除去。他のすべてのドメインは*契約的*プライバシーを持ちます — データを交換する当事者はアカウントの条件やユーザーの同意に拘束されます。これらは異なる保証を持つ異なるメカニズムであり、それらを混同する提案は混乱した機能を生みます。 **なぜ選んだか。** 構造的プライバシーは高価です — スキーマを制約し、分離されたインフラを要求し、可能な合成を制限します。私たちはそのコストを TMP で支払います。なぜなら TMP は、契約的機密性が届かない混合したバイヤー/セラー境界を越えて、インプレッション時に動作するからです。TMP の外では、当事者はすでに商業的関係を確立しており、契約が信頼の正しい単位です。この 2 つを交換可能であるかのように装うことは、契約的ケースを過剰設計するか、構造的ケースを過少保護するかのいずれかを意味します。 **これが排除するもの。** TMP のプライバシー保証が直接販売のアドサーバー決定に適用されると仮定する「TMP 検証済み直接販売ターゲティング」ケイパビリティを提案すること。適用されません — TMP は GAM/FreeWheel の決定フックとして設計されておらず、「直接販売について TMP をサポートするアドサーバーはない」と言うのは真だがやや誤解を招きます。なぜならそれは TMP が動作する層ではないからです。正直なフレーミングは異なります: AdCP には、セラーが保証ラインアイテムにシグナルベースのターゲティングを強制できるかどうかを宣言するプロトコルレベルのメカニズムがありません。それは `signals.features` フラグと [`create_media_buy`](/docs/media-buy/task-reference/create_media_buy) 検証ルール — 構造的プライバシー機能ではなく契約的開示機能です。 **反論が正しいとき。** クロスドメインのプライバシークレームを持ち、どのメカニズムが適用されるかを名指しできるとき。「これは契約的機能で、契約にこれが入っている」または「これは構造的機能で、それを機能させるスキーマレベルの禁止がここにある」。曖昧なプライバシー改善はどちらにも着地せず、誤った場所に落ちがちです。 → ドメインごとのメカニズム表については [Architecture — Privacy posture across domains](/docs/protocol/architecture#privacy-posture-across-domains) を参照。 *** ### 7. The protocol exposes seams; deployers wire decisions AdCP は、どのフィールドが存在し、それらについてプロトコルがどんな保証をするかを定義します。デプロイヤーのポリシーがどう強制されなければならないか、ガバナンスエージェントがどう決定しなければならないか、何が「良い」バイヤーと見なされるかは定義しません。この姿勢は 3 箇所に現れ、それらは単一の姿勢を共有します: **プロトコルは、決定が実際にどう起こるかについて現実的である — 当事者間に分散し、時間的に非同期で、プロセスにおいて人間がチェック可能。** * *ケイパビリティは宣言され、ゲートされない。* `check_governance` はシームであり、強制者ではありません。ガバナンスエージェントを設定していないセラーはそれを呼びません。プロトコルは非準拠のセラーが取引するのを妨げません。スキーマレベルの強制は存在しますがまれで、名指しされています（3.0 の `fair_housing`、`fair_lending`、`fair_employment`）。デフォルトは強制ではなく露出です。 * *非同期がデフォルト。同期は最適化。* すべての変更タスクは `*-async-response-{submitted,working,input-required}.json` の兄弟を持ちます。すべての操作が同期的でアトミックであるかのように装うプロトコルは、実際のワークフローが到着した瞬間に壊れます。 * *人間のレビューは例外的ではなくアーキテクチャ的。* 任意の変更は [タスクライフサイクル](/docs/building/by-layer/L3/task-lifecycle) を通じて人間の承認のために非同期にできます。キャンペーンガバナンスは宣言的なバイヤー側のレビューチャネルを提供します。HITL は、特定のタスクにボルト留めされた特殊ケースであるのではなく、他のすべて — 監査ログ、ガバナンスチェック、非同期レスポンス — と合成します。 関連する不変条件がアカウント境界に存在します: **作成サーフェスではなくアカウント所有権が可視性を決定する。** AdCP の外で作成されたバイも、それが該当するアカウントに属し、アカウントスコープのクエリに現れます。これは、すべての「アドサーバー上の API」を壊すシャドウ台帳パターンを防ぎます。 **なぜ選んだか。** ポリシーを出荷するプロトコルは、余計なステップを持つプラットフォームです。オープン標準の信頼性は、まさに何を決定しようとするかについての抑制です。デプロイヤーのポリシーは、コンテキスト固有の判断が属する場所でもあります — あるバーティカルでブランドセーフティ違反であるものが、別のバーティカルでは問題ないことがあり、AdCP は側につくことなくそのニュアンスを運べません。 **これが排除するもの。** 「プロトコルはケイパビリティ X に一致しないバイを拒否すべき」。多くの場合、正しい答えは「プロトコルはケイパビリティ X を可視にすべきで、デプロイヤーがバイを拒否する」です。また: 自律性と監督を対立するものとしてフレーミングすること — 「エージェンティックが真に機能するには、X がエンドツーエンドで自動化されなければならない」。ほとんどの規制された高リスクの操作について、それは私たちが望むものではなく、プロトコルが仮定するものでもありません。 **反論が正しいとき。** 非対称性が十分にひどく、デプロイヤーごとのポリシーが協調問題を解決しないとき — バイヤーとセラーが、プロトコルレベルのルールなしに強制について経済的に合意できないとき。スキーマレベルの強制はまれで獲得されるものです。それを持っているときに論じてください、最初の一手としてではなく。 → AdCP が提供するものと明示的に提供しないものについては [Trust & Security — Governance](/docs/trust#governance) を、HITL がプロトコルにどう現れるかについては [Governance — Embedded human judgment](/docs/governance/embedded-human-judgment) を参照。 *** ### 8. Reference data: own the namespace and the resolution contract, not the corpus AdCP は **名前空間**（どの分類システムが存在し、その ID の形状は何か）と **解決コントラクト**（モデルの訓練データから識別子を推論するのではなく宣言されたソースに対して名前を解決し、1 つを選ぶのではなく曖昧さをサーフェスする）を定義します。基底のコード↔名前テーブル — **コーパス** — は、AdCP 自身が値を鋳造する権威でない限り、公開しません。コードはアイデンティティであり、ワイヤー上を無損失で移動します。名前はそのコードの*レンダリング*であり、それを表示する者が、すでに保持しているルックアップからエッジで再構成します。 **なぜ選んだか。** 耐久性のある資産はコーパスではなくコントラクトです。他者の参照テーブルを公開することは、レジストリを、外部パブリッシャーを永遠に追跡しなければならない下流のミラーにします — その正しさ、リフレッシュケイデンス、ライセンスエクスポージャーを、その背後に運用機能を一切持たずに所有することになります。そして誤っているが正準なテーブルは、テーブルがないよりも悪い: エージェントは幻覚を起こし、まさに信頼すべきでないときに権威の刻印を信頼するため、古いまたは捏造されたエントリは実際の支出を静かに誤誘導します。名前は移動する必要も中央集権化される必要もありません — それは次元属性であり、一度エッジに複製されてローカルで結合されるもので、すべてのリクエストに非正規化されるものでも、ルックアップごとに中央サービスから取得されるものでもありません。 **これが排除するもの。** 正準なジオメトロレジストリ — エコシステムが真実の源泉として取得するバージョン管理された DMA `code → name` テーブル（提案され、却下された）。その提案の最初のコミットは、市場ランクで順次番号付けされた捏造コードを出荷しました — ソース権威とこのリポジトリ自身の例の両方に矛盾し、人間のレビュアーだけがそれを捕まえました。自動化された権威チェックはないため、そのエラークラスは再発します。名前はまた、プロジェクトが再配布するライセンスを持たない、独占的で商標登録されたコーパスです。プロトコルはすでに読み取り方向を正しく扱っています: `geo-delivery-metrics` は必須の `geo_code` の隣に任意の `geo_name` を運ぶため、セラーはバイヤーに素のコードから名前を再構成させるのではなく、自身のカタログからレンダリング*できます*。それは反対の過剰修正も等しく排除します — 表示名を権威あるものとしてターゲティング値にステープル留めすること。「Albany」は 2 つの異なる DMA（NY と GA）を名指します。ターゲティング値は宣言された名前空間内の ID であり、名前はせいぜい非権威的なラベルとして相乗りするだけです。 **反論が正しいとき。** AdCP 自身が値を鋳造するとき、テーブルの所有はデータ運用ではなく相互運用です — `v1-canonical-mapping.json` が正当な例です: AdCP は v1 フォーマット語彙とそれが投影する v2 正準の両方を定義し、集合は加算的（エントリは削除されず、非推奨化のみ）で、外部の権利保持者はいません。そして単一の外部権威が公開に発行するとき（ISO 3166、Eurostat NUTS、ONS ITL、CC-BY の GeoNames）、プロジェクトは来歴と再生成スクリプトを持つ薄い**生成された**ミラーを出荷*してもよい* — 明示的に非権威的な投影であり、ソースがドリフトするか 2 番目のソースが不一致になった瞬間に降格されます。ハードル: 権威を名指し、ライセンスを名指し、なぜ fetch-once-cache-locally のルックアップがそれをすでに解決しないかを説明すること。 **レビュアーテスト。** これらの値の単一の外部権威が存在するか、そしてそれは私たちか？ 外部の団体が真実を所有するなら、AdCP は名前空間と解決コントラクトを宣言し、バイトを委ねます。「誰もがこの厄介なマッピングを再実装する」はプロトコルの義務ではなく、ライブラリの機会です。 → 原則 5 と同じ反中央集権化の本能を、信頼ではなく参照データに適用したもの: [Registry](/docs/registry) は解決と発見を助けますが、エコシステムのルックアップテーブルにはなりません。 *** ## Where the surface doesn't yet follow these principles 原則は、サーフェスがまだそれらに違反している箇所を私たちが名指しする限りにおいて信頼に足ります。これらは既知で追跡されています。 **`media_buy.execution.trusted_match`（原則 4）。** ケイパビリティスキーマは TMP 関連のフラグを `media_buy.execution.trusted_match` の内側に置きますが、アーキテクチャページは TMP を Media Buy、Creative、Signals と並ぶ対等な取引ドメインとして扱います。これらの原則を使って提案を評価するレビュアーは、TMP 形状のフラグがどこに属するかについて矛盾する答えに行き着きます。スキーマのサブ名前空間化は正しかった（原則 4 に従い）。親の位置が未解決の問いです。TMP ケイパビリティ宣言への変更を提案する RFC は、これが俎上に載ることを予期すべきです。 **`axe_integrations` と `axe_include_segment` / `axe_exclude_segment`（原則 1 と [spec-guidelines のベンダー中立ルール](/docs/spec-guidelines#platform-agnosticism)）。** これらは v3 スキーマに規範的フィールドとして生き残っています。AXE は Scope3 起源のブランドです。spec-guidelines テストによれば、これらは 3.0 GA の前に `ext.axe` へ移動するか `trusted_match` によってクリーンに置き換えられるべきでした。これらは安定した形状ではなく進行中の非推奨化を反映しています — これらのフィールド上に構築する提案は、それらが移動することを予期すべきです。 **「ドメインでないがこのエージェントがすること」のための 3 つのトップレベルキー（原則 4）。** `compliance_testing`、`experimental_features`、`extensions_supported` はそれぞれ、関連するが異なる形状のケイパビリティメタデータをトップレベルに運びます。レビュアーはなぜこれらが統合されないのかを問うでしょう。 **3 つの署名関連トップレベルキー（原則 4）。** `request_signing`、`webhook_signing`、`identity`（オペレーター JWKS）はすべて署名インフラのメタデータです。1 つの関心事のための 3 つのトップレベルキーは、まさに原則が警告する「スキャン可能なトップレベル」のコストです。 **信頼基盤（原則 5）。** 3.x における信頼は trust-on-first-use であり、各当事者の `/.well-known/` + DNS + CDN に根ざしています。鍵の透明性は 4.0 に延期されています。ads.txt と sellers.json は、まさにこの攻撃クラスによって何年もゲームされてきました。原則は正しいですが、基盤はまだ原則が値するものではありません。明示的なギャップ声明については [Trust & Security](/docs/trust) を参照。 これらは、鋭い第三者レビュアーが初読で指摘するサーフェスの矛盾です。正直な答えは、いくつかは進行中の非推奨化、いくつかは未解決、そして少なくとも 1 つ（信頼基盤）は負荷を担う 4.0 の作業だということです。ここで名指しすることが原則を信頼に足るものに保ちます。 *** ## How to use this page RFC を起草しているなら、タイトルを書く前に原則を通して作業してください。はね返される提案の大半は、最初の 2 つのいずれかではね返されます — 存在しないフィールドを提案する（原則 1）、または既存タスクとモードで表現可能な振る舞いのために新しいタスクを提案する（原則 2）。[ケイパビリティエクスプローラー](/docs/protocol/capabilities-explorer) は実際のスキーマツリーをレンダリングします。新しいトップレベルキーを提案する前にそれをチェックしてください。 RFC をレビューしているなら、原則はトリアージフィルターも兼ねます。どの原則に反論しているか、そしてなぜかを名指しする提案は仕事をしています。原則が適用されると認識しない提案は通常、起草の前にカバレッジ主導の返信を必要とします。 原則は不変ではありません。それぞれは特定のトレードオフに対して選ばれ、それぞれはトレードオフがシフトしたときに再交渉の対象です。しかし再交渉は RFC の仕事であって、その副作用ではありません — それに依存する変更を提案する前に、変更のコストを名指ししたうえで、ルールを変えることを明示的に論じてください。