Owned-Hardware Horizon — the "no limits" scenario under the Living Voice

Status: strategy / not built. Captured direction, not a pull-forward. Authored 2026-07-11. This is the sibling of AR_GLASSES_LIVING_VOICE.md and MOBILE_JQ_PRESENCE.md — but where those two docs are a map of the walls other people impose (Meta owns the on-glasses app layer; iOS forbids a custom wake word; neither OS lets a backgrounded app speak unprompted), this doc asks the inverse question: what does the product become when we own the walls — via open-source glasses we fully control now, or our own resold hardware later, with no third-party limit on hardware or software usage.

Nothing here changes the priority order. Workstream A (writing experience) and Odessa stay top of the stack. This is a horizon to build toward, and — more importantly — a record of the ethical spec that owning the hardware forces on us, so it's on file when the SDK watcher fires or when the owned-hardware question comes up for real.

The frame: the AR/mobile strategy is a map of walls

Read AR_GLASSES_LIVING_VOICE.md and MOBILE_JQ_PRESENCE.md as a pair and nearly every "buildable-now" compromise in them is a workaround for a limit someone else imposed: ride Siri as a borrowed mic because you can't have your own wake word; play a 30s clip as a notification sound because a backgrounded app can't speak; scope "Hear about this" to a manual trigger because there's no open camera SDK. Owning the hardware deletes three specific constraints — and each one unlocks a capability we've already half-built.

The three limits we'd actually be deleting

Not "hardware in general" — three named constraints:

1. Continuous ambient listening (our own wake word, or none at all)

• Today: forbidden. JQ rides the platform assistant; "tap the action button, then talk."
• Unlocked: JQ is genuinely with you — hears the moment you're in, addressable like a person beside you. This is the difference between a tool you invoke and a companion that's simply present. It's the thing the Living Voice roadmap keeps gesturing at and the phone structurally cannot deliver.

2. Unprompted proactive speech

• Today: JQ speaks only when a notification is sanctioned (30s clip on iOS, a scheduled local nudge).
• Unlocked: the JQ forward-voice nudge fires when the moment is actually right — your own voice, in your own ear, at the doorway of the hard thing you said you'd do. This is the capability worth owning glasses for. POST /api/jq/voice/say + the DreamPro nudge cadence engine already produce the payload; owning the hardware removes the phone and the permission dance from the loop.

3. Continuous world vision

• Today: "Hear about this" waits on a Wave-2 camera-export SDK and is scoped to a manual trigger.
• Unlocked: the camera feeds continuously, which turns two shipped loops into something new:
  • Odessa capture of lived experience — the fiction→real-change loop runs on written text today; a continuous first-person feed makes life itself raw material for the reframe. Guardrail holds hard: capture-for-the-writing, never live coaching (honor the Odessa north star).
  • "Hear about this," pointed at everything — a place, an object, a face you've met before — narrated in the house or a loved one's voice.

What becomes possible (ranked by how much is already built)

The payoff is that these are the walls coming off things that exist, not greenfield:

1. Forward-voice realtime coaching, contextual + hands-free. The literal ask. Reuses POST /api/jq/voice/say, the DreamPro cadence engine, the calm-not-nagging guardrail. Owning the glasses removes the phone + notification-permission dance from the loop; the nudge whispers at the right moment because it can.
2. Lovio presence that is actually present. Today the read-only slice plays cached capsules through the audio-first player. With continuous listening + unprompted speech, a loved one's voice answers "tell me about grandpa's boat" in the moment you thought of him — not "open app, navigate, tap play." The read-only-vs-generative bright line stays exactly as load-bearing; owning the hardware doesn't relax it, it makes honoring it our responsibility.
3. Zero-UI eldercare / Legacy Channel. Where owning the hardware is a genuine moral advantage, not a convenience: a resident who can't manage a phone UI talking to a familiar cloned voice through glasses they never configure. Already Track C in the roadmap; inherits the capacity/guardianship consent guardrails verbatim.
4. Life-capture feeding the journal (HiveJournal core). Hands-free voice entries with first-person context, continuously — the writing surface fed by lived experience instead of only desk sessions. Protects Workstream A's "build off the existing surface" rule: glasses feed the writing, never replace it.
5. The dome/stream overlaid on the real world. If we go to a display (not just audio), Track B stops being a WebXR destination you enter and becomes a layer on reality — your stream drifting at the edge of vision, your dome's warmth reflecting goal adherence ambiently. The scene already exists (StreamXRScene, dome.glb); on binocular AR it forward-ports with no app-store gate. That was always the point of building it in WebXR instead of Unity.

The catch worth staring at — owning the hardware means owning the surveillance question

The platform walls we'd be deleting are, accidentally, also our privacy protection. Meta's gatekeeping and Apple's wake-word ban are annoying — and they are the reason we can currently say "we can't always-listen" as a feature. The moment we own the hardware, "we don't surveil you" stops being enforced by the platform and becomes a promise only we keep.

That's not a reason not to do it. It's the reason the Living Voice ethics wall becomes the most important engineering spec in the product, not a footnote:

• On-device processing as the default, not a nicety. The always-listening layer should transcribe/decide locally and only ever send up what the user chose to capture. This single decision is what makes the whole thing trustable — and it should be the headline feature, not a buried setting. See the Sophia section below for a concrete implementation of the "decide" step: a local NLU intent-router that resolves simple commands without any utterance leaving the device.
• The consent graph (JQ Bridge — who may trigger/hear which voice) goes load-bearing. The camera now sees other people, not just the wearer. "Who may be captured / narrated / heard" is no longer an edge case.
• The read-only-for-the-dead bright line matters more, not less. Unprompted speech in your ear is exactly the context where a generative "grandpa reacts to what he's seeing" would be most tempting and most wrong. Read-only stays read-only.

Design principle: the products that win here treat "we chose not to, and here's the architecture that proves it" as the marquee feature. Owning the hardware is only a moral upgrade over Meta/Apple if we spend the freedom on restraint we can prove.

Sophia — a candidate "decide-locally" layer (evaluated 2026-07-11)

We have access to Sophia (cicero.sh/sophia; a local copy lives outside this repo at ~/Desktop/_SilverLamp/cicero/) — a self-hosted NLU engine (Rust core, ~20k words/sec, "works even on wearables"). It is not an LLM and never generates: it runs as a localhost RPC server (127.0.0.1:7513) reached through thin SDKs (Python / Node / PHP wrappers ship in the repo) and does three things — tokenize / interpret (utterance → phrases with verb/noun clauses + POS tags, deterministic), structured entity/word/category lookup, and a Router that maps a semantic category (e.g. verbs/action/travel/depart) to a callback so every synonym under that category in its taxonomy fires the same handler without enumerating words. Deterministic, no hallucination, no API call. Licensing: free for individual use; a premium license is required for commercial use — a real gate to clear before shipping.

Why it matters here: Sophia is a concrete implementation of the "decide" step in the ethics spec above — the deterministic intent-router that sits in front of the LLM. Route every "ask JQ" utterance (and every dictated-journal command) through Sophia first: simple intents — "what's my next step," "log that I…," "play grandpa's message," "snooze this nudge," "tag this entry" — resolve locally, instantly, for $0, and only open-ended input falls through to the LLM (Sophia's own "LLM fallback" pattern). That hits three live concerns at once:

• Latency — no round-trip for the ~80% of utterances that are simple commands (the "realtime" pitch).
• Cost — fewer OpenAI/ElevenLabs calls (a standing sensitivity — see the TTS/image spend memories).
• Privacy — fewer utterances leave the device, which is the on-device-first ethics spec. This is what makes "we chose not to, and here's the architecture that proves it" concrete rather than aspirational.

"Works even on wearables" also makes it a candidate for on-glasses command parsing in the Frame spike.

Where it is NOT a fit (don't overreach):

• It's the router, never the voice — it will never write a JQ nudge, do an Odessa reframe, or converse. Complement to the LLM + Living Voice layer, not a replacement.
• Commercial license required — the free tier won't cover prod; clear this before building on it.
• Deployment is a sidecar. Backend integration is easy (run the engine as a Railway sidecar, hit it from Express via the Node SDK). On-device mobile/glasses is a bigger lift — you'd embed the Rust engine natively; the repo ships SDK clients, not the engine binary.
• Single-utterance today — multi-turn dialog + contextual awareness are roadmap; fine for command routing, not stateful conversation.
• Small-vendor dependency — weigh longevity/support before making it load-bearing.

Next step: a time-boxed backend spike — Sophia RPC server up locally, Node SDK wired as an intent pre-filter in front of the JQ voice path, ~5 routes for the commonest commands, measured local-hit-rate + latency vs. the current LLM path on real utterances. Validates the win before any license conversation or mobile-embedding work. Tracked as a P2 idea task.

Open-source glasses now vs. our own hardware later

Don't start by buying a factory — earn your way there. The audio-first player + applyMediaSession (PR #1093) already run on any paired glasses today. The next real step toward the owned-hardware horizon is putting the forward-voice loop on glasses we fully control and seeing whether always-there-JQ-in-your-own-voice is as powerful in the ear as it is on paper. If it is, that traction — not a hardware bet — is what justifies the next move.

Hardware pick — RESOLVED (2026-07-11): Mentra Live (ordered)

A deep-research pass on the mid-2026 landscape changed the earlier "Frame-class" default. The Brilliant Labs Frame has no speaker — it cannot talk in your ear, which is fatal for the forward-voice wedge. Since Jan 2026 a single device shipped that does open-ear audio + mic + camera + run-your-own-code in one product, in TypeScript — Mentra Live ($349, shipping now). It is the controllable rig and the feel-test device in one, and its SDK language matches our stack. Ordered 2026-07-11; arriving in a few days.

How MentraOS actually works (confirms the fit): a MentraOS app is a TypeScript AppServer (subclass AppServer from @mentra/sdk, register at console.mentra.glass, deploy to Railway — our existing host). The glasses connect through the MentraOS relay + phone to our server; onSession(session, …) gives session.events.onButtonPress / onTranscription (mic → text) and session.audio.playAudio({ audioUrl }) plays an HTTPS MP3 through the speaker — which is exactly what POST /api/jq/voice/say already returns. So the forward-voice loop is a few lines. session.audio.speak() is the TTS fallback; the 1080p camera covers the Odessa capture path. Your code runs on your server, not on-glasses silicon — ideal, since Sophia runs on that same server as the intent pre-filter.

Framing — one app, two capabilities (do not brand-fork the hardware): the glasses run JQ; DreamPro and Odessa are what JQ does there. DreamPro = the speak path (forward-voice nudge out — the wedge, felt instantly, reuses shipped infra) → build first. Odessa = the capture path (mic/camera in → the fiction→real-change reframe, honoring capture-for-the-writing-never-live-coaching) → phase 2 on the same app. Shared plumbing, built once.

Sequencing

1. Prove the loop on controllable hardware — Mentra Live (ordered 2026-07-11). Ship the DreamPro forward-voice nudge (session.audio.playAudio of the POST /api/jq/voice/say MP3) as a MentraOS AppServer, then the Odessa capture path. Sophia rides the same server as the intent pre-filter. No new company required.
2. Bank the ethics spec as architecture — on-device-first processing, consent-graph-gated capture, read-only bright line — before the always-listening surface exists, not after.
3. Let traction decide the hardware bet. Reselling our own glasses is downstream of the Mentra Live prototype proving the vision, not upstream of it.

See also

• AR_GLASSES_LIVING_VOICE.md — the glasses hardware layer under the Living Voice; this doc is its "walls removed" scenario.
• MOBILE_JQ_PRESENCE.md — the phone sibling; the two hard OS walls this doc imagines past.
• LIVING_VOICE_ROADMAP.md — the voice/presence spine and the ethics/cost wall this doc inherits verbatim.
• ODESSA_NORTH_STAR.md — the capture-for-the-writing / never-live-coaching guardrail on continuous world vision.