Call a Model, Don't Train One
Standard quoted exactly
Create an application using pre-existing supervised learning models to make predictions or classifications.
Student-friendly learning targets
- I can wire a pre-existing supervised model into a tiny application flow: input, request, prediction, display.
- I can explain the difference between calling a trained model and training one.
- I can handle a blocked demo by using a paper API with printed predictions.
Essential questions
- If the model already exists, what is left for us to build?
- What does a supervised prediction look like as data (label + confidence) rather than as magic?
- Where should a human look before the app acts on a classification?
Objectives
- Sketch an app that sends an input (crop-leaf photo description, river-gauge row, or short text) to a prebuilt classifier and shows a label.
- Use a district-allowed demo (Teachable Machine or similar) OR a paper API of printed JSON-style predictions — never train as the gate.
- Parse label and confidence into a user-facing sentence.
- Refuse to send student faces, voices, or PII as inputs.
Key vocabulary
- Pre-existing model
- A model someone already trained. You send inputs and read outputs. You do not update its weights in this lesson.
- Supervised learning
- Training with labeled examples (this leaf is blight; this row is frost). The prebuilt model was supervised; we only call it.
- API
- A contract for how to ask a service for an answer: you send a structured request and get a structured prediction back.
- Inference
- The moment of using a trained model on a new input. Opposite of training in this class's vocabulary.
- Confidence
- A number the model reports with a label. It is not a promise; a 0.91 can still be wrong.
Teacher background
The standard is application using pre-existing supervised models, not a training lab. Teachable Machine or a hosted image/text classifier is fine IF the district allows it and students use teacher-provided public photos (russet leaves, smoke vs. steam, sports jersey colors). If accounts, webcams, or the site are blocked, run a paper API: printed request/response cards (JSON-like) that students wire into a flowchart or a no-code screen mock. Spreadsheet-first path: a lookup table that stands in for the model (input id → label, confidence). Python requests to a public demo is an extension. FERPA: no student selfies into a classifier. AIM.2 will add agents; today is one supervised call.
Materials and prep
Materials
- App-flow template: Input → Request → Model (black box) → Parse label/confidence → Display → Human check.
- Paper API deck: 8 request cards (leaf_042.jpg, gauge_boise_glenwood, headline_redflag) and matching printed predictions.
- Optional: district-approved Teachable Machine or a local prebuilt demo loaded by the teacher with public crop photos — never required.
- Public photo printouts (U of I extension disease cards, NWS radar crop, smoke/steam stills) if using a live classifier.
- Mock phone-screen paper for the display UI.
Before class
- Test whether the live demo is reachable without student logins. If not, go paper-first and say so in the warm-up.
- Print the API deck so every pair can finish offline.
- Choose one app story: Magic Valley leaf sort, foothills smoke alert, or Boise River 'frost tonight' classifier on a tiny weather row.
Instructional sequence
Train vs. call
5 min- Two boxes on the board: TRAIN (needs labels, time, data) and CALL (needs an input and a phone/API). Students sort four verbs: fit, predict, download weights, show a label.
- Circle CALL. That is today's build.
The thinnest possible app
10 min- Walk the flow template. The model is a sealed box that maps input → {label, confidence}.
- Show a printed response: {"label": "early_blight", "confidence": 0.81}. Demo turning it into 'This leaf is labeled early blight (81%). Check with extension if you will spray.'
- State constraints: pre-existing, supervised, no training, no student PII, human reads the screen before action.
- If live demo is on, show one inference on a public photo. If not, hold up the paper API card and treat it as the same contract.
Wire three calls together
12 min- Class maps three paper requests through the flow and writes the display sentence for each.
- Handle a low-confidence response (0.41) by branching: 'show unsure, do not spray / do not page crews.'
- Add a failure card: timeout. The app must say 'model unavailable,' not invent a label.
Build your flow
10 min- Pairs pick the leaf, smoke, or frost story. They complete the flow template, three example calls (from the deck or the allowed demo), and the display copy.
- They mark the human-check step in red.
- Spreadsheet path: VLOOKUP from input_id to label/confidence as a stand-in API.
Real-world examples
- A Magic Valley packing shed camera already has a vendor defect model; the app is the belt UI plus a reject bin, not a new training run.
- Idaho Transportation Department can call a prebuilt road-camera ice classifier; dispatchers still decide plow routing.
- A Boise State sports-stats club can call a prebuilt shot-chart classifier on public game film, not on hallway video of students.
- Extension offices calling a hosted leaf model on grower-submitted (consented) photos — still a call, still a human agronomist.
Hands-on activity
Run the paper (or live) API
8 min- Each pair 'sends' two new cards through their app and writes the on-screen text.
- Peer tries to break it with the timeout card and a PII card (student selfie). The app must refuse the selfie.
- Photograph or staple the flow; that is the application artifact.
Discussion questions
- If confidence is 0.95 and the leaf is healthy, who is wrong — the photo, the model, or the display copy?
- Why might a district forbid Teachable Machine webcams even though this standard likes demos?
- What is the smallest UI that still counts as an application?
- Where does this app log inputs, and why might logging be a privacy bug?
Differentiation
Support
- Flow boxes already drawn; students fill display sentences only and run two paper cards.
- Spreadsheet VLOOKUP version with input_id pre-listed.
Challenge
- Add a second prebuilt model (crop vs. not-crop) as a gate before the disease model.
- Sketch how a timeout retries once, then fails safe.
Multilingual learners
- Display copy required in English and the student's strongest language; labels stay as the API returns them, with a glossary.
- API / inference / confidence on a term strip.
IEP / 504
- Paper API only; no live webcam. Oral walkthrough of the flow is accepted.
- Fewer cards; the success is the wired flow, not speed.
Assessment
Formative
- Train vs. call sort.
- Display sentence for the 0.81 blight response.
Summative
- Completed flow with three calls, a low-confidence branch, a PII refusal, and no training step.
- Live demo is extra evidence, not required for proficiency.
Success criteria
- Student's artifact is an application flow that calls a pre-existing model.
- Student parses label and confidence into human language.
- Student refuses student-PII inputs.
Responsible use, ethics, and privacy
Responsible use
District-approved tools only. Teacher-loaded public images. No student accounts required. Paper API is a full-credit path.
Ethics
A called model still carries the biases of whoever trained it. Displaying a label as fact without a human check can harm a field or a person.
Privacy
FERPA: never classify student faces, ID photos, or classroom recordings. Log files of inputs are PII if they contain photos of people — do not keep them.
Reflection
- What did you build that is not the model itself?
- When is a paper API more honest than a flashy demo?
- What would you add before this app could page a person?
Homework
On paper, draw the flow for a frost yes/no app that calls a prebuilt model on public NWS values. Write two fake API responses (high confidence frost; low confidence) and the screen text. Do not upload photos from home.
Closing
You built the wiring, not the brain. Call, parse, display, check. If the demo site is down, the paper API still teaches the standard. Next period we drop in an agent that uses tools — with a human approval step.
Extensions and cross-curricular links
Go further
- 90-minute block: no-code screen (district tool) or a paper prototype test with another pair acting as the API.
- Python extension: a 15-line script that reads a printed JSON file and prints the display sentence — still not training.
- If Teachable Machine is allowed, the teacher trains once before class; students only infer.
- Trace printed JSON with highlighters (label vs. confidence vs. extra junk fields).
- Design / CTE
- UI copy for uncertain predictions is a design problem, not only a CS one.
- Agriculture
- Leaf classification apps exist; the agronomist remains the decision-maker.
- Business
- Buying a vendor model and wrapping it in a workflow is a realistic Idaho software job.