For SLPs & clinicians

A grid-based symbol AAC system with a deterministic grammar engine and partner-speech routing. This page covers the design trade, configuration, and the reporting dashboard.

Go to your dashboard Full feature list

The design premise worth arguing with

The system deliberately does not require the user to encode morphology or function words. There is no my tile, no and tile, no -ing, no is, and no possessive marker. The user taps content words in roughly semantic order, and the engine supplies inflection, articles, copulas, prepositions, conjunctions and case.

This is a trade. What you gain is a very short path from intent to fluent output for a user whose bottleneck is function-word encoding. What you give up is explicit user control over those forms — a user who can mark morphology has no tile with which to do so, and the engine's reading of an ambiguous sequence is final unless a partner edits it in the message bar.

It fits well for a client with a strong semantic core and weak morphosyntax. It fits poorly for a client working toward independent grammatical encoding as a goal, or a literate client who wants word-for-word control — for whom the keyboard's Phrase mode is the escape hatch, but not the system's centre of gravity. Decide this before you configure anything.

What the engine does

Roughly forty-five ordered rules, applied per clause after the tap stream is segmented. In clinical terms it covers:

Known gaps

Not constructed: comparatives and superlatives, dative shift, reflexives, perfect aspect, and prosodic sentence type. Most importantly: past tense comes from a time word. Without one, "I eat" is present — this is the most common source of a surprised look from a clinician.

Determinism

This is a fixed rule pipeline, not a language model. Identical taps produce identical output on every device, forever — no sampling, no drift after a server-side update. For AAC that is the correct property: what a client learns about their device stays valid.

It also means a wrong output is a reproducible defect, not variance to tolerate. If a client consistently gets bad output from a sequence, report it with the exact tap order, what was spoken, and what should have been — it can be corrected centrally, for every user at once.

Configuration priorities

  1. Decide whether the trade above fits.
  2. Personalise before you teach. People first, then 5–15 custom words with photos and categories. Nothing else raises usable output as fast.
  3. Prune the pinned row to the client's actual core. Pinned space is the most expensive real estate in the app — every word there is scrolled past on every screen for the life of the system.
  4. Set access parameters — tile size, hold time, repeat-tap debounce — and confirm reliable target acquisition before working on language at all.
  5. Teach the three tile classes to every partner, especially that Instant Words speak immediately and never enter the message bar.
  6. Set the voice with the client, not for them, wherever they can indicate a preference.
  7. Teach the repeated-person-tile possessive. The one construction that isn't self-evident, and it unlocks a lot.
  8. Introduce Listening Mode last, once the client navigates topics independently, so it accelerates access rather than replacing the skill.
The category question on custom words "What kind of word is this?" is the client-facing name for a part-of-speech tag, and it becomes a real dictionary entry in the grammar engine — an action gets conjugated and takes a to-infinitive complement, a thing takes the correct indefinite article. Left blank, the word falls back to shape heuristics, which is often fine for a concrete noun and often wrong for anything else. Adding a word into a single-part-of-speech topic pre-fills it; confirm the pre-fill rather than accepting it blind.

Supporter modeling

Aided language stimulation means you or a caregiver tapping the client's own board. Without a flag, everything spoken that way is indistinguishable from the client's own output: it is logged as their utterance and it trains the predictive keyboard toward your lexical choices.

Settings → Supporter modeling suppresses both, behind a persistent orange banner. It resets off at every launch and cannot be made to persist — a modeling flag that could be left on silently would eventually cost a stretch of a client's real data with no indication anything was wrong.

This is the toggle that keeps the reporting below meaningful. If you intend to rely on those numbers, train every partner who touches the board.

The reporting dashboard

Where an account is configured, a browser dashboard gives you aggregate usage data per client over a rolling 90-day window: total utterances, utterances by week, distribution by topic, unique and total words, and average sentence length by week.

Access is granted by the student, never claimed by you

There is no directory, no caseload lookup, and no administrative override that attaches you to a client.

  1. Sign in and select "I'm an SLP / clinician" as your role. Your role is read from your own profile at redemption, so a parent account cannot present itself as clinical.
  2. The student generates an invite code from their own signed-in dashboard.
  3. You enter it under Redeem an invite code.

Codes expire after seven days and link one viewer each. The student sees every linked viewer and can revoke any of them at any time without involving you — so if you need a figure for a report, take it while you have access.

Reading it honestly

The reports are counts and word inventories, not transcripts — no screen anywhere plays back what a client said, and no audio is involved at any point. Confirm this fits your setting's records policy before relying on it; in most districts these figures are supporting evidence, not the record.

Go to your dashboard

Privacy review

Vocabulary, grammar, topic routing and voice output are entirely on-device. Speech recognition is the one exception, and it matters for privacy review: Listening Mode uses Apple's speech framework without requesting on-device-only recognition, so partner audio may be transmitted to Apple's servers exactly as system dictation is.

Listening Mode is optional and nothing is captured unless it is pressed. If your setting requires that no student speech leave the device, either establish that on-device recognition is guaranteed on your specific hardware and iPadOS version, or instruct staff not to use the button — every word remains reachable through Topics, Search and Type. The client's own tile selections are never recorded as audio at any point.

Full privacy detail →

Access methods

Direct touch only. There is currently no switch scanning, eye-gaze integration, auditory scanning, or head-pointer support. If a client needs any of these, this is not the right system for them today.