open-standards/aac/SPEC.md

AAC — Specification

Version 0.2.0 (draft) · Status: draft · Licence: CC-BY-4.0

This document specifies the AAC open standard: the data model for a portable communication board, the access-method abstraction, the energy-tiered communication cascade, canonical serialization, the interchange format, and the receipt. The key words MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.

The Rust reference implementation in aac-rs/ is normative-by-example: where this prose and the reference types disagree, that is a defect to be reconciled, not a license to diverge.

---

§1. Scope and terms

AAC (augmentative and alternative communication) is technology that lets a person who cannot rely on speech compose and produce utterances. This standard specifies how a board — a person's communication surface and the customization invested in it — is represented, accessed, and exchanged so that it is portable across implementations and devices, operable offline, and never gated behind payment.

• Board — a surface holding cells, of a given BoardType (Grid | VisualScene | Keyboard | Hybrid | QuickAccess).
• Cell — a single selectable target on a board, at a fixed grid position, with content and an action.
• Utterance — the message a user composes by selecting cells.
• Access method — the physical channel by which a user selects (DirectTouch | EyeGaze | HeadTracking | SwitchScan{switches} | Joystick | Bci | PartialVoice | Pointer).
• Client — software that opens, renders, drives, and speaks a board.
• Cascade level — one of ten tiers (L0–L9) through which a communication operation is resolved.

This standard does not specify rendering pixels, a UI toolkit, a TTS engine, or symbol artwork. It specifies the data and the invariants that make a voice portable.

---

§2. The board data model

A board MUST be representable as the following structure (field names are normative; the reference type is aac_core::Board):

• id — a BoardId (UUID), stable for the life of the board.
• name — display string.
• board_type — one of the BoardType variants.
• layout — a GridLayout { rows: u16, cols: u16 }.
• cells — a list of Cell.

A cell MUST carry:

• id — a CellId (UUID).
• position — a GridPosition { row: u16, col: u16 }, 0-indexed.
• content — one of: Symbol { symbol_id, label }, Text(String), Photo { image_ref, label }, or Blank.
• action — one of: Speak(text), Navigate(BoardId), Modifier(GrammarModifier), Backspace, Clear, Predict, SpeakAll, Buffer(text).
• style — colors and optional font size; a client MAY override style for accessibility (§5) but MUST NOT alter position.
• frequency — usage count, monotonically non-decreasing.
• locked — whether the cell is protected from structural edits.

Boards form a graph: a Navigate action edges from one board to another. The graph is the source of truth; a grid layout is one projection of it. A Blank cell is meaningful — it reserves a position to preserve the motor grid (§3) and MUST NOT be elided on round-trip.

---

§3. Motor stability (normative invariant)

A user's motor plan — the learned muscle memory of where each word lives — is the single most valuable property of a configured board. Therefore:

1. A cell's position MUST NOT change once assigned, for the life of that cell, except by an explicit user/editor edit to an unlocked cell. Prediction, context, frequency, language switching, and any L3+ enrichment MUST NOT move a cell.
2. A client MUST NOT reflow, resort, or auto-arrange cells on a board whose cells are locked.
3. Hiding a word for teaching (progressive disclosure) MUST be done by rendering its cell as visually inactive in place — never by removing it and collapsing the grid.
4. Two openings of the same board on the same or different conforming clients MUST present identical cell positions.

An implementation that rearranges a locked board is non-conformant regardless of any other quality.

---

§4. Symbols

Cell Symbol content references a symbol by symbol_id and SymbolSource, not by embedded pixels. A board therefore travels as a small, text-like document; artwork is resolved by the client from a symbol library. A client MUST preserve the symbol_id and label on round-trip even if it cannot render the referenced artwork, and SHOULD fall back to rendering the label text when artwork is unavailable. This keeps a board legible across implementations that ship different symbol sets.

§4.1 Language honesty

A board travels between languages as a graph edge (a translation of each label), but a word list translated from one language is not another language's core vocabulary: the words people use most differ from language to language. Therefore:

1. Every language a client offers MUST state how its core vocabulary was obtained, as a CoreStatus: ValidatedNativeCorpus (a published core list derived from speakers of that language), StakeholderValidated (nominated and rated by its speakers and communication partners), PrimesOnly (a provisional seed from semantic primes and frequency lists), or GlossOnly (glosses of another language's core list).
2. A language record without a CoreStatus MUST be read as GlossOnly.
3. A client MUST NOT present GlossOnly vocabulary as that language's core vocabulary, and SHOULD show each language's status where the person chooses a language.

The reference ships 45 languages: English is ValidatedNativeCorpus; the other 44 are GlossOnly until their speakers validate their own. (Conformance C7.)

---

§5. Access model

Every access method is a first-class input. A board MAY be driven by any method; the method and its tuning travel with the user's profile, not the board.

• AccessMethod — as enumerated in §1. SwitchScan { switches } carries the switch count (1, 2, or more).
• MotorProfile — fine_motor, sustained_press, tremor_level, min_target_mm, optional max_reach_mm, preferred_side. A client SHOULD adapt target size and timing from this profile, and MUST NOT require a smaller target than min_target_mm.

Timing-based methods are normative in their own right:

1. Switch scanning — a conforming scanner MUST support row-column, linear, and group scan patterns, a configurable scan rate, and configurable acceptance/timing (§5.2).
2. Dwell / eye-gaze — selection by sustained gaze MUST use a configurable dwell time with visible progress feedback (§5.3).
3. No access method MAY be a precondition for opening or reading a board; a board authored for eye-gaze MUST still open under touch or switch.

§5.1 Timing belongs to the person

1. A client MUST let the person, or someone acting with them, set the scan rate and the dwell time directly.
2. Automatic adaptation of timing MUST be off unless the person opts in.
3. A client MUST NOT change timing silently. It MAY measure the person's own responses and propose a change, which takes effect only when they accept it — or, if they opted in, automatically under the rules of §5.2 and §5.3.
4. A proposal MUST be derived from this person's responses, never from a population norm alone.

§5.2 Scan-rate floor

A scan rate that a client recommends, proposes or applies from measured responses MUST sit above the person's typical press, so that the highlight has not moved on when they act:

• it MUST NOT be derived from fewer than 10 recorded responses;
• with M the mean and P95 the nearest-rank 95th percentile of the recorded response times, it MUST be at least max(⌊100·M/65⌋, P95) — the reference rule — clamped to [300, 5000] ms;
• a change within 10% of the current rate SHOULD NOT be proposed.

(Conformance C5.)

§5.3 Dwell proposals

A dwell proposal MAY be shorter as well as longer — a person whose dwell is too long is slowed down as surely as one whose dwell is too short makes errors:

• it MUST NOT be derived from fewer than 10 selections;
• one step longer when more than 20% of recent selections were undone;
• one step shorter when fewer than 5% were undone and more than 20% of attempts were abandoned late (gaze left after at least half the dwell);
• a shorter proposal MUST NOT go below 300 ms; no dwell may be below 150 ms or above the configured maximum;
• an opted-in client applies at most one change per measurement window, then measures afresh.

The reference steps along the ladder DT(X) = 300·e^(X/12) − 150 ms. (Conformance C6.)

---

§6. The cascade

A communication operation MUST be resolved through the lowest cascade level that can satisfy it. The ten levels and their order are normative:

Level	Name	Order-of-magnitude energy
L0	CacheHit	~1 µJ
L1	SymbolLookup	~10 µJ
L2	LocalPredict	~100 µJ
L3	ContextPredict	~1 mJ
L4	SemanticExpand	~10 mJ
L5	ConversationAi	~100 mJ
L6	GenerativeComm	~1 J
L7	VoiceClone	~5 J
L8	MultimodalGen	~10 J
L9	AdaptiveModel	~15 J

§6.1 Energy monotonicity. The estimated energy of level Lₙ MUST be strictly greater than that of Lₙ₋₁. (Conformance suite C2.)

§6.2 Offline invariant. Levels L0, L1, and L2 — and only these — MUST be offline-capable. A conforming client MUST serve every L0–L2 operation with no network access, and MUST NOT make any L0–L2 operation contingent on connectivity. (Conformance suite C3.) The practical consequence is normative: a network failure MUST NOT prevent a user from selecting cells, looking up symbols, or completing words.

§6.3 Free at every level. No cascade level MAY be gated behind payment, quota, balance, or subscription at the protocol layer. An implementation MUST NOT refuse, degrade, or rate-limit a communication operation on the basis of billing state. Hosted enrichment services (L3+) MAY be operated commercially, but a conforming client MUST remain fully functional through L2 with no account.

§6.4 Enrichment is optional. L3 and above add intelligence (context, sentence construction, voice cloning, symbol generation, model adaptation). They MUST be reached only when a lower level cannot close the request, and their absence MUST NOT degrade L0–L2 behavior.

---

§7. Canonical serialization and content addressing

A board MUST have a canonical serialization. JSON is the interchange encoding; a canonical form (sorted keys, normalized number forms) MUST round-trip byte-identically through a conforming serializer. A board's content identity MAY be expressed as a content address (e.g. BLAKE3) over its canonical bytes; two boards with equal canonical bytes are the same board.

---

§8. Interchange (ingest)

A board MUST export to the canonical form of §7 and MUST be re-importable from it without loss of cell positions, content, actions, or symbol references.

A conforming engine SHOULD additionally ingest the open board interchange format and common community exports. Ingestion is one-directional and additive: it reads existing work into the substrate so a user does not start over. On ingest:

• Cell positions present in the source MUST be preserved (§3); positions absent from the source MUST be assigned deterministically (row-major fill) and then fixed.
• Unsupported or unknown fields MUST be reported as non-fatal warnings, never silently dropped where they affect meaning.
• A format the engine cannot yet read MUST fail explicitly (a named "format not yet supported" error), never partially and silently.

---

§9. The receipt

Every operation MAY report a two-part energy cost (measured + estimated) in microjoules, with an honest provenance tag indicating whether a reading came from hardware instrumentation, a model, or an estimator. The receipt exists for transparency only. An implementation MUST NOT convert a receipt into a charge, a quota, or a gate. "This session used 3.2 mJ" is a fact shown to the user; it is never a bill.

---

§10. Conformance

An implementation is conformant if it:

1. Round-trips the published board vectors (§7) byte-identically.
2. Preserves the motor-stability invariant (§3) across open/edit/save.
3. Routes operations to the specified cascade levels and satisfies energy monotonicity (§6.1).
4. Serves exactly L0–L2 offline (§6.2) and gates no level behind billing (§6.3).
5. Ingests the interchange format without losing positions, content, or actions (§8).
6. Leaves timing to the person and keeps proposals within §5.1–§5.3.
7. States every language's core status honestly (§4.1).

The aac-conformance harness checks the cascade routing table (C1), energy monotonicity (C2), the offline invariant (C3), wire round-trips (C4), the scan-rate floor against the published response-time vectors in conformance/v1/scan_rate.json (C5), dwell proposals against conformance/v1/dwell.json (C6), and language honesty (C7). C5 and C6 recompute every expected value from the raw inputs with an independent oracle before comparing the engine against it. Any FAIL makes the run non-zero.

---

§11. Non-claims

This standard and its reference implementation are not a medical device and have not been certified as a speech-generating device (SGD) for insurance or Medicaid funding. They make no clinical claim. Choosing an access method, vocabulary, and communication approach is best done by the person with their team, often with a speech-language pathologist — but it is never a prerequisite: no one needs a professional's permission to start communicating with AAC. The standard provides the portable substrate; it does not replace assessment, training, or support.

---

Changes since 0.1.0

• §4.1 Language honesty (new). Every language states its CoreStatus; an absent status reads as GlossOnly; glosses are never presented as a language's core vocabulary. The earlier claim that one ~400-word core covers ~80% of every language is withdrawn. Conformance C7.
• §5.1 Timing belongs to the person (new). Scan rate and dwell are set by the person; automatic adaptation is off unless they opt in; changes are proposed, never silent.
• §5.2 Scan-rate floor (new). A measured rate sits above the person's typical press (max(⌊100·M/65⌋, P95), ≥ 10 responses). The previous reference rule set it to 80% of the mean press, so on average the highlight had moved on when the person pressed. Conformance C5.
• §5.3 Dwell proposals (new). Proposals go both ways, with floors. The previous reference could only lengthen the dwell, including by 50 ms every 30 selections regardless of how the person was doing; §5 item 2 no longer says dwell "should adapt to fatigue". Conformance C6.
• §11 now says access and vocabulary decisions are never a prerequisite for starting.
• Reference implementation (not normative): the demonstrator can be mounted under a sub-path (AAC_BASE_PATH, AAC_SW_URL, AAC_APP_TITLE, AAC_HIDE_ENERGY); its Settings gain a Timing section implementing §5.1–§5.3; dwell reads a monotonic clock that works in browsers (web-time); 538 gloss corrections across 44 languages (aac-core/src/gloss_audit_2026-09-28.json).