AIQ
AIQ
Part of the Your AI Invention lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · ⚡ Architect (15–18)
This age group responds well to being treated like they're doing the real thing, not a school exercise. Set that tone immediately with the app's own line:
"Time for your capstone! Pick a real problem. Design an AI solution. Think about ethics. Then present your invention. This is real AI development."
Push back gently on any eye-rolling about "just another project" by naming what's actually being asked: this mirrors the exact process a professional AI team follows before writing a line of code — find the problem, scope the solution, check the ethics, pitch it to get buy-in. Nothing about that process changes once you're being paid to do it.
It's worth being direct with students that no coding or model-building happens in this lesson, and that this is deliberate rather than a limitation of the app. Even inside real companies, most AI projects spend far more time on the problem-definition and planning stages covered here than on the eventual model training — a team that skips straight to building usually ends up throwing away work once they discover, too late, that they misunderstood the problem or the data available to them.
Warm-up: give students three minutes to individually list at least three problems — one at school, one in their community, one anywhere else — that a working AI system could plausibly help with. Push them past the first, easy answer ("an AI that does my homework" is not a real problem statement) by asking follow-up questions as you circulate: "who exactly does this affect? How do you know it's actually a problem, not just an annoyance?" Have a few students share their strongest option before moving on.
Watch for the most common failure mode at this age: a student picks a problem that's actually a wish for a fully general AI ("something that understands everything and just helps me with life"). That's not a design brief, it's a description of a technology that doesn't exist and wouldn't be gradeable if it did. Redirect immediately toward specificity — a system that does one narrow thing well for one specific group of people is both more realistic and, honestly, closer to what real AI systems actually look like today.
Run this as a structured project working session, moving the class through the app's three stages with real written output at each step. Expect this to run closer to a full period once ethics analysis and a real problem statement are taken seriously — a rushed version of this lesson, where students fill out four boxes in ten minutes without real thought, defeats the point of it being a capstone rather than just another quiz.
Offer the four categories as starting points, not limits — school, world, home, community — but push students to be specific rather than generic. "Climate change" is not a problem statement; "my barangay floods every rainy season and residents don't get enough warning" is closer to one. Have each student commit to one specific problem in writing before moving on.
A useful test to apply as students commit to a problem: could a stranger who has never met this student read the sentence and understand exactly who is affected and what specifically goes wrong? If the answer is no, the problem needs another pass before Stage 2 starts — vague problems produce vague, hard-to-evaluate solutions no matter how much technical polish gets added later.
Walk through all four parts explicitly, since this is where the real engineering thinking happens:
"A strong problem statement includes who is affected, what the problem is, why it matters, and why AI is appropriate — not every problem needs AI, so be honest about that last part. Selecting an AI technique should be based on the problem's characteristics, the data you'd realistically have access to, and the performance you'd actually need — not on what's newest or easiest. Your ethical assessment should address potential biases, privacy concerns, failure modes, and the populations affected — not just accuracy."
Spend real time on technique-matching: ask each student to state which category their idea falls into — classification (sorting things into groups), prediction (estimating a future value or event), generation (creating new text/images/audio), or recommendation (suggesting items to a user) — and to justify it in one sentence. If a student can't justify the technique, that's a sign the problem needs more definition first, not that they should force-fit a fashionable one.
A quick diagnostic question for a stuck student: "if your AI is right, what does it actually output — a category label, a number, a brand-new piece of content, or a ranked list of options?" A category label points to classification, a number or a yes/no about the future points to prediction, new content points to generation, and a ranked list points to recommendation. This reframes an abstract choice as a concrete question about the shape of the answer, which most students find much easier to reason about than the technique names themselves.
For the ethics section, require at least two distinct concerns, not one. A strong answer names a specific failure mode ("if the flood-warning model is trained mostly on data from richer neighborhoods with better sensors, it may under-warn poorer areas that need it most") rather than a generic one ("it might be biased").
On the data question, push students to be concrete about a source that could realistically exist, rather than an idealized one. "It would use camera footage of the classroom" raises very different, very real privacy questions than "it would use anonymous attendance counts" — asking students to name the actual data source, not just "the data," often reveals a privacy or consent issue they hadn't noticed. This is also where it's worth reminding students that AIQ itself follows this exact discipline: the app collects no real names, photos, or personal details from children, precisely because of concerns like the ones they're now identifying in their own projects.
"A clear problem framing, a logical solution narrative, and honest limitation acknowledgment make an effective capstone presentation — not buzzwords or technical jargon for its own sake."
Require every presentation to include: the problem statement from Stage 2, the technique chosen and why, at least one ethical risk and how it would be mitigated, and a concrete "Meet [name]" story showing the human impact. A one-slide or one-poster format works well — the goal is clarity under a real constraint, which is itself a professional skill.
Model what a weak versus strong limitation statement sounds like, since students at this age often confuse "admitting a weakness" with "undermining their own pitch." Weak: "it would work pretty well." Strong: "it would likely struggle with cases the training data didn't cover well, like flooding at night when camera footage is dark — a real deployment would need a backup data source, like water-level sensors, for those cases." The second version signals more competence, not less, because it shows the student actually thought about failure rather than assuming success.
These work best run in small groups of three or four rather than as a whole-class discussion — students at this age are often more candid about the weak points in their own thinking when talking to peers than when answering in front of the whole room. Circulate and listen in rather than leading every group yourself; jump in only when a group is stuck or being too easy on each other.
Students who breeze through this quiz typically already internalized the four-part structure — problem, technique, ethics, presentation — from having actually done it on their own project rather than from memorizing the app's phrasing. If a student misses a question, ask them to point to the exact part of their own worksheet that answers it; that's usually faster than re-teaching the concept from scratch, and it reinforces that the quiz is testing understanding they've already demonstrated in their work, not new material.
Close with: "What you just did — find a real problem, match a technique to it, honestly assess the risks, and pitch it clearly — is the actual job of an AI product team, minus the part where you'd spend months building it. The thinking is the hard part, and you just did it."
Extension activity: Run a short "red team" round. Split the class into small groups and have each group swap projects with another group. Give them five minutes to find the single strongest criticism of the other group's plan — a data problem, an ethics gap, a case where the AI technique doesn't actually fit. Have groups present their invention again after hearing the critique, this time addressing it directly. This mirrors how real technical proposals get pressure-tested before anyone commits resources to building them.
To stretch this further across a second period, have students research one existing product or service that already tries to solve a problem similar to theirs — a real app, a government program, an NGO effort — and write two or three sentences comparing their approach to it. This introduces, gently, the idea of a competitive or prior-art scan, which real product teams do as a matter of course before committing significant time to an idea, and it often reveals to students that "nobody has done this before" is rarer than it feels when an idea first occurs to you.