Verified changes and promotion checks

Only verified changes reach protected environmentsCopy Anchor Link

verified_changes_only checks the deployment's change and contained open unverified changes in its ancestry. An unverified change that is neither expected nor acknowledged fails, with the bypass kind, actor when known, repository and change ID in the evidence. Expected or acknowledged changes are excluded from that failure; acknowledgement does not rewrite their verdict. Pending verification waits. Unreadable history follows the policy's error behavior.

Promotion path checksCopy Anchor Link

These checks do not carry a release policy's own path or its Allow verified changes option. The compliance coverage check does not require a coverage report in every environment; use the release policy's Coverage along the promotion path rule for that requirement.

Outcomes and errorsCopy Anchor Link

Checks return not_applicable on pull requests, outside environments covered by gates, or without release provenance in the plan. They return pending while change verification, the deployment or lineage is pending. An incomplete or truncated ready lineage, an unreadable promotion step or a release off the declared path fails even with onEvaluationError: fail_open. If a promotion step is pending, the declared-path check waits before reporting other step problems.

For other read or evaluation errors, onEvaluationError uses Fail closed by default (fail_closed, fail) or Fail open (fail_open, pass with the error sentence as evidence). Choose fail closed to hold releases when evidence cannot be read. In API request bodies this setting is on_evaluation_error.

After Wait for CI expires, fail open releases a pending provenance check only while lineage collection itself is still pending. A pending promotion step or a missing deployment ID fails at that deadline. If a policy has several pending checks, all must be waiting on lineage collection for fail open to release it.

Missing coverage or scans fail. Invalid thresholds are rejected when saving; old invalid thresholds fail evaluation. Evidence sentences explain the result, for example uat was skipped, Lowest coverage along the promotion path is 75% (needs 80%) or 1 high findings along the promotion path.

Add checks through the APICopy Anchor Link

There is no rule picker on the Compliance page. With an authenticated app session and compliance:manage, send POST /api/compliance/policies/create with this body. The organization comes from authentication; do not send an organization ID.

{
  "name": "Verified promotion",
  "description": "Check changes and promotion evidence before production",
  "category": "deployment",
  "enforcement_level": "advisory",
  "rules": [
    { "ruleId": "verified", "description": "Only verified changes", "check": "verified_changes_only" },
    { "ruleId": "unchanged", "description": "Unchanged upstream code", "check": "lineage_unchanged" },
    { "ruleId": "path", "description": "Follow the declared path", "check": "declared_path_followed" },
    { "ruleId": "coverage", "description": "At least 80% coverage", "check": "chain_coverage_min", "threshold": 80 },
    { "ruleId": "findings", "description": "No high or critical findings", "check": "chain_no_findings", "threshold": 3 }
  ]
}

Creation returns an id and starts in Monitor. On Enterprise, a member with compliance:manage can then send PATCH /api/compliance/policies/{id} with:

{
  "mode": "block",
  "on_evaluation_error": "fail_closed",
  "environments": ["production"]
}

You can also set these enforcement options on the policy's row in Compliance. Environment names apply across repositories. See Block deployments for provider setup, pending decisions and break-glass, and overrides for releasing past a promotion result.