Bots open lockfile-refresh pull requests across 400 repositories daily. How do you make regeneration a re-trust event?

## The real constraint The scarce resource is not tooling, it is reviewer attention. Four hundred repositories with automated refreshes produce a stream of near-identical, almost always benign pull requests. Humans respond to that stream by approving without reading, and once that habit exists, the review gate reports coverage it does not have. Any answer that ends in "train reviewers to read lockfile diffs more carefully" fails, because it fights the volume instead of removing it. At the same time, the opposite failure is just as expensive. Requiring a real human decision on every refresh means teams batch them, refreshes fall weeks behind, and the organisation ships known-vulnerable versions for longer. Slower patching is a genuine risk, not merely inconvenience, so the design must reduce human load rather than increase it. ## The organising idea: reproducible versus residual A lockfile refresh is not one thing. Most of it is the mechanical consequence of resolving the manifest at a point in time - something a machine can redo. A small part of any given diff is not reproducible: someone typed it, or resolution is non-deterministic in your setup. So build a reproducer that runs on infrastructure you trust, resolves the manifest in a clean environment against the approved source, and compares its output to the proposed lockfile. - **Reproduced exactly** - the change is a fact about upstream, not a claim by an author. Merge automatically. - **Not reproduced** - this is the residue, and it is where every interesting case lives. It goes to a human. The residue is small enough to read, and the categories are worth naming in policy: a digest changed while the version did not; the resolved source host moved; a package appeared with no parent in the graph that explains it; the file was edited by hand rather than generated. Make the reproducer's own inputs pinned and its execution trusted, or you have simply moved the trust decision somewhere less visible. ## Tiering, because not all four hundred matter equally Tier by what the build can reach, not by how busy the repository is: | Tier | Examples | Rule | |---|---|---| | High | builds holding production or publishing credentials, artifacts customers install, infrastructure provider pins that touch the cloud control plane | named approver on residue; no auto-merge; hand-edited lockfiles prohibited outright | | Medium | internal services with scoped credentials | auto-merge on reproduced changes, team approval on residue | | Low | docs sites, sample apps, throwaway tooling | auto-merge, alert-only on residue | The high tier deserves a specific rule: if the lockfile may only be produced by the controlled job, then *any* hand edit is an anomaly you can detect mechanically rather than a judgement call you have to make. Removing the ambiguity is worth more than the review it replaces. ## Ownership and the exception path The platform team owns the reproducer and the classifier - a shared capability, not four hundred local scripts. Service teams own approvals for their own residue, because they are the only people who can say whether a new package belongs. Security owns the exception list and reviews the *list*, not the individual pull requests: which repositories are permitted to bypass, why, and when the bypass expires. An exception with no expiry becomes permanent within a quarter. ## What you measure - Share of lock changes that were machine-verified rather than human-approved. This should rise; it is the health of the reproducer. - Median age of unverified residue. Rising age means humans are the bottleneck again. - Time from an upstream fix being available to it being merged. This is the number that tells you the gate has not made you slower at patching. - Count of hand-edited lockfiles in high-tier repositories. The target is zero, and any occurrence is investigated. ## The argument to make to leadership The goal is not more review. It is spending review only where a machine cannot decide, so that when a human is asked to look at a lockfile change, it is because something genuinely unexplained happened - and they know that. A gate everyone approves reflexively is worse than no gate, because it produces the paperwork of assurance without the assurance.