Last month I spent three evenings convinced I understood how a small image classifier decides what it is looking at. Then my younger cousin, who had never written a line of code, asked me why it called a muffin a dog. I opened my mouth and nothing useful came out. That awkward silence taught me more about machine learning than the tutorial had. This checklist is what I now run through whenever I want to turn a fresh AI lesson into something I can actually teach.

Start with the story of the mistake, not the definition

My cousin did not want a definition of “overfitting”. She wanted to know why the machine got something obviously wrong. So the first item on my checklist is: find one concrete wrong answer from your own experiment and begin there. A real error gives the explanation a spine. Definitions can come after the listener cares.

• Did you keep the exact input that fooled the model?
• Can you describe, in one plain sentence, what the model was probably paying attention to?
• Can you say what you changed afterwards, and whether it helped?

Audit your vocabulary

When I tried to explain the muffin mistake, I discovered I was using “features”, “weights” and “training signal” as if they were interchangeable. They are not, and a beginner senses the wobble immediately. Go through your draft and circle every technical word. For each one, ask whether you could swap it for a short everyday phrase without losing the meaning. If you cannot, you have found a hole in your own understanding, which is precisely what this exercise is for.

I keep a scrap list titled “words I bluffed”. It is embarrassing and enormously productive. A beginner-friendly walkthrough such as the simple tour of how machines sort pictures into categories helped me see which terms can safely be introduced late and which must come first.

Audit your examples

One example is an anecdote; two examples that disagree are a lesson. After the muffin episode I made myself find a second case where the same model succeeded for a surprising reason. Then I had something to compare, and the explanation stopped sounding like a lucky story. Ask yourself whether your examples cover the following:

• a case that works and a case that fails, using the same model;
• a case where the reason is obvious and a case where it is not;
• a case your listener could try on their own phone in a minute.

Audit your claims about certainty

Beginners tend to hear “the model thinks” as “the model knows”. During my second attempt at explaining, I caught myself saying the system “understood” the picture. It did not understand anything; it produced the label that scored highest. Replace anthropomorphic verbs with accurate ones wherever you can, and when you are unsure how something works internally, say so out loud. Nothing builds trust with a newcomer faster than a teacher who admits where the map ends.

This is also where decision-making claims tend to creep in. If you find yourself implying that a model’s output should be trusted blindly, look again at how models are meant to support everyday business choices and reread the caveats before you repeat the enthusiasm.

Audit the order

The sequence that felt natural to me while learning was a terrible sequence for teaching. I learned in the order I stumbled, which was full of detours and dead ends. A listener needs the shortest honest path: what the thing does, one working picture of how, one place it breaks, one thing to try. Write those four beats on a card. If a fifth idea keeps trying to jump in, park it for another post.

Audit where it will live

Notes written for yourself vanish into folders. Notes written for a stranger deserve a public home, even a modest one. A blogging network like MyBlogPad lets you start a blog on its own subdomain, signing in through Google, and it describes itself as free to begin with no card required. That is enough friction-free space to publish your own “what I learned this week” write-up and invite a co-writer if you want a second pair of eyes.

The checklist in one place

1. Begin from one real wrong answer you produced yourself.
2. Circle every technical word and replace or define it.
3. Collect at least two examples that disagree.
4. Swap “knows” and “understands” for plain, accurate verbs.
5. Cut the story down to four beats.
6. Read it aloud to someone who does not work in the field.
7. Publish it, then revise when readers ask questions you missed.

Audit your own patience

The hardest item on the list has nothing to do with technology. When a listener asks the same question a second time, the temptation is to repeat it louder and faster. I now treat a repeated question as proof that my first wording failed, and I try a different analogy instead. Sorting laundry, sorting mail, sorting playing cards: I keep three in my pocket because one of them usually lands. Patience here is just a willingness to rewrite your own explanation until it fits the person in front of you, and that willingness sharpens your grasp of the idea far more than any extra tutorial would.

What my cousin taught me back

After I rebuilt the explanation with that checklist, I told her the model had learned that fluffy-looking round shapes with dark spots often belonged together, and that the muffin simply looked like the pattern it had learned. She nodded, then asked the question I should have asked myself weeks earlier: “who picked the pictures it learned from?” I did not have an answer. I do now, and the answer reshaped how I read every dataset description since.

That is the real benefit of teaching while you are still unsure. The beginner’s questions are free quality assurance. They find the assumptions you absorbed without noticing, and they point to the next thing worth studying. Keep the checklist near your notes, run it before every write-up, and treat each blank stare as a signpost rather than a failure.