video-workbench/docs/cases/training-ai-ppt-case.md

# 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
```