Quick answer: An empty test result means no evidence was collected, so it cannot be treated as a pass. When a check does not run, there is no output showing the code worked, and the correct verdict is inconclusive. A missing script is reported as unverified, and a lack of verified evidence stays open until a real run produces something you can trust.
The difference between silence and success
A pass is a positive claim. It says a command ran and produced evidence that the behavior holds. An empty result makes no such claim, because nothing executed, nothing was measured, and there is no raw output to inspect.
| Situation | What it means | Verdict |
|---|---|---|
| A test runs and passes | Positive evidence the covered path works | Pass |
| A test runs and fails | Evidence the behavior is broken | Fail |
| Some checks pass, others cannot run | Partial coverage | Partial |
| No check runs, no output | No evidence at all | Inconclusive |
The verdict is produced deterministically with no model involved. With no verified evidence, the result is inconclusive because an empty result is not a pass. Treating silence as a green check invents evidence that was never collected.
Why empty results happen
Empty or missing results are common in real projects, and they usually point to a process gap rather than clean code.
- A project has no test script, so the check cannot start.
- A command is configured but produces no runnable output in the current environment.
- A dynamic run never reaches the branch under review, so that branch gets no evidence.
- A service the check depends on is not running, leaving the run unconfirmed.
Run checks execute detected project commands explicitly. When a script is missing, the result is unverified rather than passed. If a dynamic suite never enters a branch, you have no evidence about that branch, which is not the same as evidence that it works.
The cost of treating empty as a pass
When an empty result is misread as success, defects hide behind a green-looking label. The team assumes a check exists when it does not, and the gap only surfaces later, often in production. This is especially risky with AI-generated code, where a confident summary can imply verification that never happened.
The safer reading is to keep the absence visible. Label the item as unverified or inconclusive, state which command was missing or did not run, and treat it as work to close rather than a result to trust. Each evidence item is supposed to carry a reproducible command and raw process output, so an item with neither is easy to spot.
How to close the gap
Move an inconclusive item toward a real verdict by giving it a runnable check.
- Add or fix the missing script so the command can actually execute.
- Run it and capture the raw output.
- Confirm the check covers the branch or behavior under review.
- Re-run the review so the deterministic verdict updates.
Partial verification stays partial until the remaining checks run, and only fully verified evidence passes. A model-only note never fills this gap, because an AI hypothesis is not a substitute for a measured result.
Powerduck does not promote an empty run to success; it keeps the missing evidence on screen so you can see exactly which command needs to be added.
Frequently asked questions
What if there are simply no tests in the project? Then the review has no dynamic evidence and reports the check as unverified rather than passed. The absence of tests is a gap to close, not a reason to call the code safe.
Can an AI hypothesis replace a missing test? No. A model-only claim is always a hypothesis and does not count as verified evidence. It can point you where to look, but it cannot confirm behavior.
Does inconclusive mean the code is broken? No. It means there is not enough evidence to say either way. The code may be fine, but you have not verified it.
The bottom line
A pass needs real evidence from a command that actually ran, and an empty result offers none. Keep missing scripts unverified, keep unexercised branches without evidence, and let the deterministic verdict read inconclusive rather than green. Treating silence as approval is how unverified code gets mistaken for tested code, and it hides the very gap the review is meant to expose. See the AI code review guide for more.
