The best-looking output is a poor record of an experiment. Keep the setup and the awkward attempts so another person can understand your decision.

Write the decision before the test

Choose one limited decision, such as whether to use an assistant to outline routine internal updates. Do not begin with “Should we use AI?” That question mixes many tasks, risks and people.

Write a success condition you can check. For an outline, that might mean all required points present, no invented facts and a structure a colleague can use. Define the same finish line for the existing approach. Record any constraints on what information you are allowed to enter.

Keep an experiment sheet

A document or spreadsheet is enough. Avoid collecting customer information just to make the record feel more realistic. If a source is restricted, refer to its approved location rather than copying it into another system.

  • Task and date: identify the example without private information.
  • Baseline: describe the current method and finished-work time.
  • Setup: record the tool version if visible, instructions and permitted source.
  • Attempts: keep each result, including the one you rejected.
  • Review: list errors, corrections and review time.
  • Decision: state the narrow use you will keep, adjust or stop.

A fictional three-task comparison

Imagine baseline completion times of 20, 25 and 30 minutes. With an assistant, the corresponding tasks take 18, 28 and 24 minutes, including setup and review. The totals are 75 and 70 minutes. That is five minutes less across these examples, not proof of a general productivity improvement.

Suppose the second output also omitted an important caveat. Keep that failure in the record. It may explain why a narrow outline task is useful while a final-summary task is not. Looking only at the fastest example would hide the part that needs redesign.

Do not convert three convenient tasks into an impressive percentage for a sales claim. They are a small local check. The next sensible step might be another comparison on the difficult task, or deciding the saving does not justify changing the workflow.

Change one part before repeating

If an output fails, identify the cause you want to investigate. Try supplying a checked source, narrowing the requested result or changing the review checklist. Change one of those at a time so you can connect the result to the adjustment.

Keep the original method available during the trial. An experiment should not silently become the only way to complete an urgent task. Stop if the test needs information or permissions you do not have.

Write a decision someone else can read

A useful conclusion has a scope and a reason: “Keep the assistant for outlines of these updates; review every outline against the required points. Do not use it to produce final client summaries.” Add the examples that led to that decision and what would make you revisit it.

NIST’s risk framework is a broader reference for evaluation and monitoring. This experiment sheet is a practical starting point, not a complete risk assessment. Your organization’s requirements still determine which tests and approvals a particular use needs.

Sources & context

Sources checked on 11 October 2026. Worked examples are fictional; the suggested checklists are editorial advice.

Use this next

Keep exploring

Use the free tools