What I Built

Verdant is a quest master that runs on your own laptop and wants you to close it.

An open-weight AI writes you outdoor quests based on the season and the weather, like a 3 km foliage stroll with a leaf to photograph. You go outside and do it. Back home, Verdant checks your GPS track and your photo, and if both pass, it issues a signed voucher. A sponsor, such as a running shop or an eco brand, pastes the voucher into the Verdant Sponsor Portal, sees at once that it’s genuine, and knows which reward to ship: a sticker pack, a finisher medal, or a swag box.

It’s for people who need a small push to start: new walkers, beginner runners, and anyone whose daily steps are mostly to the fridge. The screen is only for getting a quest and claiming the reward, and the real experience happens outside.

Demo

A note on testing: I wasn’t able to record a real outdoor walk before the deadline, so the route in this demo is a simulated GPS track generated with a small script. It tests the verification logic, but it isn’t a real outdoor test. The Sponsor Portal ran locally for these screenshots, and the repo includes a render.yaml for deploying it. Taking Verdant outside is my next step.

The quests Gemma generated
PASS route and PASS photo in the terminal
The Sponsor Portal showing VALID
The same voucher showing ALREADY REDEEMED
An edited voucher (bronze changed to gold) showing INVALID
Code

It’s one Python file for the quest master and one for the sponsor portal. Neither needs any extra packages, so a beginner can read all of it in ten minutes.

How I Built It

Verdant has four parts, and only two of them need AI.

Quests (Gemma, running locally). Verdant asks Gemma 3 through Ollama for quests in JSON, based on the user’s level, the season and the weather. If the model isn’t available, built-in quests take over, so the tool still works on a trail.
Route check (plain code, on purpose). A GPX track is checked for total distance, human pace and impossible jumps. A “5K run” averaging 45 km/h is a car, and a few lines of maths catch that more reliably than an AI model would. Using AI only where it helps was a real lesson for me.
Photo check (Gemma’s vision, locally). For quests like “a fallen autumn leaf”, the same Gemma model looks at the photo and answers yes or no. One model does both jobs, and the photo never leaves the machine.
Signed vouchers and the Sponsor Portal. A passed quest produces a voucher signed with HMAC-SHA256. The portal, a small standard-library Python server, verifies the signature, shows the reward, and blocks the same voucher from being redeemed twice. If someone edits a voucher to upgrade bronze to gold, the signature no longer matches and the portal says INVALID.

Only a hash of the track goes into the voucher, so sponsors never see where you walked.

What went wrong along the way: Gemma wrote long paragraphs for the photo instruction at first, so the photo check kept answering “No”. I fixed it by shortening the subject before sending it to the model and by asking Gemma for short photo subjects in the first place. I also hit install problems and a server that wouldn’t start. [Add one or two more in your own words.]

Why Does Open Innovation Matter?
It works without signal. Trails are where connectivity disappears. Because the model runs locally, quests and checks work in the woods.
Your location stays yours. GPS tracks and photos of your surroundings are very personal. They are processed on your own machine, and a sponsor only ever receives a signature and a hash.
I could swap the brain in one line. I started with one model for text and another for photos, then moved to a single Gemma model by changing two settings. With a closed API, a price change or deprecation could end the project.
It costs nothing to run. That matters if outdoor challenges are meant to be free for beginners and affordable for small local sponsors.
Sponsors can read the rules. The verification logic is open, so a sponsor can see exactly how a voucher was earned instead of trusting a black box.

Limitations: Outdoor testing was limited to a simulated route. Vouchers use a shared secret in this prototype, so public-key signatures are the next step. The “already redeemed” list lives in memory and resets when the server restarts, so a real version needs a database. The sponsors in the code are placeholders.