A music education platform built around the visual metaphor of a nine-branch menorah. Each branch represents a musical discipline. Each candle flame represents a level of achievement. Students, teachers, parents, and administrators each see a different interface over the same data. Practice journals, video submissions, teacher review workflows, and auto-generated achievement portfolios are all wired into a gamification system that rewards real progress, approved by a teacher, not self-reported.
The menorah is not decoration. It is the data model made visible. A student's progression record stores nine integers (one per branch, each value from 0 to 3). The SVG rendering maps each integer directly to a flame: no flame, small flame, medium flame, or a large animated flickering flame at mastery. The visualisation and the database are the same structure. Students interact with their learning by clicking branches on a candelabrum.
The nine branches cover the eight musical disciplines (Music Theory, Composing, Reading, Technique, Repertoire, Performing, Ensemble, and Ear) plus the ninth, the Shamash (the servant candle in a real Chanukiah), permanently lit and named Love of Music. It is always on. It represents the student's relationship to music that exists independent of formal achievement.
Teachers create goals linked to a specific student, branch, and level. Goals have a title, description, and optionally attached resources from the library. A goal starts active. The student logs practice sessions against it, selecting the goal, recording duration, mood (on a five-point emoji scale), notes, and resources used. When they have a recording ready, they submit it through the platform. The submission creates a video entity in the graph, linked to both the student and the goal, with its recording stored in MinIO object storage.
The teacher sees a review queue showing all pending submissions for their students. They play the recording, write feedback notes, and approve or reject. On approval, four things happen automatically: the goal status changes to approved, twenty points are awarded to the student, the submission enters the student's portfolio where parents can see it, and any relevant certificate trigger is checked.
Certificates are not issued manually. The system checks for certificate triggers automatically on each state change:
Reaching mastery (level 3) also triggers a sparkle animation on the menorah branch. Completing all eight branches triggers confetti across the whole menorah. These celebrations are not optional. They are wired into the state transition logic. The platform treats student achievement as an event worth marking.
New students do not start at level zero by assumption. The primer assessment (configurable by administrators) asks a series of questions about the student's background: instrument, years playing, prior formal training, ability to read music, experience with different repertoire. Answers map to level tags. The most common level tag across all answers becomes the student's starting level on relevant branches. Students begin where they actually are.
A school-wide view shows a grid of mini menorahs, one per student, with their name, tier badge (Bronze, Silver, or Gold), and total flame count. A spotlight at the top shows the student with the most flames earned in the current week. Teachers can filter to see only their assigned students. The wall is visible to all roles: it is a shared school community object, not a private view.
Multi-teacher delegation. A student can have multiple teachers, each assigned with specific metadata: role type (main teacher, support teacher), instruments covered, musical categories covered, and notes. The teaches link between teacher and student carries this metadata. The system queries it dynamically on each interaction to determine which teacher has authority over which domain for that student.
Acting on behalf. Teachers can log practice sessions on behalf of students, useful during lessons. The request carries an X-Acting-As header with the student's ID. The session is owned by the student; the teacher is the recorder. The authorisation model handles this distinction at the graph level.
Progress narrative generation. The parent view includes a prose summary of the child's progress, not a data table, but a generated sentence like "Harmony is making strong progress in Music Theory and is approaching level 2 in Reading." This is generated from the graph data, not manually authored. Parents receive language; administrators enter data.
Tech stack: React · TypeScript · Vite · MinIO (video storage) · Graph API (engage.re) · JWT with X-Acting-As delegation
ESRE Media runs its entire pipeline, partner network, and commission tracking on a system we built ourselves, on the same graph architecture. We are growing fast, and if you know organisations that need better digital systems, referral partners earn 15% on project delivery.
Find out how partnerships work