fieldcard: a pocket field card written offline by Gemma, so the screen is the shortest part of the walk

Kim Doyoung — Tue, 06 Oct 2026 14:21:28 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

fieldcard is a tiny command-line tool that writes you a paper field card for today's walk, and reads your walk back to you when you get home. Both halves run on an open-weight model on your own computer.

Most "go outside" apps want you to keep looking at them: a map, a feed, a streak, a notification. I wanted the opposite. fieldcard is designed so you spend about thirty seconds with a screen before the walk and about ten after it, and the whole middle happens with a pencil.

It has two commands:

quest asks Gemma 4 E4B (running locally in Ollama) for five things to notice where you are going, in this season, before sunset. It prints them on an A6 card with checkboxes and a one-minute "sit spot". You print it, put it in your pocket, and close the laptop.
check takes the photos you took, photos of your pencil sketches, or voice notes, and the same local model decides which card item each one is evidence for. It writes a one-page field journal: what you found, what is "not yet", and one "next time" prompt per find, something to notice with your eyes, ears or nose rather than your phone.

The voice notes are my favourite part. Gemma 4 E4B takes audio as well as images, so on the trail you don't have to unlock your phone and frame a shot. You press record on any voice recorder and say "number four, seven little brown birds in the branches over the path", and that counts.

It is for anyone who wants a reason to look closer on an ordinary walk: a lunch-break loop round the park, a weekend hike, a walk with a kid who needs a mission.

Demo

87-second narrated walkthrough (real terminal output, real model output):

▶ fieldcard-demo.mp4

The card that quest wrote for an autumn walk in Seoul Forest park:

And the journal that check wrote from the sample folder in the repo: six public-domain stand-in photos and two synthetic voice notes (I wanted a sample anyone can rerun, without shipping anyone's real walk):

It scored 4 out of 5. The acorn-caps item stays "not yet": the only acorn picture in the sample is two acorns on a twig against a blue backdrop, not caps on the ground, and the model said so. Bring the card back next time.

Code

kimdooo-a / fieldcard

Offline field card + journal for a walk, written by a local open-weight model (Gemma via Ollama).

fieldcard

A pocket field card, written by an open-weight model on your own computer. The screen is the shortest part of the walk.

fieldcard asks a small local model (Gemma 4 E4B, through Ollama) for five things to notice outside today, where you are, in this season, before sunset. It prints them on an A6 card. You go outside with the card and a pencil. When you come back, the same model looks at your photos and listens to your voice notes, on the same machine, and writes a one-page field journal.

No account. No API key. No cloud. Run it with --airplane and the process refuses every network connection that isn't to this computer.

The card (print it)	The journal (after the walk)

Demo video (87 s, narrated): docs/fieldcard-demo.mp4

Built for the DEV × Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.

Quick start

You need…

View on GitHub

One Python file, standard library only (Pillow and ffmpeg are optional), MIT licensed, twelve offline unit tests.

ollama pull gemma4:e4b
python fieldcard.py --airplane quest --place "Seoul Forest park, Seoul" --habitat park \
    --minutes 40 --lat 37.544 --lon 127.037 --tz 9
python fieldcard.py --airplane check examples/2026-10-06-seoul-autumn-walk.json samples/walk

How I Built It

The model. Everything runs through Gemma 4 E4B in Ollama: a 7.5B-parameter open-weight model, 6.6 GB on disk, that takes text, images and audio. One model does all three jobs: writing the card, looking at photos, and transcribing voice notes. On my desktop GPU, once the model is loaded, a card takes 1 to 3 seconds per attempt, and the sample journal (six photos and two voice notes) took about 10 seconds in total.

Code decides the facts, the model writes the words. I didn't want the model guessing things that can be computed. The season comes from the date and the hemisphere. Sunrise and sunset come from the NOAA solar position equations, about 40 lines of math, so there is no weather API to call. (For central Seoul on 6 October it gives 18:10; api.sunrise-sunset.org says 18:10:20.) The model gets those facts in the prompt and only writes the five observations.

Code checks every card before it can be printed. Gemma returns the card as JSON constrained by a schema, and then plain Python checks it:

exactly five items, short enough to read at a glance, no duplicates;
nothing to eat, taste, forage, touch, feed, climb, catch or leave the trail for;
no phones, screens or apps on the card;
if an item says "count it", it has to say what to count.

If a rule is broken, the card goes back to the model with the list of problems and gets rewritten. The last rule exists because of something I kept seeing: Gemma liked to mark "the crunch of dry leaves underfoot" as a tally item. You can't count a sound. Writing that rule into the system prompt didn't change much. Checking it in code did, and the rewrite takes about a second:

attempt 1: 2.75s, 347 tokens -> rejected: item 3 is a tally but does not say what to count
attempt 2: 1.35s, 275 tokens -> ok

That is the pattern I'd recommend to anyone building on a small local model. Let it do the creative part, and let a few lines of boring code hold the line on the parts that have to be right.

Reading the walk back. Each photo or voice note goes to the same model along with the card, and it answers with a small JSON verdict: what it sees (or the transcript), which item it matches, how confident it is, and one thing to look closer at next time. Each card item keeps its most convincing piece of evidence. Everything else becomes a "bonus find", because a dandelion seed head you stopped to look at still counts as a good walk.

My first version was too generous. It credited a bracket fungus for "moss on rough bark", and its own explanation even admitted the fungus wasn't moss. One extra sentence in the prompt fixed it: a match means the thing the item names is itself visible; something nearby or similar is not a match. Now the fungus is a bonus find, and when it accepts lichen for "moss" it says so in the journal and suggests checking next time whether the growth is soft and green or hard and crusty. I'd rather it be honest about being close than pretend.

Airplane mode. --airplane swaps out Python's socket functions for the process, so any lookup or connection to a host that isn't loopback raises an error. One unit test checks that https://example.com is refused while 127.0.0.1 still works. It's a cheap way to prove the privacy claim instead of just making it.

The output is paper-shaped. The card and the journal are static HTML with print CSS (A6 for the card) and no JavaScript, with the journal's thumbnails inlined. They open offline, they print, and nothing on them pulls you back in.

I built it with an AI coding agent (Claude Code) as a pair programmer. The model inside the product, the thing that makes it work, is Gemma running locally.

Why Does Open Innovation Matter?

Because of where this tool is used, and what it is shown.

It works where the signal doesn't. The card is generated before you leave and printed, and the journal is written after you're back. Neither needs the internet, so a trailhead with no reception doesn't matter. With open weights the model is a file on my disk. It won't be deprecated next quarter, rate-limited, or put behind a login.

Your walk stays yours. Photos from a walk are surprisingly personal: your street, your kid's hand holding an acorn, the route you take every evening. Voice notes are your actual voice. A closed vision API would mean uploading all of that to a server I don't control just to get a checkbox ticked. Here the model runs on the same machine as the photos, and --airplane makes that something you can check rather than trust.

It costs nothing to run, so it can be generous. There's no per-call bill, so retrying a card that breaks a rule is free, and so is reading every photo from a long walk. That changes design decisions: I could add the "check in code, rewrite if wrong" loop without counting tokens.

I can see and change everything. The prompts, the rules and the model are all swappable. --model takes any Ollama model with vision, and a club could fine-tune a small model on its local flora and get cards that name the right maples. With a closed API, how the model behaves is someone else's decision. Here it's a few lines in a file anyone can fork.

Open-weight multimodal is the enabling piece. Until recently, "local" meant text-only, or a separate speech model, a separate vision model, and a lot of glue. A single open 7.5B model that reads images and hears voice notes is what made the "keep your phone in your pocket and just talk" design practical on a laptop.

My Agent Session

I didn't record a DevRelay session for this one. The commit history and the tests in the repo show how it came together.

Prize Categories

Best Use of Gemma: Gemma 4 E4B, run locally through Ollama, is the whole engine: it writes the cards, reads the photos, and transcribes the voice notes.
Best Use of ElevenLabs: the demo's narration was generated with ElevenLabs text-to-speech, and so were the two sample voice notes in the repo, so the samples ship nobody's real voice. ElevenLabs is not used at runtime; fieldcard itself stays offline.

Credits: sample photos are public domain / CC0 from Wikimedia Commons (full list in samples/walk/CREDITS.md). Sunrise and sunset use the NOAA General Solar Position equations.

Thanks for reading. Now go outside.

DEV Community: Kim Doyoung