Test the model against a real business process
A meaningful test starts with a real decision, not a feature checklist. Choose a message where one wrong action has a cost you can measure: a change of supplier bank details, a payment instruction, a contract, a critical instruction, a payroll change.
Start a test
What a first test looks like
Start with one narrow process
The strongest first test is a narrow, high-value process where an approval step already exists. Pin down five things: which request you are protecting, who is expected to send it, who should receive it, what evidence is available, and what decision the recipient has to make.
Keep the control you already have
Test alongside the controls you already use. If your current process has a finance employee call a known supplier contact before changing bank details, that call stays in the test. The point is to find what the evidence ADDS, which you cannot measure if you drop the existing control at the same time.
Measure the evidence, not the demo
Do not ask whether the check “worked”. Ask what A proved, what B proved, which later evidence was available, which claims stayed unproven, what decision the team took, and which control was still needed. A test that shows a step does not prove a business fact has told you something useful.
A good test produces a decision, not a score
Record the outcome from the evidence actually produced, and do not let the test stretch into a broader product claim than the tested process supports. The valuable outcome is a clearer control around one real high-risk event.
Use a phone line that is genuinely independent
If a phone confirmation is part of the scenario, write down where the number came from. A proper independent line is a number you already had, never a number given in the request itself, and that sentence belongs in the written test steps, not in someone’s memory.