Pull request input document

The input documentCopy Anchor Link

Every evaluation builds an input document. Both subjects share a core (attestations is shortened here; see the release input document for its fields):

{
  "version": "prodgator.input/v1",
  "subject": "pull_request",
  "evaluatedAt": "2026-09-29T09:35:00.000Z",
  "repository": { "name": "acme/api", "id": "365246789" },
  "commitSha": "9f3c1a0",
  "commitSeenAt": "2026-09-29T09:31:10.000Z",
  "commitAgeSeconds": 230,
  "actor": { "login": "octocat", "providerUserId": "583231", "prodgatorUserId": "user_01H...", "groups": ["grp_release"], "isBot": false },
  "checks": [
    { "name": "test", "source": "check_run", "app": null, "status": "completed", "conclusion": "success", "url": null }
  ],
  "labels": ["ready"],
  "attestations": [],
  "workflows": {
    "supported": true,
    "known": true,
    "settled": false,
    "runs": [
      { "runId": "17004151", "workflow": "CI", "finished": true },
      { "runId": "17004152", "workflow": "Docs", "finished": false }
    ],
    "referenced": [
      {
        "path": "acme/platform/.github/workflows/build.yml",
        "ref": "refs/tags/v2",
        "sha": "1b9e4c7d2f0a8e6b5c3d1f9a7e5c3b1d9f7a5e3c",
        "runId": "17004151",
        "workflow": "CI"
      }
    ]
  },
  "security": null,
  "approvals": [
    {
      "prodgatorUserId": "user_01H...",
      "email": "jane@example.com",
      "groups": ["group-id"],
      "decision": "approved",
      "at": "2026-09-29T09:20:00.000Z",
      "providerLogin": "jane",
      "commitSha": "9f3c1a0"
    }
  ],
  "aiAssisted": { "value": true, "tools": ["claude"], "signals": ["commit_trailer"], "current": true }
}

• subject is release or pull_request.
• repository.id is GitHub's numeric repository id, as a string. It is null before Prodgator has recorded the run or pull request.
• actor is who started the deployment (release) or opened the pull request (pull request). prodgatorUserId is null when that person has not linked their GitHub account in Prodgator. groups lists the approver group ids of the linked account (empty when not linked). isBot is true for a GitHub account of type Bot or a login ending in [bot]. Inputs stored before groups and isBot existed lack them. The Allowed actors rule reads actor.
• checks and labels are null when Prodgator could not read GitHub facts.
• commitSeenAt is when Prodgator first saw commitSha: the first evaluation of a pull request's head commit (or merge group commit), or the deployment's creation for a release. commitAgeSeconds is the whole number of seconds from then to evaluatedAt. Both are null when unknown, for example in inputs stored before they existed. The Required checks rule counts its wait for checks to start from here.
• attestations has the same fields on both subjects, including workflowSha and jobWorkflowSha. See the release input document for the list.
• workflows lists the reusable workflows the subject's GitHub Actions runs called: every workflow run on commitSha for a pull request, the deployment's run for a release. It is null when Prodgator could not read the runs. The Required reusable workflow rule reads it.
  • referenced holds one entry per call: path is the called workflow as owner/repo/.github/workflows/file.yml (a call inside the same repository gets its name in front), ref is the ref the caller used (refs/heads/main, refs/tags/v2, or a commit SHA when the call is pinned), sha the commit the call resolved to, and runId and workflow the run that made the call. ref and sha are null when GitHub does not report them. At most 100 calls are listed.
  • runs lists the runs read (at most 50), with finished false while a run is queued, running or waiting.
  • known is false until a run has reported its calls: no workflow run on the commit yet, or a release whose run Prodgator recorded before it stored the calls.
  • settled is true when no more calls are expected: for a pull request, once every run on the commit has finished; for a release, once the run's calls are known (a run's calls are fixed when it starts). It stays false when the list of calls was cut at 100.
  • supported is false for releases from GitLab and Bitbucket, which do not report reusable workflow calls; the lists are then empty.
• security is null when your plan does not include security findings, or on a pull request whose policies have no security rule, custom rules or Rego (it is only read then). Otherwise it describes the security findings of the commit compared with a baseline (see the security rule for what counts as new):
  • scanned is true when a security report, a run report or (for a pull request) a GitHub source reported on the commit.
  • On a GitHub or Azure Repos pull request, CI scans the temporary merge commit (refs/pull/N/merge). A run report from that build counts for the pull request head it tested, and only for that pull request. A scan of an earlier head does not count for a newer one.
  • baseline.ref is the branch new findings are compared with and baseline.kind is tracked_issues (the repository's open findings) or branch_findings (the open findings uploaded for another base branch).
  • openIssues, headFindings and introduced count by severity (critical, high, medium, low and total): the repository's open findings, the findings reported for the commit, and those that are new.
  • sources names the scanners that reported. issues lists the 50 worst new findings: findingId, severity, title, vulnIds (CVE or GHSA ids), source and path (or null).
  • unavailable lists the sources that could not be read: uploads, baseline, code_scanning, dependency_review or secret_scanning.
• approvals holds each person's latest approval or rejection given in Prodgator. commitSha is the head commit the approval was given on; null for a release approval, since release approvals are per deployment rather than per commit.
• aiAssisted says whether the pull request is AI-assisted; it is null when your plan does not include AI impact (Business and Enterprise), no policy on the pull request has an AI-assisted changes rule, custom rules or Rego (it is only read then), or the classification could not be read. value is true when it is. tools lists the AI tools found (claude, copilot, cursor, devin, codex, gemini, jules, aider, or other). signals lists the kinds of evidence: commit_trailer (a commit message ends with an AI tool's trailer), commit_author (an AI agent authored a commit), description (the description ends with such a trailer), agent_author (an AI agent account opened it), agent_branch (its branch name is an AI agent's, when your organization turned that on), label (one of your organization's AI labels; never on Bitbucket, which has no labels), and vendor_commit or vendor_session (an AI vendor's own records). Labels, the author and the branch are read on every evaluation; commits a few seconds after each push. current is true once the commits of the head commit were read: value: false with current: false means not known yet. The AI-assisted changes rule reads it.

A pull request input adds these sections on top of the core:

{
  "event": "pull_request",
  "pullRequest": {
    "provider": "github", "number": 42, "title": "Add billing", "url": "https://github.com/acme/api/pull/42",
    "state": "open", "draft": false, "merged": false,
    "headSha": "9f3c1a0", "headRef": "feat/billing", "headRepository": "acme/api", "isFork": false,
    "baseRef": "main", "baseSha": "4f2c1e0", "association": "MEMBER", "authorType": "User",
    "createdAt": "2026-09-29T08:00:00Z", "updatedAt": "2026-09-29T09:00:00Z", "mergeGroup": null
  },
  "reviews": {
    "githubDecision": "APPROVED",
    "latest": [
      { "login": "reviewer", "providerUserId": "12345", "prodgatorUserId": "user_02H...", "groups": [], "state": "APPROVED", "commitId": "9f3c1a0", "stale": false, "at": "2026-09-29T09:10:00Z", "association": "MEMBER" }
    ]
  },
  "files": { "total": 3, "additions": 42, "deletions": 5, "listed": [{ "path": "src/billing.ts", "status": "modified", "additions": 40, "deletions": 5, "previousPath": null }], "truncated": false },
  "ownership": { "source": "report", "commitSha": "1b2c3d4", "files": [{ "path": "src/billing.ts", "owners": ["acme/billing"], "line": 12 }], "truncated": false },
  "expectedChecks": [{ "name": "build", "integrationId": 15368, "source": "ruleset" }],
  "expectedChecksKnown": true,
  "pendingSuites": [{ "name": "CI", "source": "workflow_run", "app": "github-actions", "status": "completed", "conclusion": "action_required", "url": "https://github.com/acme/api/actions/runs/1" }]
}

• event is pull_request for a normal evaluation, or merge_group for a merge queue evaluation. pullRequest.mergeGroup then holds the merge group's own head and base.
• pullRequest.isFork is true when the pull request's head repository differs from its base repository. headRepository is null when GitHub reports no head repository (a deleted fork).
• reviews.githubDecision mirrors GitHub's reviewDecision: APPROVED, CHANGES_REQUESTED, REVIEW_REQUIRED or null. reviews.latest keeps one entry per reviewer, the newest decisive review (approval, changes requested or dismissal) or, failing that, the newest comment; stale is true when that review was given on an earlier commit than the one being evaluated.
• files is null when Prodgator could not read the changed files; otherwise truncated is true when the pull request has more files than Prodgator lists.
• expectedChecks lists the status checks GitHub requires on the base branch, from rulesets (source is ruleset) and classic branch protection (branch_protection), whether or not they have reported on the commit. integrationId is the GitHub App a rule pins the check to, or null. Prodgator Policies is left out. expectedChecksKnown is false when Prodgator could not read those rules; expectedChecks may then be incomplete.
• pendingSuites lists GitHub Actions workflow runs on the commit that are queued, waiting or waiting for approval, and other apps' check suites waiting for approval. They may have no check runs in checks yet.
• ownership lists, for each changed file with code owners, its owners (GitHub logins or org/team, lower-cased, without @) and the line of the ownership file that matched, at most 300 files (truncated is true past that, or when the changed files are not known). commitSha is the commit whose ownership report was used: the base commit, or else the latest report for the base branch. It is null when no report exists. When the report could not be read, source is "unavailable", commitSha is null, files is empty and truncated is true. It is only read when a policy has a code owners rule, custom rules or Rego.

GitLab merge requestsCopy Anchor Link

A GitLab merge request produces the same document, so one policy serves both providers. pullRequest.provider is gitlab; a custom rule or a Rego policy can branch on it. The fields are filled from GitLab as follows:

• pullRequest.number is the merge request iid (the number in its URL); repository.name is the project path and repository.id the project id. pullRequest.association is always NONE and authorType is User.
• commitSha is the commit the head pipeline ran on: the merge request's head, or the merged result when the project uses merged results pipelines. pullRequest.headSha stays the merge request's head.
• checks holds the commit statuses of that commit, one per name, newest wins: every pipeline job and any external status, with source set to status. A success job is completed and success; failed is failure, or neutral when the job allows failure; canceled is cancelled; skipped and manual jobs (not started) are skipped; running is in_progress; anything queued is queued. Prodgator Policies is left out.
• reviews.latest has one APPROVED entry per approver GitLab lists on the merge request (GitLab resets approvals on a push by default, so they stand for the current head), one CHANGES_REQUESTED entry per reviewer who requested changes, and COMMENTED for a reviewer who reviewed without a decision. reviews.githubDecision is derived: CHANGES_REQUESTED when any reviewer requested changes; otherwise, when the merge request needs approvals, APPROVED once none are left and REVIEW_REQUIRED until then; otherwise APPROVED with at least one approver and null with none.
• files comes from the merge request's diffs, with additions and deletions counted from each diff.
• expectedChecks is empty and expectedChecksKnown is true: GitLab has no required-status rules to read. pendingSuites is empty: every pipeline job is already in checks, and the pipeline itself stays running while the Prodgator Policies status is pending, so it is never waited on. It holds the head pipeline only when the commit statuses could not be read. workflows is an empty list.
• labels are the merge request's labels.
• security counts what the commit (commitSha) introduces from security reports and run reports sent for it. GitLab has no code scanning, dependency review or secret scanning sources to read, so sources never lists them. As for GitHub, it is only read when a policy has a security rule, custom rules or Rego.
• ownership is always null: ownership reports come only from GitHub runs, so a code owners rule follows its When the base branch has no ownership report setting and its reason says that GitLab merge requests have no report.

Bitbucket pull requestsCopy Anchor Link

A Bitbucket Cloud pull request produces the same document. pullRequest.provider is bitbucket. The fields are filled from Bitbucket as follows:

• pullRequest.number is the pull request id; repository.name is workspace/repository and repository.id the repository UUID, braces included ({0a1b2c3d-...}). pullRequest.association is always NONE and authorType is User. actor.providerUserId and each review's providerUserId are Bitbucket account UUIDs, which is what a linked Bitbucket account matches.
• commitSha and pullRequest.headSha are the full hash of the pull request's head commit.
• checks holds the commit's build statuses, one per key: SUCCESSFUL is completed and success, FAILED is failure, STOPPED is cancelled, and INPROGRESS is in_progress, with source set to status. Prodgator Policies is left out.
• reviews.latest has one APPROVED entry per participant who approved and one CHANGES_REQUESTED entry per participant who requested changes. Bitbucket lists only standing decisions, so they count for the current head. reviews.githubDecision is CHANGES_REQUESTED when anyone requested changes, APPROVED when anyone approved, and null otherwise.
• files comes from the pull request's diffstat.
• labels is always empty: Bitbucket pull requests have no labels.
• expectedChecks is empty and expectedChecksKnown is true: Bitbucket's branch restrictions count builds, they do not name them. pendingSuites and workflows are empty lists.
• security and ownership are filled as for GitLab merge requests: security reports and run reports only, and no ownership report.

Azure DevOps pull requestsCopy Anchor Link

An Azure Repos pull request produces the same document. pullRequest.provider is azure. The fields are filled from Azure DevOps as follows:

• pullRequest.number is the pull request id; repository.name is organization/project/repository and repository.id the repository GUID. pullRequest.association is always NONE. actor.providerUserId and each review's providerUserId are Azure DevOps identity GUIDs, which is what a linked Azure DevOps account matches.
• commitSha and pullRequest.headSha are the full hash of the pull request's source commit.
• checks holds the statuses on the pull request and on its head commit, the latest one per genre and name. succeeded is completed and success, notApplicable is completed and neutral, failed and error are failure, and pending is in_progress, with source set to status. prodgator/policies is left out.
• reviews.latest is built from reviewer votes: approved (10) and approved with suggestions (5) are APPROVED, rejected (-10) is CHANGES_REQUESTED, waiting for the author (-5) is COMMENTED, and no vote adds nothing. A group reviewer is left out: its members vote. reviews.githubDecision is CHANGES_REQUESTED when anyone rejected, APPROVED when every required reviewer has voted and at least one approved (or, with no required reviewer, when anyone approved), and REVIEW_REQUIRED otherwise. Prodgator reads votes and never casts one.
• files comes from the changes of the latest iteration.
• labels holds the pull request's labels.
• expectedChecks is empty and expectedChecksKnown is true: Azure DevOps' status policies do not name builds the way GitHub's required checks do. pendingSuites and workflows are empty lists, because Azure Pipelines report as statuses from the moment they start.
• security and ownership are filled as for GitLab merge requests: security reports and run reports only, and no ownership report.

A Rego policy that reads both subjects branches on input.subject:

package prodgator.policy

pr_result := {
	"rule": "checks_pass",
	"status": "pass" if count([c | some c in input.checks; c.conclusion != "success"]) == 0 else "fail",
	"blocking": true,
	"reason": sprintf("%d checks read", [count(input.checks)]),
}

release_result := {
	"rule": "main_only",
	"status": "pass" if input.release.branch == "main" else "fail",
	"blocking": true,
	"reason": sprintf("deploying from %v", [input.release.branch]),
}

results := [pr_result] if input.subject == "pull_request"
else := [release_result]

Release policies read the same core plus a release section. See Release input document.