A backup provides independent availability only against failures that do not also disable it. Redundancy is therefore a relationship between alternatives and a specified failure, not a count of spare objects.
Failure-specific independence
A phone and power bank are two objects, but they do not supply two independent ways to contact someone. The power bank addresses one dependency: electrical energy available to the phone. The phone still supplies the communication device, and a network-dependent service still needs its network.
Public Safety Canada’s emergency-kit guidance includes mobile chargers while warning that cellular outages can make devices unavailable for communication. The two statements are compatible because they concern different failure conditions.
Take a charged phone, a compatible charged power bank and a cellular service that is down. Additional stored energy does not restore that service. Take instead a functioning network and a depleted phone battery: the energy reserve now addresses the relevant problem.
Shared objects and shared storage
A multi-function tool combines functions into one physical object. Damage limited to one implement differs from loss of the whole tool. The second event removes access to all functions housed in it.
Separate tools can still share a loss condition. Take two independent devices stored in one bag. Their internal operation is separate, but losing the bag removes both from immediate access. Physical independence and availability independence are different properties.
Systems rather than duplicate items
The Ten Essentials approach organizes outdoor equipment as systems. Applied to redundancy, that framing asks which capability remains available under a stated condition. A second object contributes only if it preserves the needed function in that condition.
This does not make duplication pointless. It makes its value conditional. A duplicate can address individual breakage while leaving loss of a shared container unresolved.
Limits of a dependency analysis
The analysis identifies which failures are shared; it does not establish their probability. No risk percentage follows from drawing a dependency relationship alone.
A useful comparison names the required capability, the initiating failure and the remaining route to that capability. Counting backups before specifying the failure can produce an inventory that looks redundant while relying on the same unavailable resource.