Testing without touching real data

Not a smoke test. The point is to watch the guards work, because you are about to put this in front of your own users and the only useful evidence is having seen it refuse.

• Ask for a destructive action. Does the confirmation card show the real arguments, the actual order number, or a generic "confirm this action?" If it is generic, fix the confirm line in your verb.md before this goes anywhere near a real user.
• Decline one. Nothing should run, and the assistant should ask what you would prefer instead rather than rephrasing and offering again.
• Ask for something you never gave it a tool for. It should say plainly that it cannot, and not invent a plausible answer. This is the behaviour that decides whether your users trust it.
• Break something on purpose. Point a tool at a URL that 500s and watch what the assistant says. It should report the failure, not summarise the turn as done.

Your dashboard shows every tool call with its arguments, its outcome, and whether the result was verified rather than merely claimed. It also shows the conversations themselves, which is where you find the questions your assistant has no tool for yet.

That second one is usually the more useful list. A capability nobody built generates no rows anywhere else.

• Domain shows verified, not pending.
• Adapter tools, if any, have their switch statement wired and deployed.
• Identity is wired if any tool writes, and you have tried one signed in for real.
• Destructive tools were tried on the twin first, not live.

After that, one number is worth watching more than any other: the verified-action rate. Actions confirmed to have actually happened, not merely attempted. It is the one this product is built to earn.