Skip to content
Freyja Labs

Professional Development for San Jose USD

Customized. Hands-on. Built for your teachers and your students.

San Jose, CA · 30,000 students

Map data © OpenStreetMap contributors

What we've been reading

From outside, what we notice

San Jose Unified is in the heart of Silicon Valley, where parents work in AI, ML, and semiconductor design. AI literacy is a community baseline expectation, not a novelty — and that creates a specific bar for the work. PD that treats AI as new ground will not land. AB 2876 is shaping the statewide policy frame, but for San Jose the harder question is pedagogical sophistication: how do teachers design instruction that pushes students past the consumer-level familiarity they already have, into rigorous evaluation of what tools can and cannot do? We design with that bar in mind — custom-built for San Jose teachers and students who arrive with home contexts most districts cannot assume.

If any of this resonates, you might also like

Next ↓ 02 · Sample lessons

Sample lessons — artifacts, not deliverables

We don't deliver lesson plans.

We deliver change for your teachers. The lessons below are the receipts.

These two examples were built for San Jose USD — but what we'll actually do together depends on what you tell us about where you are and where you want to go. We custom-build with your teachers around what your students, your community, and your district leadership are actually navigating: AI integration, CS/STEM integration, CA policy, the local context only your educators can read. The artifacts you'll see below are one shape that capability can take.

Tech lesson / with devices
micro:bit + AI · Build a classifier from your own data

How AI Learns: Building a Classifier From Your Data

7–10 · Science / Math · 90 minutes

Kit: micro:bit + sample lesson plan — "How AI Learns: Building a Classifier From Your Own Data" (grades 7-10, science/math). Students build a simple machine-learning classifier using micro:bit sensor data, then evaluate its accuracy. Embedded AI literacy: students see AI from the engineering side — how systems learn, where they break, and what the humans building them need to know. Designed for Silicon Valley — where understanding AI from the inside is a community expectation.

What's new — what wouldn't have happened before this PD

Without the PD, building an ML classifier is a project. After: students see AI from the engineering side — how systems learn, where they break, what the humans building them need to know — exactly the depth a Silicon Valley community has every right to expect.

Show full lesson plan objectives · procedure · materials · assessment · teacher pack

Content Objectives

  • Design a binary classification problem
  • Collect labeled training data
  • Train, test, and analyze a small classifier

AI Literacy Objectives

  • Understand AI from the engineering side
  • Identify how training data shape classifier behavior
  • Apply structured verification practice to a system the team built

What Students Do

Phase 1 · 30 min Train

Teams of 3+ design a binary classification problem (e.g., "indoor vs. outdoor", "morning vs. afternoon"), collect labeled training data with micro:bit sensors, and train a small classifier in the browser framework.

Facilitation focus

Don't standardize sensor placement across teams. Different microclimates make Phase 2 richer. Move between teams every 5 minutes; check that students are recording observations *and* numerical readings. The qualitative notes are the wedge they'll use to challenge AI in Phase 3.

Watch for

Teams logging only numbers. Push them to write at least one observation per reading ("breeze picked up", "cloud passed over"). If the campus has visibly varied environments — shade vs. sun, paved vs. planted — push teams to spread out.

Phase 2 · 30 min Test

Teams test the classifier on new data. Document accuracy, identify systematic failures, and trace each failure to a training-data limitation.

Facilitation focus

Frame the AI tool as a teammate, not an authority. When the AI prediction is wrong, students often default to "we'll fix our data." Interrupt that — the goal is to surface where AI and ground-truth diverge, not to reconcile.

Watch for

Teams that find zero divergence. Either they're smoothing data unconsciously, or the AI is generic enough to match anything. Have them pick a single 5-minute window and compare in extreme detail.

Phase 3 · 30 min Evaluate

Apply structured verification practice to a system the team built. Class produces engineering-side insights about how AI systems learn and where they break — directly relevant to a Silicon Valley community.

Facilitation focus

The class trust guidelines are the deliverable. Push for specificity: not "AI is bad at humidity" but "AI underestimates humidity in conditions like ours when [specific local condition]." Local knowledge + data = the trust criteria.

Watch for

Generic statements ("AI is sometimes wrong"). Reject these gently — every guideline must reference a specific divergence the team observed.

A four-step verification protocol your teachers will build with us

A practice students learn once and apply to any AI output, in any subject, for the rest of their lives.

1. Check the source

Where did the AI get its data? Is it the same data we used or generated?

2. Check the reasoning

How did the AI reach its conclusion? Can we follow the logic?

3. Check against reality

Does the output match what we observed with our own senses, instruments, or knowledge?

4. Check yourself

What might we have missed? What would we want a second opinion on?

More on the thinking behind this — the framework we built it from.

Materials

  • micro:bit with multiple sensor types (included in kit)
  • USB cables and student devices
  • Browser-based ML classifier framework (link at landing page)
  • Training-data design worksheet
  • Chart paper and markers

Assessment

Each team produces a one-page artifact: their findings, the AI output they evaluated, and a written verdict on when this kind of AI work is worth trusting.

Final analysis names the classification problem, accuracy results, and at least two systematic failures traced to training data.

Teacher pack — everything you need to teach this

For the Facilitator

Prior Knowledge Required
  • Read and create simple data tables and bar/line graphs
  • Distinguish between an observation (what we measured) and an inference (what we conclude)
  • Familiarity with one-step variable assignment in block-based or text-based code
Exit Ticket

"Describe one moment today when your direct measurement told you something the AI missed. What did you measure, and what should the AI have done differently?"

Look for
  • Specific reference to a measurement (number + unit + location)
  • Specific reference to what the AI output said
  • A concrete claim about what the AI should have changed (input, comparison, caveat)
Anticipated Misconceptions

"If the AI says it, it must be right — it has access to all the data."

Show the AI a deliberately wrong dataset and have students predict the (wrong) output. Reinforce: AI confidence ≠ AI correctness. The AI processes whatever input it receives, including noise and bias.

"Our sensor data is wrong because it doesn't match the AI."

Have students re-measure with a second device or different location. Direct measurement is the ground truth — divergence with AI is a signal worth investigating, not an error to "fix."

"The AI is broken if it gives a different answer to the same question twice."

This is a feature, not a bug. Use it to discuss probabilistic vs. deterministic systems. Two valid outputs can describe the same data — students should learn to ask "what stayed the same?"

Differentiation
Slide Cues — 6 slides
Standards Alignment — 9 frameworks
Family / Guardian Letter — copy & paste, edit to fit

Dear families, This week your student is learning a skill that will matter for the rest of their lives: how to decide when to trust an AI system. In this lesson, students used real sensors to measure conditions around our school and compared what they measured with what an AI predicted. The point is not that AI is bad — the point is that AI works best when paired with someone who knows the real situation. Your student is learning to be that someone. We call the protocol the verification protocol. It has four steps: check the source the AI used, check the reasoning, check the result against reality, and check yourself for what you might have missed. You can use this with your student at home — every time an AI assistant gives you an answer, ask: "How would we check this?" Questions? hello@freyjalabs.com — Freyja Labs (working with San Jose USD)

Unplugged lesson / no screens
No screens · AI screener vs. human interviewer

The Job Interview: AI Screener vs. Human Interviewer

7–10 · Social Studies / CTE · 60 minutes

The Job Interview: AI Screener vs. Human Interviewer — Teams role-play both sides: an AI resume screener and a human interviewer. They discover what each approach reveals and conceals about a candidate. Designed for Silicon Valley, where many parents have been on both sides of this process.

What's new — what wouldn't have happened before this PD

Without the PD, the AI vs. human-interviewer debate is conceptual. After: students role-play both sides — AI screener and human interviewer — and discover what each approach reveals and conceals. Many parents have been on both sides; the learning has somewhere to land.

Show full lesson plan objectives · procedure · materials · assessment · teacher pack

Content Objectives

  • Role-play distinct evaluation approaches
  • Compare what different methods reveal and conceal
  • Construct an evidence-based hiring recommendation

AI Literacy Objectives

  • Identify what AI screening captures and what it cannot
  • Articulate the comparative strengths of AI screening and human interviewing
  • Construct a role for each in fair hiring

What Students Do — No Screens, No Devices

Phase 1 · 20 min Screen

Teams of 3+ split into two roles: an AI screener (must use only the resume data) and a human interviewer (designs open-ended questions). Document each role's reasoning.

Facilitation focus

Print the artifact packets in color so detail is preserved. Don't tell students which AI claims are "right" — let them notice divergence on their own. Their lived knowledge of the topic IS the comparison standard. Treat it that way explicitly.

Watch for

Teams that pick a "winning" artifact immediately. Slow them down — every artifact reflects the AI's best guess given its inputs. The question is not which is right but how anyone could have known in advance.

Phase 2 · 15 min Compare

Teams compare what each role surfaces. Document what an AI screener catches and misses; what a human interviewer catches and misses.

Facilitation focus

Distinguish three error types: factual (X is asserted but isn't true), framing (the description emphasizes one thing while ignoring others), absence (something important is left out entirely). Most AI artifacts fail in framing and absence, not facts.

Watch for

Teams that only catch factual errors. Push deeper — what story is the AI telling? Whose perspective is implicit? What did it not have access to?

Phase 3 · 25 min Argue

Each team produces a position: how should hiring combine the two? Connect to Silicon Valley parents who have been on both sides.

Facilitation focus

Frame the argument as advice to a real decision-maker who will act on it. Students must commit to a recommendation AND name specifically what would change their mind.

Watch for

Hedging ("we can't really know"). True — but the decision still has to be made. Push students to commit to a recommendation AND explain what new information would flip it.

Materials

  • Printed fictional candidate resumes (PDF at landing page)
  • AI screener output for each candidate
  • Human-interview question template
  • Chart paper and markers

Assessment

Each team produces a one-page artifact: their findings, the AI output they evaluated, and a written verdict on when this kind of AI work is worth trusting.

Position cites specific candidate cases and names what each method revealed or concealed.

Teacher pack — everything you need to teach this

For the Facilitator

Prior Knowledge Required
  • Read and discuss informational text in small groups
  • Cite evidence to support a claim — written or verbal
  • Familiarity with the difference between a prediction and a confirmed result
Exit Ticket

"An AI tool gives someone you care about a recommendation. What three things should they check before they accept it?"

Look for
  • At least one item references the source or input data the AI used
  • At least one item references the AI's reasoning or comparison with known facts
  • At least one item references checking with a person, lived experience, or independent source
Anticipated Misconceptions

"AI is just like a calculator — if you give it the right numbers, you get the right answer."

Use a worked example where two students give the same prompt and get different outputs. AI is more like a human reader making a judgment call than a calculator computing a formula.

"If we can't see the math, we just have to trust it."

Pivot the protocol — "Check the reasoning" — to focus on what we CAN check: source, comparison to known facts, internal consistency. You don't need the math to evaluate a claim.

"AI hallucinations only happen with chatbots."

Show a printed AI example that contains a confident but factually wrong statement. Hallucinations are a property of how generative models work, not a chatbot quirk.

Differentiation
Slide Cues — 6 slides
Standards Alignment — 6 frameworks
Family / Guardian Letter — copy & paste, edit to fit

Dear families, This week your student practiced something most adults haven't been formally taught: how to evaluate an AI-generated claim before accepting it. In this lesson, students worked from printed artifacts — no screens — and applied a four-part verification protocol: check the source, check the reasoning, check the result against reality, and check yourself. They learned that the right answer to "should I trust this AI?" is almost always "let me check first." At home, you can use the same protocol. The next time an AI assistant gives your family information, ask your student: "What would we need to check before we acted on this?" Questions? hello@freyjalabs.com — Freyja Labs (working with San Jose USD)

Worth saying again: the lessons above are receipts, not the goal. The point of the engagement is change for your teachers — their confidence to design the next ten lessons themselves, for whatever San Jose USD faces next. We don't deliver lesson plans. We deliver capability.

More on how we think about this work

Next ↓ 03 · How we'd work together

Engagement Options

How We Can Work Together

We don't sell a packaged curriculum — every engagement is shaped around what your district tells us it needs. The options below are starting shapes; the actual work gets co-designed with your team. Click any that look promising and tell us what you're thinking.

Click any option below to mark it as interesting — then use the form to send a quick note.

Next ↓ 04 · Reach out

We do not provide generic materials. We provide the empowerment and support for teachers to build lessons like these — tailored to their students, grounded in their community's experience.

Mike Borowczak, Ph.D.

Andrea C. Burrows Borowczak, Ed.D.

Where growth begins.

hello@freyjalabs.com