Start with a decision object
Define the proposed effect before selecting a model or data provider. A useful object identifies the account, destination, asset, maximum amount, operation, expiration, and policy version. Keep the observations supporting that proposal attached by reference. A statement such as improve allocation does not establish a spending boundary. An instruction limited to one destination and a defined amount can be inspected and rejected when its fields change.
Separate recommendation and authorization
A recommended action should remain a proposal until the applicable authority accepts it. For Ethereum typed signatures, EIP-712 defines structured signing but leaves replay protection outside the standard. The architectural consequence is to review the signature mechanism alongside the application rules that prevent duplicate or expired use. A readable payload is helpful evidence; it is not a complete permission policy. Keep the signing component independent from the component explaining the recommendation.
Give uncertainty its own state
Missing evidence, conflicting observations, expired permission, and uncertain submission describe different situations. Return a reason that tells the reviewer which boundary failed. In a hypothetical treasury workflow, a data outage might block new spending while preserving access to reports. That fallback needs its own scope. It should not introduce a new destination or silently reuse an old quote because the preferred source stopped responding.
Keep the result reviewable
Track one intent from proposal through approval, submission, and the chosen completion condition. Preserve the actual authorized fields so the eventual transaction can be compared with them. Account for outstanding intents when enforcing cumulative budgets. The decision API design article develops this workflow, including retries and negative tests. Review records should explain decisions without retaining secret recovery material or unnecessary personal information.
