Certyn runs tests against your app, records every result in one project, and answers what needs a person and whether you can ship. These concepts explain how the system is organized and how evidence flows through it.

How everything fits together

At the top level, a Project represents the application or API you are testing. Each project contains one or more Environments (staging/production/etc), each with its own web/API base URL or mobile runtime target, 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 to control what runs and when. A process can run on-demand, on a schedule, or when an environment version changes.

When a process runs, it creates a Run, which holds one Execution per test. Agent-driven executions open a Session (an isolated container with a browser or device) that produces artifacts: logs, screenshots, traces, and a recording. Failures and discoveries become Issues with that evidence attached, for triage and verification.

Where runs come from

This is the part that makes a project worth opening: a run does not have to be something Certyn started. Every process has a kind, and all four kinds report into the same project, the same run history, and the same test health numbers.

Process kind	Who runs the test	Where the cases live
Suite	Certyn	Test cases in Certyn
Agent	Certyn	Nothing to author; the agent explores and reports what it finds
External suite	Certyn	TestRail, Zephyr Scale, Xray, or Azure Test Plans, pulled fresh at run time and written back after (guide)
Automation	Your CI	Your own Playwright, Cypress, Jest, or JUnit suite. Results are pushed to `POST /api/ci/results` and arrive already finished (guide)

An Automation process is created for you on first push, one per suite slug. Its runs have no session, because there was no agent: they carry the outcomes and timings your pipeline reported.

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

Glossary

Docs terms (Runs, Issues) and how they map to API objects.

Projects & Environments

Define what you're testing and where agents should run.

Wiki & Context

Teach Certyn what matters and what must always be true.

Processes & Test Cases

Build suites with tags, schedules, and triggers.

Issues & Runs

How runs and issues are tracked for auditability.

Agents & Sessions

AI-powered test runners in browser or mobile runtime sessions.

Mobile Runtime

Configure Appium-backed Android and iOS app sessions.

API Runtime

Test HTTP APIs with generated Hurl flows and request evidence.

Bug Tracking & Triage

Automatic bug creation, severity levels, and retesting.

Status Lifecycle

How statuses flow and what each terminal state means.

Run Results

How individual test outcomes aggregate into run-level results.

Quality Metrics

Pass rate, flakiness, risk signals, and health thresholds.

Bug Detection & Deduplication

How Certyn discovers bugs, prevents duplicates, and links failures.

Project
 ├── Environments (staging, production, ...)
 ├── Wiki (overview + rules)
 └── Processes
      ├── Suite           native test cases, run by Certyn
      ├── Agent           exploration, driven by Certyn
      ├── External suite  cases pulled from TestRail / Zephyr / Xray / Azure
      └── Automation      results pushed in from your own CI
               │
               ▼
              Run
               │
               ▼
          Executions ──────────────► Issues (with evidence)
               │
               ▼
           Sessions
   (agent-driven kinds only; pushed
    CI runs arrive already finished)

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

Core Concepts