Checking its work
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 covers where the deliverables are; this page is about trusting them.
Enforced by the system
Section titled “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
Section titled “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.
The verification pass — and what it actually is
Section titled “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
Section titled “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
Section titled “Six checks worth making”Not “use your judgement” — these are the specific things that catch real problems:
- 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.
- Check the verification label, not just that the run says Done.
- Open the artefact. A named file in the answer is not evidence the file is any good.
- Trace one number back to the material it should have come from. One trace catches most of what a whole read-through misses.
- Open one citation — the one behind whatever claim you would least like to be wrong about.
- 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
Section titled “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.