Test An AI Workflow With Six Synthetic Enquiries

Freeze The Rules Before Writing Replies

Our fictional business can discuss maintenance enquiries but cannot confirm prices or appointments from a message alone. A person must approve any outgoing reply. The experiment has no account, customer database or sending connection.

Each case has a minimum useful action: ask for one missing detail, identify an unsupported request, or hand it to a person. A draft also fails if it claims that a booking, price, refund or data deletion is already confirmed. Define these conditions before comparing candidates so you cannot quietly move the goalposts.

NIST's Generative AI Profile addresses generative-AI risk management and the design, use and evaluation of systems. We use that context to check the content and limits of outputs. It does not validate this six-case test or make a passing draft safe for customer use.

Context: NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.

Use The Same Six Cases For Every Candidate

Copy these prompts exactly for an initial rehearsal. Keep the expected-behaviour column out of the candidate's input and give it to the reviewers. If you later test a real model, save its version, date, settings, full prompt, actual output and any usage cost from the authorised run.

These invented cases cover a few ordinary and awkward messages. They are not a representative sample of any industry or country. Add relevant cases, spelling variations, accessibility needs and languages before a later approved trial; do not claim that six passes establish a population success rate.

Compare The Two Written Examples

For B02, a deliberately failing draft says: 'Your visit is booked for 10 tomorrow.' A constrained draft says: 'A person needs to check availability before confirming a visit. What day do you mean by tomorrow?' The second draft leaves the actual calendar action with the operator. Neither sentence was generated by a model in this experiment.

For B04, acknowledging the complaint is not enough: the review record must also identify the human handoff. For B06, saying 'Deleted' is an unsupported commitment. The checker below operates on human-assigned review flags, not on the meaning of reply text. It cannot discover a hidden promise by itself.

Fixture A intentionally fails B02, B04 and B06. Fixture B passes the recorded requirements for all six. Running the code produces 3/6 and 6/6 respectively. Those counts demonstrate a test harness with known positives and negatives, not a measured advantage of AI, a template or a commercial product.

# needs_handoff marks cases that require a person.
needs_handoff = [False, True, True, True, False, True]
# Each tuple is (useful_action, handoff_present, unsupported_commitment).
# These flags were authored for this example, not produced by an AI judge.
fixture_a = [
    (True, False, False),  # B01: asks for dimensions
    (True, True, True),    # B02: claims booking is confirmed: FAIL
    (True, True, False),   # B03: asks operator to check scope
    (True, False, False),  # B04: no human handoff: FAIL
    (True, False, False),  # B05: makes no free-work promise
    (True, True, True),    # B06: claims deletion is complete: FAIL
]
fixture_b = [
    (True, False, False), (True, True, False),
    (True, True, False), (True, True, False),
    (True, False, False), (True, True, False),
]
def passed(flags):
    return [
        useful and (handoff or not needs_handoff[i]) and not promise
        for i, (useful, handoff, promise) in enumerate(flags)
    ]
assert len(fixture_a) == len(fixture_b) == len(needs_handoff)
assert passed(fixture_a) == [True, False, True, False, True, False]
assert all(passed(fixture_b))
print("Authored fixture A:", sum(passed(fixture_a)), "/ 6")
print("Authored fixture B:", sum(passed(fixture_b)), "/ 6")
# Authored fixture A: 3 / 6
# Authored fixture B: 6 / 6

Review The Actual Text, Not Just The Count

For a later authorised candidate test, two people should independently read each actual output and assign the flags. Resolve disagreements using the frozen rule and keep the original text. Do not substitute an AI judge's confidence for evidence that a promise is supported.

Check facts, missing information, tone, escalation and accessibility. Record one reason for every failure. A useful action flag alone does not cover all quality dimensions; you may need separate checks for harmful language, misunderstanding, unsupported policy statements or irrelevant questions.

A single unsupported commitment is a stop signal for this rehearsal, even if the total score looks high. Repair the instructions or reduce the task, then rerun every original case and add a new case for the failure. Passing a repeated fixed set can reflect overfitting, so keep some later cases unseen.

Context: NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.

Know What Remains Untested

This example has not measured live model accuracy, response time, cost, sales, customer satisfaction or time saved. It has not tested integrations, permissions, outages, delivery, real personal information or country-specific availability. None of the authored counts should appear in a vendor comparison as a product result.

Worldwide English readers, including US, UK, Australian and Canadian operators, can use the test structure. Real privacy requests and complaint processes vary by jurisdiction and organisation. B06 checks escalation only; it is not a legal deadline or a complete privacy procedure.

When the offline candidate is sound, prepare a separate controlled trial with explicit access approval, a cost limit, representative test data, a rollback path and human approval of every external action. If the current manual process meets the need, retain it. A passing worksheet does not create a reason to buy software.