Let’s talk

Zeka Hub

A bilingual AI planning platform for teachers at an international school, grounded in 2,693 verified Turkish curriculum outcomes.

Category
Education, live product
Status
Live
Period
Apr to Aug 2026
Role
Design, build, operate
Stack
Next.js 16React 19TypeScriptTailwind CSS 4ClerkTurso (libSQL)Anthropic SDKSentryVitestGitHub ActionsVercel
The curriculum comparator showing Turkish MEB outcomes on the left and England National Curriculum outcomes on the right for a search on fractions, each with its code and a translation.

Context

Teachers at a bilingual international school were writing every lesson plan twice, in Turkish and English, and checking each against the Ministry of National Education curriculum by hand. Ask a model for a curriculum reference and it will always give you one, formatted convincingly, whether or not it exists. Those references end up on school records an inspector may read.

What I built

Zeka Hub is a Next.js application on Vercel where a teacher picks a year, subject and topic and gets a bilingual lesson plan, worksheet, quiz, assessment or phonics lesson, each citing real outcome codes. I extracted 2,693 MEB outcomes and 445 England National Curriculum outcomes from the source PDFs, recorded a SHA-256 for every document they came from, and built a single registry that owns the only valid set of codes in the system. Every generation passes through a verifier that drops any code not in the registry before anything is persisted, and an integrity check in CI fails the build if code and data drift apart.

Zeka Hub architectureCurriculum PDFs are built into a registry guarded by a CI integrity gate. Teachers authenticate with Clerk, the Next.js app injects real outcomes into prompts, Claude drafts, an outcome verifier admits only registry codes to the Turso database, and teachers confirm which outcomes were taught to produce coverage records.draftverified codes onlyMEB + UK curriculum PDFssha256 per sourceBuild scriptsextract · translate · verifyCurriculum registry2,693 MEB + 445 UK outcomesIntegrity gate in CIfails build on driftTeacherClerk auth · role from metadataNext.js app on Vercel30 pages · 55 API routesPrompt buildersreal outcomes injectedAnthropic APISonnet · Haiku by taskOutcome code verifieronly registry codes passTurso (libSQL)18 tables · daily backupTeacher confirms outcomesticks → coverage recordAdmin coverage viewsper plan, per outcome
Nothing reaches the database without passing the registry. Coverage comes only from outcomes a teacher has confirmed.
  • Data store
  • Model or agent
  • Check or gate
  • Person
  • External service

The same principle runs through phonics: the generator refuses to ask a five-year-old to read a word built from letter-sounds not yet taught that week. After each lesson the teacher confirms which outcomes it covered, and those confirmations, not the generations, drive the coverage dashboards.

Outcome

Live at one school, pre-rollout for the new academic year. Ten subjects across Years 1 to 8, 95 unit tests, a hallucination evaluation of 65 cited codes with none invented, and a measured cost of roughly $15 to $20 a month for twenty teachers. Daily database backups run from GitHub Actions.

What I’d do differently

Set up the production auth instance on day one; swapping after staff have accounts means migrating users. Validate before persisting from the start, because early invented codes were saved, counted, and fed back into the next prompt as context. And never keep two copies of a canonical map. Two subject maps diverged silently and a coverage percentage was wrong without a single error.

Screens