Skip to content
Colony Docs

Sponsor

The Sponsor owns the organizational decision to use Colony: where it may act, how much it may spend, what must remain human-controlled, and what evidence justifies expansion. This is a governance responsibility, not a Colony account role.

Charter the rollout

Section titled “Charter the rollout”

Define the initial boundary in terms the system can actually enforce:

  • registered tenants and repositories
  • eligible issue intake and selected workflows
  • configured review commands and code-host branch protection
  • automatic merge enabled or disabled per supported configuration scope
  • cost and attempt limits
  • optional features such as self-improvement, strategy, and external PR review

Start with work whose outcomes and verification are understood. A single-repository pilot is often easier to diagnose, but Colony does not require a particular pilot duration or rollout sequence.

Use real control surfaces

Section titled “Use real control surfaces”

Colony’s controls include:

  • per-issue model cost caps such as claude.max_cost_per_issue
  • broader configured cost budgets where supported by the deployment
  • review.auto_merge_on_approval, a boolean policy—not an LLM confidence threshold
  • configured deterministic checks, review-cycle limits, and provider branch protection
  • workflow selection and intake rules
  • the Strategist’s max_auto_size gate for proposed self-improvement track changes

Colony does not provide a general “human-review-required label” or per-PR automatic-merge override. Apply sensitive-path and approval policy through branch protection, required checks, repository configuration, and workflow design.

Measure from available records

Section titled “Measure from available records”

Pipeline records support measures such as throughput, cycle time, task outcomes, attempts, and cost. Cloud dashboards and self-hosted telemetry expose different views, so verify the metric and time range available in your deployment before committing to a reporting contract.

Useful rollout questions include:

  • How many admitted issues reach done, human-review-ready, or a blocked state?
  • How long does work spend queued, executing, blocked, and under review?
  • What does completed work cost by repository and task type?
  • Which deterministic checks and review findings cause repeated loops?
  • How often do humans need to intervene, and why?

An “escaped defect” rate can be an excellent organizational metric, but Colony cannot infer it reliably without your incident or defect-classification data. Treat it as a joined business metric, not a built-in pipeline fact.

Cloud records server-side audit events and exposes an organization audit-log API. Do not assume a CSV export or a specific dashboard is available unless the relevant Cloud documentation says so.

Expand or restrict

Section titled “Expand or restrict”

Expand when evidence shows the current scope is reliable and operable. Restrict intake, disable automatic merge, pause individual work, disable a repository, or stop the deployment when the risk warrants it. The exact control depends on deployment and desired scope; /colony:pause affects one issue, not the whole organization.

There is no built-in requirement to wait a fixed number of days before expanding. Choose an observation window large enough to cover the work types, failure modes, and release conditions you care about.

Going deeper

Section titled “Going deeper”