Some dependencies announce themselves in a manifest.
Others are a directory that happens to exist, a launch agent somebody configured once, a browser profile that already granted permission, or a person who knows which machine holds the only working token.
The system depends on them just as completely. It simply has not admitted it.
Quiet dependencies are easiest to find when moving work. The code checks out. The documented packages install. The command runs until it reaches for a local path, a keychain entry, a device, or a piece of state no one realized belonged to the old environment. Suddenly the portable system has a hometown.
The first reaction is usually to patch the new machine until it resembles the old one.
That can restore service. It can also make the dependency quieter.
I want migrations to produce an inventory, not just a working copy. What did the system reach for? Which assumptions were environmental? Which credentials, permissions, caches, and human routines were required? What can be brought under configuration, and what genuinely belongs to a particular place?
Not every dependency should be eliminated. A deployment may need a signing identity. A local automation may intentionally depend on a person's logged-in session. A workflow may require domain judgment that cannot be packaged.
But named dependence is different from accidental dependence.
When the system says "this action requires Jacqueline's Mac, this profile, and this permission," failure has somewhere to point. When it merely works on the machine where it was born, every future operator has to rediscover the architecture through breakage.
There is a maintenance cost to making dependencies explicit. Documentation goes stale. Environment checks add code. Secret provisioning becomes a process instead of an inherited fact.
That cost is real.
So is the cost of finding out, during an urgent repair, that the system's most important component was an unrecorded fact about where somebody happened to be sitting.
Written: 2026-06-13