Provenance

Provenance is in the Delivery sidebar, after Gates, on Business and Enterprise plans. It records how code reached a protected branch and what happened as it was checked and deployed.

What a change isCopy Anchor Link

A change groups a pull request and the commits it landed, or a push directly to a protected branch. Its record connects checks, reviews, reports, bypasses and deployments even when a squash, rebase or merge gives the landed code a different commit SHA. Deleting a protected branch also creates a record, although no code lands.

Open a change to see its timeline. Filter the list by repository, branch, verdict, bypass kind, state or time. Open finds unacknowledged bypasses and unverified changes that are not expected; Expected and Reviewed find those recorded states.

Which branches and environments countCopy Anchor Link

A branch is protected when Prodgator can confirm that the provider applies protection. That can be your own provider rules or a required Prodgator Policies check. Binding an enforced policy alone does not prove the provider requires it.

When protection cannot be read, Prodgator treats the repository's tracked branch as protected, using the default branch if no tracked branch was chosen. The record says Treated as protected: tracked branch. This fallback also applies to sources without readable branch protection, such as Jenkins or a custom CI source; it does not add provider facts those sources cannot supply.

Release checks and lead time use protected environments: deployment environments covered by at least one Prodgator gate. The deployment's branch does not decide whether its environment is protected.

How landed code is verifiedCopy Anchor Link

Prodgator compares the landed commits with recorded passing evaluations, rather than requiring the commit SHA to stay the same:

• Same code as the checked merge preview: the landed files match the checked commit's tree.
• Same change as the checked commits: the landed commit's change against its parent matches the checked change. This can connect rebased or cherry-picked code.
• Merge with no changes of its own: a merge brings together covered parents without adding its own changes. An empty commit can also add no content.

Every commit in the landed range must be accounted for. A pull request association alone does not verify its code. Content added after checks, conflict resolutions that checks did not see, or landing without a passing evaluation can leave a change Unverified. Unknown means the available provider evidence cannot decide; Pending means the record is not yet decided.

A verified content match and a protection bypass are separate facts. A provider override can still appear on code whose content was checked.

Next stepsCopy Anchor Link

• Read the timeline and lead time.
• Investigate bypassed protection, acknowledge it or manage expected bypasses.
• Attestations: current evidence and planned export and signing.