diff --git a/apps/playground/app/components/xid-tutorial/StepBackupInception.vue b/apps/playground/app/components/xid-tutorial/StepBackupInception.vue
new file mode 100644
index 00000000..7cf75b9a
--- /dev/null
+++ b/apps/playground/app/components/xid-tutorial/StepBackupInception.vue
@@ -0,0 +1,137 @@
+
+
+
+
+ The operational XID protects daily use, but the master is only as safe as its backup.
+ SSKR (Sharded Secret Key Reconstruction — Shamir's Secret Sharing) splits
+ the XID into shares, any threshold of which can reconstruct it. A single lost or
+ stolen share reveals nothing.
+ 3 shares created — any 2 can recover: Share {{ i + 1 }}
+ Shares 1 & 2 are pre-filled. Clear one and paste share 3 instead to prove any 2 work.
+
+ Your XID isn't the only key worth protecting. Amira's SSH signing key (the one GitHub has
+ on file, from §3.1) deserves the same treatment: wrap it in an annotated envelope,
+ password-encrypt it, then SSKR-shard it for resilient backup.
+ Share {{ i + 1 }}Backing Up Your Inception Key
+ 1. Create backup shares (2-of-3)
+ {{ shortShare(s) }}
+ 2. Test recovery before distribution
+ Backing Up Your SSH Key
+ SSH signing key
+ {{ sshKeyText }}
+ 1. Wrap the key + add metadata
+ {{ wrappedTree }}
+ 2. Encrypt with a password
+ {{ encryptedTree }}
+ 3. Shard the encrypted key (2-of-3)
+ {{ shortShare(s) }}
+
+ The worst case: an operational key is compromised. Because Amira kept her master key + offline and SSKR-backed (§5.3), she can recover her full authority, revoke the bad keys, + rotate in replacements, advance provenance, and rebuild a clean operational XID — all + while keeping the same identifier. +
++ With the bad keys gone and replacements in place, regenerate the operational XID + (inception key elided) for daily use. +
+{{ operationalTree }}
+ + Revoking a key doesn't retroactively invalidate signatures it already made. Amira + publishes a signed statement — structured as a standard edge (§3.1) and signed by her + new key — naming the compromised keys so verifiers can distrust signatures from the + compromise window. She can publish it alongside her XID without adding it as an edge. +
+{{ disavowalTree }}
+ + You've generated operational keys, updated and rotated them, backed up your inception and + SSH keys with SSKR, recovered from a compromise, and published a signed disavowal — all + without changing your XID. +
++ Until now a single inception key has controlled BRadvoc8's entire XID — if it's + lost or stolen, the identity is gone. Following the + least-necessary + pattern, Amira adds day-to-day operational keys with only the permissions each + device needs, then derives an operational XID that omits the master key entirely. +
+Public keys (ur:crypto-pubkeys):
+{{ lastAddedUr }}
+ + The operational XID is an elided-private copy with the inception (master) key removed, + so a compromised laptop can't rotate keys or revoke the identity. Your full master stays + intact here — you'll back it up in §5.3 and use it to recover in §5.5. +
+{{ operationalTree }}
+ + Keys aren't forever — they get over-provisioned, or need rotating after loss. XIDs let you + change a key's permissions and rotate a key (add the new, remove the old) + while the identifier itself stays constant. +
++ Rotation = add the replacement, then remove the old key. The new key inherits the + (now-trimmed) permission set. +
+{{ rotatedUr }}
+