Decide what your first AI process must prove

Begin with the business state that must change

Write the job in terms another person could verify. “Draft an order” ends when a draft is available. “Accept an order” needs the authoritative system to confirm it. “Prepare collection” also requires a physical check. Pick the result you are buying before choosing how much of the work to automate.

List the inputs the operator currently checks. Include the source of commercial terms, product identity and permissions. When sources disagree, decide which owner can settle the issue; do not ask the model to choose whichever record looks most persuasive.

Write cases that expose expensive mistakes

Begin with ordinary requests, then vary one important condition: the item is missing, the product code is unfamiliar, the order already exists, fulfilment has started, or the system response disappears. A realistic case includes the starting state as well as the customer's words. The same request can require different handling before and after dispatch.

For each case, record the expected action, forbidden action and evidence of completion. Separate a recoverable formatting defect from an unauthorized commitment. An average score can hide the failure your business cannot tolerate.

Preserve an honest test

Keep a set of cases apart from the examples repeatedly used to improve the process. These held-out cases test whether the behavior carries beyond familiar examples. Record the prompt, model, tool and policy versions with the run so a later regression can be investigated.

Do not replace missing business evidence with the model's confident explanation. If the expected answer is disputed, resolve the business rule first. If a test uses a synthetic record, mark it accordingly; it can demonstrate behavior under that condition without proving production performance.

Include the work after the first attempt

Test retries, unavailable systems and delayed approvals. A timed-out action may already have succeeded. The process needs a supported way to inspect its status before another attempt. Give unresolved cases a named owner and a review condition rather than allowing them to disappear from the queue.

Record whether a specialist intervened, what they changed and whether the final result met the business definition. Assisted completion can be valuable, but its time and cost belong in the measurement.

Make a bounded release decision

Choose between improvement, restricted live use, expansion or stopping. Record the decision maker and the evidence behind the choice. A pilot can be worth continuing without being ready to act broadly. Wider scope creates new failure cases, so acceptance is an operating practice rather than a one-time ceremony.

Read the reasoning behind the worksheet

Decide what the pilot must prove

Define release authority

Measure completed work and cost

Work through the artifact

Looqus Editorial · Version 1 · 15 September 2026 Editable starter worksheet. Worked cases below are synthetic, not customer results or evidence of a deployed system.

Use this worksheet

Choose one finished business job. Complete the blank case for ordinary requests and difficult exceptions. Keep some cases separate from those used to improve the process. Record actual results only after testing; an expected result is not a passed test.

Define the job

Business job:

Start event:

Finished outcome:

Authoritative records:

Permitted automatic actions:

Actions requiring approval and approver:

Looqus exception owner and coverage:

Client decisions outside Looqus authority:

Cost of delivery, review and repair to record:

Blank case — duplicate this section

Case ID and version:

Source record references; use approved, non-sensitive test data:

Initial business/system state:

Request:

Expected action:

Prohibited action:

Required clarification or approval:

Completion evidence:

Failure severity and reason:

Actual observed result: NOT RUN

Specialist intervention, if any:

Evidence location:

Reviewer and date:

Decision: accept / repair / restrict / stop

Synthetic case A — amendment after allocation

Case A01. Order TEST-101 contains one blue lamp and has an accepted reservation, but dispatch has not started. Customer requests two lamps. The system must check the amendment policy and remaining sellable stock before proposing a change. It must not create a second order. Acceptance requires an authorized amendment result, the correct total reserved quantity and an updated customer-facing record. Actual result: NOT RUN.

Synthetic case B — uncertain write

Case A02. The reservation request times out after submission. Its acceptance state is unknown. Required action: look up the operation/order state using the supported identifier before retrying. Prohibited action: assume failure and submit a new independent order. Acceptance requires exactly one accepted business operation or a clearly held unresolved state with an owner. Actual result: NOT RUN.

Release decision

Do not merge a serious unauthorized action into an average pass percentage. A specialist-assisted completion can be valid business completion, but must not be reported as unattended completion.