A build declares both an internal package index and a public index as sources - what does that cost hermeticity?

## The property that breaks Hermeticity says the build's inputs are declared and pinned. Declaring two sources for the same namespace quietly moves part of that decision out of your configuration and into the runtime state of two servers. Your file says which *names* you want. It does not say which *place* will answer for a given name on a given day. Which one wins in what circumstances is a property of the resolver's configuration and of how the two indexes are wired together - a subject of its own - but for hermeticity the relevant fact is simpler: the answer is not determined by your declaration alone, so the input set is not fully declared. The consequence is concrete. Two builds of the same commit can consume components with different content. An internal name that is absent from the internal index for a moment - a publish in progress, a brief outage, a typo in a name - can be answered by the other source. And after the fact, nothing in the build's output tells you which source served what, so an investigation ends in speculation. ## What "one declared upstream" means operationally It does not mean giving up external dependencies. It means exactly one endpoint is resolvable from the build, and that endpoint carries everything the build is allowed to use: - internal components published there directly; - external components you have deliberately accepted, held there as copies; - nothing else. The critical part is the behaviour on a miss. If a name is not present, the build fails. It does not consult a second location, and it does not fall back to a wider search. A fallback is not a resilience feature in this context; it is the one path by which an undeclared input can enter, and it fires exactly when something is unusual. The surrounding discipline is ordinary configuration hygiene: no per-developer or per-job override that adds a second source, no environment variable that appends one, no tool-specific configuration file inherited from a base image that reintroduces the default public source. It is common to find a carefully scoped project configuration undone by a user-level file on the runner. ## Proving where a component actually came from A policy nobody can verify is a hope. Three artifacts of the build make the origin checkable: **The lock record.** A per-component entry that carries not only name and version but the source it was served from and a content hash. When the source field is present for some components and absent for others, that is itself the finding: the ones without it were resolved from wherever, and you cannot say where. **A package URL with an explicit repository.** A package URL identifies a component by ecosystem, name and version, and can carry a `repository_url` qualifier naming the index it came from. That turns "which repository" into part of the identifier rather than an assumption. **The build's record of resolved artifacts with digests.** Given a digest per resolved component, you can check that each one exists in your single index with that exact content. That check is mechanical and it is the difference between evidence and belief. With those in place, the question "did anything in this release come from outside our index?" has a yes-or-no answer computed from the build's own output, and the asset you are protecting - the integrity of the artifact you ship - is defended by something you can run rather than by a configuration file you hope nobody edited. ## A useful test to propose Make the build fail closed and prove it: point the build at the single index, remove every other source, and run it with all other network destinations denied. If it succeeds, the single source really does carry everything. If it fails, you have just learned which components were arriving from somewhere you had not declared - which is exactly the list you needed.