As the owner of a large monorepo's CI, how far would you trust the affected-target graph as the only pre-merge gate, and what backstop would you run?

## The claim you are making Gating merges on an affected-only pipeline is an assertion: *nothing outside this set could have been broken by this change*. That is a causal claim about the software, and CI is only entitled to make it as strongly as the dependency graph is complete. The principal-level job is to size that entitlement honestly and to design for the part you cannot close. ## Grade the graph before you grade the risk Edges come from somewhere, and where decides how much they are worth. **Declared and enforced.** A build system that requires every dependency to be written down and prevents a target from reading anything it did not declare produces a graph that is complete by construction. The cost is real — every dependency is someone's explicit work, and the migration is measured in quarters — but the affected set is then a genuine safety property rather than a heuristic. **Inferred from source.** Workspace metadata plus static import analysis. Cheap, usually right, and blind by construction to anything that is not a static import. **Asserted by hand.** Path globs a human wrote. These are correct on the day they are written and drift from then on. Most organizations are at the second tier and reason as if they were at the first. Naming which tier you are on is most of the answer. ## The classes an inferred graph cannot see Write them down, because "we might miss something" is not a plan and this list is what makes it actionable: - **Network coupling.** Two services with a contract and no shared import. - **Dynamic resolution.** Plugins, handlers, or modules loaded from a configuration string. - **Generated and committed artifacts.** A schema and its generated client, where the generator is not modelled as an input. - **Out-of-repository inputs.** A base image tag, a toolchain version, an external dependency resolved at build time. - **Behavioural coupling through data.** Two packages that agree on a serialization format nobody declared. Each class has a specific remedy — declare the edge, add the file as a global input, add a contract test that always runs — and the point of enumerating them is to convert an abstract worry into a defect list someone can close. ## The backstops, in the order I would add them **1. Fail closed on computation failure.** If the diff base cannot be resolved or the graph cannot be built, build everything. An empty affected set must be an error condition, never a fast green run. This one is cheap and removes the most common silent escape. **2. A periodic full build of the main branch.** The most valuable control per unit of effort, because it converts an unbounded escape window into a known one. Nightly is the common cadence. The value is not that it finds much — it is that when it does find something, you learn within hours instead of from a customer, and you get a bisectable window. **3. Recorded evidence.** Persist the change set, the affected set and the task list for every run. After an incident the question "was this package tested on that commit?" should be a lookup, not an investigation. Without this, every escape becomes an argument about what probably happened. **4. Always-on checks that ignore the graph.** Some things are cheap enough to run unconditionally regardless of affectedness: repository-wide lint, the dependency and secret scans, contract tests at service boundaries, the smoke test of the assembled system. These specifically cover the classes the graph is blind to. **5. Graph defects as incident output.** Every escape ends with either a new declared edge or a written acceptance that this class is not covered. Without that discipline the same class recurs and the team quietly stops trusting CI at all, which is a far worse outcome than a known, bounded gap. ## Sizing it as a decision, not a preference The decision is an exchange rate: pull-request feedback minutes against escape probability. Both sides are measurable if you choose to measure them. Full-build wall-clock time, affected-build wall-clock time, changes per day, and the count of escapes attributable to a missing edge over the last two quarters. If escapes are near zero and full builds cost an hour, the affected gate is obviously right. If escapes happen monthly and a full build costs eight minutes, gating on affected is optimizing the wrong thing and you should simply build everything. That last point is worth saying explicitly in an interview, because it is the one candidates skip: **building everything is a legitimate answer.** The affected machinery — graph maintenance, base resolution, generator code, cache infrastructure — is a system with its own failure modes and its own maintenance cost. Below some repository size it is not worth owning. The senior move is knowing where that line sits for your repository rather than adopting the machinery because large repositories elsewhere need it. ## What blast-radius thinking adds Finally, not every package deserves the same confidence. A change to a shared authentication library and a change to an internal developer tool have very different consequences if the affected set is wrong. It is reasonable to apply a tiered policy: for a small number of high-blast-radius packages, always run their consumers' tests regardless of what the graph says. That is a cheap, targeted way to spend confidence where it matters, instead of applying one uniform level of paranoia to fifty packages.