---
title: Checking its work
description: How to tell whether a result can be used as it stands — which safeguards are enforced by the system, which are only rules it follows, and the six checks worth making.
---

The useful question is not "is this AI accurate?" but "which parts of this result carry
their own evidence, and which parts are just fluent?"

Some of what keeps a result honest is enforced by the system; some is only a rule the model
follows. That difference decides how much weight each carries.
[Reviewing what comes back](/docs/reviewing-what-comes-back) covers where the deliverables are;
this page is about trusting them.

## Enforced by the system

These do not depend on the model choosing to cooperate.

- **A layout is never passed off as a generated image.** If image generation was
  unavailable, any file handed to you that was not itself generated carries a plain
  statement that it is a design layout — attached by the system, not left to the model to
  admit.
- **An unconfirmed ability is treated as absent.** The check on image generation goes stale
  after 14 days; once stale the ability is reported as off rather than attempted.
- **A cut-off run says which limit cut it**, appended even on top of text the model already
  wrote, because you have to know the run did not finish on its own terms.
- **A run that produced nothing stays empty** — no invented progress.
- **A partial reply is not billed as an answer.** A response cut off mid-stream errors
  rather than being served and charged.
- **It cannot ask you to raise its own spend limit**, nothing leaves the app on an
  unrecognised action, and a share link cannot quietly start publishing more.

## Rules it follows

These shape behaviour reliably, but they are instructions rather than physics — strong
commitments, not guarantees. It is told not to claim an ability it lacks this turn, not to
invent the contents of a document it could not read, and never to confuse "this feature
exists" with "you connected it". More in [What it won't do](/docs/what-it-wont-do).

## The verification pass — and what it actually is

After an answer is written, a separate check runs: the request, the answer and the evidence
from the run's tool calls are handed back for a verdict. You see the result in the run
header, and only one of the three labels is a pass:

| What it says | What that means |
| --- | --- |
| **Result verified** | The check ran and confirmed the answer matches the request |
| **Finished — verification flagged an issue** | The check ran and objected. Its reasoning is shown, plus any outstanding follow-ups |
| **Finished with an answer** | The check did not run, or failed. Nothing confirmed anything |

Read the third as *unchecked*, not *fine*. The label only claims "verified" when a
verification actually passed.

**This check is a judgement, not a measurement.** It is another pass over the same material,
so it can be wrong in both directions, and it is a small billed step on your receipt. One
difference between chat and handed-off work: in a chat a flagged verdict is shown and the
run still ends, while in a **handed-off task** it can push the task into **Needs you**.

## Sources and citations

The links it comes back with are real results from a live search — a lookup that fails or
finds nothing returns an honest message rather than a plausible-looking source. So the URLs
exist.

What is **not** checked is whether a particular sentence is supported by the source next to
it. The sources are real; the attribution is not audited. Open the link.

## Six checks worth making

Not "use your judgement" — these are the specific things that catch real problems:

1. **Read the flagged lines before the conclusion.** When part of a job failed it says so —
   which step, what it couldn't save, what it was stopped from doing. Those lines are the
   most reliable part of the report, and they are why a **Done** run can still be missing
   something.
2. **Check the verification label**, not just that the run says Done.
3. **Open the artefact.** A named file in the answer is not evidence the file is any good.
4. **Trace one number** back to the material it should have come from. One trace catches
   most of what a whole read-through misses.
5. **Open one citation** — the one behind whatever claim you would least like to be wrong
   about.
6. **Compare the count you asked for with the count you got.** A padded list is the failure
   mode; a short honest answer is the intended behaviour.

## Signals it should not be used as it stands

Any of these means stop and look before you send the result anywhere:

- **Needs you** — waiting on you, not finished.
- **Couldn't finish** — a real outcome, not a glitch.
- **Paused** with a message about a stalled connection: resume it, don't read it.
- A note that the run hit its time, spend or size limit — the work was cut, not completed.
- **Stopped** — your cancel, so anything above it is partial.
- The answer describes work in the future tense, or names files not in the outputs list.
- A "generated image" carrying the caveat that it is a design layout.
- A document result from a scan reporting empty — nothing was read, so nothing was based on
  it.

If a run took much longer than expected, or looks stuck rather than wrong, see
[When it takes too long](/docs/when-it-takes-too-long).