ACTION TYPE · SHIP A CHANGE

Changes that reach production because the pipeline said yes.

Configuration pushes, releases, infrastructure changes, feature flags. Coding agents and release bots already ship; the change-management rules exist, and the pipeline is where they are supposed to hold.

Who runs it today: AI coding agents, release bots, infrastructure-as-code pipelines.

The rules that usually govern it

  • Only inside an approved change window
  • Reviewed by someone other than the author
  • A signed rollback plan for critical systems
  • No change during a declared freeze

Typical rule shapes, not a claim about any one organisation. A pilot starts from yours.

Where rules like these break

  1. The approval was for a different change.

    A review approves a diff. If what ships is not bound to the diff that was approved, the approval travels to changes nobody read.

  2. The window is checked by the thing it constrains.

    A pipeline that decides whether it is inside the window can be asked to decide differently. The check belongs in front of the action, not inside it.

What the gate does

  1. 01

    Checks each request against the proven policy before it executes. What fails never reaches the system.

  2. 02

    Refuses when a window or population the rule depends on is missing or does not reconcile, instead of guessing.

  3. 03

    Seals every decision, allow or block, so it can be re-checked without us.

What you can check today

NOT YET

Nothing public yet for this action type. The decisions on the home page are illustrative, under a sample policy. A pilot is where the first sealed pack for deployments would come from.