Use Cases

Retest a Saved AI Tool After an Update

Keep one small reference task, compare the new result, and decide whether your workflow needs attention.

Audience and review notes

For: People returning to an AI tool after a product, plan, or workflow change.

Check facts against original sources and remove sensitive information. Review AI output before relying on it.

Start With One Real Requirement

An announcement is a reason to check your workflow, not proof that it improved or broke. Read the linked official notice and check whether its date, account type, region and rollout scope apply to you. Aiplorer records selected changes; an empty change list does not mean a service is unchanged.

This fictional exercise uses a customer-update draft. The inputs and proposed outputs below are editorial examples, not a captured model run or a tool ranking. You can use the same method for code, slides, research or audio.

Choose The Check That Matches Your Work

Choose one relevant task rather than rerunning every pack. The writing and extraction packs have fictional inputs, separate review keys and blank two-run worksheets. Keep the key out of the AI conversation and retain the first output before asking for corrections. The code exercise instead provides a buggy function and local regression tests.

Your taskStart withInspect first
Summarize notes or documentsSummary reference packCorrected facts, unresolved disagreement and tentative commitments
Rewrite an email or client messageMeaning-preserving rewrite packDates, prices, permissions and scope that must not change
Turn messages into a tableMissing-value extraction packMissing fields, assigned owners and proposed versus confirmed dates
Review a small code fixZero-value regression packPreserve zero, default missing values and inspect the diff without changing the tests
Check a cited claimCitation support packMatch the passage to the claim; distinguish unsupported scope from a missing source

The practice downloads collect all five packs in one place. These checks do not cover every workflow. If your question is about access, permissions or a plan change, check the relevant official documentation and account instead of using an output exercise as evidence about those conditions.

Keep A Small Reference Task

Use approved, non-sensitive material. Save the exact input, expected facts and previous output before retesting. Keep the account settings and instructions the same where possible; record anything you cannot hold constant.

Source notes:
- The preview is ready for internal review.
- Customer access has not been approved.
- Maya owns the review; no deadline has been agreed.

Task:
Write a two-sentence status update using only these notes.
Do not invent a launch date, approval, deadline or commitment.
If a detail is missing, leave it explicitly undecided.

Compare Against Facts, Not Fluency

An illustrative acceptable result:

The preview is ready for internal review, with Maya owning the review. Customer access is not approved, and the review deadline remains undecided.

A plausible but unacceptable result:

Maya will finish the review on Friday so customers can access the preview next week.

The second version sounds confident, but invents a deadline and customer availability. Better phrasing cannot compensate for a changed commitment.

CheckAcceptable exampleUnacceptable example
Internal review is readyPreservedNot clearly stated
Customer access is not approvedPreservedContradicted by implied availability
Maya owns the reviewPreservedPreserved
No deadline has been agreedPreservedFriday invented

These are checks of the supplied examples, not performance measurements. One passing output does not establish reliability. Repeat a few relevant cases, including missing or conflicting information, before relying on the workflow.

No Earlier Output? Start A Baseline

Do not label today’s result an improvement or regression if the previous input, instructions or output are missing. Record a first documented run instead. An account setting that is not visible should stay “not shown”; do not fill in a model version from memory.

For example, suppose you remember a tool inventing deadlines last month, but kept no prompt or output. Today it preserves all the uncertainty in the fictional source above. The defensible note is:

Previous evidence: unavailable; remembered result is not a comparable run.
Today: preserved the four facts in this sample; first documented baseline.
Decision: continue checking this workflow, not "the update fixed it."
Next check: the same task with conflicting or explicitly revised dates.

This is an invented note, not an observed product result. A good current answer does not prove that an update caused it. Keep “could not test” separate from an output failure, and do not change a local test date merely because you opened a pack or read an announcement.

Separate Output Problems From Access Changes

If a required export, setting or workflow is unavailable, record “could not test” instead of a quality failure. Check the provider’s current documentation and your account before assuming a feature was removed. Do not upgrade or grant broader permissions merely to finish this exercise.

For code, run the existing regression tests and inspect dependencies and security-sensitive changes. For research, open the original sources. For media, verify rights and the actual delivery format. Never put credentials, private repositories or customer records into an unapproved test account.

Choose Your Next Check

Keep the first output and your reviewed worksheet before deciding what to do next. Use the outcome for the individual case, not a score for the tool. The examples below are fictional notes, not observed product results.

Meets These Checks

Keep that result as a baseline for this input. Choose one relevant boundary case you have not checked, rather than assuming the workflow is ready for unattended or sensitive work. If nothing remains unresolved, there is no need to rerun it simply because another day has passed.

Observed: the summary preserved the unapproved launch and missing date. Next check: conflicting source notes; that input has not been checked yet.

Before expanding a workflow, use the small-pilot review.

Needs Correction

Record the specific mismatch and preserve the failed first answer. Change one instruction or condition where practical, then keep the repaired output separately. If multiple conditions change, do not attribute the difference to one cause. A repaired example does not erase the original failure.

Observed: a proposed review date became a confirmed deadline. Next check: repeat the same input with an explicit uncertainty instruction; compare both answers against the source.

Use the failed-result note example to keep a completed check distinct from a passing result.

Could Not Test

Record the blocker and what evidence would let you resume. Check the provider’s current official guidance and your account when access is unclear; do not buy a plan or grant extra permissions just to finish a practice pack. No output means there is no output-quality result to compare.

Observed: the required input could not be submitted; no answer was produced. Next check: verify the account’s permitted input method before retrying.

An answer that says a cited source is missing is different: it can be the correct answer to the citation pack’s missing-source case. Review it against the key; do not mark the whole run blocked merely because it flags a gap.

For mixed results, keep each case’s outcome separate. Leave one concrete question or relevant change to watch for in a short test note. Following these links does not save a result or set a test date. Return to the practice downloads when ready to repeat the unchanged inputs.

Leave A Useful Note For Your Next Visit

Keep the full evidence in an approved location. A short private note can follow this structure:

Task: two-sentence status update from approved sample notes
Change checked: [official notice and applicable scope]
Test date / account settings: [record what you actually used]
Observed result: [facts preserved, errors, or could not test]
Decision: [continue / review before use / pause this workflow]
Next check: [specific unresolved question or trigger]

Return to your saved tools for the recorded announcement and candidate evaluation. Store only a brief, non-sensitive note there: browser-only storage is not a secure evidence archive or a synced backup. Mark announcements read only after reviewing them; that does not certify the tool or update your own test result.

For a runnable code check, try the zero-value regression exercise. For structured work records, try the missing-value extraction exercise. Browse recorded tool changes before your next retest.

If the workflow is going away rather than changing, use the work-preservation checklist to check what you can retain and test a small handoff before moving everything.

From reading to a decision

Keep the workflow connected

Choose a task-first path, save candidates locally, compare the shortlist, and recheck official details before use.