Who owns refreshing a Go service's committed default.pgo, and when would you ban the committed profile outright?

## Why this is a policy question at all Enabling PGO is technically trivial — one file, and the flag that reads it is already the default. That triviality is what makes it a governance problem. A `default.pgo` checked into the repository: - is a **binary artifact** nobody can review in a pull request; the diff shows a size change and nothing else, - **changes the emitted machine code of the whole build**, including dependencies and the standard library, - **invalidates build caches** when it changes, so a commit touching no Go source can trigger a full rebuild, - makes the binary a function of *two* inputs — the source and a recording of a past production run — so the same commit built before and after a profile refresh produces different machine code. None of those is disqualifying. All of them are things a release pipeline owner has a legitimate right to be consulted about, and a legitimate right to overrule a service team on. ## The three questions that decide it **Who refreshes it, and when?** The only sustainable answer is "the pipeline, automatically". A profile refreshed by whoever remembers is a profile that is three releases old within a year — the decay is invisible, since a stale profile produces no error and no warning, only a slow evaporation of the benefit. A workable policy is: capture from production on a fixed cadence, merge captures across instances, open the refresh as its own commit, and require that commit to be evidence-backed rather than routine-rubber-stamped. **Where did the profile come from?** This is the provenance question, and it is the one most teams skip. A profile is committed as bytes; nothing in review distinguishes a merged capture from three production instances at peak from a capture off one developer's laptop running a synthetic load. Both build fine, and the second one teaches the compiler to optimise a workload the service does not have. The mitigation is procedural: the refresh is produced by an automated job, not by hand, and the commit records which environment and window it came from. **What is a few percent worth here?** A profile-guided build typically returns single-digit CPU improvements. For a fleet large enough that a few percent of CPU is real money, or a service running close to a capacity ceiling you cannot raise, that pays for the process. For a service running three replicas well below their limits, it does not — and the honest call is to decline PGO and spend the attention on something with a larger return. Refusing a real optimisation because its payoff is smaller than its carrying cost is a legitimate engineering decision, and being able to say so plainly is the point of the question. ## When I would ban the committed artifact - **No owner.** If no team will sign for the refresh, do not commit the file. A rotted profile is worse than none, because it costs build time and review confusion while returning nothing. - **Unauditable provenance.** If profiles are captured by hand and pasted in, the artifact is unreviewable and eventually wrong. Either automate the capture or drop it. - **Reproducibility requirements that the second input breaks.** Some release processes need a binary to be a pure function of the source tree at a tag, verifiable by an independent rebuild. A committed profile is still deterministic — the same source plus the same profile yields the same binary — but it adds an input that has to be preserved and shipped with the source to make that claim hold. If your process cannot carry that, say no. - **CI economics.** If profile refreshes force wide rebuilds on a constrained runner fleet often enough to slow every team down, the few percent is not worth it. ## The middle path worth proposing The alternative to committing is `-pgo=<path>`: the release build fetches the profile from an artifact store, keyed by version, and the source tree stays free of binaries. That preserves auditability and reproducibility — the profile is versioned and addressable — at the cost of developers no longer getting the same binary from a plain `go build`. Which side of that trade you land on depends on whether you care more about the source tree being self-contained or about the build being byte-reproducible from source alone. A principal-level answer names both options and the criterion that chooses between them, rather than asserting one is correct. ## What I would ask for before agreeing Before adopting PGO across a fleet I would want: a measured A/B result on the actual service rather than a quoted industry number, an automated capture and refresh job, a documented capture source, and an agreed cadence with a named owning team. If those four exist, committing the profile is cheap and defensible. If two of them are aspirational, the feature is not ready to be a policy — and "we will add the automation later" is the specific promise that turns into a three-release-old profile nobody remembers adding.