Roadmap¶

YazSes is an Apache-2.0, privacy-first voice dictation and local interaction project for Linux, macOS and Windows. It runs speech recognition on your own hardware, without an account or cloud transcription service. The current stable release is v2.51.0, with installers and package channels described in platform support. A published installer does not by itself prove that every input method works on that operating system or on every physical device.

Our direction: make YazSes the offline, keyboard-level microphone for the agent era: dependable on Linux, evidence-backed across platforms, usable by people who cannot comfortably hold a key, and interoperable with AI tools without silently sending prompts. This direction and its limits are recorded in ADR-030 (Accepted, 2026-10-22).

This is a decision and evidence roadmap, not a schedule or product promise. It separates shipped code, real-hardware proof, technical research, and conditional ideas. For the freshest development state read what we're building now, the release notes, and the changelog. For actionable work use milestones, the contributor ROADMAP.md, and the issue linked for each item.

What our status words mean¶

A release, a working code path, a passing synthetic test, and a successful experiment on physical hardware are different claims.

For reachable features, the source of truth is the feature registry and yazses features command, which distinguish wired capabilities from designed-but-unwired ones. For actual installation and usage evidence, consult the platform validation matrix. It distinguishes Verified (HW), Reported, CI only and UNVERIFIED, records the exact release tested, and does not confer validation on later versions automatically.

How a claim gets earned¶

Release availability and real-device verification are separate evidence paths. A package can ship while a specific device remains unverified; a hardware trial can also fail. Only a complete positive hardware record for the same released build and setup can support a narrow compatibility claim.

flowchart TB
    D["Design or scoped technical decision"]
    T["Synthetic / replay tests and CI<br/>Code-path evidence only"]
    R["Published software release<br/>Installable, not device proof"]
    H["Physical-device trial by a named tester<br/>Exact version, OS and hardware; may pass or fail"]
    G{"Positive Verified (HW) record<br/>for that released build and setup?"}
    S["Bounded support claim<br/>Only what was actually verified"]
    U["No verified compatibility claim<br/>Preserve Failed, Reported or UNVERIFIED status"]
    D --> T
    T --> R
    T --> H
    R --> G
    H --> G
    G -->|"Yes"| S
    G -->|"No / incomplete"| U
    classDef verified stroke-width:3px
    classDef unverified stroke-dasharray:6 3
    class S verified
    class U unverified

Text equivalent:

See the validation evidence standard and validation matrix. Failed and incomplete reports remain visible; neither becomes a positive compatibility claim.

Current technical position — November 2026¶

A shipped experimental hardware reader is not a qualified hardware device. The software may be part of a stable release even though no specific headset, armband, sensor, electrode setup or user has passed physical acceptance testing.

Execution order — outcomes first, not feature count¶

These are priorities and evidence states, not release dates or a four-era timeline. The engineering lanes can progress independently; only the arrows entering the decision gate express a prerequisite.

flowchart TB
    subgraph DELIVERY["Current permitted delivery"]
      direction LR
      P0["P0 - Desktop reliability and OS validation<br/>ACTIVE: hardware evidence incomplete"]
      P1["P1 - Agent-era voice interfaces<br/>RELEASED code: real-client validation pending"]
    end
    subgraph RESEARCH["Measure existing technology before expansion"]
      direction LR
      ASR["R1 - Offline ASR and languages<br/>RESEARCH: benchmark and acceptance gates"]
      BIO["R1 - EMG / blink switches<br/>EXPERIMENTAL: physical validation pending"]
    end
    subgraph HORIZON["Future surfaces: not scheduled feature releases"]
      direction LR
      AND["Android<br/>SOURCE FOUNDATIONS; no APK"]
      XR["XR / expanded HCI<br/>RESEARCH ONLY"]
    end
    G{"New capability permitted by ADR-030?<br/>Substantive outside-user evidence and recorded decision"}
    BUILD["Scoped engineering issue with acceptance criteria"]
    PARK["Remain research / deferred"]
    AND --> G
    XR --> G
    G -->|"Yes"| BUILD
    G -->|"No"| PARK
    classDef current stroke-width:3px
    classDef experimental stroke-dasharray:6 3
    classDef research stroke-dasharray:2 3
    class P0,P1 current
    class BIO experimental
    class ASR,AND,XR research

Text equivalent: P0 is the first priority but not yet fully verified; it covers the installed dictation path on actual OS and compositor combinations. P1 interfaces have shipped but still need client-version tests to establish review-before-send behavior. R1 ASR work is benchmark research; R1 biosignal input has released experimental code but awaits real-device and safety evidence. Android has source foundations without an installable application; XR and expanded HCI remain research only. Neither is scheduled for delivery without the explicit ADR-030 entry gate. None of these labels is a promise to ship the next stage.

Delivery items with accepted scope belong to existing milestones. There are no dates, committed device models or unmeasured performance improvements hidden in this table.

How a research idea earns implementation¶

The accepted ADR-030 breadth freeze prioritizes reliability, truthful capabilities, first-use adoption and two small agent interfaces. Beyond that scope, a proposal stops at a Proposed ADR or an evergreen:research issue unless substantive outside-user feedback and a maintainer-recorded amendment justify it. Accessibility feature expansion also needs evidence from real hands-free users.

flowchart TB
    A["Step 1: Written hypothesis<br/>a falsifiable question"]
    B["Step 2: Local-only feasibility and licence check<br/>no cloud, no private data"]
    C{"Step 3: Human participants or body-contact sensors?"}
    D["Step 3a: Consent, privacy and device-safety review"]
    E["Step 4: Reproducible measurements<br/>named device, version and baseline"]
    F{"Step 5: Maintainer go or no-go"}
    G{"Step 6: ADR-030 breadth freeze:<br/>exception accepted and recorded?"}
    H["Step 7: Scoped implementation proposal<br/>opt-in defaults, tests and docs required"]
    Z["Stop: the result stays research"]
    A --> B
    B --> C
    C -->|"yes"| D
    C -->|"no"| E
    D --> E
    E --> F
    F -->|"go"| G
    F -->|"no go"| Z
    G -->|"yes"| H
    G -->|"no"| Z

Text equivalent:

1. Write the hypothesis as a question that a measurement could answer no to.
2. Check feasibility and licensing using local resources only, with no cloud service and no private data.
3. For human participants, on-body sensors or accessibility trials, review consent, privacy, device safety and research requirements before measurement.
4. Take reproducible measurements: named device, release, configuration and baseline, including the failures.
5. A maintainer records a go or no-go. No-go ends as published research.
6. Even a go meets the ADR-030 breadth freeze: without a recorded exception it also ends as research.
7. Only an accepted exception can become a scoped implementation task. Any eventual release must be opt-in by default and include tests and docs. The stage chart above then decides what may be claimed about it.

A code test does not replace physical tests, and no step guarantees the next.

Explicit non-goals: no cloud dictation fallback, always-listening wake-word assistant, voice-triggered routing to third-party online services, or automatic sending of user prompts/messages. Installed models may be downloaded at a user's explicit request, but recognition must not rely on network access. ADR-019 defines strict outbound-data and consent rules.

Technical evaluation paths — independently reproducible¶

The project welcomes public, evidence-led evaluation of its existing interfaces on different devices. A report can be useful even if the result is negative; it does not imply any manufacturer relationship, endorsement, validated compatibility or release commitment.

Each result needs a dated version/commit, tested device, OS, configuration, model/source revision, baseline, method, measurements, failures and limitations. Distinguish synthetic replay, CI, single-device feasibility and independent multi-person evidence. Do not upload participants' raw audio, transcripts, voiceprints, personal learning data or biosignals to public issues or third-party coding agents. Human-subject research requires its own consent and review process; a single-person technical trial is not a clinical study. YazSes is not a medical device, and its biosignal switch does not decode thoughts.

Where contributors can make measurable progress¶

The milestone policy distinguishes delivery issues (one milestone), epics (derived from their children), and evergreen research, translation and open-ended field reports (the appropriate evergreen:* label, no milestone). A research idea is not a release obligation.

There is also voice control — milestone #8, Hugging Face and multimodal HCI research and the future XR study. None overrides ADR-030's active constraints.

The destination — vision, not a delivery calendar¶

YazSes aims to make a keyboard optional for more people, with private speech processing under the user's control. Foundation dictation is released; selected perception and editing functions exist as opt-in features; more ambitious understanding and interaction need evidence.

The faculties, by how far each has got¶

Each box carries its status in words, so the picture still reads in greyscale; the table under it gives the same information as text for screen readers. A thick outline is released, a dashed outline is experimental or opt-in, a dotted outline is research or not committed. The shapes say nothing about dates, and a dotted box is not a promise.

flowchart TB
    D["Reliable input: hold-to-talk dictation<br/>Released; platform checks open"]
    T["Reliable input: file and meeting transcription<br/>Released; meetings opt-in"]
    M["Grounded interaction: local MCP server<br/>Released"]
    S["Grounded interaction: send-to Claude or Codex<br/>Experimental; client-unverified"]
    G["Grounded interaction: gaze, head pointer, Voice Pilot<br/>Experimental; off by default"]
    B["Grounded interaction: EMG, blink, jaw-clench<br/>Experimental; no device proof"]
    K["Understanding and recall: keyword recall<br/>Opt-in"]
    R["Understanding and recall: semantic, cited recall<br/>Not a committed release"]
    P["New modalities: mixed-language switching<br/>Deferred; not wired"]
    A["New modalities: Android<br/>Source foundations only"]
    X["New modalities: XR<br/>Research only"]
    D ~~~ T ~~~ M ~~~ S ~~~ G ~~~ B ~~~ K ~~~ R ~~~ P ~~~ A ~~~ X
    classDef released stroke-width:3px
    classDef experimental stroke-dasharray:6 3
    classDef research stroke-dasharray:2 3
    class D,T,M released
    class S,G,B,K experimental
    class R,P,A,X research

Text equivalent:

The boxes run from the most established faculty to the least. Their order says nothing about what is built next, and a dotted box is not a promise.

Three promises that hold across all of it¶

flowchart LR
  accTitle: Three promises that hold across every faculty
  accDescr: Offline, opt-in and private, each tied to the thing that enforces it.
  O["Offline by default<br/>enforced by an egress-inventory test"]
  F["Off by default<br/>new features ship dormant, enforced by tests"]
  L["Private learning corpus<br/>encrypted, opt-in, never leaves the machine"]
  classDef promise stroke-width:3px
  class O,F,L promise

Text equivalent:

Read the architecture, the ADRs, mobile programme and research participation guide for design background and evidence requirements.

Shipped history — where to verify it¶

The authoritative source for a historical claim is the release notes, GitHub tags/releases, and changelog. Representative milestones include v1 offline hold-to-talk, v2.12 Meeting Mode and file import, v2.14 the optional Parakeet and gaze interfaces, and later experimental biosignal source integrations. Releasing code does not certify a physical device or an end-to-end OS path.

The latest version entries are generated from the changelog at docs build time:

Future work¶

Nothing here is scheduled. Each item is labelled with the status words defined above, and none overrides the ADR-030 breadth freeze.

When a research direction does ship, it follows the same rule as everything else: off by default, opt-in, on-device.

Known limits¶

• Physical validation is incomplete and does not carry forward automatically to newer versions. See the evidence matrix.
• Wayland input varies with compositor and injector. GNOME and KDE require current-version evidence #643, and the ydotool non-ASCII fix (#329) still needs confirming on real GNOME and KDE sessions. Do not infer universal Wayland support.
• macOS and Windows remain preview-level for complete dictation under ADR-030 even while desktop installers are published.
• Models trade speed, memory and language coverage. First model installation may need an explicit download; local transcription does not. Optional features may need separate lazy-loaded extras.
• Mandarin needs native validation #505; configuration is not proof of high-quality support.
• Biosignal input is experimental and off by default. A parser, simulator, replay or driver test does not establish real-board accuracy, safety, or accessibility outcomes.
• There is no Android app or XR integration to install today. Their source and research programmes are linked above.

Request a feature or report a verifiable result¶

Use the GitHub issue templates and review the validation standard. Include the exact build, device, OS and non-sensitive reproduction steps. For new research, identify the user need, falsifiable hypothesis, baseline, failure/stop criteria and existing issues. For studies and community contributions see students, researchers and industry.

A single reproducible success or failure on a named real system can advance this roadmap more than another untested feature proposal.