Before you build
What you need
- A written rule with a known data source, such as an approved payee list.
- A dedicated test wallet and one small Arc Testnet action.
- A clear result to show when the rule blocks an action.
Sequence
Do it in this order
Write the rule in code
For example, allow one vendor address and refuse all other recipients. Compare against trusted application data, not text returned by the model.
Prepare a valid and invalid action
Change only the recipient between the two proposed transfers. Keep the amount, chain and input context the same.
Check the exact payload
Validate the intended recipient, contract and amount around the simulated transaction. Reject the invalid action before it reaches signing.
Confirm one and explain the other
Authorize the valid testnet action and follow it to a receipt. Show the precise rule that blocked the other action.
What to show a reviewer
A reviewer can reproduce both outcomes and inspect the rule. If no custom policy has been implemented, show the native simulation and manual-signing boundary without claiming vendor allowlisting is built in.
Keep this boundary clear
Simulation can show whether a payload executes against a pinned state. It cannot independently establish whether a vendor is real, an invoice is legitimate or a route is economically optimal.
Where to go next
Keep the first action small. If you need custom tools, start from the Aomi App guide rather than inventing an API call.