Mandates

A mandate is a standing statement of what Coroid should work on when nobody is there to ask: an objective, the projects it covers, a budget per week or month, and when to stop. Requests that arrive from your systems — the work intake API, automations, integrations, monitoring — are admitted against your active mandates. Requests people make are not; see Which requests a mandate governs.

A mandate decides what work may start. It does not let Coroid merge or deploy anything. See What Coroid decides, and what stays with you.

When a mandate makes sense#

Write a mandate when work reaches Coroid without anyone asking for each piece, and you want to decide in advance how much of it may happen:

• an error tracker or monitoring tool that reports incidents through the work intake API;
• GitHub issues, or Slack, Telegram and Jira messages, that a Qualify work automation turns into requests;
• a support or feedback tool that passes on what customers report;
• a scanner or CI job that files findings one by one.

Without a mandate, these requests are treated like any other: once they qualify, they queue for the same agent slots as the work people ask for, with no budget of their own. A busy week of alerts can then fill your queue. A mandate fences them in: which projects they may touch, how much they may spend per week or month, and how many agent slots they may hold at once.

How a request travels#

Take the mandate in the figure, written for a project called Billing API. Its error tracker raises an alert for a new exception in the invoice export. The alert rule's webhook, through a small relay of your own, files it with the work intake API, with the tracker's issue id as the signal fingerprint, the affected route, and 500 requests as the exposure that must pass before the fix is judged.

1. Qualification runs as for any request: it removes secrets and personal data, checks the current release, looks for duplicates, verifies the report and assesses it.
2. Admission finds the mandate that covers Billing API and checks, in order: whether the same issue is already being handled, here or in another project; whether the assessment found the behavior intended; whether one of the mandate's two slots is free; whether this week's budget has room; and whether the outcome can be measured.
3. Admitted, the request becomes a task with a reserved slot and part of the week's budget. It goes through the normal path — specification, code, tests, quality gates, QA and review — and ends as a pull request.
4. A person merges it. The task's outcome contract records what that merge should achieve: no new event for that issue for 24 hours after 500 requests on the route.

If the same alert fires again, the second request is already resolved and linked to the first. If a bad deploy produces six new issues at once, no more than two run under the mandate at a time; the rest are deferred, then admitted one by one as the mandate's slots free up. The other two agent slots stay free for what your team asks for in New Work.

Example mandates#

Keep production errors from piling up#

Your API services report errors to an error tracker, and fixing them happens when someone has time.

Requests arrive from the error tracker through the work intake API, each with a signal naming the tracker's issue id, the routes and a request count. Each issue becomes at most one piece of work, however often it fires. A bad week costs at most 100 USD. An alert sent without routes waits rather than starts, because nothing could tell whether its fix worked; send the routes, or turn on Admit work whose outcome cannot be measured.

Work through bugs reported in GitHub#

Users open issues in your web app's repository faster than anyone triages them.

A Qualify work automation on new GitHub issues files each one. Qualification stops duplicates, issues the current release already fixes and reports it cannot reproduce. The measurability switch is on because an issue names no routes or traffic, so its outcome contract cannot be measured; with the switch off, every issue would wait. Issues opened by people with write access start on their own; the rest wait for someone to start them, as described in When the work starts.

Act on what customers report#

Your support tool collects reports from customers, and the urgent ones reach engineering late.

The support tool files each report through the work intake API with a service account. Qualification turns away what it cannot reproduce, and the mandate keeps a busy week of reports from taking more than half your agent slots or more than its budget.

Finish a clean-up before a deadline#

A payment SDK you use reaches its end of life next quarter, and its deprecated calls are spread over two services.

A CI job files one request per call site, with the file and line as the signal fingerprint, so a call site found again on the next run is linked to the work already handling it. Coroid does not read the target yet: when the last call is gone, choose Complete yourself.

When you do not need a mandate#

• Work people ask for. Requests made in New Work or imported are admitted when they qualify, never deferred, and never spend a mandate's budget.
• Schedules and hook follow-ups. They create tasks directly, without Qualification, so no mandate limits them. Give them a lower priority instead; see Schedules.
• A one-off initiative. Work with a known shape and an end is a plan, not a mandate.
• Overlapping mandates. When several active mandates cover the same project, the oldest one governs its requests. Give each project to one mandate.

Where mandates live#

Open Quality Control → Mandates. Every scope in Quality Control — the organization default and each project — links to the same list, because a mandate belongs to the organization and names its projects itself. Opening a project's scope does not filter the list.

Owners and admins create and change mandates. Members can read them. Agents and service accounts cannot change a mandate at all.

What a mandate contains#

Kind. Finite mandates have a target and end when it is reached, for example "cut the open security findings to zero". Ongoing mandates are maintenance, for example "keep production routes free of unhandled exceptions"; they have a review date instead of a target.

Objective. One sentence saying what should be true. It is how people read the mandate; admission itself goes by the scope, budget and status.

Baseline. The metric the mandate is measured against, and where it comes from. You name the metric, and readings are collected by Coroid, never typed in. They never travel in a settings export. A new mandate shows No reading yet.

Target. For a finite mandate: the metric and the value that means done.

Priorities. One per line. When work competes for capacity, the first priority wins.

Scope.

• Projects. The projects the mandate covers. With none ticked, it covers every project of the organization, including projects created later. Tick the projects you mean; a mandate written for one repository should name that project.
• Areas. Path patterns inside those projects, one per line, for example apps/api-*/src/**. Empty means anywhere.
• Change classes. The kinds of change the mandate is for, for example exception_fix.
• Admit work whose outcome cannot be measured. Off by default. When it is off, a request whose outcome contract cannot be measured waits instead of starting.

Budget. What Coroid may spend on the mandate in each window, in US dollars and agent hours, per week or per month. A week starts on Monday at 00:00 UTC; a month on its first day. The budget opens again on its own.

Stopping conditions. Stop when the budget is spent, when the target is reached, after a number of inconclusive results in a row, or on a date.

Review date. For an ongoing mandate: the date on which a person renews or retires it.

Drift rule. For an ongoing mandate: a bound on the baseline metric. Crossing it in a window is meant to raise an escalation to the owner.

Status and versions#

A mandate starts as a draft. Publish makes it active, and only active mandates admit work.

Changing a published mandate publishes a new version. Earlier versions are kept with who published them and when.

Every publish and every status change is a decision in the mandate's provenance, with the person who made it, and an event in your organization's audit stream (mandate.created, mandate.published, mandate.paused and so on).

Which requests a mandate governs#

A mandate governs requests that arrive without a person in Coroid: from the work intake API, from automations and integrations such as GitHub or Jira issues, and from monitoring.

A request a person makes in New Work, or imports, is not held to a mandate. It is always admitted when it qualifies, it is never deferred, and it does not spend a mandate's budget. A person asked for it; the agent slots simply queue it.

An unattended request is matched to the oldest active mandate whose projects include the request's project, or that covers every project. A request that no mandate covers is admitted as an ordinary request.

What admission decides#

Admission is the last step of Qualification. It makes no model call. For each request it decides one of:

• Admitted. The work is created, with a reservation for an agent slot and, under a mandate, for part of the mandate's budget. Whether it then starts on its own follows the source, as described in When the work starts.
• Already resolved. The same signal — the same issue in your tracker or monitoring, or the same failure — is already being handled under another request in any project of the organization. The request is linked to that work, and nothing new is created.
• No change needed. Qualification's assessment found the reported behavior is intended. Nothing is created.
• Deferred. The request is admissible but should not start now: the mandate's share of agent slots is in use, its budget for the window is spent, or its outcome cannot be measured and the mandate does not admit that.

Each decision and its reason is recorded with the request.

Deferred requests#

Coroid looks at deferred requests again every minute and admits them as soon as a slot or budget is free, under the mandate's current version. Raising the mandate's budget, or pausing another mandate that holds slots, frees a deferral on the next check. There is no override that starts one directly.

A request that has waited longer than its mandate's window — a week or a month — or whose mandate is no longer active, ends without work.

How mandate work shares capacity#

Mandate work may hold at most half of your organization's agent slots at once, counting work that is running and work admitted but not yet started. The rest stays free for what people ask for. If your plan has unlimited slots, the same share applies to your monthly spend budget instead.

An admitted request holds its reservation for 30 minutes while its task starts. After that the reservation lapses: a request whose work was not created yet goes back to deferred, and a task that exists waits for a slot like any other.

In a settings export#

Mandates travel in a settings export: kind, objective, target, priorities, scope, budget, stopping conditions, review date and drift rule. Projects are matched by their stable key, and the owner by role. Baselines never travel; they are measurements of the organization they came from. A mandate with a new objective arrives as a draft for a person to publish. One whose objective matches an existing mandate updates it: the draft if it is still a draft, otherwise as a new published version.

Related#

• Outcome contracts
• What Coroid decides, and what stays with you
• Capacity and agent slots
• New Work and Qualification
• Provenance