When Claims Replace Custody

There is a particular kind of sentence nobody wants to hear at the wrong moment. The data is inaccessible, but there's a backup. The account is frozen, but there's an appeal process. The shipment is gone, but it's insured. The service is unavailable, but the provider guarantees compensation under the agreement.

None of those answers is necessarily bad. Depending on what failed, each may be exactly the protection we wanted. The problem is that the protection doesn't preserve the same thing that was lost. Insurance can preserve economic value without preserving the object. A backup can preserve data without preserving immediate access to it. An appeal can eventually restore an account without preserving whatever we needed to do while the account was frozen. A service-level agreement can compensate us for downtime without giving us those hours back.

We use these substitutions constantly because preserving everything directly would be extraordinarily expensive. Instead of eliminating failure, we decide which consequences we're willing to tolerate and arrange ways to recover afterward. Most of the time this works remarkably well. If my house burns down, keeping a second house permanently available in case I need it would be an absurd form of resilience for most people, so insurance accepts the possibility that the physical structure can be lost and attempts to preserve some of its economic value instead. If a database server fails, I don't necessarily need another machine containing a perfectly synchronized copy waiting beside it. Restoring a recent backup tomorrow morning may be completely adequate for what that database does.

The important question is what I thought I was protecting, because different protections preserve different properties. A backup protects recoverability. Replication can protect availability. Insurance transfers some financial risk. Redundant infrastructure can preserve service through certain failures. Local custody can preserve the ability to act without waiting for another organization. None of these means simply "safe." They answer different questions, and during normal operation those differences can be surprisingly difficult to see.

I click a button and the file appears. I present a card and the payment works. I enter a password and the account opens. I request a service and something happens. As long as everything is working, several very different arrangements can look functionally identical. The differences become visible when one of those paths stops working and I discover whether I possess the thing itself, a copy of it, the ability to reconstruct it, a contractual claim against someone who possesses it, or merely permission to use it while certain conditions remain true.

Those aren't interchangeable positions, although neither is one of them always superior. Possession creates capabilities that claims don't, but it also creates responsibilities that claims can transfer elsewhere. If I hold the only copy of something important, nobody can revoke my access to it, but nobody else is responsible for recovering it after I destroy it either. Custody removes some dependencies by accepting others.

Claims work the same way. They can look weak because they depend on another party performing later, but that other party may have resources I could never economically maintain myself. A regional disaster may overwhelm a local organization while a geographically distributed insurer continues operating. A cloud provider may recover from a hardware failure I couldn't repair for days. Sometimes distance is the resilience. Other times distance is the dependency. What matters is the particular failure we're trying to survive.

This is why I no longer find statements like "own the important things" precise enough. Ownership tells me something about authority, but it doesn't tell me whether the thing will survive. A server in my building is under my control, and so is the second server beside it. If the building burns, their shared location becomes more important than their ownership. A remote backup I don't physically possess may survive precisely because it wasn't here.

The reverse can happen just as easily. A remote service may become unreachable while the building, local network and machines inside it continue operating normally. Now local capability matters because the remote dependency failed independently of everything around me. Neither example establishes a general rule about local versus remote infrastructure. They identify different failure boundaries.

Time introduces another distinction. A recovery mechanism that restores something next week may be perfectly adequate for one loss and useless for another. If an archive is temporarily unavailable, waiting several hours may be irritating. If a payment system stops during payroll, the same delay carries different consequences. If emergency communications depend on a service that won't be restored until tomorrow, eventual recovery doesn't preserve what mattered.

This is where two questions that sound similar begin to separate: can we recover it, and can we continue without it? We often don't notice the difference until something fails. We thought we had continuity when what we actually had was recoverability, and there is nothing inherently wrong with that arrangement if we chose it deliberately. The trouble comes when the distinction was invisible during normal operation.

Resilience gets expensive quickly because insisting that every function remain continuously available through every imaginable failure requires enormous amounts of redundant infrastructure, which introduces additional complexity that itself has to be operated correctly. So we make choices. Some things need immediate continuity, some can degrade, and some can stop completely for a while. Some information must survive even if the service around it doesn't. Some losses can be converted into money. Others can't. Some risks are inexpensive enough to accept rather than engineer away.

A newspaper provides ordinary examples. If the website goes down for an hour, that's a failure, but the newspaper hasn't ceased to exist. The printed edition is still in people's houses. Reporters can still report. Phones still work. Depending on the failure, radio and social media may still reach people. If Facebook disappears, we lose an important distribution channel without losing the articles it was distributing. If a local server dies, another machine or a backup may preserve what was stored there. If the entire building disappears, copies located inside the same building stop being particularly interesting.

Each layer preserves something different, and that's much more useful to me than trying to make every layer independently sovereign. The goal isn't to eliminate dependency. I don't think that's possible, and pursuing it far enough can produce a remarkably elaborate collection of new dependencies. The goal is to understand dependency well enough that one failure doesn't unexpectedly erase something we thought another mechanism was protecting.

That requires being more specific whenever we say something is protected. Can I use it now, or only recover it later? Can someone prevent me from using it? Can someone else recover it if I can't? How much can disappear between the last good copy and the failure? How long can we operate without it? What else is likely to fail at the same time? Who has authority to act when it does?

The answers can produce very different architectures. Sometimes the right answer is custody, sometimes replication, sometimes a backup, sometimes insurance, and sometimes a contract with an organization much larger than ours. Often several of these mechanisms protect different consequences of the same failure. The important part is not confusing them.

An insurance policy doesn't keep the house standing, just as a backup doesn't keep the database online and a redundant server in the same building doesn't protect against losing the building. Owning infrastructure doesn't guarantee that infrastructure will survive, and outsourcing something doesn't necessarily mean surrendering resilience. Every mechanism preserves something while leaving something else exposed. Failure reveals the difference.

So I've changed how I think about being "made whole." Sometimes being made whole later is exactly what I need, and there is no reason to maintain immediate continuity for something whose interruption I can comfortably absorb. Other times later is too late, and no amount of restitution can restore the thing the system was supposed to preserve.

The work is figuring out which situation we're in before the failure makes the distinction for us.

Resilience isn't never needing to be made whole. It's knowing what has to remain continuous, what only has to be recoverable, and what we're willing to lose.