Teaching "Good Data vs Bad Data" to Builder mode (ages 8–10)

Hook & Warm-Up

Get the class's attention and read the lesson's own opening line, with a bit of drama in your voice — it's a genuinely important rule and worth treating that way:

"Garbage in, garbage out — the most important rule in AI! If you teach AI with bad data, it learns bad lessons."

Ask the class: "Has anyone heard the saying 'garbage in, garbage out' before, maybe about computers in general?" A few students may have heard it applied to any computer program. Explain: "It's actually an old computer saying — it means if you put bad information INTO a computer program, you'll get a bad answer OUT, no matter how fancy the program is. Today we're seeing why that rule matters even more for AI than for regular computer programs — because AI doesn't follow a list of rules a programmer wrote. It LEARNS everything it knows from examples. So if those examples are bad, everything the AI 'knows' is bad."

Tell students they're going to be earning the Data Guardian badge today by learning to spot good data, bad data, and one of AI's biggest real-world problems: bias.

Before opening the app, run a thirty-second thought experiment: "Suppose you're training an AI to recognize 'a good student essay' by feeding it a thousand essays that all happen to be about basketball, because that's what the person collecting the data happened to have on hand. What happens when a student writes a brilliant essay about, say, cooking, or music?" Let a few students predict (the AI would likely rate it worse, not because it's actually worse, but because the AI's whole notion of "good" got shaped by one narrow topic). This sets up the idea that data problems aren't always dramatic or obviously unfair on their face — sometimes they're just narrow, and narrowness quietly becomes unfairness.

Main Activity

Work through the lesson's three scenes, pausing after each item to make sure the idea has landed before moving on.

Scene 1 — Data Quality ✨. These four ideas define what makes training data good or bad:

• ✨ Clean Data — Accurate, complete, and correctly labeled. Ask: "If half the 'cat' photos in a dataset were actually mislabeled dog photos, what would happen when the AI tried to learn?" (It would get confused about what a cat even looks like.)
• 🗑️ Dirty Data — Typos, missing values, duplicate entries. Point out this isn't just a hypothetical — real datasets used to train real AI systems often need serious cleanup before they're usable, and that cleanup work is a large part of what data scientists actually do.
• 📏 Enough Data — Use the lesson's own comparison: "Too little data is like studying only 3 math problems for a big test — you might get lucky, but you haven't actually learned the pattern." Ask how many practice problems they'd want before a real test (most will say "a lot") — that's the same instinct AI needs, just at a much bigger scale (often millions of examples).
• 🌈 Diverse Data — "If every training photo shows sunny weather, the AI won't recognize things in rain or fog." Ask for another example: what if a voice assistant's training data was all recorded by adults — would it understand a kid's voice as well?

Scene 2 — Bias in Data ⚖️. This is the heart of the lesson. Introduce it plainly: "Bias means the data doesn't fairly represent everyone — and when the data is unfair, the AI trained on it will be unfair too." Then walk through three real, documented cases:

• 👤 Face Bias — Some face-recognition systems perform noticeably worse on darker skin tones. This happened because the photos used to train them were mostly of lighter-skinned faces — the systems simply had far fewer examples to learn from for other skin tones, so their accuracy dropped for exactly the group they'd seen the least.
• 💼 Hiring Bias — In 2018, it was reported that Amazon had built and then scrapped an experimental AI tool for screening job applicants. It had been trained on ten years of resumes submitted to the company, a period when the applicant pool skewed heavily male. The tool taught itself to favor resumes that looked like the historical (mostly male) hires — it even downgraded resumes that mentioned things like "women's chess club." Ask the class: "Do you think the engineers who built this WANTED it to be unfair to women?" Guide them toward: probably not — the tool just learned exactly what was in ten years of real historical data.
• 🏦 Loan Bias — Some automated loan-approval systems, trained on decades of past lending records, have been found to repeat old unfair patterns — denying loans more often to certain neighborhoods, echoing discriminatory lending practices from the past. The AI isn't inventing this unfairness; it's copying a pattern that was already baked into the historical data.

Draw the throughline explicitly: "In all three cases, notice that the AI wasn't 'evil' — it was doing exactly what it was trained to do: find patterns in its data and repeat them. The problem was upstream, in the data itself."

Scene 3 — Fixing Data Problems 🔧. End with the encouraging, practical half of the lesson — this is real, active work people do:

• 🔍 Audit Data — Systematically check: what groups are missing or underrepresented? "If no elderly people appear in a health app's training photos, the app likely won't work as well for elderly users."
• ➕ Add Diversity — Once a gap is found, actively collect more examples from the underrepresented group to balance the dataset.
• 🧪 Test for Bias — Run the AI on different groups separately and compare accuracy. If it does noticeably worse for one group, that's a signal there's bias to fix.
• 👥 Diverse Teams — People notice different blind spots based on their own experience. A team where everyone has a similar background is more likely to miss a gap that would be obvious to someone with a different background.

Make the "Diverse Teams" point concrete with one more scenario: "Say a team builds a fitness app that tracks steps and suggests workouts, and every single person on that team is a young, able-bodied adult. Would it occur to them to test how well the app works for someone in a wheelchair, or an elderly user with a slower gait? Maybe, if they're thoughtful — but a team that already includes people with those experiences is far more likely to catch that gap before launch, not after users complain."

Read the lesson's own summary together: "AI is only as good as its data! Biased, incomplete, or low-quality data leads to unfair and inaccurate AI." Then have students complete the in-app practice round, sorting scenarios into biased vs. fair data situations, before moving into the quiz.

Discussion

• "If a company found out their AI was biased after it had already been used to make real decisions about real people, what should they do?"
• "Why do you think the people who built the Amazon hiring tool didn't notice the bias before it was already trained on ten years of data?"
• "Is it possible to collect training data that's 100% perfectly fair and complete? Why might that be really hard in practice?"
• "Can you think of an app or website you use that might be trained on data that doesn't represent everyone equally? What makes you think that?"
• "Why does having a diverse team of people BUILDING an AI system help catch bias that a less diverse team might miss?"
• "If you had to choose between a small, perfectly clean dataset and a huge, messier dataset, which would you pick, and what would you do to make your choice work well?"

Quiz Walkthrough

Wrap-Up & Extension

Close with: "You've earned the Data Guardian badge today, and you've earned it for a real skill: the ability to ask 'what data was this trained on, and who might be missing from it?' before trusting an AI's decision. That question is one of the most useful things you can carry out of this classroom."

Extension activity — "Audit a Dataset" mini-project: In small squads, give students a simple made-up scenario — for example, "an app that recommends study playlists, trained only on data from students who listen to K-pop and OPM" — and have them list: (1) what group(s) might be underrepresented, (2) what might go wrong for those groups, and (3) two concrete steps (borrowed from Scene 3) they'd take to fix it. Have each squad present their audit to the class in two minutes. This turns the abstract "audit data" idea into hands-on practice and stretches the 10–15 minute core lesson into a full class period.

To make the activity feel less abstract, give each squad a different scenario so the class hears several real cases side by side — one squad could get a study-playlist app, another a school-attendance camera system, another a lunch-menu recommender. When squads present, ask the rest of the class to try to guess the missing group before the presenting squad reveals it — this turns the wrap-up into a light competition and keeps everyone's attention through all the presentations, not just their own.