Academy
4. Verdicts — Trusting the Result
Interpret the three verification verdicts (verified, failed, could not be verified) and decide when to use a result as-is versus reviewing it yourself.
Every mission ends with a verification step. Before delivering the result, @oupi automatically compares what it produced against the goal you set. This check yields one of three verdicts:
• Verified — The result matches the goal. The checker confirmed the output is complete and aligned with what you asked for. You can use it with confidence, though a quick glance is always wise.
• Failed — The result does not meet the goal. Something went wrong during execution, or the output contradicts your requirements. You should not use this result as-is; instead, reply from the mission page to give @oupi corrective feedback and launch a follow-up.
• Could not be verified — This is not a failure. It means the checker was unable to read or inspect the output — for example, because the deliverable is a binary file (an image, a compiled document) or an action performed in an external tool. The system hands the result to you for human review.
Understanding the difference between "failed" and "could not be verified" is critical. A failed verdict tells you the system detected a problem — the output is incomplete, off-topic, or wrong relative to your goal. A "could not be verified" verdict tells you nothing about quality; it only means the automated checker lacked the ability to inspect that particular output format. Think of it this way: "failed" is a red light, while "could not be verified" is a blinking yellow — proceed, but look carefully yourself.
Always read the verdict on the mission page before using any deliverable. Even a "verified" result deserves a quick human check for nuance, tone, or domain-specific accuracy that automated verification might miss. The verdict is a safety net, not a replacement for your judgment.
If a mission comes back "failed," don't start over from scratch. Reply directly from the mission page — @oupi keeps the full context of what it tried and concluded, so your corrective feedback ("the figures are wrong, use this source instead") launches a focused follow-up rather than a blank restart.
Some output types are more likely to return "could not be verified." Binary files (images, PDFs, compiled exports), actions taken inside connected tools (sending a message, updating a spreadsheet in an external app), and browser-delegated tasks may all fall into this category. When you see this verdict, open the deliverable in Studio or in the relevant tool and confirm it yourself. This is by design: @oupi prefers to be transparent about what it cannot check rather than guess.
Open your mission list in the Assistant. Find a completed mission and open its detail page. Locate the verification verdict — is it verified, failed, or could not be verified? Read the verdict alongside the deliverable and decide: would you use this result as-is, or would you reply to refine it?
Every mission gets one of three verdicts: verified (result matches the goal — use with confidence), failed (something went wrong — reply to correct), or could not be verified (the checker couldn't inspect the output format — review it yourself). "Could not be verified" is not a failure; it's a handoff to you. Always check the verdict before using a deliverable, and use the follow-up reply to fix or extend any mission without losing context.