This chapter has one job: to give you the felt sense of how this system works before you set any of it up. Every detail introduced here is revisited in later chapters — first for the non-technical reader, then for the technical reader, then for advanced cases. Nothing here is the final word, and a lot of it is left deliberately vague. The point is just to have something to recognise later.

A note before we start. Most of the substance of a system like this is not the hardware or the software. It is a set of rules about where things live and how you handle them, a set of protocols for what you do over time, and a circle of trusted people that the rules and protocols are designed around. The tools are mostly cheap and well-known. The interesting work is in the rules, the protocols, and the people.

So rather than start with parts, let’s start with one secret, and follow it.

Follow one secret

Imagine you sign up for Amazon. The screen asks for a password.

Almost every choice this system asks you to make is downstream of one question: how bad is it if this thing leaks, and how bad is it if you lose access to it? Losing your Amazon account would be annoying but recoverable — a reset email is one click away. A leaked password lets someone buy a few things on your card before you notice. Real, but bounded. And you use it often enough that retrieval friction matters.

The answer this system gives is that Amazon’s password lives in your online password manager — a piece of software, running on your phone and laptop, that follows you around. You generate the password there. You never type it manually. You never see it.

But your online password manager has a master password of its own — the one you do have to remember. Where does that password live?

This is where the shape of the system starts to show up. That master password is a key to a key. It is one of the most sensitive things you own. So in this system it lives in your offline vault — a USB stick that you only ever plug into a small dedicated laptop that has no hard drive and no network. You boot the laptop from a second USB stick that runs an amnesiac operating system, you open the vault, you read or copy what you need, you close it, you put both USBs away.

That sounds like a lot of effort. And it is — deliberately. The whole design hinges on this: the more sensitive a secret is, the more friction it costs to retrieve it. Friction is a feature, not a cost. When you have to physically retrieve two USB drives and boot an air-gapped laptop, you do not casually mistype your master password into a phishing site at 11pm. You enter a different headspace. The friction is the protection.

A category to notice: some accounts are themselves keys to other keys. Your primary email is the largest of these — whoever owns your email can reset most of the other accounts you have. So your email password is treated more like your online-vault master than like Amazon. Roughly: a passphrase you actually remember, backed up in the offline vault so you cannot permanently lose it, with two-factor authentication on every login, and day-to-day access through a passkey on your phone or laptop so you barely have to type the passphrase at all. The mechanics belong to a later chapter — the point here is to notice that “keys to other keys” is its own pattern, distinct from “Amazon” and from “the online-vault master password”.

Now turn to a different secret: your bank app PIN. This is the opposite end of the dial. You type it dozens of times a month, sometimes in a hurry. So this one lives in your memory. But what if you forget it? What if you wake up from a stroke and the last twenty years are foggy? So a backup copy also lives in your online vault — readable in a pinch from your phone, but never the first place you go for it. And then you might ask, why not just use my fingerprint to unlock the app? We’ll get to that.

A third secret: your 2FA recovery codes — the strings the website tells you to “save somewhere safe” when you set up two-factor authentication. You will probably never need them. The day you do, you will really need them, usually during a panic at an airport. They live in the offline vault, because losing them is catastrophic, and reading them is rare.

A fourth: the password you log into your laptop with. This one is bound to a specific piece of hardware — the secure element inside the machine itself — and it never leaves that hardware. There is no “copy” of it anywhere. If the laptop dies, the secret dies with it. So whatever the laptop is protecting must itself be recoverable from elsewhere.

A fifth: the seed phrase for a Bitcoin wallet you intend never to spend from. This will never sit on a computer, ever. It lives on paper — or, better, on metal — physically stored where it cannot burn down with your house.

Patterns are emerging. Without naming anything yet, you can probably guess where these would go:

• Your phone unlock PIN
• A folder of private diaries
• The Wi-Fi password at home
• Your social-media passwords
• A note recording the location of your other USB drives
• A list of which crypto wallets you own (but not the keys themselves)

The choices that govern those placements are most of what this manual is. They are not arbitrary. Each one is a particular answer to “how bad is exposure, how bad is loss, how often do you need it”.

When the secret isn’t yours

So far we have followed your own passwords. There is a second pattern in this system that is just as common: holding someone else’s. The introduction said it plainly — if you are reading this, you are probably the computer-wiz in your family. The guide is not only a tool for protecting yourself. It is a tool for protecting the people you love, especially the people who will never read it.

Picture your grandmother. She has a Hotmail account she has used since 2003, where every photo of you as a child is stored. She has a Facebook account where her remaining friends post. She has a bank she uses by phone. She does not have a password manager. She has a notebook in her drawer with passwords written in pencil, some scratched out, none of them strong.

What does being her custodian actually look like, in this system?

The first part is an audit, done together with her, on a cadence you both agree to — once a year is plenty. You sit at her kitchen table. You go through what accounts she has. You note which ones actually matter to her: the photos, the email, the bank, maybe one or two others. You quietly help her turn on two-factor authentication on the email and the bank — those two more than anything. You replace the worst of her reused passwords. You do not try to install a password manager on her phone if it will confuse her; that is the wrong battle. You leave her notebook in place, because the notebook is a tool that works for her — but you replace the entries in it with stronger ones, and you take a copy of those entries away with you.

That copy is the second part. You go home, and the passwords you took away live in your offline vault, in a separate section — call it “Gran” — walled off from your own secrets. You hold them in trust. They are not for your use. They exist for one reason: so that, when she is gone, you can recover the things she loves and that her family loves. Her photos do not disappear into a Hotmail account nobody can open. The recipes she wrote in her email do not vanish. The bank account she has been quietly setting aside money in for the grandchildren does not get lost to time.

This works because the same system you built for yourself has the right shape to also hold things for someone else. Her section is separate from yours, so a leak in your day-to-day online vault never reaches her. The annual review you already do for yourself makes a natural moment to refresh her section too. And the rules about what lives where are the same rules — you are just applying them on her behalf.

Two things are worth noticing before we move on:

• Consent is the foundation. You do this with her full knowledge and agreement, on her terms, with her choosing what you hold and what you do not. You are her custodian, not her keeper. The relationship is the thing the protocol protects; the passwords are downstream.
• The trust model runs both ways. The next section talks about your own circle of trust. The grandmother story is the same arrangement viewed from the other end — you are someone else’s trusted person. Most people who use this system will end up in both roles at once: their own circle, and a custodian role for one or two people who cannot maintain a system of their own.

When you cannot be there

So far the story has been about you, plus your tools and your rules. The other half of the system is the people.

A system that only works while you are present, alert, and alive is not a system. Half the work of this design is the part that activates when you are not there to run it.

Two kinds of trusted people appear, and they have different jobs:

• Your kin are the people you actively work with to maintain the system while you are alive. They review your vault with you. They notice if something has drifted. There are few of them. They know the system intimately.
• Your kith are a larger circle of trusted people who play essentially no role while you are alive — except that, if you die or are incapacitated, they are the ones who can put your vault back together. Each holds only a piece, and they do not know who the others are. This is not because you do not trust them; it is to limit the liability each one carries. None of them can accidentally compromise the vault, and none of them can be held under duress to do so. Together, by a protocol the manual will describe, they can recover.

Importantly: this is not two levels of trust. You trust everyone in both circles equally. The split is about logistics and about limiting each person’s risk. Anyone who could compromise the vault on their own could be coerced into doing so. So nobody can.

The trust network is an input to the system — a fact about your life that the design works around — rather than a thing you build. This is what the introduction called second-party custody, made concrete: the rules and protocols are shaped so that the people you already trust can do the job of protecting you, without any one of them carrying enough to be dangerous to themselves.

One concrete rule already follows: this system is never discussed over digital channels. Not with kin. Not with kith. Not in passing, not in jokes. You only ever bring it up in person, face-to-face, when you happen to be together anyway. There is a reason for this, and it is one of the strongest pieces of the whole protocol — but the reasoning belongs to a later chapter. For now, just notice the shape of it.

Keeping it alive

The last piece is time. A vault and a circle of trust that are set up once and never touched again will rot. People move. Hardware fails. Accounts close. Memories fade.

The system stays alive through protocols — recurring rituals, mostly with kin, that re-check it. The headline protocol is an annual review: you sit down with a kin member and walk through your vault, your inventory, your network. You confirm what should be there. You cull what should not. You replace hardware that has aged out. It does not have to be expensive. It does have to happen.

There are also event-driven protocols — what to do if a password is compromised, what to do when you travel, what to do when a kith member is no longer reliable, what to do when you die. Each one gets its own treatment later.

The rituals are not administrative overhead. They are the proof the system is still alive. A protocol that has never been performed is just a hope.

The parts you just met

You have now walked through the whole system end to end. Here are the names that will be used for the rest of the manual:

• Tools — the physical and digital substrate. The USB drives, the air-gapped laptop, the online vault, the hardware key, the paper backup.
• The trust network — your kin and kith.
• Rules — the hard policies for where each kind of secret lives and how you handle it. “Master passwords live offline.” “Recovery codes never live in the same place as the thing they recover.” “PINs live in memory and have a backup.”
• Heuristics — the rules of thumb for the in-between cases. “The more sensitive, the more friction.” “Loss is a failure mode too.” “If you would not type it in a café, do not type it on a phone.”
• Protocols — the recurring and event-driven rituals.
• Checklists — quick reference procedures for specific moments. These live in the reference section, not the manual.

One more piece of vocabulary. The vault — the thing you actually interact with — is what you get when tools, rules and some of the protocols are composed together. It is not itself a primitive of the system; it is the name for what the primitives produce. You will hear “the vault” used as a shorthand for the assembled product, but the work of the manual is in the primitives.

Five properties are what the design is trying to deliver across all of the above:

1. Useable — convenient enough that you actually use it, with friction proportional to sensitivity.
2. Foolproof — robust against lapses in concentration.
3. Limited blast radius — damage from any single mistake, loss or compromise is contained.
4. Recoverable — after damage, loss, incapacity or death, you or someone you trust can put it back together.
5. Secure — infeasible for non-trusted people to exploit.

Every rule, every protocol, every tier of the vault is a particular answer to those five — and through them, to the three failure modes the introduction named: attack, mistakes, and loss. When you read a rule later in the manual and wonder why it is the way it is, those five properties are the answer; and behind them, those three failure modes.

What comes next

The chapters that follow revisit this same ground three times, as described in How to read this — first what to do, then why, then when to deviate. Nothing said here is final. Everything will be revisited. The job of this chapter was to give you something to recognise when you get there.