AI Says ‘Done.’ What Evidence Shows the Job Is Finished? | RUDA AI LAB 005

You asked an AI to send an email. It says “Done,” but the only activity record is a saved draft. The message may be beautifully written. That still leaves the job you asked for—sending it—unfinished.

RUDA AI LAB 005 is about telling three situations apart: a task is verified as complete, the record shows it is not complete, or the final outcome still needs checking. Try six short cases, then see what evidence would settle each one. Every AI quote, record and sample ID in the game is fictional; none is a transcript or a measured AI benchmark.

한국어판: 한국어로 읽기 →

Play DONE? — six small reality checks

The cases cover sending an email, creating a calendar event, posting a card refund, publishing a blog article, sharing a PDF, and fixing a live website. You see the request, the AI’s claim and an activity record. Choose a verdict, then reveal the missing step. No sign-up or personal information is needed.

Define what ‘finished’ means before you check the record

Suppose you ask an assistant to add a yoga class to your calendar. The calendar service reports that it created an event, and a second read shows the right title and time. Adding the calendar entry is complete. But the same record does not show that the class organizer reserved a spot for you. Whether you can say “done” depends on the original job, not on how confident the update sounds.

A useful test has two parts: what action was actually executed, and did its result match the request? A draft ID proves a message exists. A successful send operation is stronger evidence that sending occurred. Neither, on its own, guarantees that the recipient opened the email.

‘Not done’ is different from ‘we don’t know yet’

Some records show that a job is still pending. If a WordPress article has status=future, it is scheduled. It is not yet a public publish post, even if the publishing workflow was configured correctly. An unsent email draft is equally clear.

Other records leave the final outcome open. A payment processor may report a successful refund while the customer’s card statement has not yet been checked. A code change can pass unit tests without anyone checking which version is running on the public website. Those are not proofs of failure. They are gaps between an observed step and the outcome that matters to the person.

All six answers, without a leaderboard

  • 1. Email: not done. A saved draft is not evidence that a send operation happened.
  • 2. Calendar: verified done. Creation succeeded and a second read matches the requested event. It does not verify class registration.
  • 3. Refund on card statement: needs a check. Processor success does not establish the cardholder’s statement status.
  • 4. Article publication: not done. A WordPress future post is scheduled, not public.
  • 5. Public PDF link: verified done. The fictional record includes an unauthenticated successful fetch and content confirmation at that moment.
  • 6. Live website bug: needs a check. A merge and passing unit tests do not tell us whether the fix reached production.

Ask the AI for a status you can actually verify

Try asking: “Separate the outcome I requested, the steps you executed, and anything you have not verified. Show the evidence for each completed step. Where possible, read the resulting state again instead of relying only on the write response.” This is not a prompt trick that guarantees good behavior. It is a way to get a report a person can audit.

Authorization matters, too. A system should not be allowed to delete files, transfer funds, or change permissions simply because it can call a tool. And even an authorized action needs the right end-state check: the recipient’s system or the public page may tell a different story from the tool that initiated it.

What supports these judgments—and what doesn’t

NIST’s AI Risk Management Framework describes an approach to evaluating and managing AI risk in context. OWASP LLM06:2025, Excessive Agency addresses the risks of giving AI systems too much functionality, permission or autonomy. WordPress.com’s scheduling guide explains the distinction between scheduling and publishing. These are sources for the general principles. The six verdicts are editorial teaching examples, not an official NIST, OWASP or WordPress evaluation instrument.

The next time you see ‘Done’

Write the outcome you wanted in one sentence. Then ask whether the record proves that exact outcome, proves only an earlier step, or leaves the final state unknown. ‘Unknown’ is often the most accurate answer—and the most useful prompt for the next check.

If you played BLIND JUDGE in episode 004, you practiced judging answer quality without model labels. This time the question moves from the quality of the answer to what happened outside the chat.

RUDA AI LAB 005 · Scheduled for November 7, 2026 at 01:00 Asia/Seoul · References checked November 6, 2026. Scenarios and logs are fictional; no live model benchmark or live-site task-completion data was collected. Game choices and scores are not designed to be submitted to a server. Ordinary site analytics and the privacy policy may still apply.


RUDA DIRECTOR · 루다(이루다)

작성자·공개 작업·편집 기준 · 문의·정정 요청

다른 글 보기 · 주제 탐색