LEGACY CHANNEL CONSENT MODEL — Docs

Status: design / not built. COUNSEL-GATED before any code. Authored 2026-07-08. This is the keystone build for the eldercare Legacy Channel: the data + consent model that lets an adult child (facilitator) capture and manage a voice clone of their parent (subject) — which the shipped Lovio consent model actively forbids today. Everything in the eldercare wedge depends on getting this right, and it is a legal problem first, a schema second. Nothing here ships until an elder-law + right-of-publicity + biometric-privacy attorney signs off (see §10).

1. The problem

Today lovio_user_voices conflates three roles into one user_id:

lovio_user_voices.user_id  →  the person whose voice it is
                           =  the person operating the account
                           =  the person who consented

The consent statement is hard-coded first-person and single-actor (LOVIO_CONSENT_STATEMENT, lovio-voice.ts): "I consent to HiveJournal using a clone of my voice to speak my own content back to me… will never be used to narrate anyone else's content." RLS is auth.uid() = user_id throughout. The one-active-voice index is per user_id.

The eldercare flow breaks every one of those assumptions: a daughter operates the account; her father is the voice; the father (or, if his capacity is gone, a surrogate) is the consenter. The current model has no way to represent "this account is operating a voice that belongs to someone else, who consented," and the bright line explicitly prohibits it. We cannot bolt eldercare onto the self-model; we must split the roles.

2. The three roles

Role	Who (eldercare)	What they do
Subject	the parent	The voice belongs to them. They (or a surrogate) must consent. They can always revoke. May have no account.
Facilitator / operator	the adult child	Owns the HiveJournal account, runs capture sessions, composes capsules, is billed. Never the voice owner.
Surrogate	guardian / POA / healthcare proxy / next-of-kin	Consents on the subject's behalf only when the subject lacks capacity — a first-class, documented, constrained path (see §7).

The self-model (today) is the degenerate case: subject = facilitator, no surrogate. Backward compatibility falls out of that (§9).

3. Design principle

Separate whose voice it is from who operates the account from who consented — and make consent a ledger, not a column.

A single boolean/column can't carry "the subject recorded a voice-specific consent statement on date X, a surrogate co-signed under POA on date Y, and posthumous delivery was authorized." Consent for a vulnerable adult is an evidentiary record that must survive audit, revocation, and the subject's death. It gets its own table.

4. Data model (proposed)

a) Extend lovio_user_voices — decouple operator from subject:

ALTER TABLE lovio_user_voices
  ADD COLUMN subject_kind        text NOT NULL DEFAULT 'self'   -- 'self' | 'other'
    CHECK (subject_kind IN ('self','other')),
  ADD COLUMN subject_name        text,                          -- the parent's name (null for 'self')
  ADD COLUMN subject_relationship text,                         -- operator→subject: 'parent','grandparent',…
  ADD COLUMN consent_status      text NOT NULL DEFAULT 'active' -- see the state machine, §10-adjacent
    CHECK (consent_status IN ('draft','pending_consent','active','revoked','retired','posthumous_custody')),
  ADD COLUMN deceased_at         timestamptz;                   -- set when the subject passes (gates read-only + custody)
-- user_id KEEPS its meaning as the OPERATOR. For 'self' rows, operator == subject (unchanged).

The one-active-voice unique index must move from per operator to per (operator, subject) — a child may legitimately manage clones for both parents:

DROP INDEX lovio_user_voices_active_unique;
CREATE UNIQUE INDEX lovio_user_voices_active_unique
  ON lovio_user_voices (user_id, COALESCE(subject_name, ''))
  WHERE retired_at IS NULL;

b) New table voice_consents — the consent ledger (the load-bearing new thing):

CREATE TABLE voice_consents (
  id                     uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  voice_id               uuid NOT NULL REFERENCES lovio_user_voices(id) ON DELETE CASCADE,
  role                   text NOT NULL CHECK (role IN ('subject','surrogate')),
  -- The proof artifact. For a subject: a recording of them reading the consent
  -- statement aloud (proves consent AND capacity-to-speak-it in one artifact).
  consent_audio_url      text,
  consent_statement_version int NOT NULL,       -- which statement text they consented to
  -- Capacity (subject role): who attested the subject had capacity, and how.
  capacity_attestation   jsonb,                 -- { attested_by, method, at, notes }
  -- Surrogate role: the authority claimed + evidence reference.
  surrogate_authority    text CHECK (surrogate_authority IN
                           ('poa','guardian','healthcare_proxy','next_of_kin')),
  surrogate_evidence_url text,                   -- uploaded POA/guardianship doc (if we require it)
  surrogate_name         text,
  -- Scope — an explicit grant, not implied. Every capability is opt-in.
  scope                  jsonb NOT NULL,         -- { capture, clone, deliver_now, deliver_posthumous, heir_durable }
  captured_by_user_id    uuid NOT NULL REFERENCES auth.users(id),  -- the operator who recorded it
  recorded_at            timestamptz NOT NULL DEFAULT now(),
  revoked_at             timestamptz,
  revoked_by             text                    -- 'subject' | 'surrogate' | 'operator' | 'admin'
);
CREATE INDEX voice_consents_voice_idx ON voice_consents (voice_id) WHERE revoked_at IS NULL;

A voice is authorized when it has ≥1 non-revoked voice_consents row whose scope covers the action being taken. A subject row is preferred; a surrogate row is the fallback for diminished capacity. Both can exist (subject consented early, surrogate later re-affirms for posthumous delivery).

Consent is captured as a recording of the subject reading a statement aloud — the same proof mechanism the self-model already uses (consent_audio_url), now scoped to the subject. Reusing that mechanism is deliberate: a voice recording of the person consenting is far stronger evidence than a checkbox, and it doubles as a capacity signal.

Proposed statement — v3 (facilitated subject, read aloud by the parent):

"My name is [name]. I understand that HiveJournal will make a recording — a clone — of my voice, and use it to read back stories and messages that I record, in my own voice. I am giving this permission freely. I understand these recordings may be shared with my family, including after I am gone, and I want that. I can change my mind and stop this at any time."

Key properties the statement must carry (per counsel, §10): living (given while alive), informed (names the clone + the uses), voice-specific (explicitly about the voice), posthumous-aware (authorizes after-death delivery explicitly), revocable (states the right to withdraw). These map directly to scope flags.

Surrogate variant (v3-S) — read by the surrogate, paired with capacity documentation and, ideally, the subject's assent where possible: a distinct statement asserting the surrogate's authority and that the action reflects the subject's known wishes. Counsel must confirm a surrogate can authorize voice cloning at all (§10) — this variant may be legally unavailable, in which case diminished-capacity subjects are simply out of scope, not force-fit.

6. Authorization, revocation, custody

Operate: the user_id (operator). RLS stays operator-scoped, but the voice is understood as the subject's.
Hear / trigger playback: reuse the JQ Bridge consent-permission graph (jq_bridge_connections / jq_bridge_permissions) as the "who may hear this person's voice" ACL — especially posthumously. Don't invent a new ACL.
Revoke: first-class for all parties — the subject (paramount; if they say stop, it stops), a surrogate, or the operator. Revocation sets voice_consents.revoked_at and flips consent_status; sealed capsules honor a pre-death revocation. This is the elder-exploitation safeguard.
Custody after death: ties to the eldercare doc's custody-outlives-owner gap. On deceased_at, the voice enters posthumous_custody: no new capture, no new consent, delivery only of pre-authorized capsules (scope.deliver_posthumous = true), custody handed to a designated legacy contact — never an automatic push (mirror Lighthouse).

7. Capacity + surrogate workflow

Capacity is impaired in 44–69% of nursing-home residents and fluctuates, so this is a first-class path, not an edge case:

Default (has capacity): the subject records the v3 statement aloud. The recording is the capacity evidence + consent. The operator attests capacity (capacity_attestation). Recommend re-affirmation on ≥2 occasions (per the clinical-consent literature) for the posthumous scope specifically.
Diminished capacity: the subject cannot validly consent. IF counsel confirms surrogate authority can convey voice rights (uncertain — §10), a role='surrogate' consent with documented surrogate_authority + evidence, plus subject assent where possible. IF counsel says no → diminished-capacity subjects are out of scope; the product's honest answer becomes "this is why we urge families to start early," reinforcing the §3 strategic-gift timing of the eldercare plan.

This is why the whole GTM aims at the early / pre-placement moment: it's the window where the subject can still validly consent in their own voice, which is both the strongest evidence and the cleanest law.

8. Heir-durability (the ELVIS Act / AB 1836 answer)

Voice/likeness rights pass through the estate, and TN's ELVIS Act + CA AB 1836 now govern deceased-person voice replicas. Our answer is not to obtain estate sign-off after death (impractical, and the heirs may differ from the operator) — it's to obtain living, voice-specific, explicitly-posthumous consent from the subject themselves (scope.heir_durable = true, captured in the v3 statement's "including after I am gone, and I want that"). The bet, to be confirmed by counsel: a person's own informed, recorded, voice-specific authorization while alive is the strongest possible basis for posthumous use — stronger than any surrogate or heir could give. If counsel says heir sign-off is also required, that becomes an additional voice_consents row type.

9. Backward compatibility

The self-model is the degenerate case and is untouched:

Existing rows default subject_kind='self', consent_status='active' — no behavior change; JQ/Lovio self-use keeps working.
Existing self-consent (consent_audio_url + consent_version on lovio_user_voices) can be backfilled into a voice_consents row with role='subject' for a uniform read path, or left in place and read with a fallback. (Lean: backfill, so there's one authorization path.)
The 'self' path never touches the surrogate/capacity/posthumous machinery.

10. Open questions for counsel (the gate — resolve before C0)

These are written up as a paste-ready attorney memo at docs/legal/LEGACY_VOICE_CONSENT_COUNSEL_BRIEF.md — hand that to counsel as-is.

Concrete, and load-bearing:

Is a recorded-aloud consent sufficient, or do we need written + witnessed consent for a voice clone of a vulnerable adult?
Can a surrogate (POA / guardian / healthcare proxy) authorize voice cloning at all — given voice/likeness rights flow through the estate, not these instruments? If not, §7 path 2 is dropped.
Heir-durability: does living, voice-specific, recorded consent bind the estate under the ELVIS Act (TN) + AB 1836 (CA) + NO FAKES (if enacted), or is separate heir/estate authorization also required?
BIPA and state biometric law. A voiceprint is a biometric identifier under Illinois BIPA (written release + published retention/destruction schedule + no profit-from-biometrics + private right of action w/ statutory damages). TX CUBI and WA also apply. This may be the single biggest legal exposure and the eldercare doc's brief under-weighted it. What written-consent + retention regime satisfies BIPA for a facilitated capture?
Capacity threshold + attester: who may attest capacity — family (operator), or must it be a clinician? What documentation is defensible?
Vulnerable-adult data: minimum retention, access, deletion, and breach terms; does keeping the family as contracting party reliably keep us out of HIPAA (per the eldercare doc §7d)?
Minor recipients: capsules delivered to grandchildren — any COPPA/consent interplay on the recipient side (echoes Lighthouse's never-before-18 posture)?

11. Build phasing (after counsel clears)

Consent-model C0 (the one-family pilot's spine): extend lovio_user_voices (§4a), add voice_consents (§4b), the v3 subject statement + facilitated capture recording it, consent_status gating on capsule seal. Subject-with-capacity path only — defer surrogate entirely until counsel rules on Q2.
C1: surrogate path (if legally cleared), posthumous custody + deceased_at handling, JQ Bridge hear-ACL for posthumous playback.
Cross-cutting: BIPA-compliant retention/destruction schedule wired from day one (not retrofitted) — it governs the raw audio + the ElevenLabs voiceprint lifecycle.

Subject-consents / facilitator-operates — the consent model