The Living Voice — Roadmap

Status: vision / near-future (mostly not built). Track A is buildable now off existing surfaces; Track C is a near-term GTM that needs only Track A's atom; Track B (spatial/VR) is the north star and is greenfield. Authored 2026-07-07, the day the first user voice clone read a HiveJournal note back in the user's own voice.

The atom (shipped)

On 2026-07-07 the voice-clone loop closed end-to-end: a user records a consent line + a ~60s reading sample at /dashboard/lovio/voice-setup, ElevenLabs Instant Voice Cloning mints a voice, and their own journal notes are narrated back in their own voice.

Storage: lovio_user_voices (migration 213_lovio_v1.sql) — one active clone per user, elevenlabs_voice_id, consent + sample audio in the season-assets bucket. Service: lovio-voice.ts.
Reusable synthesis: ttsSegment(text, voiceId, …) already turns arbitrary text + any voiceId into an MP3 buffer, with per-user quota gating via tts-spend.ts. Podcast, audiobook, and capsule paths all call it.

That atom points in two temporal directions, and that is the whole idea of this doc.

The insight: one engine, two directions

The same voice engine — your words, your voice — can pull in opposite directions in time:

Forward (Track A — "JQ"). The voice pulls you toward your future: goal-nudges, in your own voice, emanating from the JQ companion. Motion, agency, becoming.
Enduring (Track B — "Lovio Presence"). The voice outlives the person: a loved one, embodied, read back after they're gone. Memory, continuity, presence.
Market (Track C — "The Legacy Channel"). Nursing homes as the distribution wedge for the enduring side — record while you still can; heard after you're gone.

One spine, three tracks. Consent & ethics is the load-bearing wall shared by all three, so it comes first.

                 ┌─────────────────────────────────────────┐
                 │  SPINE: voice → narration → presence      │
                 │  (clone shipped · ttsSegment reusable)    │
                 └───────────────┬─────────────────────────┘
        forward in time          │          enduring in time
   ┌─────────────────────┐       │       ┌──────────────────────────┐
   │ TRACK A — JQ        │       │       │ TRACK B — Lovio Presence  │
   │ pulls you forward   │       │       │ outlives the person       │
   │ (buildable now)     │       │       │ (north star, greenfield)  │
   └─────────────────────┘       │       └──────────────┬───────────┘
                                 │                       │ its market
                                 │            ┌──────────┴───────────┐
                                 │            │ TRACK C — Legacy      │
                                 │            │ Channel (nursing homes)│
                                 │            └──────────────────────┘

This is not an appendix. Every track lives or dies here.

1. Consent v2 — broaden at clone time (decided)

The current consent line scopes the clone to lovio capsules only (LOVIO_CONSENT_STATEMENT in lovio-voice.ts): "I consent to HiveJournal cloning my voice for my own lovio capsules only. I understand my voice will not be used to narrate anyone else's content. I can retire this clone at any time."

That text does not cover JQ goal-nudges. Decision: broaden the consent at clone time so a single clone legitimately powers self-directed guidance (JQ) and lovio, while never narrating anyone else's content. Draft v2 (read aloud during recording, kept forever as opt-in proof):

"I consent to HiveJournal using a clone of my voice to speak my own content back to me — my journal entries, lovio capsules, and reminders or encouragement toward goals I've set. My voice will never be used to narrate anyone else's content, and I can retire this clone at any time."

Implementation: version the consent string (consent_version on lovio_user_voices), keep the audio proof, and gate any new use behind the version the user actually recorded — old clones on v1 keep working for lovio but must re-consent (a 20-second re-record) before JQ can speak in them. The consent line is already server-driven (GET /api/lovio/voice/consent-statement), so the copy ships without a frontend redeploy.

2. The read-only vs. generative line (the single most important ethical rule)

A voice can do two very different things:

Read-only: narrate words the person actually wrote/said.
Generative: speak new words the person never said, in their voice.

For the enduring tracks (B and C — a person read back after death), the default and often the only mode is read-only. We narrate what they left; we do not invent new speech and put it in a dead person's mouth. Any generative use for a deceased person (e.g. "answer a grandchild's new question in Grandpa's voice") is a bright-line product decision requiring explicit, documented, pre-death opt-in and family gating — treat it as out of scope until deliberately, separately greenlit. This distinction is what keeps the enduring product memorial rather than necromantic.

3. Gating, dignity, custody

Who can trigger a voice? The JQ Bridge consent-permission graph (jq_bridge_connections / jq_bridge_permissions) is the natural substrate for "who may hear / trigger this person's voice" after death. Reuse it rather than inventing a new ACL.
Framing: the UI must always read as "a recording of [name]", never impersonation. Presence, not resurrection.
Data custody after death: a designated recipient/executor inherits access on a delay (Lovio's existing delayed-vault thesis), never an automatic push. Mirror the Lighthouse "opens on their terms, never a push" rule and the Lovio ethics page.
Vulnerable-adult consent (Track C): capacity to consent, guardianship/POA sign-off, and revocation must be first-class — see Track C.

4. Cost guardrails

ElevenLabs character spend is real and already the platform's largest single AI cost line. Every track must: cache rendered audio (never re-synthesize the same line), keep nudges short, rate-limit per user/day, and never force re-render. Reuse the existing tts-spend.ts quota gate on every new synthesis path.

Track A — JQ, the forward voice (near-term, buildable)

One line: JQ speaks short, personal, goal-forward nudges in your own voice, from the companion orb — and pulses while it speaks.

Scope decision: JQ is a cross-product voice companion for the whole ecosystem (HiveJournal, write.cafe, Lovio, DreamPro). DreamPro-light is home #1 — the first surface it ships on — not the boundary of the vision.

What it builds on (all existing)

The orb: Chatbot.tsx is already the global "JQ" companion, already function-calling, already pulses via pulseGlow in Chatbot.module.css. We extend it, not rebuild it.
The goal engine: DreamPro dreams + dream_steps (029_add_dreampro.sql) and the existing nudge cron step-prompter.ts (/cron/process-step-prompts). This is exactly where "your clone pushes you toward the next step" hooks in.
The voice: getActiveVoice(userId).elevenlabs_voice_id + ttsSegment — one thin new endpoint away.

"DreamPro-light" — defining the home

No "DreamPro-light" exists in code yet. The nearest artifact is the cloneable "30-Day Reset" seed dream (from the coaching docs). Define DreamPro-light = the 30-Day-Reset-style single cloneable goal + daily steps, with JQ voice as its signature feature — a lightweight entry product (one goal, one voice coach that is you) that upsells into the fuller DreamPro Coaching System. It is the smallest thing that makes the "your own voice pulls you forward" promise real.

The two pulse behaviors (your spec)

Speaking pulse: while JQ narrates, the orb pulses in time with the audio (extend pulseGlow; optionally amplitude-drive it from the audio element). This is the "the voice is alive" signal.
Double-pulse self-advertisement: occasionally JQ double-pulses to surface the feature to a user who hasn't tried voice yet. Guardrail: the brand is calm — not gamified, not pinged (the compare page literally sells this). So the double-pulse must be rare, silent, dismissible, and self-extinguishing once the user has engaged voice once (mirror the localStorage 'jq-clicked' pattern in JQTooltip.tsx). A nagging orb would violate the core promise.

New surface area (small)

POST /api/jq/voice/say — arbitrary text + current user → getActiveVoice → ttsSegment → cached MP3 URL (quota-gated). The one genuinely new endpoint.
Nudge composer — a short LLM call turning {active dream, next step, recent journal tone} into one or two sentences in the user's own idiom, then voiced. Cache per (step, day).
jq_voice_nudges (optional) — log of what was said + when, for dedup, rate-limiting, and a "play it again" history.
Preference: a per-user "let JQ speak in my voice" toggle (default off until they've heard a preview), plus cadence control.

Phasing

A0 — Voice endpoint + one nudge. ✅ SHIPPED (2026-07-07). POST /api/jq/voice/say + GET /api/jq/voice/nudge, consent v2 (migration 458), <JqNudgeCard> on /dashboard/dreampro, and the orb's amber speaking-pulse. The primitive (sayInUserVoice — cache + quota + consent gate) is now the shared foundation for A′, B, and C. See INDEX → "JQ voice (A0)".
A1 — Speaking pulse. ✅ Orb pulses amber while narrating (shipped with A0).
Cadence — ✅ SHIPPED (2026-07-07). Occasion-aware nudges (migration 459): morning intention (once/calendar-day, first /dashboard/dreampro visit), step-complete celebration (right after completing a step), at-risk streak (<StreakNudgeTrigger> on /dashboard fires once/day when a streak is going but you haven't written today; takes precedence over the ambient persona orb), plus the default next-step (once/session). Each occasion has its own tone + its own cached line/audio. Shared frontend helpers in lib/jqPresence.ts. All four cadence occasions now wired.
A2 — DreamPro-light home. ✅ SHIPPED (2026-07-07). Packaged "a voice coach that is you" into the existing 30-Day Reset entry product (the ClickBank front-end): a signature "your coach speaks in your own voice" section on the /30-day-reset landing, and a gentle, dismissible <CoachVoiceSetupNudge> on /dashboard/my-coaching (self-hides once the user has a JQ-ready v2 clone). The nudge cadence + orb (built earlier) do the rest once a goal + voice exist — so this phase was positioning + the setup on-ramp, not new voice infra.
A3 — Double-pulse advertisement + ecosystem spread. Restrained self-advertise; extend JQ voice to write.cafe streaks and journal playback.

Open questions (A)

Cadence: how often is "forward motion" vs. nagging? (Lean: ≤1 unprompted voice nudge/day, user-tunable, off by default.)
Voice authoring: does the nudge speak the user's words back (read-only, safest) or generate new encouragement in their voice (generative — fine for self, but set the norm here)?
Does JQ-light get its own lightweight domain/skin, or live inside /dashboard/dreampro?

Track A′ — Ambient Narration (voice on every surface)

Two closely-related surfaces that fall straight out of Track A's POST /api/jq/voice/say + the entry audio-cache pattern (voice_audio_url on journal_entries, migration 216). Both are render-once, cache-forever, serve-to-all — the defining cost pattern for voice-at-scale.

A′.1 — Public voice stream (near-term; user-requested)

One line: once a note has a recording (journal_entries.voice_audio_url IS NOT NULL), let the author toggle it playable in the public stream, and surface a player icon on those items in the horizontal stream.

Builds on: the shipped entry voice-render cache (voice_audio_url, 216_journal_voice_audio.sql), the existing per-entry content_visibility ∈ (public|team|org|user) (migration 004), and the stream cards under apps/frontend/src/components (*StreamCard.tsx, dashboard/stream/page.tsx).
New surface: a toggle on the entry page that only appears once a recording exists (gate on voice_audio_url), plus a small flag (e.g. voice_stream_enabled) so "shared publicly" and "audible in the stream" are separable. The stream renders a ▶/🔊 player affordance on items where voice_stream_enabled && voice_audio_url, playing the cached MP3 inline (no re-synthesis).
Open decision (see below): which horizontal stream is "the public stream," and whether voice-public should require content-public.

A′.2 — "Hear about this" (the ambient-narration idea)

One line: any page — a tutorial, a manifesto, a product/feature page — carries a "Hear about this" button. On the first click for that surface we synthesize a voiceover (in the relevant voice), cache it, and every subsequent visitor to that surface gets the cached audio instantly. Render-on-demand, pay once.

Whose voice? For personal surfaces (a user's own dashboard), the user's own clone. For product / marketing / manifesto surfaces, a house voice — the founder's clone — so the brand speaks in one consistent human voice. Consent nuance: the house voice is a separate, explicit founder/admin consent (the founder narrating platform content is deliberately outside the per-user "never narrate anyone else's content" rule — it's the founder's own product, their own choice). Keep the two consent scopes distinct.
Data model: a surface_narrations table keyed by a surface/route key → { script, audio_url, voice_id, rendered_at, content_hash }. First click with no row → generate script (LLM, from the page's own copy/purpose) → ttsSegment → store → serve. Mirror the entry cache's content_hash invalidation so an edited page re-renders. Quota-gate the first render via tts-spend.ts.
The screen-demo layer (your headless-video idea): pair the voiceover with an auto-generated screen demo — a headless Playwright walkthrough (the repo already runs server-side Playwright sessions for AI-persona browsing) recorded to video, then muxed with the voiceover track through the existing render-kit / scene-studio audio-over-video plumbing (sync/ffmpeg recipes). Same render-once-cache-forever economics. This is the "show and tell, in my voice" endgame: a tutorial that demonstrates the click-path while narrating the thinking behind it.
Phasing: A′.2a — audio-only "Hear about this" on a handful of manifesto/product pages (house voice), lazy + cached. ✅ SHIPPED (2026-07-07): surface_narrations (migration 462), services/narration.ts (SURFACE_REGISTRY seeds → LLM script → ttsSegment in the HOUSE_VOICE_ID clone → cached by sha256(seed+voice)), POST /api/narration/hear, and <HearAboutThis surface> on /ethos, /30-day-reset, /compare. Set HOUSE_VOICE_ID to the founder's clone voice_id (that env-set IS the house-voice consent; stock Matilda fallback otherwise). → A′.2b — user's-own-voice narration on personal surfaces. → A′.2c — headless screen-demo video + voiceover, cached per surface.
Guardrail: same calm-not-noisy rule as JQ — the button is opt-in-to-play, never autoplay; never a nag.

Open decisions (A′)

Which stream is "the public stream"? /dashboard/stream (the owner's stream) vs. a genuinely public/anonymous feed (Graphene-home-style row). Determines where the player icon lives and who can hear it.
Voice-public vs. content-public: does enabling stream audio require the entry's content_visibility='public', or can audio be public while text stays private? (Lean: audio-public implies content is heard, so require content-public — no "private text, public voice" split, which would surprise users.)
House-voice consent artifact: capture the founder/admin house-voice consent as its own recorded statement, versioned like the personal consent.

Track A″ — the Presence Orb (ambient messenger)

One line: a small on-screen orb representing a person — the user themselves, or an AI-persona user — that rolls / bounces in from an edge at meaningful moments, and can bounce into the JQ orb to pop a message (spoken and/or shown). It's the playful delivery surface for everything the voice engine produces, and the 2D on-ramp to Track B's embodied presence.

Why this is the right next companion

A0 just shipped the JQ orb (bottom-right Chatbot.tsx) and its jq:speaking amber pulse. The Presence Orb is its counterpart: where JQ is the assistant, the Presence Orb is a character with a face — an avatar (the user's, or a persona's from ai_personas) that has physical presence on the page. The collision with JQ is the grammar: orb rolls in → bounces into JQ → JQ speaks / a bubble pops. That single interaction unifies three things we already have:

Voice nudges (A0): instead of a static <JqNudgeCard>, a self orb rolls in and bounces into JQ to deliver the nudge in your own voice.
AI personas: a persona orb (their avatar) rolls in to say something in-character — ambient life on the page, tied to the persona-browser/scrapbook activity that already exists.
Presence (Track B): a stylized 2D avatar with motion + a speech bubble is the crawl before the walk of a rigged/embodied avatar.

Builds on

The JQ orb + jq:speaking event bus (already shipped) — the Presence Orb dispatches/receives the same kind of window events, so it stays decoupled.
ai_personas (avatars, display names) for the persona variant.
The A0 sayInUserVoice primitive for any spoken payload.
Pure CSS/Framer-style motion; no new engine (contrast Track B's 3D).

Shape (proposed)

A global <PresenceOrb> mounted alongside Chatbot (same chromeless-surface suppression). Props/state: subject (self | persona), avatarUrl, message, optional audioUrl, motion (roll | bounce | drift), entryEdge.
Choreography: enter (roll/bounce in from an edge) → settle / idle bob → optional travel to the JQ orb + collide (JQ pulses on impact) → message pops (speech bubble; if audioUrl, plays + triggers jq:speaking) → dismiss (tap, timeout, or roll back off).
Trigger bus: a presence:show window event (or a small queue hook) any surface can fire: { subject, avatarUrl, message, audioUrl?, motion? }. One orb at a time; a queue serializes multiple.
Calm rule (inherited): opt-in-to-play audio, never autoplay sound; rare, dismissible, never a nag — same discipline as JQ's double-pulse.

Phasing

P0 — the component + one trigger. ✅ SHIPPED (#1063). <PresenceOrb> with roll-in + tap-to-pop bubble, driven by presence:show, wired to the self-orb A0 nudge. (The travel-and-collide + JQ impact flash originally scoped as P1 landed here too.)
P2 — persona orbs. Shipped 2026-07-07, UI removed 2026-07-12. A persona's avatar rolled in with an in-character line pulled from its scrapbook (GET /api/jq/voice/persona-presence → getPersonaPresence, reusing the "why this caught my eye" note — no new generation, no cost). The ambient orb was pure non-actionable flavor, so <PersonaPresenceTrigger> was removed from /dashboard — no persona orb rolls in now. The endpoint + getPersonaPresence remain (unused, read-only) so it can be re-enabled once persona voice + richer choreography make it worth a user's attention.
P1/P3 — remaining. Richer collide choreography; persona voice (their preset/cast ElevenLabs voice); multiple presences, priority, quiet hours, frequency caps; tapping a persona orb to open its kept link.

Open decisions (A″)

First payload: does P0's orb deliver the A0 voice nudge (self), or a persona "hello" (more novel, less utilitarian)? (Lean: self + nudge — reuses A0 end-to-end, immediately useful.)
Motion vocabulary: roll (ball physics) vs. bounce (squash-stretch) vs. drift (float) — pick a signature default, expose the rest.
Sound: silent by default with an optional voice payload, or a soft "bloop" on collision? (Lean: silent unless it carries a voice line.)
Does colliding open JQ chat, or just pop a self-contained bubble? (Lean: bubble first; opening chat is a P1+ affordance.)

Track B — Lovio Presence, the enduring voice (north star, greenfield)

One line: an avatar of a lovio person — the subject you chose to map first — that you can sit across from (couch / kitchen table / podium), driven by our data, reading their own words in their own voice.

Honest starting point

No 3D / avatar / VR / WebXR tech exists in the repo today. What does exist is a 2D AI-video lip-sync pipeline in scene-studio.ts (keyframes via FLUX, clips via Kling, lip-sync via Replicate sync/lipsync-2-pro). That is offline video generation, not a live-driven avatar — but it is the on-ramp: we can make a talking portrait of a person long before we can seat a rigged 3D avatar in a room.

Format recommendation (you asked: Apple, Meta, or universal)

Target WebXR first as the universal on-ramp. It runs in the Meta Quest Browser and Apple Vision Pro Safari today, with one codebase, no App Store gate, no native SDK lock-in. Use glTF/GLB avatars (portable across every engine). Defer native visionOS (RealityKit) and native Meta (OpenXR SDK) builds until a WebXR pilot proves the experience is worth the per-platform cost. Net: WebXR + glTF is the "universal format" answer; native is a later optimization, not the starting bet.

Phasing (crawl → walk → run)

B0 — Talking portrait (2D, no XR). A still photo + their cloned voice + sync/lipsync-2-pro → a lip-synced video of the person reading a note. Ships on the web, reuses scene-studio. This alone is emotionally enormous and is the demo that sells Track C.
B1 — Ambient presence (2.5D scene). ✅ FIRST SLICE SHIPPED (2026-07-07). Built before B0 (deliberately re-ordered — B1 is zero video-gen cost; B0's lip-sync is a Replicate cost + needs a source-photo answer Lovio doesn't have yet). <PresenceViewer> (components/presence/PresenceViewer.tsx) drops a portrait into a dim, intimate "room" that breathes gently at rest and more deeply + glows warm while the voice plays (pure CSS; time-based breath, not amplitude — cross-origin storage audio through Web Audio risks tainting/muting playback). Launched by <SitWithThis> on the entry page (self's avatar + the entry's cached voice render). Next: real scenes (couch/table art), and the B0 lip-sync video as a premium upgrade when the cost + source-photo calls are made.
B2 — 3D avatar in-browser. A glTF avatar (react-three-fiber) lip-synced from ElevenLabs forced-alignment visemes, seated in a room. First real-time driven presence.
B3 — Spatial (WebXR). The same avatar in Quest Browser / Vision Pro Safari — you sit across the table in a headset. Native builds only if the pilot demands them.

Data-driven, and the ethics that bound it

"Driven by our data" means the script (which of their notes, in what order, matched to the moment) and the affect (tone) come from HiveJournal data — not that we generate new words for the dead. Track B is read-only by default (see cross-cutting rule 2). The avatar reads what they left. Gating, custody, and the "recording, not resurrection" framing from the cross-cutting section are hard requirements, not polish. Tie explicitly to the Lighthouse safeguarding model and the Lovio ethics page.

Open questions (B)

Likeness rights: cloning a face is a heavier consent than cloning a voice — does B0 require a separate, explicit likeness consent captured pre-death?
Uncanny-valley risk vs. a deliberately stylized (illustrated, not photoreal) presence — which is more comforting and less exploitative in grief?
Where does the avatar's "idle" behavior come from without straying into generative fabrication?

Track C — The Legacy Channel (nursing-home GTM; your direction #3)

One line: sell the experience to nursing homes / assisted-living / hospice so residents record their voice + notes while they still can, to be read back to family in their own voice after they're gone.

Why it fits the spine perfectly

It is Lovio's delayed-vault thesis with a distribution channel attached: a place full of people with the most reason to leave a voice, and the least time to wait.
Cleanest consent story we have: the person opts in for themselves, about their own voice and words — no third-party impersonation, no minors, no alienation dynamics. (Contrast Lighthouse's much harder abuser-vector problem.)
It is monetizable with only Track A's atom + Track B0 (talking portrait). No VR required to launch — B0 is the demo, the clone + narration is the product.

The hard, humane part: elderly-first capture UX

This front-loads the most important UX work and makes it better for everyone. Design constraints:

Assisted / facilitated recording (a staffer or family member helps; the resident just talks).
Large targets, no jargon ("Create my voice clone" → "Save my voice"), forgiving retries, generous mic handling.
Prompt scaffolding: instead of a blank page, guided prompts ("Tell them about the day they were born", "What do you want them to know") that double as the notes to be read back.
Session-based: many short recordings over weeks, not one perfect take — richer clone, gentler on the person.

Business model (strawman — REVISED, see LEGACY_CHANNEL_ELDERCARE.md)

Update (2026-07-08): the detailed GTM in LEGACY_CHANNEL_ELDERCARE.md argues the wedge is not a B2B facility license but the adult child at the moment of placing a parent in care — family pays, facility refers (keeps us out of HIPAA + is a warmer, faster sale). The strawman below is the original framing, kept for the trail.

B2B per-facility license + per-resident onboarding; family receives the vault (delayed-release) as the deliverable.
Optional consumer upsell to family: the B0 talking portrait, the eventual Track B presence.
Partner shape mirrors the DreamPro/Ryan-Thomas white-label pattern: facilities (or an eldercare channel partner) rebrand and distribute; we run the rails.

Regulatory & dignity guardrails

Capacity & guardianship: capture capacity-to-consent; support POA/guardian co-consent and revocation. A resident with diminished capacity is a first-class case, not an edge case.
Vulnerable-adult data: treat recordings as sensitive PII with explicit retention, access, and deletion terms; define custody-on-death up front.
Not medical: keep it firmly a memory/legacy product, not health data, to stay clear of HIPAA scope — but store as if audited.
Dignity review: a human-reviewed tone for prompts and framing; grief and end-of-life copy is not a place for growth-hack language.

Phasing (C)

C0 — One facility pilot. Clone + guided prompts + delayed family vault + a single B0 talking-portrait deliverable. Learn the capture UX and the consent workflow with real residents and families.
C1 — Facility console + channel partner. Staff onboarding tools, family handoff, white-label; sign an eldercare distribution partner.
C2 — Presence upsell. Track B0→B1 as the premium family deliverable.

Open questions (C)

Who is the buyer and champion inside a facility (activities director? family-relations? hospice chaplain?) — shapes the whole pitch.
Pricing unit: per-bed/year, per-resident-onboarded, or family-paid with facility as channel?
The consent + capacity workflow is the make-or-break; does it need legal/eldercare-ethics counsel before C0?

Sequencing across tracks

Track A0 first — the /api/jq/voice/say endpoint + one DreamPro nudge. It's the smallest slice, reuses everything, and is the shared primitive every other track needs.
Track B0 in parallel-ish — the talking portrait, because it is the demo that sells Track C and needs only the clone + existing scene-studio lip-sync.
Track C0 pilot — once A0 + B0 exist, a single-facility pilot is mostly consent-workflow and capture-UX work, not new AI infra.
Track B1→B3 (spatial/VR) — the north star, funded and motivated by C's traction, built on WebXR + glTF when the pilot proves the presence is worth it.

The smallest next slice (if we start today)

Ship A0: version the consent string to v2, add POST /api/jq/voice/say (reusing getActiveVoice + ttsSegment + the TTS quota gate), and have the JQ orb speak one "here's your next step, in your own voice" line on the DreamPro dashboard, pulsing while it talks. That single slice makes the forward-voice real and lays the primitive under all three tracks.

Relationship to the north star

Track A (forward) is coaching-adjacent and must stay art-first, not therapy-speak to honor the Odessa north star and the ethos — the voice reflects you back, it doesn't lecture you. Tracks B/C (enduring) are the most literal expression of "fiction/story as a technology for continuity" the platform has: a voice that carries a person's own words across the one gap no other software crosses. Keep both honest, keep both consented, and the Living Voice is the same promise the clone made on day one — your words, your voice — extended across time in both directions.

The Living Voice — Roadmap

The atom (shipped)

The insight: one engine, two directions

Cross-cutting: Consent & Ethics (the load-bearing wall)

1. Consent v2 — broaden at clone time (decided)

2. The read-only vs. generative line (the single most important ethical rule)

3. Gating, dignity, custody

4. Cost guardrails

Track A — JQ, the forward voice (near-term, buildable)

What it builds on (all existing)

"DreamPro-light" — defining the home

The two pulse behaviors (your spec)

New surface area (small)

Phasing

Open questions (A)

Track A′ — Ambient Narration (voice on every surface)

A′.1 — Public voice stream (near-term; user-requested)

A′.2 — "Hear about this" (the ambient-narration idea)

Open decisions (A′)

Track A″ — the Presence Orb (ambient messenger)

Why this is the right next companion

Builds on

Shape (proposed)

Phasing

Open decisions (A″)

Track B — Lovio Presence, the enduring voice (north star, greenfield)

Honest starting point

Format recommendation (you asked: Apple, Meta, or universal)

Phasing (crawl → walk → run)

Data-driven, and the ethics that bound it

Open questions (B)

Track C — The Legacy Channel (nursing-home GTM; your direction #3)

Why it fits the spine perfectly

The hard, humane part: elderly-first capture UX

Business model (strawman — REVISED, see LEGACY_CHANNEL_ELDERCARE.md)

Regulatory & dignity guardrails

Phasing (C)

Open questions (C)

Sequencing across tracks

The smallest next slice (if we start today)

Relationship to the north star

See also