Product plan — the SLP loop

Live doc. Last meaningful rewrite: 2026-05-26 (v5.2.1).

The endgame

SLPs already run a diagnostic-therapy-feedback loop manually: they listen to the patient, identify articulation patterns to target, pick exercises (minimal pairs, target words, sentences featuring the target), have the patient practice, listen again, update the targets, pick new exercises, repeat. PhonoLex's endgame is to automate that loop — without removing the SLP from the loop, but freeing them from the mechanical curation work that today eats the bulk of session prep time.

[diagnostic input] ─→ [curriculum recommendation] ─→ [therapy delivery] ─→ [progress feedback] ─→ loop
 ↑ ↑ ↑ ↑
 Audio (R&D) Curriculum recommender Live tools Audio (R&D)
 SLP manual (R&D) (shipped) SLP manual

The live tools today serve the therapy delivery stage well. The R&D workstreams close the rest of the loop.

What's shipped (the live tools)

PhonoLex's user-facing surface is the practice toolkit:

Tool	What it does	Endgame role
Custom Word Lists	Pattern + property + similarity filters over the lexicon	Drill targets
Text Analysis	Per-passage analysis with property overlay	Assessment / progress tracking
Contrast Sets	Minimal pair / max-opposition / multiple-opposition browser	Therapy-target selection
Lookup	Per-word profile (phonology, norms, associations, similar words)	Reference lookup
Sentences	Corpus retrieval with full constraint vocabulary + per-result highlight overlay	In-context practice material

The data spine is described in the architecture doc. The lexicon is ~125K CMU-phonology entries with a ~47K canonical content-POS subset carrying ~150 columns of in-house psycholinguistic norms; the corpus is ~236K curated naturalistic English sentences indexed for fast constraint queries.

R&D workstreams (closing the loop)

Audio Detection

Status: active R&D (Jira / / ). Transcriber model trained, PER 0.093, F1 0.43.

Audio is the diagnostic input at the start of the loop AND the progress signal at the end. The workstream goal is a model that takes patient audio in, returns a phonological error profile out (which phonemes are mistargeted, in which positions, with what error patterns). Initially a clinician-attended tool — patient speaks, clinician records, model annotates. Eventually unattended in-session capture.

See memory/project_audio_detection_spike.md.

Curriculum Recommender

Status: concept. Successor framing for what was called "Content Catalog."

Maps a diagnostic profile to a graded sequence of targets that the live tools can deliver. Not a single bag of material — a progression: foundational targets first (e.g. word-initial /s/ in CV shape), then adding complexity (CCV onsets, S-blends, medial /s/, final /s/, longer words), each stage with assessment criteria for advancement.

The catalog-style work in packages/catalog/ was per-passage generation. The reframe: instead of generating individual passages, generate curricula — structured progressions that an SLP can walk a patient through. The per-passage delivery niche is already served by Sentences (corpus retrieval) and the live tools.

See memory/project_catalog_package.md for the catalog-era findings that will inform this work.

Governed Generation

Status: paused. The CSP solver + Qwen3-Embedding reranker stack was retired in v5.2.0 in favor of Sentences (corpus retrieval) for the per-passage niche. Snapshot at tag archive/csp-generation-v5.2.

Returns as R&D when the curriculum recommender needs synthetic material the corpus can't supply — for example, when a curriculum stage needs a sentence that hits a specific minimal-pair contrast in a specific length / complexity bound where no attested sentence in the corpus satisfies all constraints simultaneously.

See memory/project_csp_and_reranker_deprecated.md for the v5.2 retirement post-mortem.

Adaptive Loop

Status: concept.

The glue between the other three. Diagnostic profile → recommended curriculum → SLP runs therapy → audio feedback → updated profile → next curriculum stage. Builds on validated curricula + audio output; the work here is the orchestration layer + the model that adapts recommendations based on progress.

Engineering posture

• Don't ship R&D as if it were live. Audio Detection, Curriculum Recommender, and Governed Generation are not user-facing. Don't list them in the tool grid; don't describe them as planned-soon features. They live in memory/project_*.md and in research branches.
• The live toolkit is the substrate. Improvements that make the live tools more useful as therapy delivery surfaces are themselves loop investment, even when the loop closure isn't shipped yet.
• Single deploy artifact. Only d1-seed.sql is LFS-tracked. Developer builds locally, CI applies the seed. No Python pipeline in CI.
• R&D writes to memory + research/. When R&D produces concrete code (models, build scripts, audit notebooks), it goes under research/<date>-<topic>/ with a markdown lab notebook. When it stabilizes into a shippable feature, it migrates into packages/.

What this doc is NOT

• A roadmap with dates. Dates are unhelpful given the R&D workstreams' uncertainty.
• A pitch deck. This is the engineering team's shared model of where the product is going and why.
• A frozen vision. Update when the framing changes — the previous iteration of this doc (2026-03-12) was a monorepo migration plan and is obsolete; this rewrite captures the post-corpus-retrieval framing.