Scientia

Scientia is a an exploratory application, the goal of it would be to explore different way of teaching a subject so everyone can find THEIR teacher. It is first baby steps and on hold for a while, brb.

Technically it is single-page app that teaches six school subjects — physics, chemistry, biology, math, earth & space, and computer science — through short JSON-authored lessons, a quiz at the end of each one, and a layer of XP, levels, streaks, and badges wrapped around all of it. There's an AI tutor too: a chat panel next to a shared whiteboard that a language model can draw on, play tones through, and count on, on request. It runs entirely in the browser, ships as a static build, and went from an empty Vite template to this in four days.

What follows is a straight account of what's actually there, read from the code rather than the pitch, and then my own read on what's worth building next.

What's actually built

A content library, not yet a curriculum

Six subjects, each with its own accent color and a handful of topics. Lessons are plain JSON — paragraphs, facts, callouts, and occasionally an interactive block — rendered by one shared LessonContent component, so adding a topic never touches React code.

PhysicsChemistryBiologyMathEarth & SpaceComputer Science

Nineteen lessons, eighteen quizzes. Enough to prove every mechanic works end to end — content, quiz, XP, achievement unlock — but each subject is closer to a tasting menu than a course.

The gamification loop

XP, ten levels, a daily streak, fifteen achievement badges. The implementation detail worth noting: every rewarding action — completeLesson, submitQuiz, playWidget — is idempotent, keyed off subjectId/topicId (or /widgetId), and funnels through one withDerived step that recomputes level and re-evaluates all fifteen achievement criteria for free. That's a small, well-chosen piece of architecture: it means "reward the user once for X" is enforced in exactly one place, not re-implemented per feature.

Interactive widgets

Two so far — a shape explorer for geometry, a wave explorer for amplitude and frequency — both hand-drawn in SVG with no charting dependency. They're wired through a widgetRegistry keyed by an id that lesson JSON references directly, so a new widget is one component plus one registry line. The project's own docs are candid that this is a placeholder choice: reach for a real charting library "once the need is concrete," not before.

The AI teacher

This is the most ambitious piece, and the most interesting design decision in the codebase. The tutor doesn't get a general tool-use loop — it gets exactly four verbs: draw_shape, clear_board, play_tone, count_aloud. No code execution, no open DOM access. It's deliberately a puppet with four strings, which is the right call for a product aimed at kids: the ceiling on what can go wrong is set by the tool list, not by prompting.

It also runs against two interchangeable backends behind one ChatProviderinterface: Anthropic's API with a bring-your-own-key, or a local Ollama server. One conversation per lesson, persisted to localStorage.

The tool-restricted design is the single best decision in this codebase — everything else is standard SPA plumbing, but constraining the model's action surface to four named, schema-checked verbs is what makes an LLM in front of children defensible at all.

Architecture, honestly

There is no backend. Content is static JSON bundled at build time; user state — XP, streak, badges, chat history, API key — lives in localStorage via Zustand's persist middleware; deployment is vite build mirrored over FTP to a folder on a shared host. That's a completely reasonable shape for what this is today: a prototype proving out mechanics, not a service with users.

6 SUBJECTS

19 LESSONS

18 QUIZZES

15 ACHIEVEMENTS

2 WIDGETS

4 TEACHER TOOLS

2 MODEL PROVIDERS

0 BACKEND SERVICES

Where it's thin

1. The leaderboard isn't one. It merges your live XP into a fixed JSON seed file of fake names. There's no second player anywhere in this system.
2. Progress doesn't leave the browser. Clear site data, or open the app on a phone, and every badge and streak is gone. There is no account, so there's nothing to log back into.
3. The tutor has a real onboarding wall. A ten-year-old is not pasting an Anthropic API key into a settings panel, and "run a local Ollama server" is a non-starter outside a developer's laptop. As shipped, the flagship feature is mostly a demo for adults.
4. Breadth over depth. Three or four lessons per subject means a curious kid finishes a whole subject in one sitting.

Where I'd take it

Not a wishlist — an order. Each of these unlocks or de-risks the one after it, and I'd resist doing them out of sequence.

Put a real backend behind the same client

1. Accounts and cross-device sync are the load-bearing wall here — a genuine leaderboard, a parent or teacher view, adaptive practice, all assume progress lives somewhere other than one browser's localStorage. The store is already a single, well-isolated Zustand slice with a clean action surface (completeLesson, submitQuiz, playWidget); swapping its persistence for a thin API is a rewrite of one file, not the app.

Take the API key off the kid

1. The BYOK model is fine for a developer kicking the tires, indefensible for the intended user. A small proxy server holding one shared key, with per-session rate limits, turns the tutor from a demo into a feature — and it's the same backend from step one doing double duty.

Deepen before widening

1. Resist a seventh subject. Nineteen lessons across six subjects is a proof of concept; the near-term win is more topics per subject, not more subjects. The tutor itself is a plausible drafting tool here — have it draft new lesson JSON against the existing schema, then a human edits, rather than hand-authoring every block.

Feed quiz results back to the learner

1. quizResults already records score, correct count, and completion time per topic — the data for "you're weak on genetics, here's a five-question refresher" already exists and nothing reads it yet. Basic spaced repetition is a feature built entirely on data already being collected, which makes it cheap relative to its payoff.

Grow the widget catalog on purpose

1. Two hand-drawn SVG widgets is the right amount for now, and the docs already say so explicitly. The next few widgets can stay dependency-free; the one after that, needing real multi-series plotting, is the trigger to finally pull in a charting library — for that widget, not preemptively for all of them.

Make it installable

1. It's already a static, client-only bundle — the smallest possible step to a PWA. For the actual audience, a tablet icon that opens instantly with no connection matters more than it would for most web apps.

None of this is a criticism of the four days it took to get here — a tool-restricted LLM tutor, an idempotent gamification core, and a JSON-driven content pipeline built cleanly enough to extend without touching React is a strong foundation for that timeframe. The gap between "impressive prototype" and "thing a classroom actually uses" is entirely the backend that doesn't exist yet — everything on this list either builds toward that or waits behind it.