Issue Triage & Verification
How Certyn turns failures into evidence-rich issues and supports fast verification loops.
Certyn is built around a simple idea: failures are only useful when they come with evidence. When something breaks, Certyn should produce an issue that a developer can act on quickly.
What an issue contains
Issues are backed by run and session artifacts such as:
- screenshots
- step-by-step logs
- the agent trace (what it observed and why it chose actions)
- environment metadata (base URL, version, variables used)
Review is a feature (not a bug)
Autonomous systems can be wrong. Certyn intentionally surfaces items that need a human decision:
- is this a real product defect or test ambiguity?
- is this severity high enough to block a release?
- should a flaky test be quarantined?
- is a fix actually verified?
You will typically handle these from Overview and the Issues area.
Severity
Use severity to communicate impact, not just "how annoying it is".
| Severity | Meaning |
|---|---|
| Critical | a primary workflow is broken |
| High | major feature impaired |
| Medium | noticeable issue with limited scope |
| Low | cosmetic or minor usability issue |
Verification loop
After a fix ships:
- run the relevant process (or the specific test)
- compare the new artifacts against the failing run
- mark the issue as verified (or reopen it with new evidence)
The key is to avoid "looks fixed" decisions without a confirming run.