PRODUCT CASE
WorldLim
A live AI learning product that turns the work of skilled teaching—sequencing, lesson construction, and contextual re-explanation—into reviewed lesson data plus a runtime tutor grounded in the same material.
Inspect now
Why This Product Needed to Exist
Reading a dictionary definition is not the same as learning a concept. A skilled teacher clarifies its boundaries, anticipates common misconceptions, introduces alternate perspectives and applications, and re-explains it around the learner's question.
That quality remains bound to expert time and does not scale across every subject and learner. Language models made open-ended questions available to everyone, but a chat alone does not assemble what to learn first, material that builds understanding, and an answer grounded in the learner's current step into one coherent experience.
Split the Expert's Role Into Two Systems
I split the teacher's work by what could be designed and inspected ahead of time and what could only be known during learning.
- Lesson data production: sequence the path, then generate, review, and repair explanations of boundaries, misconceptions, perspectives, context, and application.
- Runtime tutor: read the exact word sense, stage, and material on screen, then respond to the learner's current question or misunderstanding.
The product does not ask one open-ended chat model to own the entire learning experience. Reusable learning design and material become product data; the runtime model handles the learner's current misunderstanding and question.
The Learner Experience
The learner selects a specific sense of a word, then moves through recall, definition, alternate perspectives, context, and personal application. A word can be examined through different lenses, such as Kant, Plato, or Korean poet Jeong Jiyong. When the learner gets stuck, the tutor receives the lesson and context shown on the current screen.
The learning world, stage assets, and character placements were generated, reviewed, and integrated into Flutter. The content pipeline became a product learners can navigate, question, and continue using.
Responsibility Split
| Owner | Responsibility |
|---|---|
| Source data | Word sense, difficulty, and learning-unit ground truth |
| Deterministic code | Normalization, schema, duplicate, length, state, and publish checks |
| Generation and evaluation models | Explanation, context, question candidates, and semantic diagnosis |
| Runtime model | Answer questions grounded in the active lesson and screen context |
| Human | Own learning design, quality criteria, ambiguous review, and final responsibility |
Problems Solved While Building
Learning Unit: Prevent Different Meanings From Collapsing Together
- Observed problem: Generating from a word string alone could mix parts of speech and unrelated senses into one lesson.
- Reasoning: Generation, review, UI state, and the tutor needed to share the same selected sense.
- Implementation: Dictionary sources were normalized at the sense level. Recall prompts, definitions, perspectives, context, and application followed the same identifier.
- What changed: The pipeline could detect explanations teaching the wrong meaning and trace content back to its source sense.
Product Data Gate: Treat Fluent Output as a Candidate, Not a Finished Asset
- Observed problem: Valid JSON and natural prose could still teach the wrong sense or omit a required learning step.
- Reasoning: Model output needed to enter the system as a candidate with a review state.
- Implementation: Structural and semantic checks assigned pass, repair, or reject. Failed items were regenerated from explicit reasons and checked again.
- What changed: Of 3,780 definition-understanding items, 410 stopped at first review. 409 passed after the first repair and the last item after a second repair.
Runtime Grounding: Let the Screen and Tutor Share the Same Material
- Observed problem: An open chat could drift away from the selected sense, current word, or lesson visible on screen.
- Reasoning: Production and runtime should be separate systems but share the same active learning bundle and UI state.
- Implementation: The server loads the active material and verifies what the screen exposes before assembling it with the user's question for the tutor.
- What changed: The tutor became a guide inside the current learning scene rather than a general-purpose chatbot.
AI Asset Pipeline: Turn Generated Images Into Product Assets
- Observed problem: Generated images varied in style, aspect ratio, transparency, and UI fit.
- Reasoning: Each asset needed a role, constraints, acceptance decision, and integration location.
- Implementation: Role, size, style, and exclusions were defined first; only reviewed assets were connected to maps, stages, and character positions.
- What changed: Generated images became reusable map, stage, and character assets integrated into the live Flutter product.
Live Operating Scope
- 3,778 active learning bundles
- 11,334 persona contexts
- 11,334 concept lessons
- 15,112 dialogue scenarios
- 37,780 child content items in total
These numbers describe product-data operating scope, not users or measured learning effectiveness.