モジュール XIV — 内部カタログとマーケットプレイス

モジュール XIV は組織の内部カタログ — 全社で再利用が承認されたエージェント、MCP サーバー、スキル、テンプレート、モデル、サードパーティコネクターの、キュレーションされガバナンスされたレジストリです。estate が場当たり的なコピーではなく、精査されバージョン管理されたケイパビリティに標準化できるよう、そして「承認済み」が wiki の中の言葉ではなく検証可能な何かを意味するよう、存在します。Intelligence レイヤーに位置し、作用サーフェスを持ちません: キュレーションし記録する一方で、プロビジョニングは別の場所で起こります。

それは何か

カタログはレジストリであって、ドキュメントストアではありません。エントリーは、再利用可能なケイパビリティの、キュレーションされバージョン管理された一つの定義であり、agent、mcp、 skill、template、model、connector のいずれかの種別を持ちます。各 (kind, slug, version) はそれ自身が不変のアーティファクトです — 新しいバージョンの公開は新しいエントリーを作成し、承認と署名はバージョンごとに行われます。エントリーは固定されたライフサイクルを進みます:

draft → pending → approved → deprecated

draft のみが可変です; 承認はそれを凍結します。エントリーのスペックはオペレーターが作成した定義 — トランスポート、モデル、プロンプトの参照、スコープ、そしてシークレットへの参照 — であって、決して資格情報の値ではありません。作成／承認パスはインライン資格情報を運ぶスペックを拒否するため、このモジュールは定義、参照、ガバナンスメタデータを格納し、シークレットやペイロードを決して格納しません。

バージョン管理、凍結、署名

承認こそが「承認済み」を検証可能にする場所です:

コンテンツハッシュ。 承認時、エントリーは、その正規かつ決定論的にシリアライズされた前像に対する SHA-256 コンテンツハッシュでピン留めされます。オペレーターが作成したすべてのフィールドがカバーされるため、承認済みエントリーのその後のいかなる変更も検知可能です — 署名がなくても改竄検知可能です。
台帳証明。 承認は追記専用でハッシュチェーン化された監査台帳に記録され、それを承認した 実際のプリンシパルに帰属されます。
Ed25519 署名。 カタログ署名鍵がプロビジョニングされている場合、承認はコンテンツハッシュに対するデタッチド Ed25519 署名も生成し、公開鍵と短いフィンガープリントを伴います — 「承認済み = 検証可能」。署名鍵はエンジンのフェイルクローズドな鍵シームの下、ブート時にロードまたはミントされ、監査台帳鍵とは独立しています; このモジュールは自身のカタログ鍵を所有し、エンジンの内部監査署名者に到達することは決してなく、トラスト境界をクリーンに保ちます。

検証はハッシュを再計算し、ノードに鍵が設定されている場合は署名をトラストアンカーとして扱います: 剥がされた署名（ダウングレード）や他の鍵で作られた署名（差し替え）は not verified として報告されます。GET …/pubkey は署名が有効かどうかを報告します; エントリーごとの verified / signed / signed_by の状態は、エントリールートと検証ルートによって返されます。

検証済みサードパーティコネクター

connector エントリーは、リリースされたサードパーティコネクタープラグイン — ビルドされたバイナリまたは OCI アーティファクト — をキュレーションします。そのスペックは、キュレーション対象を記録します: アーティファクトの sha256（artifact_digest）、リリース／OCI 参照、パブリッシャー、コネクターのディスクリプター名。エントリーは外部コネクターエコシステムのテナント向け認証記録 です: 「承認済み」を、単に「誰かが承認をクリックした」ではなく「そのサプライチェーン証明が検証された」を意味させることができます。

このフローは MCP エントリーのアドミッションペアを反映し、独自のポリシーと判定の記録を持ちます（エビデンスは種別ごとにカウントされるため、コネクターの判定が MCP の判定とテーブルを共有することは決してありません）:

GET/PUT …/connector-admission/policy — テナントごとのトラストルート: require_signed、オプションの require_subject_digest、Sigstore のアイデンティティ／発行者のピン、ベアな公開鍵、CA ルート、そして in-toto のプレディケート許可リスト（デフォルトは SLSA provenance v1/v0.2 と SPDX/CycloneDX の SBOM — コネクターはモデルウェイトではなくビルドされたアーティファクトであるため、provenance と SBOM の形）。ポリシーがなければ観測モード — テナントがオプトインするまで何もゲートされず、ポリシーエンドポイントは誠実にそう述べます。
POST …/entries/{id}/admit — エントリー種別（mcp または connector）でディスパッチされる一つの共有ルート: オペレーターが供給した Sigstore 証明バンドルを検証し、エントリーごとに一つの claim 対 verified の判定を記録します。リクエストが expected_digest をピン留めしない場合、バインディングはエントリーの spec.artifact_digest からデフォルト化されます — エントリーは自身がキュレーションするアーティファクトを名指すため、明示的にオーバーライドされない限り、アドミッションはそのアーティファクトにバインドされます。不正な形式のバンドルは 400 です; 整形式だが検証に失敗するバンドルはエラーではなく、記録された否定判定です。
GET …/connector-admissions — 記録された判定。エントリー（entry_ref）でフィルタ可能で、検証済み判定に限定可能（verified=true）。
デナイクローズドな承認ゲート。 require_signed がオンのとき、コネクターエントリーは、 エントリーが現在キュレーションしているダイジェスト（spec.artifact_digest）にバインドされた検証済みの provenance/SBOM アドミッション判定があるときにのみ承認（したがって検証済み コネクターとして掲載）できます; require_subject_digest がオンのとき、そのアーティファクトバインディング自体が確認されなければなりません。アドミッション後にキュレーション対象のダイジェストを編集するとゲートは無効化されます — 新しいアーティファクトに対する再アドミッションが必要です。

ガバナンス下のセルフサービス・インスタンス化

インスタンスは、承認済みエントリーをインスタンス化するセルフサービスのリクエストです — 承認済みエントリーのみがインスタンス化できます。このモジュールはリクエスト、そのプロベナンス （どのエントリーバージョンに由来するか）、そのターゲット、そのガバナンスステータスを記録し、健全なステートマシン（requested → approved/rejected → active）を強制します。誰が承認してよいかを 決定せず、プロビジョニングも行いません: 承認の決定はガバナンスに、実際のプロビジョニングはデプロイメントに属します。承認、非推奨化、署名、インスタンス化は、実際のプリンシパルに対して 特権的で、RBAC でゲートされ、自己監査されるアクションです。

作用なし、プロビジョニングなし。 モジュール XIV はリクエストを記録しガバナンスします; ケイパビリティを立ち上げることは決してありません。承認の決定はガバナンスのもの、配線はデプロイメントのもの — そしてそこでのライブな apply/retire 自体がデナイクローズドなシームです（エグゼキューターがプロビジョニングされるまで 503）。誠実さと限界を参照。
署名は本物だが鍵に依存する。 Ed25519 署名は実装されており、署名鍵はブート時にデフォルトオンでプロビジョニングされます。鍵が設定されていない（または無効な鍵の）ノードでは、承認済みエントリーはハッシュでピン留めされ台帳で証明されるが未署名です — API は署名が存在すると示唆するのではなく、signing_enabled/signed を通じて誠実にそう述べます。
キュレーションであって、観測ではない。 カタログはイベントバスを購読も発行もしません; ライブな観測から導出されるのではなく、人々が API を通じて投入します。組織が再利用のために承認した ものを主張するのであって、現在実行されているものを主張するのではありません。
このモジュールは承認ポリシーを強制しない。 ステートマシンと RBAC の動詞ティアを強制します; 誰がどの条件下で承認してよいかはガバナンスが決定します。