Provenance
Follow a change from its first commit to a protected environment.
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 is
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 causal tree. Each promotion hop is a top-level section, joined to the prior hop by the deployment that carried the code forward. Within a hop, nested levels show how the change was produced and checked: pull request or push, merge, run, job and report; gates, policies and rules; reviews; and deployments. A pull request can have runs, reviews and gate evaluations beneath it. A run can have jobs and reports. A gate can have policies and their rules. Each head commit of a pull request also has a Checks row beside its gate: the checks the provider reported for that commit, one row per check with its result, app and a link to the provider when it gives an https address, and a Prodgator tag on Prodgator's own checks. The row shows the counts and starts collapsed unless a check failed or has not finished. A head commit with no recorded checks has no Checks row. At most six levels are shown. Hops start expanded; failed, bypassed, overridden and running paths start expanded, while passed detail starts collapsed.
Nodes keep identifying facts after provider records expire. Details no longer available means the live provider record or copied snapshot has expired or could not be read. The tree still shows facts retained in the provenance event chain, and only shows a provider link when a saved, valid link is available. It does not mean the event chain failed verification.
The list uses filters for verdict, bypass kind, state, repository, branch and time range. Search accepts a pull request number, title or short commit SHA. Open finds unacknowledged bypasses and unverified changes that are not expected; Expected and Reviewed find those recorded states. Repository and branch filters show available counts. The Protected environments column lists every protected environment the change reached, in time order, each linked to its deployment.
Which branches and environments count
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. Lead time ends only after every required protected environment has deployed the change or skipped it as unchanged. The first protected deployment remains a separate milestone. Without a gate covering a deployment environment, lead time cannot be measured. Set up a gate, or see how to enforce provenance without an approval.
How landed code is verified
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.
Concerns
When something on a change's path needs attention, the cause tree shows a concern row in place: a verification concern, a protection bypass, a release override or an incomplete promotion path. Each row says what happened and shows the evidence Prodgator kept, such as the commits involved, who acted and the reason. The change and deployment pages also show an N concerns button. It opens the first concern in the tree, expanding the rows above it. Missing evidence is never shown as a pass.
Provider details
Names follow the provider. GitLab pull requests are called merge requests, and their pipelines appear with GitLab's pipeline wording. Azure DevOps job links are available only when the build has a timeline record ID; otherwise the job is shown without a link. Missing provider data is not replaced with a guessed link.
Next steps
- Read the timeline and lead time.
- Investigate bypassed protection, acknowledge it or manage expected bypasses.
- Attestations: collected evidence, signed attestations on Enterprise and how to verify them.