---
name: verifying-outcomes
description: Gather evidence before claiming that work is finished, delivered, correct, or fixed. Use immediately before reporting completion — 完成了吗 / 好了没 / 交付 / 验收 / 检查一下 / 确认下. Requires a named artifact or a direct observation behind every claim, checks each plan step against its own stated criterion, and forces coverage gaps to be disclosed together with their cause and their effect on the conclusion. Enforces the rule that "we did not observe X" must never be reported as "X does not exist". Produces .superclarity/<task>/report.md. Do NOT use it to redo work that failed — fix the step first, then verify. Never skip it because the task looked simple or because the tools returned without errors.
license: MIT
metadata:
  pack: superclarity
  phase: verify
---

# "Done" is a claim, and claims need evidence

Saying "the report is ready" without having opened it is the most expensive error available here, because the user acts on it. They forward the file, they walk into the meeting, they close the decision. The cost lands entirely on them, and it lands late.

Answer the user in whatever language they wrote in.

## Check before you report

| Check | How | Passes when |
| --- | --- | --- |
| Every step reached a terminal state | Read `plan.md` | Each step is `completed`, or `skipped` with the user's agreement on record |
| Each step met its own criterion | Re-read each `verify` line against reality | Every one holds now, not merely at the time |
| Artifacts exist and have content | Open them | They exist, are non-empty, and contain what was promised |
| Conclusions trace to something | Follow each claim back | Every claim names a source, a file, or an observation |
| Gaps are known | Read `capabilities.md` and the journal | You can state what was not covered and why |
| Success criteria met | Read `brief.md` | Each criterion is met, or its shortfall is stated |

Doing this costs a few minutes. Not doing it costs the user their meeting.

## A tool returning without an error is not evidence

It means the tool ran. Not that it produced what you asked for, that the output is complete, or that it answers the question. Open the artifact. Read enough of it to know.

Empty result sets, truncated outputs, and default placeholders all return successfully.

## The rule this pack exists for

**Absence of evidence is not evidence of absence.**

If a source was unreachable, a channel unauthenticated, a dataset unavailable — you learned nothing about the subject. You learned something about your coverage.

> Correct: "The gated analyst report was not accessible, so this comparison does not reflect analyst positioning."
>
> Wrong: "No analyst coverage exists for these vendors."

> Correct: "Pricing is not published for vendor C; they route to a sales contact."
>
> Wrong: "Vendor C's pricing is unavailable."

Every restatement of a coverage gap as a finding must be corrected before delivery. This is not a stylistic preference — it is the difference between a useful report and a misleading one, and misleading reports are worse than no report because they are acted upon with confidence.

## Reporting

Three parts, none optional, in [`report.md`](templates/report.md) and in what you tell the user:

1. **What was delivered** — named artifacts, where they are, what each is for.
2. **What was covered** — the actual extent: how many of what, over which period, from which sources.
3. **Where the gaps are** — what was not covered, why, and **what that means for the conclusions**. A gap without its consequence is decoration.

Lead with gaps that affect the decision. Burying a load-bearing gap in a closing paragraph is a way of technically disclosing it while ensuring it is not read.

## Phrases that signal you skipped this

- "Should be fine" — then go and check.
- "The report has been generated" (unopened) — open it.
- "All sources covered" (warnings unread) — read them.
- "No issues found" (nothing examined) — you found no issues because you looked for none.
- "Successfully completed" as the entire report — completed at what, verified how?

## Partial success is a real outcome

Only two step states are terminal: `completed`, and `skipped` with the user's agreement recorded. Anything still `pending`, `running`, `failed`, or `blocked` has to be resolved before you report, and there are exactly three honest ways to resolve one:

1. **Finish it** — go back and do the work.
2. **Abandon it, with agreement** — put the situation to the user, and if they agree to drop it, mark it `skipped` and note what the result no longer covers. Delivery becomes `partial`.
3. **Stop** — if the task cannot proceed and the user has not agreed to drop anything, delivery is `blocked`. Report what exists and what is in the way.

What you may not do is quietly mark a failed step `skipped` to make the checklist pass. That converts a failure into a silent scope reduction, and the user finds out when the decision they made on your report turns out to rest on missing work.

If four of six steps succeeded, say so plainly and early. Report what exists, what does not, and what it would take to close the gap. An honest partial delivery lets the user decide; a partial delivery dressed as a complete one removes that choice and is discovered at the worst possible moment.

## Worked example

A quarterly summary drawing on three data sources. Two loaded; the third timed out and was retried once, without success.

Wrong: deliver the summary from two sources, note "some data was unavailable" in a footnote, and present the totals as the quarter's totals.

Right: state up front that the summary covers two of three sources, name the missing one and the period it covers, and say what that does to the numbers — the totals understate by roughly the third source's usual share, so they are a floor, not a total. Then offer the options: deliver as-is with the caveat, retry later, or have the user export the missing source. The user's decision depends on which they are doing, and only they know that.