# Training AI PPT Case Pattern This pattern is for training, AI education, customer enablement, internal workshops, and method lectures that need a teachable slide deck. It is extracted from the old `31_CASE` training AI PPT case. The original topic, prompts, Codex JSON, output paths, and global text prohibitions are not carried forward. ## Use When Use this pattern when the target is: - a training deck, course deck, lecture deck, workshop deck, or AI education PPT; - a slide sequence that must support live explanation, pause, discussion, and later reuse; - a deck where each page is a teaching unit, not a video shot; - not a customer proposal whose primary goal is decision conversion. ## Core Difference Training PPT pages are not scenes. They are teachable units. Each page should answer: - What should the learner understand after this page? - What misconception or resistance might exist before this page? - What example, analogy, contrast, diagram, or exercise lowers the learning barrier? - What can the learner do, judge, or remember after this page? ## Learning Path Common sequence: ```text problem entry -> concept or model -> method frame -> example or contrast -> practice or migration -> summary and action ``` Not every deck needs all six parts, but the page order should behave like a learning path rather than a list of impressive points. ## Page Granularity Default rule: - one page solves one teaching goal; - slide copy stays sparse and editable; - speaker notes carry explanation, examples, and transition; - interaction is included when the page benefits from learner reflection; - abstract models need a diagram, matrix, loop, ladder, map, or other visible structure. Avoid one page trying to explain a concept, prove a case, give a method, run an exercise, and conclude the section at the same time. ## Local Page Spec For Video Workbench, put this in `slides/sNN/sNN-unit-spec.md` or use it as the basis for that file: | field | purpose | | --- | --- | | `unit_id` | `sNN` identifier used by local files | | `slide_role` | opening, concept, model, contrast, case, practice, summary, transition | | `teaching_goal` | what the learner should understand, change, or be able to do | | `core_message` | one sentence that gives the page its point | | `slide_copy` | editable title, subtitle, bullets, labels, or quoted line | | `layout` | comparison, triangle, matrix, timeline, loop, ladder, map, flow, dashboard | | `visual_asset_brief` | background, metaphor, concept visual, diagram base, or scene asset | | `speaker_notes` | how the instructor explains the page | | `interaction` | question, quick vote, reflection, mini exercise, or none | | `transition` | how this page connects to adjacent pages | | `review_focus` | what Codex should inspect during iteration | This is a local execution spec, not a final image prompt or JSON execution package. ## Slide And Asset Layering Keep these layers separate: | layer | owns | | --- | --- | | editable slide text | titles, subtitles, bullet points, labels, formulas, exact wording | | layout | structure that controls learner attention | | visual asset | background, metaphor scene, illustration, diagram base, icons, texture | | speaker notes | explanation, example, pacing, transition, instructor emphasis | | interaction | question or exercise that turns listening into retrieval or judgment | Generated images should not be asked to carry precise deck body copy by default. If the design needs diagram labels or visible text inside an image, document that choice in `execution-plan.md` or the unit review criteria. ## Speaker Notes Style Speaker notes should do three jobs: - explain the key concept in plain language; - give a concrete life, classroom, business, or product example; - bridge to the next page. Good notes are not page copy repeated aloud. They let the slide stay sparse while still giving the instructor enough material to speak for 1-2 minutes when needed. ## Common Page Patterns | pattern | use when | layout hint | | --- | --- | --- | | structural problem | establish why the topic matters | triangle, tension map, before/after | | misconception correction | replace a shallow belief with a better frame | split screen, false/true contrast | | model introduction | name and explain a reusable model | matrix, loop, layered diagram | | method frame | turn concept into steps or checks | flow, ladder, checklist, flywheel | | case comparison | show how AI changes a task or judgment | traditional vs AI-enabled | | practice page | make learners apply the frame | prompt, scenario, quick exercise | | summary chain | close the logic path | timeline, chain, staircase, map | "Traditional vs AI-enabled" is especially useful for AI training case pages, but it is a pattern choice, not a global rule. ## Review Dimensions Review drafted or generated pages against these dimensions: | dimension | pass condition | | --- | --- | | teaching goal | one page has one clear learner outcome | | copy density | slide text is sparse enough to scan and edit | | layout clarity | structure helps understanding rather than decorating the page | | speaker notes | notes explain, exemplify, and transition | | asset layering | visual assets do not replace editable slide text by accident | | interaction | any question or exercise has a clear teaching reason | | sequence | the page advances the learning path | | live usability | an instructor can pause on the page and teach from it | ## Small-Batch Strategy Do not build the full deck visually before validating the teaching system. Pick representative pages: - one opening or problem page; - one abstract model page; - one method-frame page; - one case-comparison page; - one practice or summary page if interaction or closing tone is uncertain. Record the selected batch in `execution-plan.md`, then track page-level status in `slides/slides.md`. ## Abstracted Example Shape ```md ## s08 Unit Spec - slide_role: model introduction - teaching_goal: Learners understand that the model is a decision aid, not a decorative framework. - core_message: A usable model changes what people can notice, compare, and improve. - slide_copy: - title: short model name - subtitle: one-line use claim - bullets: three editable labels or dimensions - layout: center matrix with one highlighted region - visual_asset_brief: clean diagram base with subtle learning-path motion; exact labels remain editable in the slide layer - speaker_notes: - define the model in plain language - give one concrete classroom or work example - explain why the next page moves from model to use case - interaction: ask learners which dimension they currently under-observe - review_focus: - model structure is legible - page is not crowded - notes can support live explanation ```