AIQ
AIQ
Part of the AI or Not? The Game lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · ⚡ Architect (15–18)
Hacker mode students respond to being told their assumptions are about to be tested — frame this as a challenge to their existing tech literacy, not a beginner lesson, since many will already have opinions about "what counts as AI" from social media and gaming.
"Not everything that seems smart is AI, and not everything that seems simple is AI-free. Let's challenge your assumptions with some edge cases that trip up even tech-savvy people."
Open with a quick, low-stakes competitive round to match the energy of Nova's leagues: put four or five example names on the board — calculator, Gmail spam filter, traffic light, phone battery manager, chess engine — and have students individually and silently write "AI" or "not AI" next to each before any discussion. Don't reveal answers yet. Tell them you'll come back to this list at the end of the lesson and see how many they'd change.
State the actual test precisely, since this age group can handle — and benefits from — more exact language than "smart helper":
"The defining criterion is: does the system improve through exposure to data? Rule-based systems — a calculator, a traffic light on a timer, an old chess program with hand-coded strategy — don't count, no matter how complex their rules are. Systems that learn patterns from data — spam filters, recommendation engines, predictive text — do."
Flag the traffic-light and chess-engine examples as intentionally tricky: a traffic light cycling through a fixed timer is not AI, and a very old-style chess engine that just searches through possible moves using hand-written rules (no learning involved) is a genuinely contested case even among professionals — some call rule-based systems like this "AI" in the historical, symbolic-AI sense, but this lesson's test is about machine learning specifically, which is what the term almost always means in current usage.
Worth naming out loud before moving on: this ambiguity isn't a flaw in the lesson, it's a real property of the term "AI" itself. "AI" is an umbrella that has, at different points in computing history, referred to rule-based expert systems, search algorithms, and today's data-driven machine learning — all legitimately called "AI" by researchers in their respective eras. The test this lesson teaches ("does it learn from data?") is really asking a more specific question: is this machine learning, which is the branch of AI responsible for almost everything students will encounter labeled "AI" today.
Work through the app's three rounds, but push past "AI or not" into "why, specifically" for each item — this age group should leave able to name what data a system is likely learning from, not just its label.
Calculator vs. auto-DJ: "A calculator's logic is fixed at design time — the same input always produces the same output, with zero adaptation. An auto-DJ feature, like the one in Spotify, is doing something categorically different: it's inferring your likely mood and preferences from listening history and using that to select and blend tracks — its output for the 'same' input (you, right now) can change as it learns more about you over time." Ask: "What's the actual signal Spotify's DJ is probably learning from?" (Expected answers: skip behavior, replay behavior, time of day, genre patterns, playlists you've made.)
Digital clock vs. voice-changer filter: "A digital clock is arguably the purest non-AI example in the whole lesson — it's literally just counting oscillations of a quartz crystal at a fixed, physically-determined rate. A real-time voice changer, by contrast, typically needs a model that's learned the relationship between raw audio and vocal characteristics like pitch and timbre well enough to transform one voice convincingly into another, in real time. Ask students why real-time matters here — it's a much harder engineering constraint than transforming audio after the fact."
This is the round to spend the most time on, since it directly maps to the quiz. Walk through Gmail's spam filtering explicitly: it's trained on enormous numbers of labeled examples (spam vs. not-spam, contributed in aggregate by users marking mail) and continuously updates its classification of new, unseen mail based on the patterns it has learned — this is a textbook supervised-learning setup, even though most users never think of "not getting spam" as an AI feature.
Then battery management, which is the quiz's second question and worth being precise about: many modern phones use on-device machine learning to observe a user's specific app-usage patterns — which apps get opened, when, and how often — and use that to predict what to keep ready in memory or restrict in the background, optimizing battery life around that individual's habits rather than a one-size-fits-all rule. Contrast directly with an LED bulb (fixed electrical conversion, no learning) and a calculator watch (fixed arithmetic, no learning).
It's worth pointing out to this age group why "on-device" matters as a design choice, not just a technical detail: running the learning model directly on the phone, rather than sending usage data to a server, means the personal usage-pattern data involved doesn't necessarily have to leave the device to produce the benefit. Ask the class: "Why might a company choose to do this learning on-device instead of in the cloud, beyond privacy?" (Possible answers: speed/latency, working without a network connection, reducing server costs at scale.)
Smart farming is the clearest real-world example of applied computer vision at this age level, and it's also the quiz's fourth question: precision agriculture uses drones to capture aerial imagery of fields, and AI models trained on labeled examples of healthy vs. diseased or stressed plants analyze that imagery to flag problem areas — often before those problems would be visible to a person walking the rows. This is a genuine, currently-deployed application, not a hypothetical.
Smart toilets are worth naming honestly as an unusual but real category: some products use sensors and AI-based analysis to flag potential health indicators from waste data. It's a legitimate (if niche) health-tech application, and it's a good moment to ask the class why health-adjacent AI products like this raise different stakes than, say, a music recommender — this previews the privacy-and-reliability thread that becomes more central at the Architect level.
Close with the stapler (fixed mechanical action, zero learning, unchanged for over a century) and AI-generated art (a model trained on large volumes of images or text that can generate novel output from a description) as the clean endpoints of the spectrum, then let students complete the app's sorting practice round individually to apply the test to the remaining items without guidance.
Return to the board list from the warm-up and reveal the correct classification for each item, having students update their own written predictions. Close with the sharpest version of the rule: "The word to listen for is 'learn.' If a system's behavior only changes because a programmer edited its code, it's automation. If its behavior changes because it processed more data, it's AI — regardless of how complicated, fast, or old-fashioned it looks."
Extension activity — AI Claim Fact-Check League (20–25 minutes): Have students find (or bring pre-screenshotted) three real product descriptions, ads, or app store listings that claim to use "AI" or "smart" technology. In pairs or small competitive teams (fitting Hacker mode's league format), each team argues whether the claim likely reflects genuine machine learning or is probably marketing language stretched over ordinary automation, using the "does it adapt from data" test and whatever public information they can find about how the feature actually works. Award points for the most well-reasoned case, not just the "correct" verdict — the goal is practicing the diagnostic reasoning, not memorizing which specific products are or aren't AI.
Run it as a real league match if your class already uses Hacker mode's competitive format: two teams present opposing claims on the same product ("this is genuine ML" vs. "this is automation dressed up as AI"), a third team acts as judges scoring the arguments on evidence and reasoning quality, and teams rotate roles each round. This format rewards the exact skill the lesson is building — defending a classification with specifics, not gut instinct — while keeping the competitive energy Hacker-mode students respond to.