Data Dictionary

1. Account

Created at signup. Visible on My profile.

• Username — Purpose: your login handle and the name you see in the app. Expect: a short identifier, letters / digits / underscore. Don't put: your email, your date of birth, or anything you wouldn't want to appear in a URL.
• Email address — Purpose: password reset, account activation, service notifications, and GDPR correspondence. Expect: a mailbox you actually read. Don't put: a shared alias you don't monitor — you'll miss a contest-window email and your memos may be released in error.
• Password — Purpose: authenticate you. Expect: 10+ characters, unique to this site. Don't put: a password you've used elsewhere; credential stuffing is the single most common account-takeover vector. We store only a salted hash — never the plaintext — so we cannot tell you what your password was if you forget it.

2. Profile

The personal details you enter at signup and can update at Edit profile. Every field in this section is AES-encrypted at rest.

• First name — Purpose: personalise emails to you and identify you if you contact support. Expect: your legal given name. Don't put: a handle or a nickname only your friends know.
• Last name — Purpose: same as above, plus identity disambiguation if two accounts share a first name. Expect: your legal family name.
• Date of birth — Purpose: identity disambiguation if two accounts share a name, and age-based eligibility checks. Expect: DD/MM/YYYY, your own. Don't put: a fake date; it may block account recovery later.
• Country of residence — Purpose: route your data to the correct regional data-protection regime and help trustees understand jurisdiction. Expect: the country you currently live in. Don't put: your citizenship if you live somewhere else — residence is what matters for GDPR.
• Phone number (optional) — Purpose: a second contact channel if you lose access to email, and the hook for eventual SMS-based 2FA. Expect: an international E.164-shaped number (e.g. +44...). Don't put: a landline you can't receive SMS on, or a number you don't control.
• Unique identifier — Purpose: a public, unguessable UUID that a death-notification submitter uses to identify you without needing your email or full name. Expect: set automatically at signup; shown in your data export. Don't share it publicly — it's the handle strangers use to start a release flow against your account.

3. Notification preferences

Toggles on the Notification preferences page. Both default on.

• Email me when a new trustee is added to my account — Purpose: spot unauthorised changes to your trustee list. Leave on unless you're doing a bulk add and the emails are noise.
• Email me when an existing trustee's details change — Purpose: same reasoning, for edits rather than additions.

4. Trustees

One row per person you nominate, on the All trustees page. Every field is AES-encrypted at rest.

• First name — Purpose: the name that appears in the invitation and release emails so the trustee knows it's them. Expect: the trustee's real given name. Don't put: placeholders like "Mum" or "Lawyer".
• Last name — Purpose: same. Expect: the trustee's real family name.
• Email address — Purpose: where the invitation, update and release emails are sent. Expect: a mailbox the trustee actually reads. Don't put: your own email as a placeholder — releases will go to you, not the intended recipient.
• Phone number (optional) — Purpose: backup contact if the trustee's email bounces. Expect: international format. Don't put: a work extension you can't reach them on directly.

5. Memos

The heart of the service. Every memo shares a title, body and trustee assignment; some types add extra fields. Titles and bodies are AES-encrypted at rest.

• Title — Purpose: how you (and the receiving trustee) identify the memo. Expect: a short descriptive label — "HSBC current account", "Letter to Susan". Don't put: the password itself — the title is also used in list views and could appear in support screenshots.
• Details / additional details — Purpose: the actual content you want to pass on. Expect: account references, instructions, passwords, private messages — anything the trustee will need. Don't put: someone else's data without their consent, and don't write a memo you wouldn't want released if a notification of your death were verified.
• Trustees — Purpose: who this memo is addressed to. Expect: one or more trustees you've already nominated. Memos with no trustee assigned will not be released to anyone.

5.1 Financial memos with an institution link

Bank account, loan / credit card, mortgage, pension and investment memos additionally carry:

• Financial institutions — Purpose: link the memo to a known bank / lender / pension provider / brokerage so the trustee has a clear pointer. Expect: one or more entries from the dropdown. If your institution is missing, describe it in the details instead and email us so we can add it.

5.2 Crypto account memo

• Crypto account financial institution — Purpose: name of the exchange or platform (Coinbase, Kraken, etc.). Don't put: your wallet seed phrase here — that belongs in a wallet memo.
• Crypto account username — Purpose: the login or account identifier on that platform. Don't put: your password — put that in the additional details field.

5.3 Crypto wallet memo

• Wallet details — Purpose: location and access notes for a self-custodied wallet. Expect: recovery-phrase hiding place, hardware-wallet PIN hint, derivation-path note. Don't put: the raw seed phrase in plaintext if you can help it — prefer to describe where it is, split across trustees if the value warrants it.

5.4 Video / image memo

• Upload — Purpose: the actual video or image file. Expect: MP4 / MOV / JPG / PNG up to the configured size limit. Don't put: executables or archives — the MIME-sniff check will reject them. The file lives in a private bucket and is served only via short-lived presigned URLs.

5.5 Will / Real-estate / Other-financial-asset / Written memos

These carry only the shared fields (title + details). Use the details field for the substance of the memo.

5.6 Investment memo

Investment memos (shares, bonds, mutual funds, ETFs, employer stock, brokerage / platform holdings) reuse the standard title + details shape plus a financial-institution link (see 5.1). Use the details field to record asset mix, beneficiary arrangements, statement locations and account access notes — but do not paste full credentials.

5.7 Funeral wishes memo

Funeral wishes memos carry only the shared title + details. Use the details field for disposition (burial / cremation / donation / natural burial), service preferences (religious or secular, readings, music), location, dress code, flowers-vs-charity-donation preference and anything else the person arranging the funeral should know. Delivered to the trustees you assign, only after a verified and uncontested death notification.

6. Death notification

Filled in by whoever submits a Notification of death. Every field is AES-encrypted at rest.

• First name of the deceased / Last name of the deceased — Purpose: name of the person the notification is about. Expect: the deceased's real name.
• Unique identifier of the deceased — Purpose: matches the notification to the correct LGCYBox account. Expect: the 36-character identifier the deceased shared with you (or that you find in their paperwork). Don't put: a guess — a wrong UUID will fail validation.
• First name of submitter / Last name of submitter — Purpose: so we can get back in touch with you for clarification. Expect: your real name.
• Email address of submitter — Purpose: same — for follow-up during review. Expect: a mailbox you can read.
• Death certificate — Purpose: the official document we review before approving the release flow. Expect: a scan or photo of the certificate. Don't put: an obituary screenshot — we need the official record.

7. Medical profile (optional pre-death record)

Distinct from memos: the Medical profile is a single live record reached by emergency responders through an unauthenticated URL printed on a wallet card or bracelet. Consent is captured explicitly the first time you save it. Every clinical field is AES-encrypted at rest.

• Blood type — Purpose: instant reference for emergency responders. Expect: A+, O-, AB+ or the word "unknown".
• Allergies — Purpose: flag dangerous reactions before a medication is given. Expect: drug, food, latex allergies with severity where known (e.g. "anaphylactic to penicillin"). Don't put: trivia unrelated to emergency care.
• Medications — Purpose: tell responders what you're currently taking. Expect: drug names and daily dosage.
• Conditions — Purpose: diagnoses that affect emergency treatment. Expect: chronic or significant conditions (e.g. Type 1 diabetes, hypertension, epilepsy).
• DNR / resuscitation status — Purpose: communicate your resuscitation wishes. Expect: free text — the legal form varies by jurisdiction, so describe what's on file and where. Don't put: "maybe" — responders need a clear steer.
• Organ donor — Purpose: organ-donation preference. Expect: Yes / No / Partial, and if partial which organs or tissues.
• Primary physician — Purpose: a starting point for medical history. Expect: name, practice, phone.
• Medical power of attorney — Purpose: identify the person authorised to make medical decisions on your behalf if you cannot. Expect: name, relationship, phone. May be different from your trustees.
• Insurance — Purpose: hospital billing reference. Expect: provider name, policy / member number.
• Emergency contact — Purpose: who hospital staff call when you arrive. Expect: name, relationship, phone.
• Religious considerations affecting care — Purpose: alert staff to treatment preferences tied to faith. Expect: brief notes (e.g. "no blood products", "female clinician preferred").
• Other notes — Purpose: anything else a first responder should know. Expect: disability accommodations, phobias affecting care, communication needs.
• Access token / wallet-card URL — Purpose: the short UUID-based URL reached from the printed wallet card. Set automatically on first save. Rotate or disable from the medical profile page. Rotation invalidates the old URL immediately — reprint any card or bracelet carrying it.
• Access enabled — Purpose: soft on/off switch that disables the public URL without deleting the record. Useful if a wallet card is lost and you want the URL to stop resolving before you reprint.
• Share with trustees on death (optional, default off) — Purpose: mirror the medical record into the consolidated release emails sent to your trustees after a verified, uncontested death notification. Off by default: the medical profile is primarily a pre-death tool.
• Consent timestamp — Purpose: record the moment you explicitly agreed that the medical URL is unauthenticated and anyone holding it can read the record. Stamped once, on first save. Not re-asked on edits.
• Access log entries — Purpose: one row per successful GET of the public URL, with timestamp, IP address and a truncated user agent. Shown to you at Medical access log. Lets you spot unfamiliar IPs and rotate the token if needed. Not encrypted — the rows hold only metadata (no clinical content).

The access token is cleared automatically when a death notification naming you is released: the record itself is preserved for audit, but the public URL stops resolving.

8. System-generated fields you'll see in your export

Alongside the user-entered fields above, the Download my data ZIP carries a handful of system-managed fields you did not type in but that describe the row's lifecycle. We list them here so the dictionary stays complete.

• row_id (on every row: trustees, every memo type, financial-institution references) — Purpose: internal row identifier. UUID, unguessable, used by URLs and foreign keys. Grants no access on its own — every endpoint that reads a row checks that the requester owns it, so possession of a row_id is not equivalent to being able to read or edit the row. Showing it in the export just means you can round-trip the data through a re-import and quote it in support tickets.
• created / updated (on every memo and trustee) — Purpose: record when the row was first written and last modified. Set by the server, never editable. Let you audit your own history and help us investigate if you report something odd.
• uploaded_at (on video / image memos and death notifications) — Purpose: record when the associated file was uploaded. Same set-by-server semantics as created/updated.
• date_joined (on the top-level account) — Purpose: when you signed up. Derived from Django's built-in auth.User row.
• email_confirmed (on profile) — Purpose: has the activation link been clicked? Controls whether certain actions can run on your account.
• is_alive (on profile) — Purpose: release-flow state flag; true unless a death notification has been verified and released. Nothing for you to change yourself.
• exported_at (on the top-level of the account block) — Purpose: timestamp stamped into the ZIP at export time. Not stored in the database; it's just a header on the file you downloaded.

9. How to see your actual data

The self-service export at Download my data gives you a ZIP with one JSON file per memo type, plus your trustees, profile metadata and notification preferences, with all encrypted fields already decrypted. That export is the ground truth for everything above; if anything on this page disagrees with the export, the export wins.