Product status
Roadmap language is deliberately literal. Available now, In development and Research stage describe product maturity only; they do not imply clinical validation, accessibility conformance or a promised release date.
Available now
Implemented in the current early-access delivery path.
In development
Actively being built, but not yet a shipped availability claim.
Research stage
Exploratory or validation-dependent; not a production availability claim.
Available now
EyeSay's current private early-access communicator experience is delivered through the installable web app at console.eyesayaac.com. eyesayaac.com remains the public information and legal website.
Boundary: Available now means the current early-access delivery path; it does not imply general availability, clinical validation or universal device support.
In development
Native EyeSay clients are in development. Public copy must not promise a release date, supported-device list or parity with the current web app until release evidence exists.
Boundary: A roadmap item is not a shipped feature. Device-specific availability is stated only after that client is released and verified.
In development
The native Android client will first be distributed as a signed file from eyesayaac.com, at no cost. Android warns about anything installed from outside the Play Store, so each release is published with its SHA-256 and signing-certificate fingerprints for a reader to check. A Play Store release is planned and is what removes that warning.
Boundary: No release date for either route may be published until an accountable release plan is approved. Do not describe the app as available on Google Play, and do not describe the install warning as a problem with the device or something to be bypassed - it is correct, and the page explains it rather than coaching a reader past it.
In development
EyeSay's position guarantee is a within-surface guarantee today: a communicator's learned positions are stable inside the web app. One board is now defined once and shared by both the web app and the in-development native client, and an automated cross-surface check fails the build if either drifts from it. What has not happened yet is a release carrying that board, so continuity between surfaces is still a property being built rather than one a family can rely on.
Boundary: Do not describe learned positions as carrying across from the web app to a native client. A shared definition and a passing check are not availability: this advances only when the reconciled board is live in the early-access delivery path, and the first release that carries it moves every communicator's board, which is a migration to plan rather than an upgrade to announce.
In development
EyeSay ships a starter vocabulary across the 48 stable motor positions plus topic pages. A broader core vocabulary, and the published method used to choose it, are in development.
Boundary: The starter vocabulary is a seed, not a complete AAC vocabulary, and must never be described as comprehensive, complete or sufficient for every communicator. Vocabulary size is not an effectiveness claim.
In development
The board currently uses a small built-in icon set. A bundled, openly licensed symbol library that works fully offline is in development, together with the ability to substitute a commercially licensed set later.
Boundary: Do not state a symbol count, name a symbol set or imply parity with commercial symbol libraries until a set is bundled and released. An offline product can only show symbols it ships.
In development
An invited adult can propose a word and a guardian can review it, and that exchange is recorded with an audit trail. What does not yet happen is the word reaching the communicator's board: the Voice Canvas renders a fixed starter set, promotion to a permanent slot is deliberately refused until a reviewed motor-map migration creates reserved geometry, and adding a word on the communicator's own device during a session is in development.
Boundary: Do not describe proposing or approving a word as changing what a communicator can say today. Do not describe on-device authoring, offline authoring, a tap count or a retrospective approval queue as available. Scoped team invitations and the change record are separate, implemented capabilities and may be described on their own terms.
In development
Console-managed configuration reaching a native EyeSay client is in development and is a precondition for releasing one.
Boundary: Do not imply that a Console change reaches a native device today. Statements about Console management are scoped to the current web app unless a released native client is named.
Research stage
A bounded prototype can offer optional grammatical forms after a communicator has selected a word. It is a profile-scoped device preference, never automatic, and can be removed without changing the base communication system.
Boundary: A prototype is not a grammar feature. Do not describe EyeSay as providing morphology, tense or word forms, and do not describe any suggestion as automatic, inferred or corrective.
In development
The web app has a letter keyboard, reachable from the Voice Canvas, that composes text into the utterance the communicator then chooses to speak. What is not built is word prediction, a phonics-first letter progression, and the same keyboard on a native client.
Boundary: Do not describe EyeSay as providing word prediction or as a literacy intervention, and do not imply an age range or developmental ceiling either way. Having a keyboard is not evidence that it supports a communicator's literacy development.
Research stage
Contrast and presentation settings exist, but EyeSay does not claim a presentation mode designed for cortical visual impairment or low vision. This is research-stage work requiring clinical input and real-user validation.
Boundary: Do not convert a high-contrast setting into a CVI or low-vision suitability claim, and do not imply EyeSay has been evaluated with these populations.
Research stage
EyeSay's modelling architecture is implemented, but structured partner-training materials are research-stage. Published AAC evidence attaches large effects to partner instruction, and that evidence belongs to the field rather than to EyeSay.
Boundary: Do not present external partner-training evidence as evidence for EyeSay, and do not state or imply that using EyeSay will produce a communication or language outcome.
Research stage
EyeSay does not currently claim production-ready switch access. Switch workflows remain subject to implementation and real device/browser or native-client validation.
Boundary: Do not convert keyboard or automated test coverage into a switch-access availability or accessibility-conformance claim.
Research stage
EyeSay does not currently claim production-ready gaze access. Gaze interaction remains a research-stage access path until supported hardware and end-to-end behaviour are implemented and verified.
Boundary: Do not infer communicator intent from gaze signals, and do not describe gaze access as available before device-level evidence exists.
Research stage
EyeSay currently makes no broad interoperability claim for third-party AAC ecosystems, specialist access hardware, vocabulary interchange or clinical systems.
Boundary: Any future integration must be described by the exact supported interface, version and verified behaviour rather than by a generic compatibility claim.
A status changes only when repository or release evidence supports the new state. In-development and research-stage items must not be rewritten as present-tense product capabilities, and dates are not published unless an accountable release plan has been approved for publication.
Product-status review also checks the public-site versus Console boundary, device-specific evidence, accessibility evidence, interoperability scope and wording that could accidentally imply clinical validation or communicator intent.