Status Lifecycle
How statuses flow from creation to terminal states, and what each status means for runs, issues, and tests.
Every run and issue in Certyn follows a status flow. Understanding what each status means helps you interpret results and decide what needs attention.
Status flow
open → ready_to_test → in_progress → [terminal state]
When a run is queued, it moves to ready_to_test. Once an agent picks it up, it becomes in_progress. When the session finishes, the system assigns a terminal status based on the outcome.
Terminal statuses
| Status | Meaning |
|---|---|
| Verified Passed | Test completed and all checks passed |
| Verified Failed | Test completed and at least one check failed |
| Blocked | Cannot execute — environment issue, missing data, or dependency failure |
| To Verify | Inconclusive result — partial run, no results, or ambiguous outcome |
| Done | Completed without verification (non-test task or intentional skip) |
| Closed | Won't fix or not a bug |
| Cannot Reproduce | Issue could not be reproduced during re-test |
To Verify always needs a human
Items marked To Verify are genuinely ambiguous. The system could not determine pass or fail. Review the session artifacts and make a decision.
Issue-specific statuses
Issues (bugs) follow the same flow with one addition:
| Status | Meaning |
|---|---|
| Resolved | A developer applied a fix, but it has not been verified yet |
Resolved is not terminal
Resolved means a fix exists — it does not mean the fix works. The issue must be re-tested and moved to Verified Passed or Verified Failed before it can be considered closed.
The Needs Review flag
Certyn automatically flags items with Needs Review when the system is uncertain and a human must decide:
- the result was inconclusive (no test results, partial run, agent crash)
- the run had mixed outcomes (some test results + some non-test statuses)
- an auto-created bug needs human triage to confirm severity and validity
Needs Review is cleared when a human reviews the item and sets a definitive status.
Priority levels
Priority determines execution order and release impact:
| Priority | Meaning | Release impact |
|---|---|---|
| Required | Must pass for release | Blocking — release cannot proceed |
| Critical | Severe impact, needs urgent attention | Should block unless explicitly overridden |
| High | Significant impact | Should be addressed before release |
| Medium | Moderate impact (default) | Address within sprint |
| Low | Minor impact | Address when convenient |