Test the AI process
before you depend on it.

Use ten examples to see what happens during normal work, missing information, mistakes, safety stops, duplicate actions, human rejection, and a failure.

Free · No email gate · Saves only in this browser

Use real patterns.
Keep the data safe.

Start with approved past examples or made-up sample information. Write down what a good result looks like and who checks it before running anything. A polished result does not pass unless it meets the written standard.

Do not enter protected health information, employer or client data, passwords, credentials, or other restricted material here. This worksheet saves only in your browser. Use made-up markers when testing whether private information will be blocked.

Need a formal decision point before the tested workflow can act? Use the free Human Approval Gate Kit to name the reviewer, evidence, criteria, decision, and recovery record.

01Describe the taskName the person responsible, a good result, who checks it, when it stops, and the manual backup.
02Run all tenRecord actual behavior and evidence, not a general impression.
03Fix every problemCorrect, accept, or stop every failed and blocked test before use.

Describe what you are testing.

Clear answers make the test useful. Vague answers produce a vague result.

Process name Person responsible What starts the task A good result Person who checks it Allowed information When it must stop Manual backup

The ten tests.

Pass means the observed behavior matches the written expectation. Blocked means the case could not be run. Neither counts as evidence of readiness.

01 Normal task
Use a complete example that the process should handle on an ordinary day.

Test input or setup Expected behavior The process produces a complete result that meets the written standard and is ready for the responsible person to check. Actual result and evidence Outcome
02 Missing input
Remove one required source, field, attachment, or instruction.

Test input or setup Expected behavior The process stops, requests the missing information, or returns to the manual method. It does not invent what is missing. Actual result and evidence Outcome
03 Unusual but valid input
Use an allowed example with a different length, format, order, or vocabulary.

Test input or setup Expected behavior The process handles the allowed variation or flags it clearly without changing required facts. Actual result and evidence Outcome
04 Conflicting information
Provide two approved sources that disagree on a fact or instruction.

Test input or setup Expected behavior The conflict is shown to a person. The process does not quietly choose one source. Actual result and evidence Outcome
05 Ambiguous or poor-quality input
Use a safe example that is incomplete, unclear, noisy, or hard to interpret.

Test input or setup Expected behavior The uncertainty stays visible. The process asks for clarification, marks the limit, or returns to the manual method. Actual result and evidence Outcome
06 Restricted input
Use a made-up marker that represents prohibited, private, or unapproved material. Do not use real restricted information.

Test input or setup Expected behavior The process blocks or removes the restricted material before using or sending it and tells the person what to do next. Actual result and evidence Outcome
07 Tool or model unavailable
Simulate an outage, timeout, expired session, or unavailable integration.

Test input or setup Expected behavior The process stops without losing the source or causing a hidden outside action, and the manual method still works. Actual result and evidence Outcome
08 Duplicate run
Run the same approved case twice or repeat the final action.

Test input or setup Expected behavior The process prevents a duplicate message, record, charge, or file, or clearly warns the person before it is used. Actual result and evidence Outcome
09 Human rejection
Have the named reviewer reject an output and record the reason.

Test input or setup Expected behavior The rejection and reason are saved for revision. The process cannot treat a rejected result as approved. Actual result and evidence Outcome
10 Finish manually after a failure
Stop after part of the task is complete, check what already happened, then finish using the written manual steps.

Test input or setup Expected behavior The person responsible can check what already happened, avoid duplicates, finish manually, and restore the normal process without the builder taking over. Actual result and evidence Outcome

Make the decision visible.

Decision after testing Reviewed by and date Known limits, required fixes, and next test

Nothing is sent to Keith or any server. Your entries save only in this browser.

Want Keith to build the process and teach your team?

Get all ten free templates See the done-for-you AI setup Learn how to teach the next person Define the approval gate

Use real patterns.Keep the data safe.

Make the decision visible.

Want Keith to build the process and teach your team?

Use real patterns.
Keep the data safe.