Software / The runtime
Intent, resolved.
Decoding gives you text. The runtime decides what the text meant, in the window you're actually in, and performs it through interfaces that were never designed for you.
Five stages between a thought and a result.
Each stage is separable and testable. When something goes wrong, the system can tell you which stage it went wrong in, which is the difference between a tool you trust and a tool you stop using.
- DECODE Myoelectric signal becomes text. The band's decoder emits a phoneme lattice with per-token confidence, not a single finished sentence. Downstream stages get to know how sure the model was.
- NORMALISE Text becomes a stable utterance. Disfluencies removed, homophones scored against the active language model, and confidence below threshold handed back for a second read rather than guessed at.
- GROUND Utterance meets context. The runtime reads the foreground application, selection, cursor position, and reachable devices. "Send this" binds to a specific window, not to a guess about what you probably meant.
- PLAN Intent becomes a sequence of actions. A request like "file the invoice and tell Priya" expands into keystrokes, a message, and a confirmation, each step individually inspectable before it runs.
- EXECUTE Actions are performed through native interfaces. Synthetic input, accessibility APIs, and local device radios. No target application needs to know Lumina exists, and none needs to be modified to work with it.
What the runtime is allowed to touch.
Scope is set by you per session, not by the product roadmap.
Prompt anything without switching windows
The runtime opens the assistant, writes the prompt, and returns focus to what you were doing. You never speak aloud and never leave the surface you were thinking about.
"Ask it to summarise this thread and keep the decisions."
- Focus assistant window
- Compose prompt from selection context
- Submit, wait, return result to originating app
Navigate like you said it out loud
Open a page, search within it, fill a form, move through a flow. The runtime handles the mechanics through real navigation and real input events; nothing about the site changes.
"Find the refund policy and paste the relevant clause here."
- Open URL in a background tab
- Locate policy section, extract clause
- Paste into focused field
Drive applications that were never designed for this
Anything that accepts a keystroke or a pointer is controllable: editors, terminals, spreadsheets, CAD, scientific tooling. Unmodified, and without a plugin ecosystem to maintain.
"Rename every file in this folder to the pattern on screen."
- Read pattern from foreground document
- Open shell, build and preview command
- Show diff, require confirmation, run
Physical things, no hub in between
The band carries a sub-GHz radio, so the runtime can talk to receivers directly: lights, sockets, thermostats, blinds, locks. No cloud round-trip, no vendor account, and no phone required to be in the room.
"Lights down, and lock up for the night."
- Dim group "office" to 20%
- Send lock command to paired receiver
- Report state back in the HUD
System-level verbs
Window management, media transport, notifications, shortcuts, clipboard, focus modes. The small verbs that cost a hand movement each and add up to most of a day.
"Focus mode, play the album, close everything else."
- Toggle focus profile
- Start playback via system media API
- Quit non-allowlisted foreground apps
Fast enough to disappear.
Latency is the specification that decides whether a hands-free interface feels like thinking or like waiting. The budget is spent where the user can feel it.
Decode → resolve → act, visualised
| Stage | What it does | Budget |
|---|---|---|
| Capture | EMG window collected and buffered | 6 ms |
| Decode | Phoneme lattice scored on-device | 14 ms |
| Normalise | Language correction, confidence gate | 5 ms |
| Ground + plan | Context read, action sequence built | 9 ms |
| Execute | Input injected on the host | 5 ms |
A device that reads intent has one chance to get this right.
These are architectural commitments, not settings. They hold because of where the work happens, not because of a policy page.
-
Local by default
Decoding runs on the band. The signal never leaves the device to become useful, which means there is no raw neural data on a server to be subpoenaed, leaked, or repurposed.
-
Visible when active
A hardware indicator that cannot be disabled in software, and a HUD line on the host showing exactly what was recognised. If it heard you wrong, you find out immediately rather than after it acted.
-
Scoped, not standing
Permissions are granted per application and per device, with a session model for anything irreversible. Nothing is granted "always" without an explicit, revisitable choice.
-
Confirm before committing
Anything destructive, financial, or externally visible shows the exact action sequence first. Confirmation is one thought, a deliberate subvocal yes, but it is a deliberate act and never a side effect of recognition confidence.
On-device decoder
The privacy claim is a layout decision on this die.
Raw myoelectric data has no route off the board. There is no radio path for it and no buffer that persists it. What leaves is text you produced deliberately, and nothing else.
Nothing you use has to be rebuilt for this.
Lumina sits at the input layer, where every application already accepts commands. That is a deliberate constraint: software support is a property of the operating system, not of an integration programme.
See the full catalogue- Host runtime
- A background service per platform. Reads foreground state, injects input, manages device radio pairings.
- Optional extensions
- Deeper awareness for tools that opt in: an editor exposing its symbol graph, a browser exposing the DOM. Additive, never required.
- Device control
- Radio pairings stored locally. No account, no cloud bridge, no dependency that can be discontinued underneath you.
If you build software, we want to hear what breaks.
The runtime gets better fastest when it meets applications it wasn't designed around.