Certyn uses issues and runs to track work and outcomes.
Certyn is not trying to replace Jira, Linear, or GitHub Issues. Internal issues and runs preserve Certyn's QA audit trail.
Runs and executions
An execution is one attempt at one test. It carries the status, the outcome, and the evidence.
A run groups the executions from one batch: a process run, or a CI report pushed in from your pipeline. A run holds one execution per test and reports pass and fail counts across them.
Not every execution belongs to a run. Single-test paths create a standalone execution with no run:
| Path | Creates |
|---|---|
| Running a process (suite, agent, external suite) | A run, plus one execution per test |
A CI report pushed to /api/ci/results | A run, plus one already-finished execution per reported test |
| Quick test, retesting an issue, running one saved case | One execution, no run |
Agent-driven executions open a session, which produces the artifacts. Pushed CI executions have no session, because your pipeline already did the work.
Runs are how you answer: "Did this environment version actually work?"
Issues
An issue is a problem found by a run or filed by a person. A good issue includes:
- environment and run context
- evidence (screenshots, logs, traces, and the session recording)
- a clear statement of expected vs actual behavior
An issue is linked to the executions it came from, so the original discovery and every later retest stay attached to it.
Verifying fixes
Certyn is designed for a fast verification loop:
- issue is created with evidence
- fix is deployed to an environment
- you re-run the relevant process/tests
- the new artifacts confirm whether the fix actually worked
The goal is to make verification evidence-based and cheap.