A learning app built around the evidence behind the answer. Designed and used by a parent, built with AI.
I design the learning workflow and direct AI collaborators who implement and review it. My family uses IvyBloom to connect teaching, practice, writing feedback, and learning records. Comprehension prompts add evidence about understanding; a correct answer or a time total alone cannot establish mastery. The walkthrough below is a historical demonstration on synthetic data.
From a curriculum source to a lesson a child can use
The current work connects curriculum sources, teaching cards, practice, writing corrections and revision, and the learning record. Recent reviews found limits in question quality, coverage reporting, and access to scheduled lessons. The linked stories describe those findings and their evidence limits; they do not imply every September change has been deployed or that learning gains were measured.
Everything shown is a 100% synthetic student— “April Brown,” a fictional grade-11 competitive climber — on a throwaway database. The demo's assessment changes and transcript illustrate the workflow, not measured learning gains. My family's use of the product is a separate claim from the fictional record shown here. This older recording is not a current feature or deployment audit.
Homeschool parents spend thousands on curriculum but still can't tell if their child truly mastered the material — and now there's a sharper fear: a kid uses AI to produce perfect work and learns nothing. When it's time to apply to college, years of real learning are scattered and have to be rebuilt into a record from scratch. The hard part isn't generating lessons — it's proving the learning is real and earning a parent's trust in what an AI puts in front of them. IvyBloom is built around that boundary: use assessment records, check teaching material, and ask for additional evidence of understanding. These checks can also fail and need review; they do not guarantee that every fact is correct or every accepted response proves mastery.
Keep the evidence behind the learning visible.
The platform brings assessment records, reviewed teaching material, and checks for understanding into one workflow. Those are separate pieces of evidence, each with limits. A comprehension response can prompt a closer look; it cannot guarantee authorship or mastery. The parent remains responsible for interpreting the record.
How IvyBloom does this — the assessment modeling, the generation pipeline, and how the integrity layer decides — is deliberately not published. It's the product's competitive core, and this page has been scrubbed of it on purpose. If you're evaluating my work and want the deep dive, I'm happy to walk through it in a conversation.
How the system works — and why it's built this way.
This historical walkthrough uses a fictional student to show how assessment inputs, teaching, practice, writing feedback, and learning records connect. It illustrates a workflow, not evidence of a real student's progress.
The assessment history in the demo is synthetic. It shows how multiple observations can inform the next learning task. The displayed changes are invented inputs, not measured learning gains or evidence that IvyBloom caused improvement.
A flag routes the demonstrated work to a comprehension check. That adds evidence for review; neither a flag nor a correct follow-up answer proves authorship or mastery.
The walkthrough shows teaching material being checked. A passing check can still leave the wrong learning task; the published science-question story explains one failure and the judgment it changed.
Draft narratives and portfolios are raw material for a parent to review and rewrite. A polished synthesis cannot replace its source evidence or the author's judgment.
The transcript, assessment values, and application-planning examples shown here belong to the fictional demo student. They illustrate record and sharing controls, not a real three-year academic transcript or evidence of an admissions outcome.
My family uses IvyBloom. This older synthetic walkthrough illustrates the product's design; it is not a current audit of every feature, billing path, or deployment.
The four calls that define the system.
Understanding needs evidence
Comprehension prompts give a parent something to inspect. They do not certify mastery or determine authorship on their own.
Checks have limits
The science-question review documents where valid-looking material tested the wrong skill. Content checks do not eliminate model errors.
Synthetic assessment history
The demonstration uses invented assessment values to illustrate targeting. Those values are not a child's results or a measured learning benefit.
Family use, separate from the demo
Real use motivates the design. The fictional walkthrough makes that design inspectable without presenting a child's private learning record.
- 01Designed & architectedthe platform — the adaptive engine, the trust boundary around generated content, the academic-integrity layer, and the admissions suite.
- 02Directedthe AI build — wrote the specs, set where the model may and may not be trusted, reviewed the output, and decided what shipped. (Halted a finished feature when AP-level chat would have overloaded absolute beginners — domain judgment over code.)
- 03Validatedit end-to-end — audited the billing-bypass paths before features shipped, caught the logic bug that wrongly auto-stopped an athlete for switching to another study tool, and QA'd on the real running app, not “it compiles.”
This is how I work: design the system, draw the trust boundary, own the verification.
If you're evaluating someone to design or operate AI-augmented systems, this is a representative piece of how I think. There's more in the collection.