Require Approval Before a High-Impact Go-to-Market Change Goes Live

To require approval before a high-impact go-to-market change goes live, connect the repository that holds your Cargo project and make the Cargo check required in branch protection. Cargo counts what each pull request’s merge would send and spend, and when the total goes above 100 emails, 100 LinkedIn actions, 100 chat messages, 5,000 audience adds or 2,500 credits, the check stops with “Needs approval: add the cargo:approve-impact label”. A reviewer reads the counts and adds the label, and Cargo plans the pull request again, this time passing.

This page is about the gate itself: what trips it, how to approve, and who should. How each count is computed is in preview what a change will send before you merge it.

Turn it on #

The gate comes with the connected-repository deploy. Once a repository is connected in Settings → States, every pull request is planned and every plan is assessed against the limits. Two GitHub settings make it binding:

1. Require the Cargo check on the production branch in branch protection. It is named Cargo, or Cargo (directory) for a project that is not at the repository root. Without this, a waiting check is only advice.
2. Protect the production branch so changes reach it only through pull requests. The gate lives on the pull request, so a direct push skips it.

Cargo creates the cargo:approve-impact label on the repository the first time a pull request needs it. The GitHub page covers installing the app.

What counts as high impact #

Cargo totals what every play and one-off execution in the pull request can do, then compares each total with a fixed limit:

The limits are set in Cargo’s code (STATE_RUN_IMPACT_THRESHOLDS, November 2026), and the comparison is strictly above: 100 emails pass, 101 need approval. They are sized so a routine tweak to a play that enrolls a handful of records a day never asks, and a filter that would email a whole model always does.

Three kinds of change trip it in practice:

• A play that starts sending. Adding an email or Slack step to a play that runs on hundreds of contacts, enabling a paused play, or widening its filter. A changed filter counts every record it matches, because a new filter can swap who the play holds.
• A large one-off job. A batch declared in code that enriches 4,000 accounts with a one-credit action is 4,000 credits, above the credit limit even though it sends nothing.
• An audience sync. Adding thousands of records to an ad platform audience.

The check also waits for approval when a play or execution that sends or spends cannot be counted: its model or segment is created by the same pull request, its steps could not be read, or it sends inside a loop that runs an unknown number of times per record. A batch over a workflow passed by workflowRef(uuid) always needs approval for the same reason.

Two things never count toward the limits: actions on a connector that uses your own API key cost zero credits, and steps that call a tool or an agent are noted in the comment without being counted.

How approving works #

1. The check waits. Its conclusion is Action required, which GitHub shows as waiting on someone rather than as a broken build, and a required check in that state blocks the merge. The plan comment opens with the same ask.
2. A reviewer reads the “On merge” table. It lists each play and execution with the records it runs on and what it can send and spend, as upper bounds.
3. The reviewer adds cargo:approve-impact. Adding the label re-plans the pull request, and the new check passes.
4. Removing the label holds it again. Taking it off re-plans and the check waits once more.

The label stays on the pull request across later commits, and each new commit’s plan reads it. So a commit pushed after the approval is approved too, even if it raises the counts. When a pull request changes materially after approval, remove the label and add it again once someone has read the new table.

What the merge does with the approval #

A merge starts only the executions a pull request previewed and approved. Before starting a batch or run, the deploy checks that a successful plan counted that exact version of it, that the plan was approved (under the limits, or labelled), and that it runs on no more records now than the preview allowed: up to 10% over a filter’s or segment’s count, since records keep arriving. An execution that fails a check is held. It stays pending, the deploy’s check names it with the reason, and the next pull request previews it again.

Who should approve #

The label is a judgement about the outside world, so the approver should own the thing the change spends:

• Emails and LinkedIn actions: whoever owns the sending domain, the mailboxes or the LinkedIn seats, since that person answers for deliverability and for what prospects receive.
• Chat messages: the owner of the channel or of the team being notified, when a routing change will post hundreds of alerts.
• Credits: whoever holds the Cargo budget.
• Audience adds: the owner of the ad account.

In GitHub, anyone with triage or write access to the repository can add a label, so the label alone does not limit who approves. Pair it with GitHub’s own controls: a CODEOWNERS file naming the owner of each folder (for example infra/plays/ and outputs/), and branch protection that requires their review. The pull request’s timeline records who added the label and when.

What the gate does not catch #

• Anything under the limits. A play that emails 90 contacts merges without asking. Required reviews cover the changes below the line.
• Sends inside tools and agents. Those steps are noted but not counted, so read them yourself.
• Edits made in the Cargo UI. They never go through a pull request. Pick one owner per resource.
• Pull requests from forks. They are not planned at all.

Counts assume every branch of a workflow is taken, so the table is a ceiling. A play that emails only scored leads will usually send fewer than the table says.

The full CI/CD picture, from plan to rollback, is in CI/CD for go-to-market. Reference: GitHub deploys in the Cargo docs.

FAQ #