ガバナンスの責任: バイヤー対セラー
キャンペーンガバナンスは、トランザクションの 2 つの異なる位置から同じcheck_governance タスクを使います。バイヤー側オーケストレーターはアクションを送る前に意図をチェックします。セラーはコミットまたは配信変更の前に実行をチェックします。両方のチェックはバイヤーの構成されたガバナンスエージェントに行きますが、異なる証拠を運びます。
ロール
セットアップ: セラーをガバナンスエージェントにバインドする
セラーがセラー側チェックを行える前に、バイヤーアカウントはsync_governance 経由でガバナンスエージェントエンドポイントをセラーと同期しなければなりません。これはアカウントセットアップであり、バイごとの交渉ではありません。
セラーは、アカウントの構成されたガバナンスエージェントエンドポイントと認証情報を保存します。後で、統制リクエストが到着したとき、セラーはどこで check_governance を呼ぶかを知ります。
バイヤー側の意図チェック
バイヤー側オーケストレーターは、統制プランの支出コミットアクションごとの前にcheck_governance を呼びます。
意図チェックは以下を送ります:
ガバナンスエージェントが
approved または conditions を返す場合、governance_context トークンを返します。オーケストレーターはそのトークンをセラーに送るリクエストに添付します。レスポンスが conditions の場合、オーケストレーターは進む前に条件を適用して再チェックしなければなりません。
セラー側の実行チェック
セラーが統制された支出コミットリクエストを受け取ると、アクションを確認する前に独立した実行チェックを行います。 セラー側チェックは以下を送ります:
セラーはバイヤーの意図チェックをそれ自体で十分と扱ってはなりません。セラーは実際に配信するものをチェックします。それは在庫可用性、セラーのデフォルト、実装制約のためバイヤーのリクエストと異なりうる。
ガバナンスエージェントが実行チェックを拒否する場合、セラーは進んではなりません。ガバナンスエージェントが条件を返す場合、セラーは計画された配信を調整し確認前に再チェックしなければなりません。
結果報告
セラーが応答した後、バイヤー側オーケストレーターはreport_plan_outcome を呼びます。これはガバナンスエージェントが承認されたアクションをセラーの実際の応答と照合し、確認された結果から予算状態を更新できるようにします。
結果報告は、ガバナンスエージェントが試みられたアクションをコミットされた支出として数えることを防ぐものです。ガバナンスエージェントは実際に起こった状態を追跡します。
よくある間違い
最小シーケンス
- バイヤーが
sync_governanceでアカウントにガバナンスを構成。 - バイヤーが
sync_plansでプランを作成または更新。 - バイヤーが
toolとpayloadでcheck_governanceを呼ぶ。 - バイヤーが
governance_contextでセラーリクエストを送る。 - セラーがコンテキストを検証し
plan_id、caller、planned_deliveryでcheck_governanceを呼ぶ。 - セラーがガバナンス判定に基づいて確認、拒否、または調整。
- バイヤーがセラー結果で
report_plan_outcomeを呼ぶ。
check_governance タスクリファレンス を、ライフサイクルとトークン検証詳細については キャンペーンガバナンス仕様 を参照してください。