Core Concepts

Certyn is designed to behave like an autonomous QA team: it runs continuously, produces evidence, and pulls humans in only for decisions. These concepts explain how the system is organized and how artifacts flow through the product.

How everything fits together

At the top level, a Project represents the application you are testing. Each project contains one or more Environments (staging/production/etc), each with its own base URL, variables, and model settings.

To keep runs repeatable, you provide context in the Wiki (overview + rules). This context helps Certyn explore the right areas, write better tests, and produce higher-signal issues.

You define Processes (suites) to control what to run and when. Processes typically select tests by tags and can run on-demand, on a schedule, or when an environment version changes.

When a process runs, it creates a Run. A run spawns one or more Sessions (isolated agent containers). Sessions produce artifacts (logs, screenshots, traces). Failures and discoveries become Issues with evidence for triage and verification.

If you want API-native terminology, start with the Glossary.

Entity relationship overview

Project
 └── Environments (staging, production, ...)
 └── Wiki (overview + rules)
 └── Processes
      └── Tests (tagged)
           └── Run
                └── Sessions ──► Issues (with evidence)

Projects scope everything; environments control where sessions run; wiki provides truth; processes define what/when; runs and sessions record what happened; issues capture what needs attention.