--- title: "Top-Down Plan — Bloom's Taxonomy as the Driver" description: "\"GO to the page, read/analyze the page content. If the page has a good enough amount of teachable content that is relevant to the skill being taught, then use and organize the page content into a sequence of activities…" created: 2026-10-22 updated: 2026-10-22 authors: ThinkingCap topics: [Research Development] status: published canonical: https://console.thinkingcap.com/guest/Research-Development/Thinking-Cap-Everywhere/BLOOM-TOP-DOWN-PLAN --- # Top-Down Plan — Bloom's Taxonomy as the Driver ## 0. The goal (Dan, 2026-10-15 — the north star, verbatim) > "GO to the page, read/analyze the page content. If the page has a good > enough amount of teachable content that is relevant to the skill being > taught, then use and organize the page content into a sequence of > activities to teach the user the skill on the page in the most > straightforward manner. The end goal should be that the activities give > the user a solid and thorough understanding of the topic via the material > on the page, so much so that they should be able to successfully pass an > examination demonstrating their understanding of the skill to qualify/earn > them a certification for said skill." **Operationalized, the pipeline this whole project serves:** ``` PAGE → read & analyze (bottom-up, built and measured) → teachable? (gate + Bloom inventory: enough substance, at enough levels) → SEQUENCE of activities, ordered by cognitive level (remember → understand → apply → analyze → evaluate, most straightforward path first — never harder than needed) → thorough understanding of THE PAGE's material → examination passed (proof of understanding) → CERTIFICATION for the skill ``` Everything else in this document — the objective selection, the understandings, the strategy table, the translation gates, the Bloom-shaped diagnosis — exists to serve that sequence and that exam. The activities are not the product; the certification is. A sequence is done when the user can pass. **Status:** PLANNING ONLY (Dan, 2026-10-14: "So far we've been doing work with a bottom-up approach; look at Bloom's taxonomy and let's also plan out a top-down approach. Just planning, no implementation yet.") **Series:** follows PLANNING.md → PLANNING-v2.md → PHASE-0-PLAN.md → FINAL-PLAN.md → LEARNING-EXPERIENCE-GENERATOR.md --- ## 1. The two directions, and why both matter **Bottom-up (built, benchmarked):** page → text → sentence anatomy → clause frames → knowledge kinds, measured against an LLM gold set (currently: welding 46.6%, photosynthesis 38.1% sort accuracy, ratcheted up-only). **Top-down (this plan):** objective → understandings → activity → assessment. Bloom's taxonomy supplies the objective language: what should the learner be able to *do*, and at which cognitive level? **Where they meet:** the knowledge model is the shared substrate. Bottom-up builds it deterministically and measures it. Top-down consumes it: objectives are expressed over it, activities are generated from it, and assessment writes back into it. Neither direction works alone — bottom-up has no purpose, top-down has no material. ## 2. Bloom's taxonomy, operationalized for this system The 2001 revision: **six cognitive process levels** × **four knowledge dimensions**. The two-axis structure maps unusually well onto what we have: | Cognitive level | The learner can… | Our knowledge kinds that serve it (substrate) | |---|---|---| | **1. Remember** | recognize, recall, name | `definition`, `vocabulary`, `formula`, `fact` (atomic) | | **2. Understand** | classify, exemplify, infer, explain | `example`, `non-example`, `application`, `concept`, `historical-context` | | **3. Apply** | execute, implement, use | `process`, `procedure`, `rule` (in-situation) | | **4. Analyze** | differentiate, organize, attribute, compare | `relationship`, `cause`, `effect`, `constraint`, `exception`, `evidence` | | **5. Evaluate** | check, critique, judge | `rule`, `principle`, `warning`, `evidence`, `misconception` | | **6. Create** | generate, plan, produce | *(no source kind — this is the learner's construction, seeded by understandings)* | **Knowledge dimension** (the other axis) we get nearly free: factual (facts/definitions/vocabulary), conceptual (principles/relationships/cause), procedural (process/procedure/rule), metacognitive (misconception/warning + the learner's own diagnosis later). **The determinant already in the pipeline:** several Bloom levels have deterministic text cues we already emit — `definition`/`vocabulary` ≈ Remember, `example`/`application` ≈ Understand, `imperative-candidate` form ≈ Apply, `relationship`/`cause` ≈ Analyze. A Bloom tagger is a rule table over the sorter's output, not a new engine (see §4, layer 1). ## 3. The knowledge → Bloom → activity table The pedagogical engine's core lookup. Each row is a generation path; the H5P.Everywhere instance kinds are the targets (spec §10+). | Bloom level | Substrate kinds | Activity form (H5P-style) | Built from | |---|---|---|---| | Remember | definition, vocabulary, formula | flashcard, term↔def match, fill-the-blank | term = subject, def = complement (M23 signatures) | | Remember/Understand | fact, historical-context | retrieval quiz, timeline ordering | fact candidate + provenance sentence | | Understand | example, non-example, application | classify-the-instance, sort-the-cases, label-the-diagram | example candidates + their anchors | | Apply | process, procedure, rule | sequencing (order the steps), guided-procedure, predict-next-step | process/procedure candidates + sequence words | | Analyze | relationship, cause, effect, constraint, exception | compare/contrast matrix, causal-chain build, find-the-error, predict-the-outcome | relation anchors (M25) + frames (subject/predicate/complements) | | Evaluate | rule, principle, warning, evidence, misconception | judge-against-criteria, critique-the-claim, evidence-or-opinion | rule/evidence candidates + their contexts | | Create | (understandings + author) | construct-an-explanation, design-a-solution, author-a-question | essential understandings + essential questions (§4 layer 3) | The **author disposes** at every row: AI proposes, human selects/edits (spec §4, translation layer). ## 4. The top-down pipeline — missing layers, in build order **Layer 1 — Bloom tagging (deterministic, cheap).** Rule table over sorter output: kind → candidate Bloom level(s), plus text cues (imperative form, sequence words, comparative markers). Same discipline as the definition signatures: named rules, honest unclassified. Extend the Knowledge tab with a **Bloom axis** (group by level, then kind inside) so Dan can eyeball it on the test pages. **Layer 2 — Objective selection (author-facing).** The author picks target Bloom level(s) for a page/section. The system lists the substrate available at each level ("this page has 6 definitions, 14 facts, 3 processes, 9 relationships") — the Knowledge tab's counts become the objective's menu. **Layer 3 — Understandings (LLM-side, the spec's §6–7).** Essential understandings + essential questions distilled from the sorted model. This is where the **essential questions** come from (Dan's earlier "questions" — Wikipedia prose contains almost none; they are *generated* here from understandings, not extracted). Deterministic input, LLM judgment, provenance back to entities. **Blocker carried over:** Tally routing + tool spec (Doug). **Layer 4 — Strategy selection (deterministic).** Bloom level × knowledge kind → activity form, from the §3 table. Doug's "tree of if statements" applied to pedagogy — free, testable, reviewable. **Layer 5 — Translation (LLM drafts + deterministic gates).** LLM drafts instance configs (question, distractors, feedback) from the substrate + objective; deterministic gates validate: schema-valid (semantics.json), answerable-from-source (provenance check — a question whose answer isn't in the source never ships), difficulty-matched-to-level. **Author disposes.** **Layer 6 — Assessment loop.** Learner attempts → xAPI results (the estate's existing spine) → diagnosis by Bloom level (which levels fail, which knowledge entities are weak) → adapt/reinforce. The runtime exists (H5P + LRS + gradebook projector); the Bloom-shaped diagnosis is new but small. ## 5. Honest inventory — what exists for each layer today | Layer | State | |---|---| | 0. Extraction (page → objects) | ✔ built + e2e | | 1. Bloom tagging | ✘ not built — but ~60% of its cues already exist as kinds/forms | | 2. Objective selection | ✘ not built — the Knowledge tab's counts are the prototype | | 3. Understandings | ✘ not started — blocked on Tally routing/tool spec (Doug) | | 4. Strategy | ✘ not built — table above is the spec for it | | 5. Translation | ✘ not started — needs Tally; gates are cheap | | 6. Assessment | ~ runtime exists (H5P/LRS/gradebook); Bloom-shaped diagnosis unbuilt | ## 6. Measuring top-down the way we measured bottom-up The gold-benchmark pattern transfers directly: 1. **Extend the gold set** with a Bloom label per sentence (same LLM-curated process as M24) → `docs/gold/.bloom.json` 2. **Bloom-tagging accuracy** becomes the second benchmark number: per-level precision/recall + confusion list, ratcheted 3. Later, **activity quality**: author acceptance/edit/reject rate of LLM-drafted instances — the translation layer's measured number ## 7. Open decisions for Dan 1. **Bloom tagging:** deterministic cue rules first (measured against a Bloom gold set), or straight to the LLM for tagging? (Recommendation: deterministic first, benchmark it, LLM only where the number says we lose.) 2. **Knowledge tab axis:** keep kind groups and add a Bloom-level group toggle, or replace kind groups with Bloom groups? 3. **First activity form to build:** retrieval practice (Remember/Understand — cheapest, most substrate) or sequencing (Apply — showcases the process extraction)? 4. **Where Bloom tags live:** on the sentence (like kinds), on the knowledge entity (the M15 artifact), or only at the activity instance (generation-time)? 5. **Essential questions scope:** per section, per page, or author-specified topic? ## 8. How this lands against Doug's boundary Nothing in this plan crosses the deterministic/LLM line drawn in FINAL-PLAN.md: layers 1, 2, 4, 6 are deterministic and free; layers 3 and 5 are the only LLM calls, both routed through Tally Max when Doug's routing lands, both gated by author review. The bottom-up half we already shipped is exactly the deterministic substrate this plan assumes. --- *End of plan. No implementation committed or started. Next step when Dan says go: pick the open decisions in §7, then layer 1 (Bloom tagging + benchmark extension) is the cheapest first build.* --- # Appendix A — Layer 1 as BUILT (2026-10-15, v0.30.0, drop #2477) Layer 1 (Bloom tagging) is no longer a proposal — it shipped, and it is measured. ## The tagger (`src/understand/bloom.ts`) Deterministic kind → level mapping with named rules (each verdict line shows the rule that fired): | kind | Bloom level | |---|---| | definition, vocabulary, formula, historical-context | **remember** | | example, non-example, application, concept, process *(described mechanism)* | **understand** | | procedure | **apply** | | relationship, cause, effect, constraint, exception, evidence | **analyze** | | rule, principle, warning, misconception | **evaluate** | Two refinements on top: - **Imperative escalation** — an imperative form is `apply` whatever its kind ("Apply the filler rod"). - **Fact splitting by predicate** — a fact with an action predicate (explanatory work) is `understand`; only be/have-carried facts are atomic `remember`. 'create' is never assigned (the page never creates), and an unclassified sentence stays honestly untagged. ## The second benchmark All 684 sentences of both test pages were LLM-labeled by Bloom level (`docs/gold/.bloom.json` + reviewable `.txt`). A verification pass caught a **calibration split** between the two pages' labelers (one read explanatory facts as remember, the other as understand) — photosynthesis was re-labeled under an explicit style guide: *remember = atomic recall only (dates, names, term identity); explanatory facts = understand*. Welding already matched. `src/understand/bloomBench.ts` scores the tagger against the labels: overall accuracy, per-level precision/recall, and an off-by-one adjacency rate (misses exactly one level off). Floors ratcheted in `test/bloomBench.test.ts`. **First measured Bloom accuracy: welding 48.4%, photosynthesis 57.6%** (floors 0.48 / 0.57 — up-only from here). ## What it changes (honest) 1. The page is now readable as a **course menu** — the Bloom tab shows which cognitive levels a page can feed, with counts, before anything is built. 2. "Does this page deserve activities?" now has a second clause: *of what kind* — a page with no analyze-level material cannot host an analyze-level objective. 3. **Layer 2 (objective selection)** now has its data and its number: the Knowledge tab's counts become the target menu, and Bloom-tagging accuracy is benchmarked the same way the kind accuracy is. Deliberately not done: the activity-validity *judge* (parked pending Doug's specifics), and any generation. --- # Appendix B — The Process, End to End (2026-10-15) The full flow from page arrival to certification, each step marked by who does the work: **DET** (deterministic — free, instant), **LLM** (small paid calls), **AUTHOR**, **LEARNER**, and its build state. 1. **Arrival — DET *(built)***. Chip mounts; the gate scores the page (rich / thin / fluff with named reasons). Not rich → honest stop. 2. **Extraction — DET *(built)***. One pass, computed once: main content, section tree, objects, media, sentences. 3. **Anatomy — DET *(built)***. Tokens, word classes, phrase chunks with heads. 4. **Frames — DET *(built)***. Subject / predicate / complements, voice, clause boundaries. 5. **The sorter — DET *(built)***. Knowledge kinds with provenance (definition, fact, process, relationship, cause, rule, warning, example…). 6. **Bloom tagging — DET *(built)***. Cognitive level per sentence (remember → evaluate). 7. **The inventory — DET view *(built)***. The page as menu: counts per kind and level, every item traced to its sentence (inspector tabs: Tree | Kinds | Bloom). 8. **Objective — AUTHOR *(partially planned)***. Skill + target level declared; the fit-check answers "does this page support it?" and hands over the substrate menu. 9. ~~Understandings — LLM~~ → **DEFERRED to v2** (see lean review below). 10. **Sequence design — DET *(planned)***. The strategy table (level × kind → activity form) lays out the ramp, most straightforward order first. 11. **Translation — split *(planned)***. Mechanical forms templated deterministically (term-match, sequencing, classify-by-kind — zero LLM); LLM drafts only free-language items, over provenance-checked slices. Deterministic gates before anything ships: schema-valid, answerable-from-source, level-correct, distractor sanity. 12. **Author review — AUTHOR *(planned)***. AI proposes, human disposes (per item or per set). 13. **Sequence runtime — LEARNER + DET *(estate exists: H5P/LRS)***. The ramp runs in order; attempts stream as xAPI to the LRS. 14. ~~Diagnosis (adaptive)~~ → **DEFERRED to v1.1** — v1 is a fixed linear ramp; adaptivity (drop/remediate/advance) follows. 15. **Examination — LEARNER + DET *(planned; needs Doug's validity specifics)***. Items at the target level; pass rule = threshold + level coverage. 16. **Certification — DET + estate *(planned)***. Pass → certification xAPI statement. The goal, reached. ## The lean review (Dan's audit: accomplish / why necessary / verdict) - **Gate** — stops all downstream spend on worthless pages. **Keep — free.** - **Extraction** — foundation for everything downstream. **Keep — free.** - **Anatomy** — which words do what; unreadable without it. **Keep — free** (one pipeline with extraction, not an independent task). - **Frames** — relations, definition terms, answer/distractor validation. **Keep — free.** - **Sorter** — the typed substrate everything is chosen from. **Keep — free.** - **Bloom tagging** — the ramp; "most straightforward order" and exam-level targeting ride on it. **Keep — free.** - **Inventory** — a *view* of 1–6, not computation. **Keep as a view.** - **Objective** — intent; someone must aim. **Keep — human, cheap.** - **Understandings (LLM)** — compression to essential truths. **CUT for v1**: the substrate already carries the high-value entities with levels; generate straight from entities + strategy table. Defer to v2. - **Sequence design** — the ramp itself, deterministic. **Keep — free.** - **Translation** — **SPLIT**: mechanical forms (term-match, sequencing, classify-by-kind) are deterministic templates needing zero LLM; only free-language items justify drafting (~40% of forms). - **Author review** — a certification needs an accountable human on the items. **Keep for v1** (sampling later, once measured acceptance is high). - **Sequence runtime** — the product itself. **Keep — estate exists.** - **Diagnosis (adaptive)** — **CUT for v1**: a fixed linear ramp with the exam at the end is viable; adaptivity lands in v1.1. - **Examination** — the proof gate; the goal IS the certification. **Keep.** - **Certification event** — the credential record. **Keep — free xAPI statement.** ## The lean outcome Two LLM-touching steps cut (understandings, adaptive diagnosis), one halved (translation mostly templated). What survives: **gate → extract → analyze → sort → Bloom → objective → strategy → template + minimal drafting → author review → sequence → exam → certification** The LLM is reduced to exactly one job: **drafting free-language items over provenance-checked substrate** — the only work in the pipeline that genuinely needs it, at the only point where the decision tree runs out.