Container taxonomy — data model rework

The example throughout: a teacher assigns practice on equivalent ratios, plus the grape-catch mini. Here's how today's schema holds (and fails to hold) that.

Three problems: (1) the KC table is a container wearing a pedagogy costume; (2) assignment slots point at a raw variation and the container is recovered by indirection; (3) sequences (minis/decks/testlets) don't fit at all — they get crushed into one mega-question. And resources hang off to the side, unable to participate in any of it.

Same rows, honest names. knowledge_components → question_containers (a variation set: members are interchangeable, serving picks ONE) and assignment slots point at the container, not a raw variation.

A question_container says "serve ONE of my members" (variations, unordered). The new sequence_container says "serve ALL of my members, in order" (steps: questions and resources). That one sibling is the entire multipart/deck/mini/testlet model. Fixed depth, every arrow a real foreign key:

questions and responses keep their exact shapes — questions gain nothing, responses still attach only to the served question. The mini-level rollup stays a projection (now: sequence #70 → items → containers → served-question responses).

Click a student. Watch one rule run everywhere: slot → container → serve ONE member — for the plain practice slot AND for every step inside the mini.

Sections 1–5 model everything BELOW the assignment. Above it, today's schema has exactly one grouping primitive — modules — while the curriculum being authored (NY Grade 6 Math) has a real tree: unit → section → lesson, with the lesson owning four assignments by role (ONE interleaved building-blocks assignment + the three synthesis assignments) and the unit owning the unit test. Inside an assignment, items carry their own role (instructional | practice | check) — that item-level role is what lets building blocks be one assignment instead of three (see the #210 table below). Naming (settled 2026-06-11): the entity is called lessons — the domain word wins; teachers and the scope & sequence already say "Lesson 5," and an invented term would tax every conversation forever. The collision with today's config.mode: "lesson" resolves by deprecating that mode value, not by renaming the entity: a deck or mini-series was never a "lesson" — it's the INSTRUCTIONAL part of one — so the item role is instructional and the mode value dies with no successor (mode keeps only how-it-runs values: sequential, assessment, mastery, survey, collab). Bonus: checkType: "lesson" becomes correct — it finally points at a real lesson. The Open edX lesson properly read: one name per thing, aligned WITH domain language — calling it "cluster" internally while every human says "lesson" would have re-created their mess.

Same disease as section 1, one level up: the module table is a unit wearing a classroom costume, and everything the curriculum knows ("this is the mastery check of Lesson 5 in Section B of Unit 0") has nowhere to live. checkType: "section" sitting in assignment config today is the fossil of someone needing section-level attachment with no table to put it in.

Position is data, identity is not: display numbering ("Unit 0", "Section B", "Lesson 5") derives from position; slugs/external_ids never encode it. Reordering is an UPDATE, not a cascade of renames — the same rule the authoring repo already enforces for its directory names.

Why role lives on the item: today the only way to say "this is practice" vs "this is a check" is the assignment-level mode — which is exactly why the curriculum first looked like six assignments per lesson. With role on assignment_items, per-item behavior (check items gate + lock; practice retries freely; instructional items teach) coexists inside one assignment, and the assignment's mode shrinks to pure orchestration — how the assignment RUNS (sequential, assessment lockdown, mastery scheduling, …). mode: "lesson" is deprecated with NO successor: it answered "what is this," and that job moved to item roles + sequence templates. (Legacy Sidekick lessons keep it until the player keys off roles/templates; then the enum value dies. The same fate eventually awaits mode: "check", but checks have live mastery behavior keyed on mode — later cleanup, not now.) A "block" needs no table: it's the span from one instructional item to the next, and remediation ("check at position 4 failed → re-serve positions 1–3, fresh variations") is just reading the order. Open question: synthesis could collapse the same way (one assignment: deck → practice → mastery check) — kept as three pending the product call on independent scheduling.

Why LOs are entities, not prose: the builder flow gives them three structural jobs — CTA tags which KCs are primary per LO; LOs link to standards (with "stock LOs" generated for any KC not covered through an LO, so the KC→standard chain never breaks); LOs tie to the lesson's assignments. Edges need identity; a markdown bullet can't hold them. Open question (flagged in the Curriculum Building doc itself): do LO↔concept edges carry parameters, the way item↔concept edges carry weights (3 gatekeeper / 2 required / 1 supporting)? Undecided — the table ships without params and they're additive later.

External precedent here too: every major LMS standard splits along this exact seam. Common Cartridge / SCORM: a package is files + a manifest whose <organizations> tree gives meaning to generic resources — that's the repo layer, standardized. Open edX OLX: typed, fixed-depth course → chapter → sequential → vertical at runtime — the closest large-scale analog to units → sections → lessons, holding up for a decade. Nobody serves students out of a cartridge; platforms import it into their own typed model. The standards ecosystem already agrees with the two-layer split.

Two forks are open: D1 (below the assignment) and D7 (above it, added 2026-06-11). D2–D4 are defaults that ride with D1 (expand to challenge one); D5–D6 are already running in the prototypes.