What would finished look like?
Give yourself something concrete to check.
A response can be complete and still leave you wondering what to do with it.
The plan has headings. The summary sounds clear. The assistant says the work is finished. But can you use it?
Before asking AI to do something, try finishing this sentence:
I’ll be able to use this when…
That sentence is the beginning of an acceptance criterion: an observable condition the result needs to meet. “Make it good” doesn’t give you much to inspect. “Every action has an owner and a deadline, and missing information is marked” does.
It also gives you permission to say what’s wrong without starting over. “This is missing the deadlines” is a much more useful correction than “I don’t like it.”
Two different things to check
Engineering has a helpful distinction here. Verification asks whether a result meets its specified requirements. Validation asks whether it serves its intended use in the conditions where someone needs it. NASA explains both in its product-verification guidance.
You don’t need a spacecraft to borrow the distinction.
Imagine asking an assistant to turn meeting notes into an action list. These are two separate checks:
| Check | What you would look for |
|---|---|
| Does the list meet the requirements? | Actions match the notes. Owners and deadlines are included when stated. Missing details are marked. |
| Can the team actually use it? | People can tell what they’re responsible for and what needs clarification before work starts. |
A beautifully formatted list can pass a formatting check while failing both of these.
We saw a related distinction while checking our own system after a computer restart. The saved work was still there. That supported a claim about persistence: the information had survived. It didn’t establish that a future scheduled job would run. That behavior needed its own check.
The lesson is simple enough to use anywhere: ask what a result actually demonstrates before letting it stand in for something larger.
Give the check a fair chance to catch a problem
In AI work, you’ll sometimes hear eval, short for evaluation. At its simplest, you give a system a task and judge the response against defined criteria. Here’s a small version you could try with that action-list example.
Start with a few notes whose meaning you already know. Include an action with a clear owner and deadline. Include another with no deadline. Perhaps include an idea someone discussed but never agreed to do.
Now inspect the result:
- Did the confirmed action stay accurate?
- Did the missing deadline stay missing?
- Did the tentative idea become an invented commitment?
Those examples test different failure modes. If every example is straightforward, you may learn very little about how the assistant handles ambiguity.
This is a proposed exercise, not a test we’ve run on your assistant. Passing it would give you evidence about those cases. It wouldn’t establish that every future meeting will be handled correctly.
The point is to make review useful. Choose a few checks tied to what you need, try them on the actual output, and correct the specific gap you find.
If your goal is learning, ask yourself to apply the explanation to a different example. If your goal is a workable plan, look for the first action and the resources it requires. If your goal is accurate extraction, compare the result with its source.
“Finished” becomes much easier to recognize when you know what you’re looking for.
Tomorrow: Has anything actually changed?