Teaching "Your AI Invention" to Architect mode (ages 15–18)

Hook & Warm-Up

Treat this as a proposal review, not a classroom exercise — that framing raises the bar naturally for this age group. Open with the app's own line:

"Time for your capstone. Combine everything you've learned into one project. Identify a problem, design a solution, and present your work."

Tell the class explicitly what "combine everything" means at this level: evidence the problem is real (not assumed), a technically honest plan, a genuine stakeholder and ethics analysis, and a presentation that could survive being questioned by someone skeptical. This capstone is deliberately structured like a lightweight version of a real AI product pitch, not a report.

Warm-up: give students five minutes to draft a one-sentence problem statement for an idea they're considering, then trade with a partner. Each partner's only job is to ask "how do you know this is actually a problem, and for whom, specifically?" If a student can't answer with more than a guess, that's the first thing to fix before going further — this reinforces that validation comes before design, not after.

Be direct with the class about scope: this is a design and analysis capstone, not a software engineering one. No student is expected to write and train a working model — AIQ itself runs on no budget for paid compute or APIs, and every "AI" example inside the app is either pre-built or runs client-side, for the same reason. What's being evaluated here is the quality of the thinking that would need to happen before any of that work started: is the problem real, is the technical approach plausible, and has the student honestly reckoned with who it could affect and how it could fail.

Main Activity

Structure the period (or, better, two periods) around the six components the app names for a complete capstone: evidence of a real problem, a technical plan, an ethics assessment, a working prototype (conceptual is fine — see note below), evaluation results, and a clear presentation. Treat this less like a worksheet to complete in order and more like a proposal document that gets revised as weaknesses surface — a student who discovers during the ethics analysis that their data source is unrealistic should go back and revise the technical spec, not push forward with a plan they already know doesn't hold up.

Problem Validation

"A rigorous problem validation includes evidence from user research, a literature review, and quantitative need assessment — not just asking one friend, assuming the problem exists, or reading a single article."

Push students toward at least a lightweight version of this: a short survey of five to ten people, a search for existing statistics or news coverage about the problem, or a quick review of whether something similar already exists (and if so, why their approach differs). The standard is "you looked for evidence," not "you conducted a peer-reviewed study."

Model the difference between weak and strong validation on the board. Weak: "I think a lot of students forget their PE uniform, so an AI reminder app would help." Strong: "I asked 15 classmates and 9 said they'd forgotten PE uniform at least twice this term; our adviser said it's a recurring issue at the grade level; and I found a similar reminder-app concept used at another school, but theirs required a paid subscription, which most families here couldn't use." The second version doesn't need to be dramatic or extensive — it needs to show that the student went and checked, rather than assumed.

Technical Specification

"Technical specification quality is measured by feasibility, appropriate complexity, and an honest assessment of limitations — not length, buzzword count, or diagram polish."

Clarify explicitly that no student is expected to actually train a working model for this capstone — AIQ has no budget for compute or paid AI services, and that constraint mirrors most real early-stage projects, where the technical spec comes well before any model gets built. What's being assessed is whether the plan is realistic: does the proposed technique fit the data that would actually be available, and does the student understand where it would likely struggle? A student who writes "this would probably have trouble in low-light conditions because most public image datasets skew toward daytime photos" is demonstrating stronger technical judgment than one who claims 99% accuracy with no basis for the number.

Push students to also name a fallback for the "what happens when it's wrong" question, since a technical spec that only describes the happy path is incomplete. A strong answer says something like "if confidence in the flood prediction is low, the system defers to a human moderator or falls back to a simpler rule-based alert rather than guessing" — showing the student has thought about graceful failure, not just best-case performance. This is also a fair moment to note that even the most capable AI systems available today, including large language models, are still probabilistic and make confident-sounding mistakes; designing around that reality, rather than assuming it away, is itself the technical skill being assessed here.

Stakeholder & Ethics Analysis

"Stakeholder analysis in ethical assessment should map all affected parties, including indirect stakeholders and future populations — not just users, or just developers."

Require students to name at least one stakeholder who isn't the obvious end user — someone indirectly affected, someone excluded by the design, or someone affected only if the system scales up later. For a flood-warning app, that might be residents without smartphones, or people whose behavior changes in ways that create new risk (over-reliance on automated alerts instead of local knowledge).

Also require students to specify a realistic data source and name at least one privacy or consent question it raises, rather than leaving "the data" abstract. If a project would use data about minors, images of people's homes, or health-adjacent information, that's worth flagging explicitly as a reason the idea would need real legal and ethical review before any actual deployment — not a reason to abandon the idea, but a reason to be honest in the proposal that this step exists and hasn't been done yet.

The Pitch

"An effective AI pitch balances technical rigor with an accessible narrative and honest risk acknowledgment — not only caution, only optimism, or only a list of features."

Have students structure their final presentation as: problem (with evidence), proposed technique (with justification and one honest limitation), stakeholder/ethics analysis (naming at least one real risk and a mitigation), and impact (a plausible estimate of scale, not an invented statistic). Encourage cross-examination from classmates after each pitch — a version of the "red team" idea, but framed here as investor-style due diligence questions rather than criticism for its own sake.

Discussion

• "What evidence convinced you this problem is real — and what would change your mind that it isn't?"
• "Who is a stakeholder in your project who isn't the obvious end user, and how would your design change if you took their needs seriously?"
• "What's the most likely way your project fails in practice — not in a dramatic sense, but in a boring, everyday sense (bad data, low adoption, edge cases)?"
• "If you had to defend your technique choice to someone proposing a completely different approach, what's your strongest argument?"
• "What would you need to see, in a pilot test, to know your invention is actually working as intended?"
• "If a version of your idea existed and started being used by thousands of people, what's a consequence that might only show up at that scale, and not in a small classroom pilot?"

These land best as a structured discussion where students respond in writing first, individually, before any group talks — several of these questions (especially the failure-mode and scale ones) tend to get answered more honestly on paper than out loud in front of classmates who are, in a sense, competitors for the same grade. Collect written answers, then open the floor for whoever wants to share.

Quiz Walkthrough

At this age, a student who scores poorly on this quiz has usually treated one of the four capstone components as optional rather than misunderstood the underlying concept — for example, skipping problem validation because the problem "obviously" exists, or skipping stakeholder analysis because the intended users seemed like the only people involved. The fix is rarely re-teaching the definition; it's pointing back at their own proposal and asking which of the four sections got the least real effort.

Wrap-Up & Extension

Close with: "What you built today — a validated problem, a realistic technical plan, a real stakeholder and ethics analysis, and a pitch that's honest about its own limits — is the actual work of early-stage AI product development. Companies pay people well to be good at exactly this kind of thinking, before a single line of a model gets trained."

Extension activity: Turn the class period into a "pitch panel." Assign three or four students as a rotating panel of "investors" for each round of pitches (rotate the panel so everyone gets a turn presenting and a turn evaluating). Give the panel a short rubric — problem evidence, technical honesty, stakeholder coverage, and narrative clarity — and have them ask at least one hard follow-up question per pitch before scoring. This stretches the lesson into a full period, and the experience of being questioned in front of peers is close to what a real technical review feels like.

For a class with strong momentum, extend this into a second period as a written revision assignment: after the pitch panel, have each student write a short "what I'd change" memo — two or three paragraphs identifying the weakest part of their proposal based on the questions they were asked, and what evidence or research would strengthen it. This closes the loop on the capstone's real lesson: a first proposal is a starting point for iteration, not a finished answer, which is exactly how AI product development actually works outside the classroom.