For school IT

What it’s actually built from.

The homepage is written for the teacher who has to stand in front of the class. This page is written for the person they forward it to.

The catalogues

Every teaching surface on the platform is a typed, purpose-built component rather than a free-form slide. These are counts of shipped, registered types.

25
classroom components — the projector-scale teaching moves, from opening objectives to a closing exit check.
83
student lesson components — quizzes, flashcards, puzzles, speaking and dictation, visual maths, charts, comic reading, hotspot images.
93
canvas board card types, across maths, science, language, diagrams and assessment.
85
of those card types the AI can author for you. That figure is enforced by a startup check — the app refuses to boot on a missing or duplicated spec — rather than estimated.

The algorithms, named

Per-student mastery
Bayesian Knowledge Tracing over a prerequisite concept graph, combined with a custom exponential memory-retention decay whose stability updates per answer. Repeated attempts on the same section are geometrically down-weighted. It is real adaptive-learning maths — not a neural network.
Spaced repetition
The SM-2 family, with two additions: lapse tracking, so a mature card that fails is flagged rather than quietly reset, and a same-day relearn step that brings a miss back in ten minutes instead of next week.
Next-step routing
One live policy: a deterministic rules-and-heuristics engine that scores candidate next steps from mastery state, misconception state and attempt history, then persists every candidate’s score for later analysis. New routing logic can be run in shadow mode — fully scored and logged, never shown to a student — before it is turned on.
AI generation
Every generated lesson plan is validated against a JSON Schema and against the target component’s own schema. On failure the system issues exactly one targeted repair attempt; if that also fails it raises a structured, human-readable error rather than shipping invalid content.
Narration
Authored once at publish time and cached as audio, keyed by a hash of persona, voice, language and text. The classroom runtime’s hot path never calls a model. Three text-to-speech providers are available; the classroom and the content studio share one integration.

What it runs on

In the classroom
A browser on the machine driving the projector. No student devices, no student accounts, and no app to install for a whole-class lesson. Class responses are teacher-mediated: teacher select, a manual poll count, or a webcam hand-count.
The live view
The projector updates over server-sent events, and re-reads state from the database on every cycle as a fallback, so an update always arrives within seconds even across multiple server processes.
Languages
English and German. Right-to-left layout infrastructure exists but no right-to-left language is enabled, so we do not claim it.
Face recognition
Optional, and used for one thing: identifying which student is at the board so the lesson can address them by name. Embeddings are stored server-side, scoped per teacher. It is not attendance, not assessment, and not attention monitoring.

The limits, stated

The things a due-diligence review would find anyway. We would rather you read them here.

  • One AI classroom voice ships today. The architecture takes more; only one exists.
  • There is no offline mode. If the connection drops mid-lesson, the projector run stops until it returns.
  • The classroom product records class-level outcomes only — got it, partial, confused. There is no per-student data row in it at all, by design.
  • We have a large automated test suite. It is not wired into a deploy gate, so treat it as “substantial coverage”, not “verified before every release”.
  • We are pre-revenue. There is no price list, no published uptime commitment, and no data-processing agreement on file yet.

Something here that decides it for you either way? Ask on the call →