# flenn-asr-ipa — STRATEGIC PLAN (G0 draft, rev 2026-07-06 per Tom)
> **DEMOTED 2026-07-06 (Tom):** downstream of tglx-collector. This recognizer cannot move past
> bootstrap until the collector produces training data. Build the collector first; ASR resumes at
> the collector's G4. See /var/we/rnd/tglx-collector/PLAN.md.

Build a modern speech→IPA recognizer, then test whether a FLENN-enhanced version improves on it.
Depends on tglx-collector for data at scale. Approve G0 to open G1.

## The bet (corrected — modest, honest)
Build a competent recognizer with MODERN methods (speech → IPA symbols), then build the same
recognizer ENHANCED with FLENN feature-logic, and see whether it shows a measurable improvement.
Tom's realistic priors: the features→segment step (a phoneme as an AND of distinctive features,
[+voice]&[+bilabial]&[+stop]=/b/) is TRUE but not expected to give huge leverage; the interesting
question is whether FLENN + the wake/dream abstraction search (FLENN-ARCHITECTURE.md) buys anything
on transfer / low-resource / interpretability. A small, honest improvement is the target, not a
revolution.

## Correcting the earlier "Tom owns the data" claim
FALSE, and dropped: Tom's ~60–300 tglx recordings are too few, American-accented, and thin on the
world's sounds — NOT a competitive training corpus. Speech recognition needs a large, multilingual,
phonetically-broad corpus. So the DATA is the real gate. Two sources:
1. **Bootstrap on public corpora** — Common Voice (multilingual), TIMIT (phone-labeled), etc., mapped
   to IPA. Enough to build v1 and run the FLENN-vs-baseline comparison at modest scale.
2. **The flywheel** — the tglx-collector project (/var/we/rnd/tglx-collector) turns uotd / iterciter /
   playalong / teachionary into a consented data-collection tool: users speak known prompts (so
   transcription is nearly free), producing a large multilingual prompted corpus over time. This is
   the durable advantage — not existing data, but the ability to GROW it. flenn-asr-ipa's dataset gate
   (G2) is largely satisfied by "the collector has produced enough."
- Output is IPA → feeds the literacy ecosystem (pronunciation assessment, read/, teachionary): the
  recognizer is dual-use, and its in-app deployment is what powers the collector's flywheel.

## Success metric + the alternative it must beat
Primary: **phone error rate (PER)** transcribing speech into IPA, FLENN-feature model vs. a standard
DNN/CTC phone recognizer (e.g., a small conv acoustic model, or a wav2vec2 probe) of matched size,
on the same data. Secondary, and the real prize: **cross-lingual transfer** — train on English
feature-logic, test PER on a held-out language's IPA (from public multilingual data). FLENN
wins if features (universal) transfer where a plain DNN (which learns language-specific patterns)
degrades. Tertiary: interpretability — do the feature logic nodes actually fire on their features
(does [+nasal] light up on /m,n,ŋ/)? Kill criterion: no PER benefit AND no transfer benefit AND no
readable features → feature-logic wiring isn't earning its keep; report it.

## The MVP experiment
Frame-level (or short-window) classifier: acoustic features (MFCC/mel or a small learned front-end)
→ IPA symbol. Three models, matched params: (a) plain DNN, (b) the same with a distinctive-feature
FLENN layer (feature-detector nodes → AND-bundles → phoneme posteriors), (c) a published-baseline
probe for sanity. Metric sweep: PER vs. training minutes; then the en→hi/th transfer test. Data seed:
TIMIT + Common Voice (public, multilingual); Tom's tglx wavs are too few to train on
but can seed a small transfer probe only.

## Doorway sequence
- **G0 Strategic plan** (this).
- **G1 Model / architecture** — the distinctive-feature inventory (which features, binary vs scalar),
  the FLENN feature→phoneme logic layer, the acoustic front-end (fixed MFCC vs learned), the
  alignment approach (frame-labels via forced alignment, or CTC). The one design question to settle:
  do we predict features-then-phonemes (interpretable, FLENN-native) or phonemes directly with
  feature nodes as hidden structure? Recommend features-first (that's the whole point).
- **G2 Dataset** — bootstrap on PUBLIC corpora (Common Voice multilingual + TIMIT) mapped to IPA for
  v1 + the comparison; in parallel, the tglx-collector flywheel grows the real corpus. tvbet↔strict-IPA
  normalization (Tom's convention work) applies to labels; speaker-disjoint splits; transfer holdout.
- **G3 Subsystem development** — front-end + the three models + the feature-logic layer + PER/transfer
  harness. Effort: moderate (alignment + a custom feature layer are the novel bits).
- **G4 Initial testing** — PER sweep + en→hi/th transfer + feature-firing probe. Deliver: results +
  verdict.
- **G5 Results + refine-loop** — iterate feature set, add SLA arm, scale data, OR ship it into the
  literacy ecosystem as a pronunciation-assessment module (that productization is a natural pivot
  and a real Benefax payoff).

## Effort / risk
- Effort: moderate. Alignment + IPA label hygiene are the fiddly parts; Tom's tvbet/tglx work
  de-risks them. The feature-logic layer is the one novel component.
- Risk: MEDIUM. Speech is noisier than chess (no oracle), so a clean win is harder to isolate — but
  the transfer test is where FLENN could show a modest, honest advantage. DATA RISK is the real
  one — mitigated by public corpora for v1 and the tglx-collector flywheel for scale. Scope risk:
  resist "build a full ASR system"; the deliverable is the FLENN-vs-baseline comparison.
- Who: me for the feature-logic design (with Tom's phonetics input — this is a genuine collaboration
  gate); sonnet agents for alignment, data pipeline, training harness.

## Portfolio fit
Aligned with Tom's phonetics expertise (the feature-logic design is genuinely in-house) and with a
productization path (pronunciation assessment → literacy). Its real dependency is DATA — so the
tglx-collector is the true first step, and this project rides on whatever scale the collector reaches.