How it's built

Operating principle

One rule governs the whole system: content is data, not code. A lesson is not a hand-built page — it's a lesson row that names a stage-arc format and the skill it builds, with one row per stage and optional scene rows beneath. Cloning a cohort is seeding a new row, not copying a codebase. This is what keeps thirty-plus lessons consistent and lets the curriculum be audited as a database rather than read as prose.

Architecture

SvelteKit (Svelte 5, runes) on the front; PostgreSQL as the system of record; Vercel for hosting. Every public route is prerendered at build time — the server reads the database while the site compiles and ships static HTML. There is no runtime database connection on the public surface, so there is no live attack surface against the data and no per-request latency: the stakeholder reading this page is served a static file.

• Render: SvelteKit SSR → static prerender (`prerender = true`).
• Data access: typed query functions, never inline SQL in routes.
• Build: one command compiles the whole catalogue from the database.

Source of truth

All course content lives in one Postgres instance, organised into five workspaces — theming, knowledge, activities, courses, and lessons. There are no exported JSON files, no spreadsheets feeding the build, no second copy that can drift. A fact is true because a row says so; the website is a projection of that row. When a lesson changes, the change is a database write, and the next build reflects it everywhere it appears — curriculum, calendar, lesson runner — with no manual sync.

Data model

Content is tiered to separate what's reusable from what's cohort-specific:

• Library tier — lessons, stages, and scenes that any cohort can run. Authored once, reused across courses.
• Cohort tier — a specific course's identity, schedule, team, partner, and the sequence in which it runs library lessons. It holds ordering and branding, never duplicate lesson bodies.

Relationships are real foreign keys and junction tables — the curriculum is assembled by joining tiers, not by copying content down into each cohort. Promoting a one-off into the shared library is a deliberate, gated step, not an accident of copy-paste.

Theming system

Every visual surface is driven by a central theming cascade: a named aesthetic resolves a full set of CSS custom properties (palette, type, surface, motion) that every component inherits. Switching the aesthetic re-themes the entire site in place — including this document, which is pinned to a clean Editorial theme for readability. There is no per-app styling fork; one cascade, declared once, rendered everywhere.

AI integration

AI is taught as a capability, not a novelty. Each AI-skill is a row that carries the prompt patterns, technique, and a build exercise students practise against — so the AI work is structured, repeatable, and version-controlled like any other content. Students don't watch a demo; they run the capability, with per-lesson prompt variables applied at render time.

Pedagogy, engineered

The teaching model is explicit in the data. A lesson commits to a named stage-arc format and the quantified skill it builds, and ends in a real artefact — because the 2026 job market hires on delivery evidence, not credentials. Students are treated as adults: they argue, take hard cases on real numbers and named thinkers, and lose an argument well. The rubric rewards rigour in frame, not agreement. That stance is a design decision, and it's enforced structurally — every lesson stage is bound to an activity, and a stage with no activity doesn't render.