This is how a normal week looks. A developer adds a package on your develop branch and pushes. SourceTrust reads the branch, checks the new package and asks you to review it there. When develop is merged into main, the package is already approved on production, because a review a person made is remembered for your whole organization. It works the other way round as well: a fix that goes straight to main is reviewed on production, and when main is merged back, the same package on develop is already done.
Each repo-connected project (GitHub, GitLab, or Azure DevOps) always watches a Production branch. Watching a Testing branch is optional: turn it on during Connect or later in project settings with Watch a testing branch. Production inventory is what you publish on the public attestation page. Testing is a separate inventory for reviewing changes before they reach production.
Above the package list you pick the branch you are looking at. With two branches it is one control in two parts, each part showing the role, the branch name and how many packages there still need review, so you can see both at once. With three or more branches it is a list you open. The branch you pick stays in the address of the page, so a reload keeps it and a link you send opens the same branch.
How they differ
- Production: only this branch feeds the public attestation page when you click Publish.
- Testing: vendor-only review lane. It never publishes on the public attestation page automatically.
- The same package on both branches is two rows, one per branch. A review you make on one of them is used on the other one as soon as it is checked there, as long as it is the same version and we found the same thing about its license.
A clean promotion is quiet: packages you already approved on Testing are already approved on Production, with no Change badge and no second review nudge. You are not asked to review work you just finished.
Open the project Before merge tab when the project has two branches to see which approvals would carry and whether publishing would succeed. Reviews are shared between your branches, so the tab usually has little left to report. Comparison runs when you open that tab. Before merge keeps each exact package version and source or peer variant visible and uses the same eligibility as review transfer: both packages must be present, Testing must be approved, and versions and legal inputs must match. A removed package or different legal inputs cannot carry an approval. One unambiguous gap between versions shows both versions as a blocker without predicting a transfer. Ambiguous unmatched variants stay separate, and packages present on only one side remain one-sided. The separate Production review count includes every package that would still need review.
When a review is not used again
A review is used again only for the same package at the same version, and only while what we found about its license is unchanged. A version bump, a different license file or a changed statement from the publisher all mean the package is looked at once more. Your project's own rules still apply: if this project ships binaries and a step is open here, the license and the text are copied and the package keeps that one step for you. A package that has never been checked on this branch yet is still waiting for its check, not for a merge. After a release, the Changes section Reviews that did not carry over from Testing gives the full actionable total and a sample of affected packages with the exact reason, for example the version reviewed on Testing versus the one now on Production. It says when additional packages are outside the sample.
When Production moves ahead of Testing
Normally Testing leads and Production follows. If a change lands straight on your Production branch (a hotfix committed there directly), Production can move ahead of Testing. Those changes are still reviewed on Production, and your dashboard shows a Testing behind badge on the project so you know the two lanes have diverged. The badge links to Before merge so you can see the current gap. Packages removed directly on the Production branch also count until Testing catches up, and the dashboard banner lists the affected packages with their Production and Testing versions. Reconcile by merging Production back into Testing in your repository. The flag clears automatically once Testing catches up, and the reviews you did on Production are already there.
Manual upload projects
Manual lockfile upload uses one inventory by default. You can turn on separate Production and Testing upload lanes in project settings, but you maintain both lockfiles yourself. Reviews are shared between the two lanes in the same way. On the first repository connection, any manually uploaded Production and Testing inventory is permanently deleted, including review decisions, pasted license text, obligation acknowledgements, vulnerability findings and acknowledgements, and package comments. Manual upload is disabled while connected. Disconnecting or a failed initial sync cannot restore the deleted upload work. Published attestation history remains unchanged. Connect a repository (GitHub, GitLab, or Azure DevOps) to get Production + Testing automation instead.
Reconnect with the same repository authority and Production and Testing selections, including leaving Testing off if it was off before. Extra watched branches are retained automatically with their reviews and comments. In Billing, Remove branch takes a watched branch and its inventory out of this project straight away, and cleanup continues in the background. Your reviews are remembered for your organization and come back if you watch the branch again. Release capacity separately when you no longer need the paid allowance. Both controls work for archived projects.
Manual review transfer is queued and continues in the background. Its status shows queued, running, stopped, or completed with the number processed and promoted. Reloading the project reconnects to that same run, including a stopped run after a lane changes. A stopped run keeps reviews already transferred. Inspect the reason and retry against the current inventories. Starting a transfer is not completion and never publishes a manual project. Changes shows the true number of packages needing attention and a sample of at most 50 reasons, with any additional count shown separately.