DandyLine — Seed Keys & Guardian System

What Is a Seed Key?

▶

A Seed Key is a unique, shareable code tied to a vault. It's how someone who isn't yet on DandyLine — or doesn't exist yet — eventually connects to the memories planted for them. Think of it like a gift card code for a vault: whoever redeems it gets access to the content inside when it blooms.

Seed Keys are generated automatically whenever a vault is created for someone who can't claim it immediately. They can be shared by text, email, copied as a code, or delivered through a link. The key itself doesn't expire unless the planter sets an expiration.

Seed Keys work regardless of what email address the recipient uses to sign up — the key is the proof, not the email match.

Recipient States

▶

Every vault has one or more recipients. Each recipient falls into one of four states:

Active

They have a DandyLine account and are linked to the vault. Done. When the vault blooms, they see it.

Invited

They don't have an account yet, but the planter sent them an invite (email or text). The invite contains a Seed Key link. When they sign up using that link — with ANY email address — the vault auto-links to their new account.

Held in Trust

They can't join yet. Too young, not born, no contact info. A Guardian holds the Seed Key on their behalf. The vault shows as "Held in trust for [name]" under the Guardian's profile.

Open Claim

No specific person named. The Seed Key can be redeemed by anyone who has it, up to a limit the planter sets (1 person, 3 people, unlimited). Perfect for "all future grandchildren" scenarios.

Important: Multi-Recipient Vaults

A single vault can have MULTIPLE recipients in DIFFERENT states simultaneously. Example: Grandma's vault might have Sterling (Held in Trust, guardian is Ashley), Stella (Held in Trust, guardian is Ashley), Uncle Mike (Invited via email), Grandpa (Active), and Future Grandchildren (Open Claim, unlimited).

Individual seeds within the vault can be assigned to specific recipients OR to the whole vault. So Grandma could plant one seed that says "To all of you" (everyone sees it) and another that says "Sterling, this one is just for you" (only Sterling sees it when he claims his Seed Key).

The Planting Flow — "Who Is This For?"

▶

When a gardener creates a vault, the flow asks "Who is this for?" and the interface works like a contact picker:

1. Start typing a name. DandyLine searches existing users and shows matches (like tagging someone on Facebook).
2. If a match appears, tap it — they're linked. State: Active.
3. If no match, two options appear:
- "Invite them" — enter their email or phone number. They get an invite with the Seed Key embedded. State: Invited.
- "They can't join yet" — the person is too young, unborn, or unreachable. The planter becomes Guardian (or assigns someone else). State: Held in Trust.
4. For vaults intended for unnamed future people, select "A future recipient" and set the claim limit (1, specific number, or unlimited). State: Open Claim.

Email Address Independence

The invite link is the connection mechanism, not the email address. If Emma receives an invite at her old college email but signs up with her Gmail, the link still works. The Seed Key doesn't care which email she uses.

If an invite email bounces or gets lost, the planter can see the pending status in their Gardener profile and resend to a different email or text instead.

The Guardian System

▶

A Guardian is a trusted person who holds a vault's Seed Key on behalf of someone who can't claim it yet. Guardianship is a responsibility, not a setting.

Becoming a Guardian — The Planter's Choice

When planting a vault for someone who can't claim it, the planter gets two options:

"I'll hold this myself" — planter becomes the Guardian.
"Assign someone else" — planter picks another person. That person receives an invitation to accept guardianship.

Critical Rule

The planter remains Guardian until the assigned person explicitly accepts. The vault is never orphaned. If the assigned person ignores the invite, never makes an account, or life gets in the way — the vault stays with the planter. Ownership only transfers on confirmed acceptance.

What Accepting Guardianship Means

When someone accepts, they see a clear, plain-language explanation:

"You are being entrusted with a vault that [Planter's name] planted. Your role is to make sure it reaches the right person at the right time. You are not the recipient — you are the keeper. The original planter chose when this blooms and who it's for. Your job is to deliver the Seed Key when the moment comes."

What a Guardian Can and Cannot Do

✓ Can Do

See that a vault exists and who it's for
See bloom status (sealed, blooming, bloomed) — but NOT the actual content inside
Transfer guardianship to another person (with confirmation)
Share Seed Keys with recipients when the time comes
Set delivery dates if the planter dies before confirming fuzzy dates

✗ Cannot Do

View the actual seeds inside the vault
Change what the planter wrote or uploaded
Cancel or delete the vault
Change who the recipients are (only the original planter can do this while alive)

Content-Blind Guardianship

Guardianship is content-blind by default. This is a locked decision. The Guardian manages delivery but never sees the content. They hold the key but can't use it on themselves.

The Trust Layer — Protecting Sealed Content

▶

Three levels of trust protection, layered on top of content-blind guardianship:

Level 1

Content-Blind Guardian

Guardian can manage delivery but never view contents. They see THAT a vault exists, WHO it's for, and WHEN it blooms — but the actual seeds are invisible to them.

Level 2

Planter-Set Passphrase

Optional. The planter can add a passphrase to a seed or vault. Something personal only the intended recipient would know — a nickname, a shared memory, an inside joke. The Guardian delivers the Seed Key, but the recipient still needs the passphrase to view the content.

Level 3

Dual-Key Delivery

Scale feature, not MVP. The Seed Key is split into two halves. The Guardian holds one, a secondary trustee holds the other. Neither can open it alone. Maps to Shamir's Secret Sharing.

What Happens When the Planter Dies — Posthumous Delivery

▶

This is where the Seed Key and Guardian systems become most critical.

Step 1

Death Verification

Death certificate upload required — no honor system. DandyLine verifies before granting elevated Guardian access.

Step 2

Waiting Period

Pre-authorized Guardian: 7-day wait. Request-based Guardian: 30-day wait. The waiting period protects against premature activation.

Step 3

Guardian Activation

After the waiting period, the Guardian's role elevates. They can now set delivery dates and distribute Seed Keys.

Step 4

Scheduled Blooms

Seeds with confirmed bloom dates fire automatically. The Guardian doesn't need to do anything — the system delivers them exactly as the planter intended.

Step 5

Vault Persistence

The vault persists beyond the planter's account. Subscription-independent preservation ensures nothing is lost.

Posthumous Notification Language

Important UX Consideration: When a bloom arrives from someone who has passed away, EVERY touchpoint needs an alternate, softer version:

Email subject lines — no "Grandma just sent you something!" energy
Bloom reveal screen — slower animation, different pacing, warmer tones
Seed detail cards and pop-ups — gentle indicator that acknowledges the planter is no longer here
The delivery must feel like a gift arriving from far away, not a notification

The system needs to know the planter's status (alive vs. deceased) so it can choose the right experience. This affects: notification templates (HW#41), bloom reveal animation (ux-bloom-reveal.html), and seed pop-up card design.

Where This Lives in the App — The Gardener Tab

▶

Seed Keys and Guardianships live under the Gardener icon in the bottom navigation bar (the profile/identity tab). The bottom nav remains: Field | Pressed | Plant | Gardener.

Inside the Gardener tab:

Your Profile — name, email, account settings
Seed Keys to Share — vaults you planted for people who haven't claimed yet. Shows recipient name, state (Invited / Held in Trust / Open Claim), and a button to share the Seed Key (copy, text, or email). For Open Claim keys, shows how many have been redeemed.
My Guardianships — vaults OTHER people planted where you're the keeper. Shows who planted it, who it's for, bloom status. You can transfer guardianship or share Seed Keys from here.
Seed Keys for Me — codes waiting for you to redeem. Enter a code or tap a link and a vault connects to your account.
Notification preferences, data export, etc.

This ensures nothing gets lost in an email inbox from 2031. Every Seed Key, every guardianship, every pending claim is visible in one place.

Multi-Recipient Logic & Seed Assignment

▶

A vault can have multiple recipients. Some may be born, some not. Some may be active users, some not. The system must handle:

One vault → many recipients, each in a different state, each with their own Seed Key
Individual seeds within a vault can be assigned to specific recipients OR to all recipients
Different seeds in the same vault can bloom at different dates for different people (already a locked decision for Legacy vaults — multiple bloom dates within the same vault)
A grandparent can add grandchildren over time as they're born — recipients can be added to an existing vault after creation
Vault settings (adding recipients, updating contact info, changing guardians) should be editable after creation. Certain things are NOT editable after sealing (content of sealed seeds, bloom dates of already-sealed seeds — TBD what the full list is)

Schema Implications for Build (Josh Reference)

▶

The Seed Key system requires additions to the D1 database schema:

New Tables Needed

seed_keys — id, vault_id, recipient_name, recipient_email, recipient_phone, status (active/invited/held_in_trust/open_claim), claim_limit, claims_used, passphrase_hash (nullable), created_at, claimed_at, claimed_by_profile_id
guardianships — id, vault_id, guardian_profile_id, assigned_by_profile_id, status (pending/accepted/transferred), accepted_at, transferred_to (nullable), created_at
vault_recipients — id, vault_id, seed_key_id, profile_id (nullable until claimed), recipient_state, display_name

Changes to Existing Tables

vaults — add: planter_status (alive/deceased), guardian_activation_date (nullable)
seeds — add: recipient_scope (all/specific), assigned_recipient_ids (array or join table)
profiles — add: recovery_email (nullable)

Brand Vocabulary Additions

▶

New terms to add to the DandyLine vocabulary:

DandyLine Term	What It Means	NOT This
Seed Key	The unique code that connects a recipient to a vault	Token, access code, claim code
Guardian	A trusted person who holds a Seed Key on behalf of someone who can't claim it yet	Admin, executor, manager
Held in Trust	A vault's status when the intended recipient can't claim it yet	Pending, unclaimed, locked
Claim / Redeem	The act of entering a Seed Key and connecting a vault to your account	Activate, unlock, register
Content-Blind	A Guardian who can manage delivery but cannot view sealed content	Read-only, restricted

Open Questions (Still Being Figured Out)

▶

Questions Still in Flight

What EXACTLY can and can't be edited after a vault is sealed? Need a full list of editable vs. locked settings.
The full posthumous notification language — copy, tone, visual treatment. Needs its own design session.
Compost mechanics for Seed Keys — does an unclaimed Seed Key expire? If a vault composts, do the Seed Keys die too?
What happens if a Guardian dies too? Succession chain? Or does the vault just persist and wait?
Dual-key (Shamir's Secret Sharing) implementation details — scale feature, not MVP, but needs architectural thinking.
Legacy vault physical archive export — how does the Seed Key system interact with the memorial box / printed book concept?
Passphrase recovery — what if the planter dies and the recipient doesn't know the passphrase? Is there a recovery path?

Opportunities to Explore

▶

Ideas generated during the April 12, 2026 brainstorm session. Each is tracked as a homework item for further development.

1. Seed Key Chains — Generational Forwarding

After a planter dies and their vault is delivered, the Guardian or recipient could continue planting new seeds into it. Grandma's vault grows over time as her daughter adds context and stories. Creates layered, multi-generational memory objects. No competitor offers anything like this. (HW#56)

2. The Dandelion Drop — Event-Based Open Claim Vaults

Open Claim Seed Keys at events — weddings, graduations, baby showers, corporate retreats. QR codes on place cards, 150 guests scan and plant seeds, vault fills in real time, blooms on anniversary. Revenue opportunity: per-event pricing or bulk Seed Key packs. Partnership channel with event planners, wedding coordinators, retreat organizers. (HW#57)

3. Memory Capsule Partnerships — Institutional Distribution

Organizations that deal in time + memory embed DandyLine into their services. Hospitals giving new parents a Seed Key at birth. Retirement communities offering Legacy Vault setup. Schools giving graduating seniors a Grove Vault. Each partnership = distribution channel + emotional proof point for investors. (HW#58)

4. The Waiting Room — Pre-Bloom Anticipation UX

The emotional space between planting and blooming is invisible to recipients. Show a "Something is growing for you" indicator — not what's inside, not when. Like a wrapped present under the tree. Drives retention, creates anticipation, makes the bloom moment even more powerful. (HW#59)

5. Seed Key as Physical Product — Printed Cards / Gift Items

Beautiful physical Seed Key cards — like a gift card but for memories. Sold at retail, included in gift boxes, mailed as invitations. "Someone planted something for you. Scan this to claim it." Makes DandyLine tangible. Solves "how do I explain this to my mom." Revenue stream AND marketing channel. (HW#60)

6. Guardian Network — Trust Circles (Multi-Guardian)

Instead of a single Guardian, allow a trust circle — 2-3 people who collectively manage delivery. No single person bears the full weight. Adds redundancy. Voting mechanic: 2 of 3 agree → action proceeds. Connects to Shamir's Secret Sharing concept. (HW#61)

🌱 Core Growth Engine Insight

The Seed Key system isn't just a feature — it's DandyLine's core growth engine. Every vault for someone not on the platform = organic invitation. Every Open Claim Key at a wedding = 150 potential signups. Every "Held in Trust" vault for an unborn child = a user who joins years later and arrives to something already waiting. "Sign up and immediately receive a message from someone who loved you before you existed." No other app can offer this. (HW#68 · VP-10)

Guardian Authority & The Default Guardian System

▶

Resolved April 18, 2026. Originally worked through in ux-planting-flow.html (Unknowns section) and moved here as the canonical home. Also tracked as HW#81, HW#82, HW#85.

Who can change a bloom date, recall a seed, or act on a vault when the Planter can't? This section is the authority model for everything a Guardian touches. It's built around one principle: a seed is a gift to the recipient, and once planted, nobody reaches in and rearranges it except under strict rules.

The Tiered Authority Model — non-locked seeds

Planter — can change the bloom date freely while active on the app. Their vault, their seed, their moment.
Grove co-planters — can propose a date change; the vault creator must approve. Proposal sits in the vault's activity feed until accepted or declined.
Guardian — activates only under (1) Held in Trust status (planter inactive 2+ years — see Section 15), (2) verified-deceased status via the death verification flow, or (3) explicit co-planner rights granted at vault creation.
Recipient — never modifies. The delay is sacred. This is non-negotiable.

Super Lock — Permanent Bloom Date (opt-in, irreversible)

A per-seed or per-vault opt-in flag at planting time that permanently freezes the bloom date. Once sealed with Super Lock ON, the flag is irreversible. No one can ever change the date — not the planter, not the Guardian, not Premium users.

Available on all tiers — never Premium-gated. Certainty should never be a paid feature.
Locks only the bloom date. Content, recipient, and sharing still follow normal rules.
Small padlock UI indicator on the sealed seed.
Super Lock extends to sharing settings — a Planter can lock a vault as "sealed forever, nobody can ever open this up," same mechanic.
Super Lock is blocked for vaults without a set bloom date (see HW#89 and Section 15). You can't permanently lock a date that doesn't exist yet.

On-Brand Rationale

Super Lock embodies the DandyLine promise: "when you're this certain, we honor it forever." The irreversibility is the feature.

Default Guardian — a profile-level setting

Gardeners can name a Default Guardian in their profile that auto-applies to all new vaults (changeable per vault). At account setup, the user is asked but never required: "You can skip and add later, but we strongly encourage it."

Up to 5 Guardians per vault, all equal authority. Any one can act; actions are logged and other Guardians notified via Weather Update. No primary/backup hierarchy.
Content-blindness applies to all Guardians (existing rule — see Section 04).
Every Guardian gets a "My Guardianships" view in their profile showing what they Guardian — content-blind, just names and states.
Guardian replacement — Planter can change Guardian at any time. Previous Guardian gets a subtle notification; access transfers cleanly.
Guardian death/inactivity — no auto-cascade. Planter reassigns; if all Guardians are inactive when action is needed, the 3-Layer Ladder + Sunset flow catches it.

Per-vault-type Guardian defaults

Personal — no Guardian by default. Prompt only if vault is Date TBD or bloom is >5 years out.
Grove — profile default applied. Nudge at 10+ seeds / 3+ contributors: "Want to add additional Guardians?" Uses Hybrid model (below).
Milestone — profile default applied. A Milestone vault can hold multiple internal bloom dates (Wedding · 1yr · 5yr · 10yr); the Guardian oversees the whole vault regardless of internal seed count.
Legacy — strongly recommended, NOT required. Prominent notice: "Legacy vaults can bloom decades from now. Without a Guardian, if you become inactive, delivery may fall back to our Sunset flow." Forcing someone to name a Guardian they don't have pushes them to name the wrong person.
Journey — no Guardian by default (community model, no traditional recipient). Opt-in only.
Roots — profile default applied for named-recipient seeds. Public-drop Roots seeds skip Guardian (no single recipient).

Hybrid Grove Guardian Model

Every Grove has two Guardian layers:

Vault Guardian (creator's choice, defaults to their profile default) handles structural decisions — bloom scheduling, vault lifecycle, Grove closure.
Contributor Guardian (each contributor's own profile default) handles what happens to that contributor's seeds if they go inactive or die.

A contributor's Guardian can only manage that contributor's seeds within the Grove — never other contributors'. The Vault Guardian cannot touch individual contributor seeds. Personal ownership is preserved inside a shared container.

Premium adds flexibility, not authority

Premium tools are: calendar view across all vaults, bulk rescheduling, a "snooze" button for upcoming blooms. Premium users don't get new powers over their non-locked seeds (they already have those) — they get better tools.

Account deletion — a deliberate walkthrough, not one-click

Personal vaults with a Guardian → transfer to the Guardian.
Personal vaults without a Guardian → enter Sunset.
Grove vaults created by the user → transfer to the Vault Guardian, or get flagged "This Grove has no designated owner. Claim ownership?"
Grove seeds planted by the user → transfer to their Contributor Guardian. They cannot take other contributors' seeds with them.
Super Locked seeds cannot be deleted, full stop.

Final confirmation shows a full impact summary. This is also a retention mechanism — the considered exit often changes the user's mind mid-flow.

Age Milestones — The Event-Anchor Model

▶

Resolved April 18, 2026. Originally mapped in ux-planting-flow.html Unknowns section. Also addresses COPPA compliance architecture.

How does DandyLine know when an age-based trigger fires? If a Planter seals a vault to bloom "when she turns 18," the system needs the recipient's birthday — but the Planter shouldn't have to carry that fact around in their head, and for unborn recipients it's unknowable at planting time.

The Event-Anchor Model separates intent (set by the Planter) from fact (sourced from the person the fact belongs to). The Planter declares the trigger; the recipient or their Guardian supplies the data. Three layers make this work:

1 — Birthday becomes a required profile field at signup

It does two jobs at once:

COPPA age verification — legally we need to confirm an account holder is 13+.
Auto-fill for any vault addressed to them — no typing, no guessing.

Displayed discreetly. Month + day may be visible to Grove members the Gardener has chosen to share with; year is private unless the user opts in.

2 — The trigger auto-pulls from profile

When a Planter assigns an age-milestone trigger, DandyLine pulls the recipient's birthday from their profile automatically. The UI confirms back in plain language: "Stella turns 18 on March 4, 2044" — as soon as Stella is selected.

If the Planter attaches a recipient who doesn't have an account yet (Seed Key path), the bloom date is calculated later — at claim time, when the recipient or their Guardian enters the birthday.

3 — Unborn recipients and Seed-Key-only paths work naturally

For an unborn grandchild, the Guardian enters the birthday when the child is born.
For a Seed Key planted to "my future nephew," the recipient supplies the birthday at claim.
Either way, the Planter never has to know the fact — just the intent.

Age milestone is one trigger subtype, not the flagship

The planting UI should not over-center birthday. Equally valid triggers: life events (graduation, marriage, first job), custom dates (anniversaries, memorials), calendar dates, and bloom-on-demand. Birthday is just the "age + date math" case. All trigger types live on equal visual footing in the planting flow.

Edge-case handling

Planter guesses wrong — impossible by design. The Planter doesn't enter the birthday; the recipient/Guardian does.
Birthday correction before bloom — the recipient or Guardian can update it anytime before bloom. After bloom, locked.
Super Lock interaction — if a Planter Super-Locks an age trigger, the calculated DATE shifts when the birthday is corrected, but the AGE RULE stays sacred.
Unborn + Guardian never enters birthday — falls into the 3-Layer Ladder (nudges → Held in Trust → Sunset).
Privacy-minded user refuses birthday — required at signup (COPPA), but year can be hidden from other Gardeners via opt-in.

Why This Works

Intent and fact stay separated — the way age milestones work in real life. You know you're writing this for your daughter's 18th birthday; you don't carry her birthday around as a data field. The profile-birthday approach also resolves COPPA compliance in the same stroke as the trigger mechanic — one field, two legal-and-product jobs.

Seed Keys & Guardianship