Glossary
Alphabetical reference of Colony terminology. Each definition links back to the Core Concepts page where that concept is introduced in context.
Attribution
Section titled “Attribution”A short disclosure footer Colony appends to every agent-authored GitHub artifact — issue comments, PR descriptions, review bodies, and created issue bodies. Enabled by default to satisfy EU AI Act Article 50(1) transparency obligations. The footer text and opt-out behavior are configured under attribution in colony.config.yaml.
Author
Section titled “Author”One of the four human roles in a Colony deployment. The Author files issues, writes acceptance criteria, and validates the result. Typically product managers, product owners, or tech leads briefing work for their teams.
Executor
Section titled “Executor”A function that implements one phase of the pipeline for a custom workflow. Executors receive a task from the worker, perform their work (typically via Claude Code), and return a requestedTransition naming the next pipeline state. The Colony SDK exports executor contract types and validation helpers. See the Pipeline States reference for which transitions each executor type may request.
A discrete piece of work — a GitHub issue, Azure DevOps work item, or similar ticket. Issues are Colony’s primary input: they describe what needs to be done, and the pipeline drives them to completion autonomously. See Core Concepts — Issues for what makes a well-formed issue.
Labels
Section titled “Labels”The projection of Colony’s pipeline state onto your version control system. Colony writes a label (e.g. colony:in-development) to every GitHub issue to reflect its current pipeline state. Labels are write-only: removing or changing a label in GitHub does not affect Colony’s internal state. See Core Concepts — Labels and Tags.
Operator
Section titled “Operator”One of the four human roles in a Colony deployment. The Operator configures the colony, allocates worker capacity, and intervenes when work stalls — typically by posting slash commands on blocked issues. Typically platform engineers, tech leads, or whoever owns the deployment.
Pipeline
Section titled “Pipeline”Colony’s model of your development process. A deterministic state machine that drives issues from New (first ingested) to Done (PR merged). Each tenant has exactly one pipeline. The pipeline is opinionated at the state-machine level but configurable at the behavior level. See Core Concepts — Pipeline.
Pipeline Store
Section titled “Pipeline Store”The per-tenant data layer that backs every pipeline. The authoritative record of all issues, their current states, work history, agent transcripts, cost events, and audit logs. Postgres-backed. GitHub labels are a write-only projection of Pipeline Store state; they do not drive it. See Core Concepts — Pipeline Store.
Repository
Section titled “Repository”A codebase hosted in a version control system — GitHub or Azure DevOps. Each repository belongs to exactly one tenant. Colony reads configuration, file structure, and history from the repository and writes code, opens pull requests, and merges changes back into it. See Core Concepts — Repository.
Reviewer
Section titled “Reviewer”One of the four human roles in a Colony deployment. The Reviewer judges Colony’s pull requests for architectural fit and intent — typically senior ICs, tech leads, or anyone who would review a colleague’s PR today.
Self-Improvement
Section titled “Self-Improvement”A Colony feature that allows Colony to file issues against its own configured repositories based on observed patterns, test failures, or configured tracks. Self-improvement issues flow through the pipeline like any other issue. Configured under self_improvement in colony.config.yaml. Tracks can also be managed via the Colony Cloud dashboard.
Slash Commands
Section titled “Slash Commands”Commands posted as comments on GitHub issues to control pipeline state. Operators post them to intervene when work stalls or to trigger specific behaviors. Common examples:
| Command | Effect |
|---|---|
/colony:retry | Unblock a failure-blocked issue and re-queue it |
/colony:reimplement | Close the current PR and re-queue the issue for a fresh development attempt |
/colony:state <state> | Move the issue to a specific pipeline state |
/colony:review | Request a Colony review of an external (human-authored) PR |
/colony:pause | Pause a running issue |
/colony:resume | Resume a paused issue |
Sponsor
Section titled “Sponsor”One of the four human roles in a Colony deployment. The Sponsor charters the rollout, sets risk envelopes, and tracks throughput and cost at an organizational level — typically engineering managers, directors, or whoever owns the budget.
Sprint Master
Section titled “Sprint Master”The central conductor of the pipeline — Colony’s always-on pipeline orchestrator. There is one Sprint Master per tenant. It ingests newly created issues, delegates work to available workers, manages cross-issue dependencies, and runs recovery protocols when work stalls. See Core Concepts — Sprint Master.
The current position of an issue in the pipeline. Every issue is in exactly one state at any time. The state determines what work happens next and which executor will claim it. Colony defines 16 states; see the full Pipeline States reference for the complete list, valid transitions, and the state machine diagram.
Tenant
Section titled “Tenant”Colony’s top-level organizational unit — both a security boundary and a configuration boundary. Every resource inside a tenant (repositories, workers, API keys, GitHub access) is shared across everything within that tenant. Use a single tenant for multi-repo projects that share resources; use separate tenants for strict isolation between independent groups. See Core Concepts — Tenant.
Tracks
Section titled “Tracks”Self-improvement tracks are configured prompts that tell Colony what kinds of improvements to look for and file as issues on a regular cadence. Each track defines a prompt, a cooldown period, and the target repository. Tracks can be configured in colony.config.yaml under self_improvement (deprecated) or managed via the Colony Cloud dashboard.
Worker
Section titled “Worker”An individual unit of work capacity — a container running a Colony agent process. Workers listen for tasks enqueued by the Sprint Master, claim one task at a time, execute the work autonomously, and report the result back to the Pipeline Store. Any worker can handle any task type (analyze, plan, develop, review, merge). Pool size controls how many issues are actively worked in parallel. See Core Concepts — Workers.
Work Types
Section titled “Work Types”The five task types that workers execute. Each type corresponds to a phase of the pipeline:
| Work type | When it runs |
|---|---|
| Analyze | Triages the issue — estimates complexity, produces an implementation plan, transitions to ready-for-dev or flags for clarification. |
| Plan | Decomposes an epic-scale issue into smaller, actionable subtasks. |
| Develop | Implements the issue — writes code, runs review checks, and opens a pull request. |
| Review | Inspects the pull request — runs deterministic checks, performs an LLM review, and either approves or requests changes. |
| Merge | Rebases and merges an approved pull request into the target branch. |