Terms are defined here once and linked to from elsewhere.
Acceptance criteria
The verifiable statements in a specification that determine whether the work was successful. Verification tests are carried out against these criteria.
Advisory gate
A quality gate whose failure is recorded as a Finding but does not halt the Task. This differs from a blocking gate.
Agent
A specialised worker that carries out one stage of a Task. Each Agent has a fixed role and a limited set of tools. See Agent roles.
Agent-hour
A unit of metered execution time. This counts while an Agent is actively working on a Task, not while the Task is waiting in the queue.
Agent slot
The unit of parallelism. One slot runs one Task at a time. See Capacity and agent slots.
AI profile
A named model configuration assigned to an Agent, balancing cost, speed, capability and constraints such as data residency. See AI profiles.
Blocking gate
A quality gate whose failure halts the Task until it is passed or overridden.
BYOK
"Bring your own key" — providing your own model provider credentials so usage is billed by your provider at your rates rather than through Coroid.
Check
A single verification carried out against a change. Checks are grouped into policies and run as gates.
Discovery
Something Coroid identifies in your codebase during analysis, which may be suggested as work.
Finding
An issue recorded against a change — by a reviewer Agent, a scanner, or an advisory gate. Findings are either fixed as rework or attached to the pull request.
Hook
An organisation-level automation that responds to a platform event. See Hooks.
Intake
The stage where a request becomes trackable work, whether entered manually or imported from an issue tracker.
Lane
The branch into which a plan's Tasks are integrated. Tasks target the lane rather than your base branch, and the combined result is promoted as a single pull request. See Tasks, plans, sprints and lanes.
MCP
Model Context Protocol. Coroid connects to external MCP servers and can be used as one. See the Integrations overview.
Plan
An ordered set of Tasks grouped into phases, approved before any code is written.
Policy
A named, versioned set of quality gates attached to projects.
Project
One repository along with its configuration, context and settings. This is the container in which work runs.
Promotion
Opening the pull request that moves the integrated work from a lane to your base branch, once it meets the required standards.
Provider key
A credential for a model provider that you supply. It is encrypted at rest, never returned by API, and never included in settings exports.
Quality gate
A check that must be passed before moving forward. See Quality gates.
Review evidence
Artefacts attached to a pull request as proof of verification — preview deployments, scan results, coverage reports, test runs. See Review evidence.
Review rule
An organisation-defined instruction that determines what the reviewer Agent looks for.
Rework
Sending a Task back to the developer Agent with findings, while retaining its context, rather than starting over.
Sentinel
Autonomous monitors that detect certain conditions and can initiate remediation work. See Sentinel.
Service account
A non-human identity for programmatic access, with its own scoped credentials.
Specification
A document outlining the scope, exclusions and acceptance criteria drawn up prior to starting any work.
Sprint
A time-bound period for carrying out work, complete with its own metrics and timeline.
Task
A single unit of work that results in one pull request. This is the actual unit that gets executed.
Work qualification
The process of confirming that a piece of work meets the required standards to progress further.
Workspace
An isolated, disposable environment where an agent clones your repository and carries out work. There is one workspace per Task.