Notes /
What happens to your AI companion when your computer dies?
The power light comes on, the fan turns once, and the screen stays black.
This is not the moment to discover what “stored locally” really meant. Your conversations may have survived on the disk. So may the diary, the names, the promises, and the small facts your companion learned over months. But DT Life encrypts that material with a data key sealed to your Windows account. A copy of the database and its key file is not enough on a new laptop: the new Windows account cannot open a key protected for the old one.
That is good protection when a database file is copied or a disk is removed from a stolen computer. It is a terrible recovery plan by itself.
Local should not mean stranded
Imagine using a companion through a job search. It knows which applications are waiting, which interview happened last Tuesday, and what you promised to send on Friday. None of that was placed in somebody else’s account. That is the point. Then the laptop fails.
A cloud service would say, “Sign in again.” It can say that because it kept a copy. DT Life cannot: there is no company-side copy, no password-reset desk, and no hidden administrator key. If the only copy was on the failed disk, we cannot retrieve it.
The answer is a recovery bundle: one .dtlife file containing a consistent
snapshot of the database and its data key, encrypted under a passphrase
you choose. The protection moves from “this Windows account” to “the person
who knows this passphrase.” That is what lets the same private history open
under a rebuilt profile, a different Windows account, or a new machine.
Creating one lives in Data & privacy → Recovery bundle. Choose a passphrase of at least 12 characters, save the bundle somewhere other than the disk it protects, and write the passphrase down somewhere safe. A backup on the same drive is part of the same failure.
Restore is deliberately uneventful
Recovery is the wrong place for a clever shortcut. A half-written restore can destroy the data it was meant to rescue, so DT Life never overwrites the live database while the app has it open.
First, the app decrypts the bundle into a staging area. It verifies the passphrase, the encrypted chunks, the declared size, the file fingerprint, and the recovered database itself. It then stops and tells you the restore is waiting. Nothing you are currently using has been replaced.
The swap happens on the next start, before DT Life opens its database. The
staged files are copied into place and renamed, rather than streamed over the
live files. Your previous database and key are moved into a timestamped
replaced-... folder, not deleted. If you restored the wrong bundle, that
should be a reversible mistake, not a second data-loss event.
Those previous copies are kept until you remove them. That is safer during recovery, but each one can be large, especially if your local document library is large. Once you have checked the restored history, cleaning up old copies is your responsibility.
The honest limit comes before the feature
A recovery bundle cannot travel backwards in time. You must create it before the machine fails, store it away from that machine, and keep its passphrase. Nobody at DT Life can reset the passphrase or reconstruct a bundle from our servers, because we have neither the data nor a server-side recovery key.
That inconvenience is inseparable from ownership. If a company can always recover your private history for you, that company has retained a way into it. DT Life gives that power—and the duty that comes with it—back to you.
