Timeline and lead time
Read a change's checks, reports, bypasses and deployments in order.
Open a change from Provenance, or follow Open in Provenance from a run, deployment or pull request. The detail page shows the verdict, landed commits, bypasses and the causes table: a tree of what led to the change, from the first pull request through runs, jobs, tags, releases and deployments.
Read the evidence
The timeline records available first commits and pull request updates, gate evaluations, reviews, test counts, coverage, scans, software bills of materials, build provenance, finding carry-over, pipeline results, compliance decisions and deployments. Events link to their source when a link is available.
Checks the provider reports for a pull request's head commit are recorded per head commit as a event, so a later push does not overwrite what an earlier commit showed. The pull request's expanded row on the Pull Requests page lists them.
A missing fact is not a passing check. Not reported means the provider or source did not supply that fact. Open Landed commits to see how each commit was matched to checked code and why any commit remains unverified.
Bypasses include their kind, actor when known, time and evidence. Confirmed by means the provider reported the bypass; Inferred from the push means Prodgator inferred it from the available facts. See provider coverage.
The Audit event link opens Organization > Audit Log for members who can read the audit log and whose plan includes it. It opens the linked audit entry.
Lead time
Lead time runs from the first known commit to the first recorded successful deployment containing the change in a protected environment. If the first commit's time is missing, it starts at pull request opening, then at landing if the opening time is also missing. The page names the start used and the environment reached.
A later deployment can include the change through a descendant commit. Prodgator must be able to confirm that the deployment contains the landed commits. Failed deployments and deployments to environments without gate coverage do not establish this milestone. If no qualifying deployment has been recorded, the milestone and lead time remain unreported.
Record integrity and retention
Record intact means the retained timeline events pass the stored hash-chain check. Record changed after writing identifies an event where that check failed. Ask your Org admin to investigate an integrity warning before relying on the record.
Older events can expire under your plan's retention. Earlier events expired means verification starts at the retained portion; expiration alone is not evidence that someone changed the record. The Record card on the side of the page has a Download record button. It saves a nested cause tree as a JSON file built by the server. A hash-checked record is not a signed attestation; on Enterprise you can request a signed one.
Download record
Choose Download record in the Record card. The file uses schema . It includes the export time (), the change page , identifying fields, integrity fields, and a nested .
Each node has an , , plain English , , , , , allowlisted and . Children follow the same cause hierarchy as the table, including concern nodes. Provider names and other text are plain text. Release bodies are excluded.
The node opens that node on the change page. opens the provider object when an HTTPS link was reported. opens the related app page when available. App links carry to offer the correct organization. A missing or unsafe link is .
is , , or . is the stored chain head, is the first retained sequence checked, identifies the failed sequence when known, and is the recorded event count. Nodes derived from chained events carry matching and arrays. Nodes from live records alone have empty arrays. These references identify the source events; the file is a view of the record, not a signed attestation or a copy of the complete hash-chain inputs.
The export loads more detail than the ordinary tree view, with hard limits of 6,000 nodes, 4 MB and 400 reads. When history is incomplete or a limit is reached, is . names the code and explains it in plain English. A truncated record must not be treated as a complete history.
The download needs the same organization membership and plan feature as the tree view, and it always uses your current organization.