基礎

MissionWeaveProtocol 0.1

ステータス: ドラフト標準、バージョン 0.1.0。

このドキュメントでは、MissionWeaveProtocol のバージョン 0.1 を定義します。キーワード MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、 SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、およびこの文書の OPTIONAL は、ここに示されているようにすべて大文字で表示される場合にのみ、BCP 14 で説明されているように解釈されます。

1. 目的と範囲

MissionWeaveProtocol は、1 つの信頼できる Organization 内で動作する自律エージェント用のグループ指向の連携プロトコルです。これにより、Agent は多くの Mission グループに同時に参加し、ピアと永続的なメッセージを交換し、Group ごとのキューに明示的な WorkItem を受け入れ、グループ全体でそれらの WorkItem をスケジュールし、検証可能なアーティファクトを公開し、完了したミッションについて人間の承認を得ることができます。

MissionWeaveProtocol は、Agent から Agent への RPC ではありません。エージェントは会話のピアであり、MAY はいつでもメッセージまたは WorkItem 提案を開始します。それにもかかわらず、構造化された権限は明示的です。Message は副作用を許可することはなく、組織のインフラストラクチャは Mission の状態を変更するすべてのコマンドを検証します。

MissionWeaveProtocol 0.1 は以下を標準化します。

Agent ID、Agent カード、プレゼンスレコード、およびランタイムフェンシング。
Mission ごとに 1 つの一時的な Group と 1 つの単調な Event 履歴。
交換可能な Coordinator と人間の MissionOwner;
Membership、会話、メッセージ、作業項目、作業契約、成果物、Evidence、コンテキストパッケージ、リース、予算、承認。
耐久性のあるコマンド、不変のイベント、リプレイ、確認応答、冪等性。
Group ごとの Worker キューと、プライバシーを保護する Group 間スケジューリング信号。
複雑な分解のための再帰的なサブタスク。
認証された WebSocket-over-TLS バインディング上の正規 JSON。そして
管理された拡張プロファイル。

MissionWeaveProtocol 0.1 では、組織間のフェデレーション、物理ピアツーピアルーティング、Group エンドツーエンド暗号化、分散コンセンサス、モデルプロンプト、プライベートモデル推論、ナレッジベース API、 Artifact オブジェクトストア API、または Organization のポリシーおよび認可サービスの実装。

2. 規範的な参照とデータの規約

MUST の実装は、参照されている場合、次の外部仕様に従います。

RFC 2119 および RFC 8174 (BCP 14)、規範的な言語。
RFC 3339、タイムスタンプ。
RFC 4648 セクション 3.2、3.5、および 5、正規のパディングされていないbase64url。
RFC 6455、WebSocket;
RFC 7493、インターネット JSON (I-JSON);
RFC 8446、TLS 1.3;
RFC 8785、JSON 正規化スキーム (JCS);
RFC 8032、Ed25519;
JSON スキーマドラフト 2020-12;そして
構造化プロトコルエラーに関する RFC 9457 原則（該当する場合）。

すべてのプロトコルオブジェクト MUST は有効な JSON です。永続プロトコルオブジェクト MUST は、schemas/ の JSON スキーマに準拠しており、すべてのプロトコルタイムスタンプ MUST は RFC 3339 になります。 date-time。 MissionWeaveProtocol 0.1 では、Signed Document 検証プロファイルに決定論的なタイムスタンププロファイルが使用されます。セクション 6.4 でカバーされる Signed Document のすべてのタイムスタンプ、およびその文書の検証に使用されるすべての Registry または信頼できる受け入れタイムスタンプ、MUST は、次の追加ルールを満たします。

暦年は 0001 から 9999 までの包括的な範囲内にあり、グレゴリオ暦の日付は有効です。
2 番目は 00 から 59 までの包括的な範囲内にあります。うるう秒の綴り v0.1 ではサポートされていません。
オプションの小数秒には、1 つ以上の ASCII 数字が含まれます。切り捨てや四捨五入を行わずに即座に比較します。そして
RFC 3339 不明なローカルオフセットスペル -00:00 は許可されません。

大文字と小文字を区別しない T 区切り文字、Z 指定子、および完全な RFC 3339 数値オフセット範囲は、後のルールでより狭いスペルが必要でない限り、引き続き有効です。汎用 JSON スキーマ date-time 検証は必要ですが、このタイムスタンププロファイルを確立するには十分ではありません。実装 MUST は、解析された瞬間とは独立してシリアル化されたタイムスタンプテキストを保存し、MUST NOT はハッシュまたは署名検証の前にそれを書き換えます。存在しない小数秒はゼロであり、後続のゼロの数字は表される瞬間を変更しません。セクション 6.4 ではさらに、保護された署名時刻と signature.createdAt が大文字の Z 接尾辞を使用し、バイトごとに同一であることが必要です。

JCS 入力 MUST は、RFC 8785 および I-JSON データモデルに従います。 JSON の数値 MUST は、有限の IEEE 754 binary64 値として解釈され、RFC 8785 ECMAScript の最短往復形式でシリアル化されます。任意精度の数値 MUST を使用する実装では、同じ正しく丸められた binary64 変換が適用され、MUST NOT は署名バイトにおけるホスト固有の特別な精度を保持します。有限の binary64 ドメイン外の値、またはペアになっていない Unicode サロゲート MUST を含む文字列は、正規のバイトが出力される前に、JCS データモデルのエラーとして拒否されます。

Base64url 値 MUST は、RFC 4648 URL セーフアルファベットを使用し、= パディングを省略し、未使用のパッドビットをゼロとして使用します。デコーダー MUST は、予期されたバイトにデコードされる場合でも、非正規のスペルを拒否します。 v0.1 MUST のコンテンツハッシュでは、小文字の 16 進数 SHA-256 と形式 sha256:<64 hex digits> が使用されます。シーケンス、リビジョン、エポック、およびバジェットに使用される整数 MUST は負ではない安全な整数である JSON 。 Group Event シーケンスは 1 から始まります。

識別子 MUST は識別子の種類内でグローバルに一意である必要があり、MUST は IRI のみのスペルではなく絶対 RFC 3986 URI としてシリアル化されます。非 ASCII 文字 MUST は UTF-8 パーセントでエンコードされ、検証 MUST は完全な文字列を消費します。空白、制御文字、および末尾の行終端文字は無効です。 UUID 識別子 SHOULD では、小文字の urn:uuid: 形式が使用されます。実装 MUST は、発行側 Organization によって選択された URI 正規化ルールに従って識別子をバイトごとに比較します。受信者 MUST NOT は追加の正規化を考案します。

規範的なスキーマ内のすべての format キーワードはアサーション要件です。 MUST の実装により、これらのキーワードを注釈として扱うのではなく、uri および date-time を含むドラフト 2020-12 形式の検証が有効になります。

3. 用語と役割

../CONTEXT.md

のドメイン用語集は標準的なものです。次の役割ルールにより、その語彙が洗練されます。

Organization は、v0.1 における唯一の信頼およびガバナンスの境界です。
Agent は、最大 1 つのアクティブなランタイムセッションを持つ、安定した 1 つの ID です。水平スケールアウトは、個別に登録された Agent ID で表現されます。
MissionOwner は、指示、承認、および通常のキャンセルに責任を負う Group メンバーです。ルート Mission では人間が担います。サブタスクでは、ルートの人間が負う責任のもとで Parent Coordinator がこの役割を担います。

Coordinator は、更新可能なロールリースを保持する Agent です。1 つの Mission につき、一度に正確に 1 つの Coordinator Epoch がアクティブであることを MAY 許可します。

Worker は、WorkItem を自身のスケジューリングキューに受け入れる Agent です。同じ Agent が複数の Group で Worker になることを MAY 許可します。

Group Authority は、セッションを認証し、Membership とポリシーを検証し、構造化された遷移をシリアル化して Event を追加する Organization インフラストラクチャです。これはセマンティックマネージャーではなく、Agent が何を言うべきか、どのように推論すべきかを決定しません。

Group Authority は、Group ごとに 1 つの論理権限です。実装 MAY はそれを内部的に複製しますが、コンセンサス、リーダー選出、レプリカトポロジ MUST NOT は MissionWeaveProtocol セマンティクスとして公開されます。この選択により、エージェントがスプリットブレイン実行を社会的に解決する必要がなく、決定的な排他的所有権が提供されます。

4. コアの不変条件

準拠する実装 MUST は、次の不変条件をすべて保持します。

Mission が 1 つ、Group が 1 つ。 各 Mission は、プライマリ Group を 1 つだけ所有し、各プライマリ Group は、正確に 1 つの Mission に属します。

会話は権限ではありません。 Message、メンション、概要、Context Package、またはモデル出力 MUST NOT は、それ自体でツール呼び出し、ビジネスを承認します。アクション、WorkItem 割り当て、予算支出、または権限付与。

構造化された実行権限。 結果的なアクション MUST が接続されます。承認された WorkItem、現在の所有権エポック、有効な実行リース、該当するポリシーの承認、およびスコープ付き機能トークンにアクセスします。

1 つのアクティブなランタイム。 状態を変更する Agent Command MUST は現在の Session Epoch を保持します。より低い Epoch の Command は、WebSocket が接続されたままでも MUST 拒否されます。

排他的な作業はフェンスで囲まれています。 現在の所有権エポックは最大 1 つしか存在しません。排他的な WorkItem。古いエポック MAY の結果は、権限のない Evidence として保持されますが、MUST NOT によって WorkItem が完了します。

追加専用の履歴 受け入れられたイベントとコミットされたメッセージは次のとおりです。不変。修正、撤回、編集、取り消し、修復は新しいイベントです。
Group ごとの注文のみ。 すべての Group には 1 つの単調 Event シーケンスがあります。MissionWeaveProtocol は、グループ全体にわたるグローバルな順序やアトミックなトランザクションを定義しません。

少なくとも 1 回の配信。 イベント MAY は複数回配信されます。安定した識別子と冪等処理 MUST により、受け入れられた各状態遷移が 1 回観察可能になります。

Mission の分離。 Mission のコンテンツ、認証情報、中間状態、および Agent メモリは、デフォルトでは Group スコープです。 Group 間の開示 MUST は明示的かつ許可されている必要があります。

人間による最終承認。 ルート Mission は、MissionOwner は、正確な Mission リビジョンと Artifact セットを承認します。 Coordinator レビューは最終的な人間による Approval ではありません。

予算と権限は下方に絞り込まれます。 WorkItem およびサブタスクの予算、機能、リソース権限 MUST NOT が親の許可を超えています。

プライベート Mission サイドチャネルはありません。 Mission 関連の Agent 通信 MUST は、Mission Group に記録されるか、Coordinator および MissionOwner に表示される、リンクされたアクセス制御された会話に記録されます。

プライベート推論の要件はありません。 エージェント MUST は決定、入力、監査に必要な証拠、阻害要因、結果。 MUST NOT は、プライベートな思考連鎖、非表示のプロンプト、または生の内部メモリを公開するために必要です。

5. システムアーキテクチャ

MissionWeaveProtocol デプロイメントには少なくとも以下が含まれます。

Organization によって制御される Agent Registry;
Group Authority ストアと耐久性のある Group Event ストア。
ポリシーを評価し、機能トークンを発行する認可サービス。
1 人以上の独立してスケジュールされたエージェント。
Artifact ストレージはコンテンツハッシュによってアドレス指定されます。そして
Mission ディレクティブ、監視、介入、および Approval。

権威ある状態は、Mission、Membership、WorkItem、Ownership Epoch と Lease Epoch、重複排除レシート、Approval、および Group Event で構成されます。Agent のローカルカーソル、Group ごとのキュー、checkpoint、outbox、inbox、および scheduler 状態は再構築可能な projection です。Agent のローカルデータベースの喪失は、権威ある Mission 状態を MUST NOT 変更します。

PostgreSQL および Agent ローカル SQLite は、v0.1 リファレンス実装の場合は RECOMMENDED であり、コンテンツアドレス指定されたオブジェクトストレージはアーティファクトの場合は RECOMMENDED です。これらの製品はワイヤプロトコル要件を満たしていません。