Freyja Labs

Professional Development for Columbus City Schools

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

Columbus, OH · 45,000 students

Map data © OpenStreetMap contributors

What we've been reading

From outside, what we notice

Columbus City Schools is in the early years of Dr. Chapman's tenure as CEO, navigating a "Power of One" strategic plan and a Portrait of a Graduate built around Technology, Critical Thinking, and Adaptability. Across 113 schools, students bring 95 languages and roots in 104 countries — the kind of diversity that makes one-size-fits-all PD obviously wrong. With the Wallace investment supporting the community campus model and Ohio's forthcoming AI policy guidance giving every district a starting point, the harder work is what comes after the policy is adopted: what teaching actually looks like when AI is in the room. That's where Freyja Labs comes in: we custom-build a path with your teachers, designed for what your students need and what your community is already navigating.

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 Columbus City Schools — 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, OH 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 · Sensors and pattern analysis

Data Detectives: Sensors and AI in Our School Environment

6–8 · Science / Math · 90 minutes

Kit: micro:bit + sample lesson plan — "Data Detectives: Using Sensors and AI to Understand Our School Environment" (grades 6-8, science/math integration). Students collect temperature, light, and sound data with micro:bit sensors across the school building, then use an AI tool to identify patterns. The lesson includes embedded AI literacy objectives: students apply the verification protocol to evaluate whether the AI's pattern analysis matches what they observed firsthand. Tailored to Columbus's Portrait of a Graduate attributes (Technology, Critical Thinking, Adaptability). This is one example of what a teacher produces in a single day of working with us — co-designed with AI, grounded in 15 years of research in STEM integration.

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

Without the PD, the sensor data and the AI pattern analysis would land as the answer. After: students treat AI as a teammate to challenge, and the 95-language student body brings community knowledge the model cannot access.

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

Content Objectives

  • Collect environmental data using digital sensors across multiple campus locations
  • Represent collected data in tables and graphs to support comparison
  • Identify patterns in physical environment data over time

AI Literacy Objectives

  • Compare AI-identified patterns with student observations to identify divergences
  • Apply structured verification practice to evaluate AI output
  • Articulate criteria for when AI analysis is and is not worth trusting in a multilingual school context

What Students Do

Phase 1 · 25 min Collect

Teams of 3+ deploy micro:bit sensors at chosen building locations (cafeteria, library, hallway, courtyard). Record temperature, light, and sound at 5-minute intervals for 25 minutes. Note observations alongside numerical readings.

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 Compare

Teams input their data into the AI pattern-analysis tool and ask it to identify patterns. Document at least three places the AI agrees with their observations and three where it diverges.

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 · 35 min Evaluate

Each team applies the verification protocol to the divergences. Class develops shared trust criteria for AI pattern analysis on data from a campus serving 95 languages and 104 countries.

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 temperature, light, and sound sensors (included in kit)
  • USB cables and student devices with internet access
  • AI pattern-analysis tool access (at landing page)
  • School building floor map (printed)
  • Data recording sheet and chart paper

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.

Trust criteria reference at least one specific divergence the team observed; observations and AI output are documented side by side.

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
Differentiation 1 / 4
Below grade

Pre-load the data table with column headers and one example row. Pair with a peer for the AI comparison phase. Provide a sentence frame for the evaluate phase: "We trust the AI when ___ because ___. We don't trust it when ___ because ___."

At grade

Standard procedure as written.

Above grade

Add a fourth phase: students design a follow-up experiment that would resolve a specific AI-vs-observation disagreement they found. They write the protocol; they don't need to execute it in class.

Multilingual learners

Provide vocabulary cards in advance: sensor, prediction, observation, evidence, divergence. Allow team discussion in students' home language; final class artifacts can be authored bilingually. The verification protocol works in any language — emphasize that direct measurement and lived knowledge are the most authoritative inputs.

Slide Cues — 6 slides
Slide cues 1 / 6
Slide 1 What we are doing today
  • Collect real data on our campus
  • Compare it with what an AI predicts
  • Decide together when AI is worth trusting
Slide 2 The verification protocol
  • Source · Reasoning · Reality · Yourself
  • You don't need to know how the AI works to check its work
  • A protocol, not a checklist — adapt to the situation
Slide 3 Phase 1 — Collect
  • Teams of 3 deploy sensors at chosen spots
  • Record at intervals; vary your locations
  • Log a written observation with each reading
Slide 4 Phase 2 — Compare
  • Input your data into the AI tool
  • Find at least 3 places it agrees, 3 places it diverges
  • Don't correct your data to match the AI
Slide 5 Phase 3 — Evaluate
  • Apply structured verification practice to your divergences
  • Present one trust guideline based on what you found
  • Class builds the shared trust framework together
Slide 6 Exit ticket
  • One moment when your measurement beat the AI
  • Be specific — number, location, what AI missed
Standards Alignment — 9 frameworks
Standards 1 / 9
NGSS MS-ESS3-3

Apply scientific principles to design monitoring method for human impact

NGSS MS-ETS1-3

Analyze data from tests to determine best design solutions

CCSS Math 6.SP

Statistics & Probability — Grade 6

CCSS Math MP.4

Model with mathematics — Math Practice

CSTA 2-DA-08

Collect data using computational tools; transform for reliability

CSTA 2-DA-09

Refine computational models based on generated data

CSTA 2-IC-21

Discuss bias and accessibility in technology design

ISTE ISTE-3b

Evaluate accuracy, credibility, relevance of information

ISTE ISTE-5b

Collect data and identify data sets; use tools to analyze data

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 Columbus City Schools)

↑ Top of Tech lesson ↑ Top of Lessons Next: Unplugged Lesson →
Unplugged lesson / no screens
No screens · AI prediction critique

The Prediction Game: Can You Out-Think the Algorithm?

6–8 · Social Studies / ELA · 60 minutes

The Prediction Game: Can You Out-Think the Algorithm? — Teams receive printed cards with Columbus neighborhood data (demographics, transit, weather). They role-play as an AI system making predictions, then compare with actual outcomes. Students discover what local knowledge adds that data alone misses. Tailored to Columbus's 104 countries and 95 languages — students bring community knowledge the model does not have.

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

Without the PD, an AI prediction about Columbus neighborhoods would be a fact to discuss. After: students role-play as the AI itself, then catch what 104 countries of community knowledge add — knowledge no training set contains.

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

Content Objectives

  • Read and interpret community demographic, transit, and weather data
  • Generate predictions from data and evaluate them against actual outcomes
  • Identify gaps between aggregate data and on-the-ground knowledge

AI Literacy Objectives

  • Distinguish between data an AI has and lived knowledge it does not
  • Articulate the role of community knowledge in AI prediction quality
  • Identify specific community inputs no training set captures

What Students Do — No Screens, No Devices

Phase 1 · 15 min Examine

Teams receive printed cards with Columbus neighborhood data. Each team reads the data and writes one prediction per card about what an outcome (transit ridership, weather impact, service demand) might be.

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 · 20 min Role-play

Teams role-play as an AI system: using only the data on the cards, generate a "prediction." Then receive the actual outcome packet. Document where the prediction held and where it failed.

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

Teams identify what local knowledge — speaking 95 languages, having family in 104 countries — adds that the data alone misses. Class builds a shared list of community-knowledge inputs no AI training set contains.

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 Columbus neighborhood data cards (demographics, transit, weather) — PDF at landing page
  • Predicted-vs-actual outcome packets
  • Verification protocol reference card
  • 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 list cites at least three specific community-knowledge inputs and ties each to a divergence the team observed.

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
Differentiation 1 / 4
Below grade

Reduce to two artifacts in the packet (instead of three or four). Provide a graphic organizer with three columns: What the AI said / What I know / What I would tell someone who asked me. Sentence frames provided for the final argument.

At grade

Standard procedure as written.

Above grade

Add a meta-question: students draft two or three rules for when the kind of AI tool in this lesson should and should not be used by adults in their lives. The rules are evidence-cited from the packet.

Multilingual learners

Encourage discussion in students' home language. The artifacts in the packet can be discussed in any language — the analysis transfers. Final class artifacts can be authored bilingually. Pair vocabulary cards if helpful: source, reasoning, reality, evidence.

Slide Cues — 6 slides
Slide cues 1 / 6
Slide 1 Real decisions, real evidence
  • AI tools are showing up in decisions that matter
  • Your job today: evaluate whether the AI's reasoning holds up
  • No screens. Just the artifacts in front of you.
Slide 2 Verification protocol — without the machine
  • Source · Reasoning · Reality · Yourself
  • Same protocol whether you're looking at a sensor reading or a printed AI claim
  • Adapt to what's in front of you
Slide 3 Phase 1 — Examine
  • Read the artifacts carefully
  • Note what the AI got right and wrong
  • Don't pick a winner yet
Slide 4 Phase 2 — Investigate
  • WHY did the AI reach this conclusion?
  • What data did it have? What did it miss?
  • Was it the model, or what the model knew?
Slide 5 Phase 3 — Argue
  • Make a defensible recommendation
  • "It depends" is allowed if followed by "specifically, on these things"
  • Cite evidence from the packet
Slide 6 Exit ticket
  • Three things to check before accepting any AI recommendation
Standards Alignment — 6 frameworks
Standards 1 / 6
CCSS ELA RI.7

Reading Informational Text — Grade 7

CSTA 2-IC-21

Discuss bias and accessibility in technology design

CSTA 2-IC-23

Describe tradeoffs between public and private information

ISTE ISTE-3b

Evaluate accuracy, credibility, relevance of information

ISTE ISTE-7b

Use collaborative tech to examine issues from multiple views

NCSS C3 D2.Civ.14.6-8

Compare historical/contemporary means of changing society

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 Columbus City Schools)

↑ Top of Unplugged lesson ↑ Top of Lessons Next: How we'd work together →

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 Columbus City Schools 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