PhonoLex Commercialization and Productization Plan

Addendum — decisions of 2026-07-12

This plan (AI-drafted) was verified claim-by-claim against the repository and adopted with the following corrections and decisions. Where the addendum conflicts with the body, the addendum wins. Work is tracked in Jira under Workstream PHON-158 (tasks PHON-159–180).

1. Wedge adopted. Therapy Packs as recommended (§2.1). The pack builder and a new editor surface are one artifact: the list/pack is the primary object, existing tools become add-to-list pickers, the guided flow seeds it (PHON-170–176).
2. §6.6 corrected. No mysterious branch divergence: PR #137 (v6.1 remediation) is merged to develop; develop = main + v6.1. Remaining release work is staging QA → promote → tag (PHON-159, PHON-160).
3. §6.4 resolved by removal. The TalkBank developmental frequencies (freq_age_2y/5y/8y/12y, 93 band columns, freq_age_all) are removed as clinically unfit — not cleared, removed (PHON-161). CYP-LEX (CC BY 4.0) and FineWeb-Edu frequency remain; "age-appropriate" maps to AoA + CYP-LEX. NOTICE/manifest already cover the remaining sources.
4. §12 partially reversed. Illustrations are NOT out of scope: pediatric therapy materials are picture cards. Word→image mapping ships in the MVP, Mulberry Symbols first (CC BY-SA — commercial with attribution; ARASAAC is BY-NC-SA and excluded), with a has_image filter (PHON-162).
5. Entity (§15 Q1). Neumann's Workshop, LLC — for-profit — is the commercial vehicle (SBIR/STTR requires a for-profit applicant). "Just Semantics" is a separate proposed nonprofit and its branding in LICENSE/NOTICE/ToS is being flipped back (PHON-163). LDC-noncommercial-trained audio models stay out of paid tiers permanently; paid audio requires own-IRB or commercially cleared data.
6. Analytics (§15 Q3). Cloudflare-native only: Workers Analytics Engine for events + CF Web Analytics for pageviews. No third-party analytics processors (PHON-168, PHON-177).
7. Posture (§15 Q4). Dual-track: Therapy Packs as earned revenue now; SBIR (fall, post-IRB) funds the audio/diagnostic loop as separately gated R&D.
8. §8.1 confirmed feasible. SLP recruiting is not a bottleneck: in-house practicing-SLP advisor, two external SLPs already exposed, warm network for the 12–15-clinician cohort (PHON-179).
9. Market research added (not in original backlog): competitive matrix vs LessonPix, SLP Toolkit, Ultimate SLP, Word Vault, Boardmaker, TPT → docs/commercial/market-differentiation.md (PHON-178).

Purpose

This document converts the current PhonoLex product and codebase review into an implementation-oriented plan. It is intended to live in the repository, be discussed in the IDE, and be decomposed into GitHub issues.

The central recommendation is:

Commercialize PhonoLex first as a clinician-controlled therapy-material builder for speech-sound targets.

The near-term product should help a speech-language pathologist move from a target sound or contrast to an editable, therapy-ready practice pack in under two minutes. The existing lexical, contrastive, corpus, and psycholinguistic infrastructure should power that workflow. The more ambitious diagnostic–curriculum–therapy–feedback loop remains the long-term strategy, but it should not be the first commercial promise.

---

1. Executive summary

PhonoLex already contains substantial differentiated technology:

• Approximately 125,000 pronunciation-bearing lexical entries.
• An enriched canonical content vocabulary of roughly 47,000 words.
• Hundreds of thousands of minimal and contrastive pairs.
• A curated corpus of roughly 236,000 naturalistic sentences.
• In-house psycholinguistic features and learned phoneme representations.
• Word-list, contrast-set, sentence, lookup, text-analysis, and beta speech-analysis tools.
• A credible long-term plan for diagnostic input, curriculum recommendation, therapy delivery, and progress feedback.

The product is technically ahead of its commercialization layer. The current user experience exposes a collection of sophisticated tools, but it does not yet complete a single paid job from beginning to end.

The initial paid job should be:

“I have a speech-sound target. Give me appropriate words, contrasts, and sentences that I can edit, print, share, and use in therapy.”

The recommended sequence is:

1. Resolve privacy, terms, license, version, and commercial-data-rights inconsistencies.
2. Instrument the product so usage and retention can be measured.
3. Build a guided Therapy Pack workflow over the existing tools and APIs.
4. Recruit a small cohort of practicing SLP design partners.
5. Test actual willingness to pay before building a complete billing, account, district, or enterprise platform.
6. Keep Speech Analysis invite-only until its reliability, privacy posture, cost controls, and clinical framing are ready for broader use.

---

2. Strategic decisions

2.1 Primary product wedge

Product: PhonoLex Therapy Packs

Job to be done: Turn a target sound, position, process, or contrast into a complete set of editable therapy materials.

Primary promise:

From target sound to therapy-ready practice in under two minutes.

Supporting promise:

Choose a sound, position, or contrast. PhonoLex finds age-appropriate words, evidence-based contrast sets, and natural sentences—ready to edit, print, or share.

2.2 Initial user

The first user should be a school-based or pediatric SLP who:

• Treats speech-sound disorders.
• Repeatedly builds word lists, contrast sets, and practice sentences.
• Pays personally for lightweight clinical tools or can secure a small clinic purchase.
• Values time saved more than a broad research interface.
• Can judge whether returned material is clinically usable.

2.3 Initial payer

Prioritize these in order:

1. Individual clinicians.
2. Small pediatric clinics.
3. University clinics and graduate programs.
4. Commercial API and research licenses.
5. School districts only after vendor readiness and individual adoption are established.

2.4 Long-term product

The long-term product remains the closed loop already described in docs/product-plan.md:

diagnostic input
    ↓
curriculum recommendation
    ↓
therapy delivery
    ↓
progress feedback
    ↺

The existing text-based toolkit is the therapy-delivery substrate. Audio Detection and a Curriculum Recommender may eventually create a higher-value clinic or district product, but they should be treated as separately gated R&D until validated.

2.5 What not to lead with

Do not lead the commercial message with:

• “150 psycholinguistic dimensions.”
• “125,000 lexical entries.”
• “A learned 26-dimensional phoneme space.”
• “A free public REST API.”
• “AI speech assessment.”
• A grid of six separate tools.

These are supporting capabilities, not the user’s immediate outcome.

---

3. Evidence from the current repository

The recommendations in this document are grounded in the following current surfaces:

Area	Repository evidence
Product scope and data spine	README.md, docs/index.md, docs/getting-started/tools-overview.md
Long-term loop	docs/product-plan.md
Current no-signup onboarding	docs/getting-started/quick-start.md
Current home and tool navigation	packages/web/frontend/src/components/WelcomeView.tsx, packages/web/frontend/src/App_new.tsx
Product metadata and public claims	packages/web/frontend/index.html
Privacy policy	packages/web/frontend/src/pages/PrivacyPolicy.tsx
Terms	packages/web/frontend/src/pages/TermsOfService.tsx
Contact data flow	packages/web/frontend/src/components/ContactForm.tsx
Speech Analysis claims and limitations	docs/user-guide/speech-analysis.md, packages/web/workers/src/routes/audio.ts
Proprietary license	LICENSE, docs/about/license.md
Data-rights posture	NOTICE, docs/data-derivation-manifest.md, docs/about/citations.md
Recent engineering audit	docs/audits/2026-07-03-develop-full-audit.md, PR #137
Search acquisition surfaces	packages/web/frontend/public/landing/, packages/web/frontend/public/sitemap.xml

---

4. Product definition: Therapy Packs

4.1 Core user story

As an SLP preparing for a speech-sound session, I want to enter a target sound or contrast and receive an editable set of words, contrast pairs, and sentences that fit the learner’s approximate level, so I can prepare an individualized session without searching multiple resources.

4.2 V1 input

The clinician should be able to specify:

• Target mode:
• Single sound.
• Sound and position.
• Two-phoneme contrast.
• Phonological process preset.
• Word position:
• Initial.
• Medial.
• Final.
• Any.
• Approximate developmental level or difficulty.
• Sounds to avoid.
• Optional CV-shape constraints.
• Optional intervention approach:
• Drill targets.
• Minimal pairs.
• Maximal opposition.
• Multiple opposition.
• Number of requested words and sentences.

Advanced users may open the existing fine-grained filters after the guided defaults are applied.

4.3 V1 output

A Therapy Pack should contain:

Target practice

• 15–25 candidate words.
• Easier or more familiar words ranked first by default.
• Variant pronunciations surfaced where relevant.
• One-click removal of unsuitable words.
• Optional replacement suggestions.

Contrast practice

• Relevant minimal, maximal, or multiple-opposition candidates.
• A short clinician-facing explanation of the retrieval approach.
• No claim that PhonoLex autonomously chose the correct treatment.

Context practice

• Short natural sentences containing the selected targets.
• Per-word highlighting for target hits.
• Controls for sentence length and approximate difficulty.
• One-click removal and replacement.

Take-home material

• A clean printable format.
• Optional caregiver-facing instructions.
• Space for clinician notes.
• Export as PDF.
• Export as CSV or text where appropriate.
• Shareable, non-patient-specific link in a later iteration.

4.4 Recommended V1 flow

Landing page
    ↓
“What are you targeting?”
    ↓
Guided target configuration
    ↓
Preview generated from existing PhonoLex APIs
    ↓
Editable pack
    ↓
Export / save / duplicate
    ↓
Optional account or upgrade prompt

The product should provide value before requiring an account.

4.5 Suggested data model

The following is illustrative rather than prescriptive:

type TargetMode = "sound" | "contrast" | "process";
type WordPosition = "initial" | "medial" | "final" | "any";
type InterventionApproach =
  | "drill"
  | "minimal-pairs"
  | "maximal-opposition"
  | "multiple-opposition";

interface TherapyPackRequest {
  targetMode: TargetMode;
  targetPhones: string[];
  processPreset?: string;
  position: WordPosition;
  ageBand?: "2y" | "5y" | "8y" | "12y" | "all";
  difficulty?: "easier" | "balanced" | "challenging";
  excludedPhones: string[];
  cvShapes?: string[];
  approach: InterventionApproach;
  requestedWordCount: number;
  requestedSentenceCount: number;
}

interface TherapyPack {
  id: string;
  schemaVersion: number;
  title: string;
  request: TherapyPackRequest;
  words: TherapyPackWord[];
  contrasts: TherapyPackContrast[];
  sentences: TherapyPackSentence[];
  clinicianNotes?: string;
  createdAt: string;
  updatedAt: string;
}

4.6 Implementation recommendation

For the first usable version:

• Orchestrate the workflow in the frontend using existing APIs.
• Avoid introducing a new generalized recommendation service until observed user behavior shows what the ranking needs to do.
• Store drafts locally first if accounts are not yet present.
• Keep all pack content non-patient-specific.
• Add server persistence only when saving, sharing, team access, and billing justify it.
• Keep audio completely outside the Therapy Pack MVP.

---

5. Product packaging

5.1 Free tier

Retain frictionless access as the acquisition engine.

Suggested free access:

• Lookup.
• Basic word-list and contrast searches.
• Limited sentence results.
• One or two complete Therapy Packs per month.
• Basic copy and export.
• Rate-limited API experimentation.
• No account required before first value.

5.2 Clinician Pro

Initial price test:

• $149 per year, or
• $18 per month.

Suggested paid value:

• Unlimited Therapy Packs.
• Saved targets and presets.
• Duplicate and revise prior packs.
• Advanced filtering.
• Batch pack creation.
• Clean PDF and caregiver handout exports.
• Shareable packs.
• Clinic branding.
• Export history.
• Priority support.
• Later: limited monthly Speech Analysis usage after that feature is commercially ready.

A founding-clinician offer of approximately $99 for the first year is reasonable if it requires real payment and clearly states the normal renewal price.

5.3 Clinic and university pilots

Begin with manually sold annual pilots rather than a polished enterprise platform.

Possible pilot range:

• $1,000–$2,500 per year, depending on seats and support.

Pilot value may include:

• Shared presets.
• Central billing.
• Faculty or supervisor access.
• Onboarding.
• Direct product feedback sessions.
• Basic usage reporting.
• Early access to clinically reviewed workflows.

5.4 API and research licensing

Treat the API as a separate product surface:

• Free academic/developer key with modest limits.
• Paid commercial key.
• University or laboratory license.
• Bulk exports only for data products explicitly cleared for redistribution.
• No uncontrolled anonymous production API once meaningful usage or cost appears.

5.5 District sales

Do not prioritize district sales until PhonoLex has:

• Demonstrated clinician retention.
• Correct privacy and security documentation.
• Data-processing and student-data terms.
• Administrative accounts.
• Purchase-order and invoicing support.
• A support process.
• Clear audio retention and subprocessors documentation.
• Any required state- or district-specific agreements.

---

6. Immediate launch blockers

6.1 Privacy-policy accuracy

Current policy language and current data flows are inconsistent.

The policy currently states that PhonoLex does not collect, store, or transmit personally identifiable information and that there are no third-party services collecting user data. The product currently:

• Sends audio to server-side inference.
• Uses Web3Forms for contact submissions containing name, email, subject, and message.
• May add analytics as part of commercialization.

Required work:

• State exactly what data is transmitted.
• State whether uploaded audio is retained, cached, logged, or processed transiently.
• State retention and deletion behavior.
• List subprocessors.
• Explain whether patient-identifiable material is allowed.
• Add consent and age/guardian expectations.
• Clarify children’s data handling.
• Clarify what usage analytics are collected.
• Replace dynamically generated “last updated” dates with an explicit revision date.

6.2 Terms of Service

The current Terms state that the service is provided free of charge for educational and research purposes. This conflicts with a paid plan.

Required work:

• Define free and paid service tiers.
• Add payment, renewal, cancellation, and refund terms.
• Clarify permitted clinical decision-support use.
• Preserve the “qualified professional remains responsible” language.
• Define acceptable automated/API use.
• Add account and suspension terms when accounts exist.
• Confirm the correct legal entity and governing law.
• Review third-party model and dataset obligations.
• Add beta-feature language for Speech Analysis.

6.3 Public metadata consistency

At least the following should have one canonical source:

• Product version.
• License.
• Free/paid offer status.
• Data counts.
• Tool list.
• Product description.
• API availability.
• Organization/legal owner.

packages/web/frontend/index.html, header version chips, package manifests, docs, structured data, and public landing pages should not disagree.

6.4 Commercial data-rights review

The repository has already completed meaningful remediation, but commercial launch should include a focused review of:

• TalkBank-derived developmental frequencies.
• Any known-weak vocabulary-list provenance.
• Sentence outputs derived from CC BY-SA or unclear source terms.
• OpenSubtitles output and attribution posture.
• Exact rights to redistribute derived values through paid exports or APIs.
• Attribution placement in generated materials.
• Whether any previous model or corpus obligations remain in current production.

The review should produce a matrix with:

artifact / column / endpoint / source / license / transformation /
redistribution status / attribution requirement / commercial status /
owner / remediation

6.5 Speech Analysis beta gate

Before broader access:

• Add an explicit beta notice.
• Add a concise audio-processing consent notice before first upload or recording.
• Warn users not to include names or unnecessary identifying information.
• Document retention and deletion.
• Add per-user or per-session quotas.
• Add rate limiting and abuse controls.
• Confirm timeouts and permanent-error behavior.
• Monitor inference cost and saturation.
• Avoid marketing language that implies autonomous diagnosis or validated scoring.

6.6 Production release state

PR #137 remediated a broad set of findings on develop, while the repository has recently shown divergence between main and develop.

Before inviting users:

• Confirm the intended release branch.
• QA the complete v6.1 remediation on staging.
• Resolve branch divergence intentionally.
• Promote a tagged production release.
• Verify production version, D1 schema, frontend, Worker, and audio container alignment.
• Run a launch smoke-test checklist.

---

7. Instrumentation

7.1 Objective

The next product decisions should be based on observed behavior rather than feature opinions.

7.2 Minimum event taxonomy

landing_view
therapy_pack_started
target_mode_selected
target_configured
therapy_pack_results_shown
word_removed
word_replaced
contrast_removed
sentence_removed
export_started
export_completed
pack_saved
pack_duplicated
upgrade_viewed
checkout_started
checkout_completed
returned_1d
returned_7d
returned_30d

Include properties such as:

• Target mode.
• Position.
• Intervention approach.
• Requested result counts.
• Time to first results.
• Time to export.
• Number of removed items.
• Number of replacement requests.
• Error category.
• Anonymous session identifier.
• Account or plan type where applicable.

Do not send target words, notes, audio, or any patient-identifying content to an analytics provider without a deliberate privacy review.

7.3 Funnel

The initial commercial funnel is:

landing_view
    ↓
therapy_pack_started
    ↓
therapy_pack_results_shown
    ↓
result_edited
    ↓
export_completed
    ↓
returned_7d
    ↓
checkout_completed

7.4 Success thresholds for the first cohort

Signal	Encouraging threshold
Clinicians observed on a real task	10
Produce a usable pack in under five minutes	7 of 10
Export or save in the first session	6 of 10
Return independently within seven days	5 of 10
Report saving at least twenty minutes	5 of 10
Pay $99–$149 for founding access	3 of 10
Refer another clinician	2 of 10

These are discovery thresholds, not permanent company KPIs.

---

8. Go-to-market plan

8.1 Founding-clinician program

Recruit 12–15 practicing SLPs.

Each participant should:

• Bring a real, de-identified preparation task.
• Use the workflow while being observed.
• Explain why individual returned items are accepted or rejected.
• Use PhonoLex independently during the following week.
• Be asked to pay for founding access if the product saves meaningful time.

At least one practicing clinician should become a paid clinical advisor responsible for reviewing:

• Presets.
• Public claims.
• Clinical terminology.
• Sample packs.
• Caregiver instructions.
• Intervention explanations.

8.2 High-intent search pages

Create useful, interactive acquisition pages around specific clinician tasks, for example:

• Initial /s/ word list.
• Final /k/ word list.
• Medial /ɹ/ practice.
• /k/ versus /t/ minimal pairs.
• Fronting therapy words.
• Stopping minimal pairs.
• Maximal-opposition examples.
• Multiple-opposition set builder.
• Age-appropriate /l/ sentences.
• CV-shape-filtered practice lists.

Each page should:

• Provide a genuinely useful example.
• Explain the target in plain language.
• Open a preconfigured Therapy Pack.
• Avoid thin, duplicated SEO copy.
• Include a clear clinical disclaimer.

8.3 Shareable outputs

Generated materials should quietly identify their source:

Built with PhonoLex — customize this target set.

This creates a referral loop through colleagues, supervisors, graduate students, clinic teams, and caregivers.

8.4 University and educator partnerships

Prioritize:

• University clinic supervisors.
• Professors teaching phonological intervention.
• SLP creators who demonstrate real preparation workflows.
• Continuing-education presenters.
• Small clinic owners.

Lead with a custom example built around their actual teaching or clinical target, not a generic product tour.

8.5 Free materials library

Publish a small, high-quality library of clinically reviewed packs.

Each sample should:

• Be usable without signup.
• Link to an editable configuration.
• Explain the retrieval logic.
• Avoid individualized treatment claims.
• Encourage duplication rather than static downloading only.

---

9. Six-week commercialization sprint

Week 1: Trust and release readiness

Goals

• Make the current product safe and credible enough for invited clinicians.
• Establish the production baseline.

Deliverables

• QA and release v6.1 remediation.
• Resolve main/develop release strategy.
• Correct privacy policy.
• Correct Terms.
• Correct structured metadata, license, version, and product claims.
• Document audio processing and retention.
• Add beta consent gate or disable broad audio access.
• Produce commercial data-rights checklist.
• Add initial event instrumentation.

Week 2: Therapy Pack foundation

Goals

• Create the guided entry point.
• Prove existing APIs can generate a coherent pack.

Deliverables

• New “Build a Therapy Pack” route.
• Target configuration flow.
• Three presets:
• Sound and position.
• Minimal-pair contrast.
• Maximal or multiple opposition.
• Frontend orchestration of words, contrasts, and sentences.
• Loading, empty, and error states.
• Basic editable results.

Week 3: Export and acquisition

Goals

• Complete the first useful job.
• Make the result portable.

Deliverables

• PDF export.
• Text/CSV export where appropriate.
• Clinician notes.
• Caregiver instructions template.
• Founding-clinician landing page.
• One strong sample pack.
• Contact and onboarding workflow.

Weeks 3–4: Observed use

Goals

• Learn where the workflow fails.
• Identify ranking and content-quality problems.

Activities

• Conduct at least ten guided sessions.
• Measure time to first useful pack.
• Record every rejected word, contrast, and sentence.
• Track whether users export.
• Ask participants to use the tool independently.
• Interview non-returners before enthusiasts.

Week 5: Willingness-to-pay test

Goals

• Distinguish praise from commercial demand.

Deliverables

• Founding plan offer.
• Manual or lightweight checkout.
• Clear renewal price.
• Founding-member terms.
• Paid clinical-advisor agreement.
• First clinic or university pilot proposal.

Week 6: Small paid beta

Goals

• Operate the workflow with 25–50 invited users.
• Establish repeat use and support requirements.

Deliverables

• Paid beta cohort.
• Weekly cohort review.
• First time-saved case study.
• Prioritized post-beta roadmap.
• Decision on whether to invest in accounts, sharing, billing automation, and clinic administration.

---

10. Issue-ready backlog

The following backlog is written to be converted into GitHub issues. Identifiers are placeholders.

Epic A — Commercial trust and release readiness

PHON-GTM-001 — Establish canonical product metadata

Priority: P0
Labels: commercialization, metadata, frontend, docs

Problem

Version, license, offer, data counts, and feature descriptions are duplicated across multiple surfaces and have drifted.

Scope

• Create a canonical product metadata module or build artifact.
• Use it for:
• Frontend version display.
• Worker root response.
• Structured data.
• Documentation where feasible.
• Public data-count chips.
• Remove stale Apache-license and zero-dollar structured-data claims where inaccurate.

Acceptance criteria

• Public page source reports the correct license.
• Public page source reports the current release version.
• Header, Worker, package manifests, and docs do not conflict.
• A test fails when the canonical version diverges from package versions.
• Current tool count and product description are consistent.

---

PHON-GTM-002 — Rewrite the Privacy Policy for current data flows

Priority: P0
Labels: commercialization, privacy, legal, audio, frontend

Scope

Document:

• Contact-form data.
• Audio upload and recording.
• Server-side processing.
• Retention and deletion.
• Logs.
• Analytics.
• Cookies/local storage.
• Subprocessors.
• Children’s data.
• Prohibited patient-identifying content if applicable.
• Contact route for privacy requests.

Acceptance criteria

• Policy no longer claims that no data is transmitted.
• Web3Forms is disclosed or removed.
• Audio processing is accurately described.
• “Last updated” is a fixed revision date.
• Policy is reviewed against the actual production architecture.
• Audio consent text links to the policy.

---

PHON-GTM-003 — Rewrite Terms for free and paid use

Priority: P0
Labels: commercialization, legal, billing, frontend

Scope

Add or revise:

• Free and paid tiers.
• Renewal and cancellation.
• Refund handling.
• Accounts and acceptable use.
• API limits.
• Beta features.
• Professional responsibility.
• No autonomous diagnosis.
• Governing law and legal entity.
• Third-party obligations.

Acceptance criteria

• Terms no longer promise that all use is free.
• Paid-plan terms are present before payment is accepted.
• Beta Speech Analysis is addressed explicitly.
• Commercial API use is addressed.
• The correct legal entity and contact are shown.

---

PHON-GTM-004 — Build a commercial data-rights matrix

Priority: P0
Labels: commercialization, data, legal, documentation

Scope

Create docs/commercial/data-rights-matrix.md or equivalent.

Cover:

• Shipped word properties.
• Edges.
• Contrast pairs.
• Sentence corpus.
• Developmental-frequency columns.
• Exported pack content.
• Public API.
• Paid API.
• Bulk export.

Acceptance criteria

Every shipped or planned commercial artifact has:

• Source.
• License.
• Transformation.
• Redistribution status.
• Attribution requirement.
• Commercial status.
• Owner.
• Remediation task if unresolved.

Outstanding TalkBank, vocabulary-list, CC BY-SA, and OpenSubtitles questions are visible and assigned.

---

PHON-GTM-005 — Add Speech Analysis beta consent and privacy gate

Priority: P0
Labels: audio, privacy, frontend, commercialization

Scope

Before first record/upload:

• Explain server-side processing.
• State retention behavior.
• Warn against unnecessary identifying content.
• Explain beta limitations.
• Require affirmative acknowledgement.
• Persist acknowledgement locally with a policy version.

Acceptance criteria

• No audio can be submitted before acknowledgement.
• The consent version is recorded locally.
• Copy says decision support, not diagnosis.
• The UI links to the privacy policy and audio-method documentation.
• The gate is accessible by keyboard and screen reader.

---

PHON-GTM-006 — Production release and branch reconciliation

Priority: P0
Labels: release, deployment, qa

Scope

• Establish release source of truth.
• Reconcile main and develop.
• Validate PR #137 changes on staging.
• Verify frontend, Worker, D1, and audio container compatibility.
• Tag and deploy the intended release.

Acceptance criteria

• Production displays the intended version.
• Production smoke tests pass.
• The release commit is tagged.
• Staging and production deployment documentation is current.
• No unexplained branch divergence remains.

---

Epic B — Product analytics

PHON-GTM-010 — Define privacy-safe event schema

Priority: P0
Labels: analytics, privacy, product

Scope

Define the event taxonomy from Section 7, approved properties, prohibited properties, retention, and environments.

Acceptance criteria

• Event schema is documented.
• Patient-identifying content is explicitly prohibited.
• Development and production events are distinguishable.
• Every event has an owner and purpose.
• Consent requirements are documented.

---

PHON-GTM-011 — Instrument the Therapy Pack funnel

Priority: P1
Labels: analytics, frontend, product

Acceptance criteria

The following can be measured end to end:

• Start.
• Configuration.
• Results.
• Edits.
• Export.
• Return.
• Upgrade.
• Checkout.

Time-to-results and time-to-export can be calculated.

---

PHON-GTM-012 — Create a lightweight founder metrics view

Priority: P1
Labels: analytics, internal-tooling

Scope

A simple report is sufficient. Do not build a full analytics product.

Acceptance criteria

The founder can review weekly:

• Pack starts.
• Result views.
• Export rate.
• Median time to export.
• Seven-day return rate.
• Top target modes.
• Common errors.
• Upgrade and payment conversion.

---

Epic C — Therapy Pack MVP

PHON-PACK-001 — Add Therapy Pack entry route and outcome-oriented homepage

Priority: P0
Labels: therapy-pack, frontend, ux, commercialization

Scope

• Add primary CTA: “Build a Therapy Pack.”
• Replace tool-grid-first positioning with the outcome.
• Retain advanced tools as secondary navigation.

Acceptance criteria

• A first-time user can begin without knowing which existing tool to open.
• The existing tools remain accessible.
• Homepage copy focuses on preparation time and material quality.
• Mobile flow is usable.

Suggested hero

From target sound to therapy-ready practice in under two minutes.

Suggested subhead

Choose a sound, position, or contrast. PhonoLex finds appropriate words, evidence-based contrast sets, and natural sentences—ready to edit, print, or share.

---

PHON-PACK-002 — Build guided target configuration

Priority: P0
Labels: therapy-pack, frontend, ux

Scope

• Target mode.
• Target phones.
• Position.
• Approach.
• Developmental level.
• Excluded phones.
• CV shape.
• Result counts.
• Advanced controls.

Acceptance criteria

• The basic flow can be completed without using raw property columns.
• IPA input is validated consistently.
• Defaults produce a useful request.
• Configuration can be edited after results appear.
• The request is serializable.

---

PHON-PACK-003 — Create clinical presets

Priority: P0
Labels: therapy-pack, clinical, frontend

Initial presets:

1. Sound and position practice.
2. Minimal-pair contrast.
3. Maximal opposition.
4. Multiple opposition, if current retrieval supports an understandable flow.

Acceptance criteria

• Presets apply visible, editable defaults.
• Presets include plain-language explanations.
• No preset claims to select treatment autonomously.
• Presets are reviewable by a clinical advisor.

---

PHON-PACK-004 — Orchestrate existing APIs into a unified preview

Priority: P0
Labels: therapy-pack, frontend, api

Scope

Compose:

• Word results.
• Contrast results.
• Sentence results.

Use existing routes before creating a new recommendation backend.

Acceptance criteria

• One action produces all three result sections.
• Partial failure is recoverable.
• Each section has loading, empty, and error states.
• The clinician can rerun one section without losing the others.
• The request and response can be logged without patient information.

---

PHON-PACK-005 — Build editable pack results

Priority: P0
Labels: therapy-pack, frontend, ux

Features

• Remove item.
• Restore item.
• Request replacement.
• Reorder item.
• Edit pack title.
• Add clinician note.
• Show why an item matched.
• Preserve edits when configuration panels are collapsed.

Acceptance criteria

• Removing one item does not rerun the entire pack.
• Replacement respects the original constraints.
• The interface remains usable on tablet widths.
• The final export reflects the edited state exactly.

---

PHON-PACK-006 — Add Therapy Pack PDF export

Priority: P0
Labels: therapy-pack, export, frontend

V1 export

• Title.
• Target summary.
• Word list.
• Contrast sets.
• Sentences.
• Optional notes.
• Optional caregiver instructions.
• PhonoLex attribution.

Acceptance criteria

• Export is legible on US Letter and A4.
• No interface controls appear in the output.
• IPA renders correctly.
• Page breaks do not split individual contrast rows badly.
• Export matches the current edited state.
• Analytics capture export start and completion.

---

PHON-PACK-007 — Add text and CSV export

Priority: P1
Labels: therapy-pack, export

Acceptance criteria

• Word and sentence content can be copied cleanly.
• CSV uses stable column headers.
• Unicode and IPA survive round trips.
• Export does not include hidden or removed items.

---

PHON-PACK-008 — Add local draft persistence

Priority: P1
Labels: therapy-pack, persistence, frontend

Scope

Use local storage before accounts are built.

Acceptance criteria

• A draft survives refresh.
• Draft schema has a version.
• Corrupt drafts fail safely.
• User can delete all local drafts.
• The UI does not imply cloud backup.

---

PHON-PACK-009 — Add reusable pack duplication

Priority: P1
Labels: therapy-pack, productivity

Acceptance criteria

• A saved local pack can be duplicated.
• The duplicate has a new ID and timestamp.
• The source is unchanged.
• User can quickly change the target and regenerate.

---

PHON-PACK-010 — Add clinically reviewed sample packs

Priority: P1
Labels: therapy-pack, content, clinical, growth

Acceptance criteria

• At least three sample packs are published.
• Each has clinical-advisor review.
• Each opens as an editable pack.
• Sample content includes a visible disclaimer.
• Sample pages are indexable and linked in the sitemap.

---

Epic D — Founding-clinician commercialization

PHON-GTM-020 — Launch founding-clinician application

Priority: P1
Labels: growth, commercialization, frontend

Fields

• Name.
• Email.
• Setting.
• Approximate caseload.
• Frequency of speech-sound preparation.
• Current tools.
• Willingness to join observed sessions.
• Optional target they want to build.

Acceptance criteria

• Privacy disclosure covers submitted information.
• Submissions reach a reliable owner.
• Conversion source is recorded.
• Confirmation explains the program and next step.

---

PHON-GTM-021 — Create design-partner interview protocol

Priority: P1
Labels: research, product, clinical

Deliverables

• Session script.
• Consent.
• Observation checklist.
• Time-on-task sheet.
• Item rejection log.
• Follow-up survey.
• Seven-day return interview.
• Payment test script.

---

PHON-GTM-022 — Add in-product feedback for pack quality

Priority: P1
Labels: feedback, therapy-pack, clinical

Scope

Allow item-level reasons such as:

• Too difficult.
• Inappropriate meaning.
• Wrong pronunciation.
• Not useful for target.
• Unnatural sentence.
• Other.

Acceptance criteria

• Feedback can be submitted without patient data.
• Removed-item reason is optional.
• Feedback is tied to retrieval parameters and item ID.
• Founder can export aggregated reasons.

---

PHON-GTM-023 — Create founding paid plan

Priority: P1
Labels: billing, commercialization

Recommended test

• $99 first year.
• Normal renewal price disclosed.
• Limited cohort.
• Direct founder support.
• No lifetime deal.

Acceptance criteria

• A real payment can be accepted.
• Terms are shown before purchase.
• Receipt and cancellation instructions are available.
• Founder can manually grant and revoke access.
• Full billing automation is not required for the first cohort.

---

PHON-GTM-024 — Create first clinic or university pilot package

Priority: P2
Labels: sales, commercialization, pilot

Deliverables

• One-page pilot description.
• Pricing range.
• Included seats.
• Onboarding.
• Support.
• Data handling.
• Evaluation metrics.
• Exit and renewal terms.

---

Epic E — Speech Analysis commercial gate

PHON-AUDIO-GTM-001 — Add quotas and rate limiting

Priority: P0 before broad beta
Labels: audio, security, cost-control

Acceptance criteria

• Anonymous users cannot create unlimited inference load.
• Limits are configurable.
• Limit errors are user-readable.
• Metrics show requests, failures, cold starts, duration, and estimated cost.
• Abuse handling is documented.

---

PHON-AUDIO-GTM-002 — Verify timeout and permanent-error semantics

Priority: P0 before broad beta
Labels: audio, reliability

Acceptance criteria

• Cold start is distinguishable from a permanent host failure.
• Permanent failures do not trigger multi-minute repeated uploads.
• Worker-to-host requests have timeouts.
• The same clip is not retried indefinitely.
• User can cancel a pending analysis.

---

PHON-AUDIO-GTM-003 — Document and enforce audio retention

Priority: P0 before broad beta
Labels: audio, privacy, infrastructure

Acceptance criteria

• Retention behavior is documented.
• Application behavior matches the documentation.
• Logs do not contain raw audio.
• Temporary files are deleted deterministically.
• A privacy review covers every audio-processing layer.

---

PHON-AUDIO-GTM-004 — Establish clinical validation plan

Priority: P1
Labels: audio, research, clinical

Deliverables

• Intended-use statement.
• Population and language scope.
• Reference-standard plan.
• Error categories.
• Fairness and accent evaluation.
• Minimum evidence for each future public claim.
• Separation between technical metrics and clinical utility.

---

11. Definition of launch-ready

The first paid beta is ready when all of the following are true:

Trust

• [ ] Privacy policy matches current production behavior.
• [ ] Terms support paid use.
• [ ] Public license and version claims are correct.
• [ ] Audio beta has explicit consent and accurate limits.
• [ ] Commercial data-rights unknowns are documented and assigned.

Product

• [ ] A user can start from one primary CTA.
• [ ] A useful pack can be generated from a sound or contrast.
• [ ] Words, contrasts, and sentences are editable.
• [ ] PDF export works.
• [ ] Empty and error states are understandable.
• [ ] The workflow works on tablet and desktop.
• [ ] No account is required before first value.

Measurement

• [ ] Starts, results, edits, export, return, and payment are measurable.
• [ ] Analytics exclude patient-identifying content.
• [ ] A weekly funnel report exists.

Operations

• [ ] Production release process is understood.
• [ ] Error monitoring exists.
• [ ] Contact and support requests are owned.
• [ ] Founding users know how to reach the founder.
• [ ] Audio usage has controls or remains invite-only.

Validation

• [ ] Ten real clinician sessions have been observed.
• [ ] At least six users export in their first session.
• [ ] At least five return independently in seven days.
• [ ] At least three pay the founding price.

---

12. Explicitly out of scope for the first commercialization cycle

Do not make these prerequisites for the first paid beta:

• Complete district procurement support.
• Full enterprise administration.
• Automatic treatment-plan selection.
• Patient records.
• Insurance or billing workflows.
• A complete EHR.
• Longitudinal outcome tracking.
• Connected-speech segmentation.
• Autonomous diagnosis.
• Broad consumer or caregiver marketing.
• Illustrations and game mechanics.
• A generalized AI generation stack.
• A complete self-serve billing platform.
• Native mobile applications.
• Large conference sponsorships or paid advertising.

---

13. Product copy starter

Homepage

Headline

From target sound to therapy-ready practice in under two minutes.

Subhead

Choose a sound, position, or contrast. PhonoLex finds appropriate words, evidence-based contrast sets, and natural sentences—ready to edit, print, or share.

Primary CTA

Build a Therapy Pack

Secondary CTA

Explore advanced tools

Trust line

Built for clinician-guided preparation. PhonoLex supports professional judgment; it does not diagnose or prescribe treatment.

Therapy Pack start

Prompt

What are you targeting today?

Options

• A sound in a specific word position.
• A minimal-pair contrast.
• A maximal or multiple opposition.
• A common phonological process.

Upgrade

Save the work you repeat every week.

Upgrade for unlimited Therapy Packs, saved targets, advanced filters, reusable exports, and priority support.

---

14. Key risks and mitigations

Risk	Likely consequence	Mitigation
Product remains a tool collection	Low activation and weak willingness to pay	Guided Therapy Pack workflow
Returned material contains clinically unsuitable items	Loss of trust	Editable output, reasons for match, item feedback, clinical review
Audio is marketed before readiness	Privacy, trust, cost, and clinical risk	Invite-only beta and explicit gate
Accounts and billing are built too early	Months of work before product proof	Manual founding plan first
SEO pages become thin content	Low quality and reputational risk	Publish fewer interactive, clinically reviewed pages
Data-rights issue blocks paid redistribution	Commercial delay or takedown risk	Rights matrix and targeted counsel
Free API creates unbounded cost	Abuse and infrastructure expense	Keys, quotas, and rate limits
District procurement consumes founder time	Slow learning and long sales cycles	Individual and small-clinic focus first
Product claims exceed evidence	Clinical and legal exposure	Intended-use statements and claim review
Feature development resumes before retention	Engineering progress without business proof	Six-week commercialization freeze on major R&D

---

15. Decisions still requiring founder input

These questions do not block starting the first engineering work, but they should be resolved during the sprint:

1. What is the correct legal entity behind Just Semantics and PhonoLex?
2. Is any production audio retained, cached, or logged at any layer?
3. Which analytics system is acceptable under the intended privacy posture?
4. Is the goal a bootstrapped small company, a grant-supported research company, or a venture-scale clinical platform?
5. How many hours per week can the founder personally spend interviewing and onboarding clinicians?
6. Is there already a practicing SLP advisor?
7. What are the current monthly infrastructure and audio inference costs?
8. Does PhonoLex have any meaningful current traffic or repeat users?
9. Which exported artifacts may include third-party sentence text?
10. Should the first paid plan include any Speech Analysis allowance, or should audio remain entirely separate?

---

16. Recommended next repository action

Create a commercialization milestone with these first issues, in order:

1. PHON-GTM-006 — Production release and branch reconciliation.
2. PHON-GTM-002 — Privacy Policy rewrite.
3. PHON-GTM-003 — Terms rewrite.
4. PHON-GTM-001 — Canonical product metadata.
5. PHON-GTM-004 — Commercial data-rights matrix.
6. PHON-GTM-010 — Privacy-safe event schema.
7. PHON-PACK-001 — Therapy Pack entry route.
8. PHON-PACK-002 — Guided target configuration.
9. PHON-PACK-004 — Unified preview.
10. PHON-PACK-005 — Editable results.
11. PHON-PACK-006 — PDF export.
12. PHON-GTM-020 — Founding-clinician application.

The team should avoid beginning another major R&D workstream until the first ten observed clinician sessions and the first willingness-to-pay test are complete.

---

17. Final recommendation

PhonoLex should not attempt to commercialize “all of PhonoLex” at once.

The first company-worthy product is a simple promise built on sophisticated infrastructure:

A clinician enters a speech-sound target and receives an editable, individualized therapy pack faster than they can assemble one elsewhere.

The current database, contrast engine, sentence corpus, psycholinguistic features, and learned phoneme representations make that promise credible. The immediate work is not another model or another search surface. It is packaging, trust, measurement, observed use, and payment.

Once that workflow retains paying clinicians, the same product can expand toward saved curricula, team workflows, progress tracking, and—when evidence and privacy controls support it—the diagnostic and feedback capabilities envisioned in the closed loop.