Violin Stand Partner — Building a Human-Judgment System Between Lessons

The product will not compete primarily as a general-purpose AI violin expert capable of answering any question and generating broad practice advice.

The product’s primary problem space is the interval between moments of human instruction.

The app will not present itself as a replacement for a qualified violin teacher.

Adopt Violin Stand Partner as the product name and organizing relationship.

Use distinct metaphoric systems for distinct products.

The app’s promise is not mastery, instant diagnosis, or comprehensive instruction.

The initial self-directed audience includes returning adults and developing players who can articulate practice concerns but need continuity and structure.

Parents helping children are not secondary users.

Advice suitable for a trained player cannot automatically be presented to a parent or novice helper.

The app may support multiple levels, but the same guidance should not be delivered identically to all users.

Physical-action routes at launch should remain violin-specific.

Do not make the daily product a large AI-generated practice plan.

The primary daily action should generally be completable in five minutes.

The app must distinguish the action that constitutes today’s commitment from additional work the user may choose.

Allow multiple active practice pages.

Users select how many pages they want open.

Each open page may contain extensive history but only one current action per day.

Do not regenerate the day’s plan continuously.

Today is the center of the product.

Coach is powerful but should not become the whole product.

Avoid generic encouragement.

The AI should be correctable without defensiveness.

Verified Ben content must remain distinguishable from AI-generated explanation.

The system may not invent Ben-specific stories, memories, quotes, motives, or positions even when explicitly asked to be creative.

The AI can execute cognitive and organizational work but cannot take final judgment from the user or appropriate human authority.

The app is governed by: Capture; Why; Why-Not; Commit; Timestamp.

The system must ask what happened before concluding what it means.

When experimentation is appropriate, change one variable and preserve a path back.

The YY Method should remain usable directly from the website.

The AI should not treat the entire conversation as durable memory.

The user must be able to recover context even when the AI forgets.

Material memory writes should be visible and correctable.

Memory should be contextual, not constantly visible.

Do not rely on the LLM to search Ben’s entire corpus and generate a confident answer without reviewed structure.

Break Ben’s existing videos into addressable teaching segments.

Send users to the exact relevant segment rather than a full long video.

The system must not force a source match.

The app does not need to solve every problem.

Safety disclaimers are insufficient if the model can still generate unrestricted advice.

Ben’s reviewed lived-experience judgments should be encoded in bounded knowledge units.

The AI may gather context conversationally.

The system must not stretch a Compact to fit an uncertain case.