FieldClass AI: Turning Textbooks into Outdoor Experiments with a Local Small Model

An AI Learning Tool That Does the Opposite

Most AI education tools compete for your screen time. FieldClass AI does the opposite — it wants you to put your phone down and go outside to measure things in the real world. This open-source project was built by developer mukul9116 for Hacktoberfest's open-source AI challenge under the "Touch Grass" theme.

The core logic is simple: the trigonometric formula for calculating tree height only becomes concrete when you're actually standing in front of that tree. FieldClass transforms the abstract concepts you're studying into experiments you can complete outdoors. You spend less than a minute reading the task instructions, pocket your phone, go measure real objects, then come back and enter your measurements and answers. The app checks your results and offers hints before finally revealing the correct answer.

The developer is a student who personally experienced the disconnect between textbook concepts and reality: we often memorize formulas without knowing where they're used. FieldClass aims to make learning more hands-on, encouraging students to step outside their comfort zone and do rather than just memorize.

Four Starter Experiments and an "Off-Screen" Design

The app currently includes four starter experiments covering STEM topics from high school through freshman year:

• Trigonometry: Build a simple inclinometer from a straw, protractor, and string to estimate the height of trees, utility poles, or buildings;
• Statistics: Count and categorize objects within a 1-square-meter grid and calculate frequencies;
• Plant Morphology: Measure and compare two fallen leaves;
• Average Speed: Time a friend walking a measured path and calculate their average speed.

The app targets two audiences: high schoolers and college freshmen who struggle to visualize STEM concepts, and educators looking to quickly set up an outdoor exercise.

What's truly interesting is how it nudges you offline. The task screen shows just a single blue prompt box that reads: read this, then put your phone away. A read-aloud button lets you listen instead of stare at the screen, and the interface only reappears when you return with your measurements. A step tracker in the header shows your current progress (Select, Task, Report, Feedback), a "what to bring" checklist handles packing, and the feedback screen includes a proximity gauge and a chart comparing your answer against the answer derived from your own measurements.

The developer tested it personally outdoors: estimating a building's height from 12 meters away at a 45° angle with eye level at 1.5 meters yielded 13.5 meters; walking 20 meters in 5 seconds (4 m/s); measuring the heights of five students (mean: 160 cm).

Technical Approach: Python Owns the Facts, the Model Handles the Words

The most instructive part of this project is its architectural choices. The model is the open-weight Gemma 3 1B, running locally via Ollama on an 8GB machine with no GPU. The surrounding stack is Python, Pydantic, and Streamlit, with 34 pytest tests.

Initially, the developer had the model generate entire experiment tasks. This produced the classic "fluent but wrong" problem: writing "angle of sunshine rays" instead of "tangent of the angle," omitting eye height from the formula, cutting off safety instructions midway, and even praising students for things they hadn't done yet.

The key insight was changing the format rather than the prompts, because "the model doesn't understand facts." Each experiment card is pre-populated with materials, steps, safety rules, and formulas. The model uses the student's measurements to calculate the correct answer, renders a verdict, and identifies common mistakes — if the answer is 10.0 and the correct value is 11.5, the hint says "you may have forgotten to add your eye height." The model is only responsible for generating the title, objective, hints, and the lead-in to the next challenge.

This design also has a nice privacy property: the model never sees the correct answer, so it can never leak it; anything the student enters is also never sent to the model. Offloading work from the model noticeably improved speed — a single task generation now takes 10 to 17 seconds (roughly 16 tokens/sec), down from up to 50 seconds before; feedback takes 5 to 10 seconds. (The developer notes these are personal impressions, not formal benchmarks.)

There are limitations too: the model frequently concatenates words (e.g., "degreesto"), tends to ignore student notes, and the developer didn't get to test larger Gemma versions — it's a single model on a single configuration profile.

---

Gemma 3 1B is the smallest open-weight model in Google's Gemma 3 series, released in 2025, with approximately 1 billion parameters. "Open-weight" means anyone can download the model weights and run them locally — but unlike fully open-source models, the training data and some implementation details are not publicly disclosed. A 1B-scale model runs smoothly on ordinary consumer hardware (such as a laptop with 8GB of RAM), which is precisely why FieldClass chose it. Ollama is a local large language model runtime framework that wraps model downloading, quantization (compressing model weights to lower precision to reduce memory usage), and inference serving into a simple command-line tool. Developers can spin up a locally running inference endpoint compatible with the OpenAI API format without configuring complex Python environments. Together, these tools dramatically lower the barrier to deploying fully offline, local AI applications.

Pydantic is a widely used data validation library in the Python ecosystem. It defines data schemas through type annotations and automatically validates and converts data formats at runtime. In AI applications, Pydantic is commonly used to structure model outputs — parsing and validating unstructured text generated by a model into predefined data objects, so that downstream code can reliably consume the results. This is especially important in FieldClass's architecture: it helps the system catch malformed model outputs and prevents "fluent but wrong" text from flowing directly into calculation logic.

Why a Local Open-Weight Model Is the Right Fit Here

This project makes a compelling case for why you'd choose a small local open-weight model over a more capable closed-source one.

Privacy and offline capability: All task generation, grading, and feedback happens on the student's own device. Results and answers are never uploaded to a server. After the initial model download, the app runs entirely offline — and costs nothing per use.

Visible failure modes: The behavior of a local small model is easy to observe. The developer could run hundreds of tests, see exactly how it fails, and design around those failure patterns. Closed-source large models produce prettier sentences, but their factual errors are actually harder to catch.

Honest trade-offs: Closed-source models do write more fluent prose, but the developer chose to sacrifice some text quality in exchange for privacy, zero cost, and controllability — with Python serving as the backstop for factual computation. This is precisely the best use of Gemma 3 1B for this application: the entire "Python owns the facts, validates model output" design evolved directly from repeatedly testing small Gemma's behavior.

---

The "visible failure modes" point here reflects an important engineering concept: failure mode observability. Closed-source large models (like GPT-4 or Claude) are typically accessed via API, and each request may produce different behavior due to server-side version updates, sampling variance, or rate-limiting policies — making it difficult to reproduce the same error under fixed conditions. A locally deployed small model, by contrast, behaves relatively consistently: the same input and the same temperature parameter typically yield highly similar outputs. This allows developers to systematically enumerate the model's failure modes and build deterministic code defenses against them. The idea of "trading a predictable small model for debuggability" is an underappreciated engineering advantage in resource-constrained or security-sensitive contexts.

Takeaway

The value of FieldClass AI isn't in how powerful the model is — it's in the pragmatic engineering philosophy it demonstrates: when a model is unreliable, don't give it tasks it's bad at. Hand off factual computation to deterministic code, let the model do what it's good at (natural language generation), and layer on the privacy and cost advantages of running locally. A tiny 1B model can power a genuinely usable educational application. For developers looking to deploy AI on edge devices or in privacy-sensitive contexts, this is a case study worth studying.