AI Beneficiaries and Payers

Declare benefit, not payment

beneficiaryUserIds is the exact list of human users who benefit from one AI generation. It must be non-empty, sorted, duplicate-free, contain at most 64 IDs, and contain only current non-spectator participants. User IDs are not entity IDs. The platform validates the complete list and never silently filters it.

Typical choices are:

• group output: every human controller whose play benefits from the result;
• personal advisor, suggested actions, or action review: the requesting human;
• game-wide simulation: all current human participants who benefit;
• automated utility work: the humans whose gameplay receives that decision.

Connection state does not decide semantic benefit. Use the trusted beneficiary list supplied in the workflow context rather than rebuilding participation from UI presence.

The platform chooses payers

Creators cannot set payer identities, resources, or shares. The game's platform-owned billing structure resolves payment:

• token_split assigns equal obligations to the beneficiaries;
• random deterministically selects one beneficiary;
• host assigns the obligation to the durable game owner.

Acceptance is all-or-nothing. After trusted validation and payer resolution, the call freezes its beneficiaries, payer obligations, model, price, policy, and request fingerprint. A later disconnect, spectator transition, ownership change, reset, or game deletion does not rewrite that accepted responsibility.

Changed intent means a new call

Transport redelivery of the same workflow attempt reattaches to or replays that attempt; it does not dispatch and bill another generation. Changing the prompt, tools, fidelity, or beneficiary list is different intent and must create a new workflow attempt. If the workflow deliberately retries, link the new attempt with retryOfAttemptId as described in failures and retries.