Skip to content
ConceptsDoc

Glossary

The user-facing terms used in Certyn docs, and how they map to API objects.

This documentation uses Runs and Issues as the primary user-facing terms. The REST API uses lower-level object names like tickets, executions, and testcases.

Core terms (docs)

TermMeaning
ProjectA single application or service you operate Certyn against.
EnvironmentA named target for testing (staging/prod/etc) with its own base URL, variables, and model configuration.
WikiThe context you provide to Certyn: product overview and non-negotiable rules.
TestA reusable check (natural-language test case) that can be run repeatedly.
ProcessA suite definition: what to run, how to schedule it, and who executes it. See process kinds.
RunOne batch execution of a process. Holds one execution per test and reports pass/fail counts.
ExecutionOne attempt at one test. This is the unit that carries a status, an outcome, and its evidence.
IssueA problem found by a run or filed by a person, backed by evidence and linked to the executions it came from.
SessionAn isolated agent runtime (container + browser or device) that performs a unit of work and records artifacts.

Mapping to API objects (precision)

Docs termAPI objectNotes
RunProcessRunCreated only by batch paths: a process run, or a CI report pushed in. Carries TotalItems, StartedAt, CompletedAt, HasFailures. Pass and fail counts are computed from its executions.
ExecutionExecutionEvery test attempt is an execution, whether or not it belongs to a run. Single-test paths (quick test, retest, running one case) create an execution with no ProcessRun.
IssueTicketTypes are bug, improvement, task, and vulnerability. issue is accepted as a legacy alias for bug.
TestTestCaseTests may be human-authored or agent-generated (often needing review). External-suite processes run cases that live in your test management tool and create no TestCase rows.
SessionAgentSessionThe live browser or device session you can watch. Pushed CI runs have no session.
ProcessProcessDefinitionCarries the kind (Suite, Agent, ExternalSuite, Automation), schedules, tags, and triggers.

Issues are linked to the executions that produced or retested them through ExecutionTicketLink, so one issue can carry its original discovery and every later retest.

Older docs said Run = Ticket

Runs used to be stored as tickets of type TestRun. That is no longer true. Runs are ProcessRun plus Execution records, and a Ticket is only ever a found issue. If you have integration code that filters tickets by a TestRun type, it needs updating.