DEV Community: Mats Gustafsson

Ghost Hunter's Lab 👻

Mats Gustafsson — Sat, 31 Oct 2026 09:10:14 +0000

Hacktoberfest 2026 — Ghost in the Machine

What if I could change something inside an AI model, instead of just changing what I asked it?

Not the prompt. Not a system instruction. The model's own internal activity.

For this year's Ghost in the Machine challenge, I decided to take the theme literally.

I wanted to go ghost hunting inside an open-weight model.

And I found something interesting. Not a supernatural entity or a conscious thought, but a mathematical direction associated with ghost-related text.

The harder question was: what would happen if I changed it?

What I Built

The Ghost Hunter's Lab is a local AI interpretability experiment built around Gemma 3 4B IT, Gemma Scope 2 and llama.cpp.

I built a Python pipeline to extract a published sparse-autoencoder (SAE) feature direction, inject it into the model during inference, and compare the results against random interventions.

I also built an editorial website using FastAPI, Jinja2 and native CSS, with GSAP animations to bring the visual storytelling to life. The website presents the experiments, measurements and findings in a clear, structured format.

Live Project

Explore The Ghost Hunter's Lab

GitHub — Source Code and Scientific Evidence

Cinematic Sci-Fi Visualization

Watch the Ghost Hunter's Lab cinematic visualization

The video uses AI-generated cinematic illustrations to explain the investigation. The scientific measurements are taken from real experiments performed locally with Gemma, not generated by the video model.

The website presents recorded results rather than executing new inference when someone visits it.

The First Strange Result

I began with one unfinished sentence:

The mysterious figure was a…

The original model generated:

man

I applied the ghost-related SAE direction at strength +16.

It still generated:

man

Then I applied a random direction at the same strength.

Again:

man

So had nothing happened?

Not quite.

I inspected the probability assigned to the exact alternative next token " ghost" — including its leading space.

These are the results from the locally reproduced pilot:

Condition	Probability of `" ghost"`
Original Gemma	5.862800%
Ghost direction +16	6.131469%
Random direction +16	6.294708%

The surprising result was that the random direction raised the absolute ghost-token probability more than the ghost-related direction did.

Without a random control, I could have looked at the change from 5.86% to 6.13% and declared success.

That would have been misleading.

I also measured the relative log preference between " ghost" and " man". On that different metric, the SAE direction produced the larger shift.

The generated answer was unchanged, but the probability distribution underneath it had moved.

And different measurements revealed different aspects of the result.

This was an exploratory pilot, not the final evaluation.

The Ghost in the Machine

In 1949, philosopher Gilbert Ryle challenged Cartesian dualism in The Concept of Mind, using the phrase “the dogma of the Ghost in the Machine.”

He wasn't suggesting that machines were haunted.

I borrowed the metaphor for something different: investigating patterns inside an AI model.

Large language models contain many internal representations that are difficult to interpret directly.

Sparse autoencoders can help researchers break complicated internal activations into features that are easier to investigate. These features are not literal thoughts stored in individual neurons, but some correlate with recognizable patterns of text.

One feature in Gemma Scope 2 appeared associated with ghosts and spirits.

It became my experimental subject.

Where I Found the Tools — and How I Got Inside Gemma

This was one of the most interesting parts of the project, because I wasn't simply connecting to an API and sending prompts. I needed access to the actual model weights, an interpretability resource and an inference runtime that supported internal interventions.

1. Starting with Google DeepMind's Gemma Scope research

I began with Google's work on mechanistic interpretability and its published Gemma Scope 2 resources.

Google describes sparse autoencoders as tools for examining internal model representations. The release includes SAEs and transcoders for the Gemma 3 family.

These were my starting points:

The important discovery was that I didn't need to train a sparse autoencoder myself. Google had already published checkpoints that could be inspected locally.

That made this investigation possible within the challenge week.

2. Exploring the features with Neuronpedia

I used the public Gemma Scope 2 feature-exploration resources, including Neuronpedia, to understand how individual SAE features are organized and interpreted.

The relevant feature collection is:

Neuronpedia — Gemma 3 4B IT, Layer 22, Gemma Scope 2, 65K

This corresponds to a sparse autoencoder trained on Gemma's residual-stream representations at layer 22.

I selected feature #23871 as the ghost-related candidate to investigate.

But finding an interesting feature wasn't enough. I needed its actual numerical representation.

3. Downloading the original SAE checkpoint

Google hosts the Gemma Scope 2 checkpoints on Hugging Face:

google/gemma-scope-2-4b-it

I navigated to:

resid_post/layer_22_width_65k_l0_medium

Open the exact layer-22 checkpoint directory

This directory contains the SAE configuration and checkpoint data, including params.safetensors and examples.safetensors.

The parameter file contains the trained tensors needed to examine the SAE's mathematical feature directions.

Using Python and safetensors, I extracted the decoder direction corresponding to feature 23871.

The result was a vector of 2,560 float32 numbers.

I saved that direction locally as:

ghost-23871.f32

That small file represented the direction I would later inject into Gemma.

It wasn't a separate AI model, a prompt, or a piece of executable code. It was the mathematical direction extracted from the SAE.

4. Downloading Gemma 3 to run locally

Next, I needed the actual language model.

I chose Gemma 3 4B IT, using a Q4_K_M quantized GGUF version so it could run on my Debian computer.

I obtained the model from:

bartowski/google_gemma-3-4b-it-GGUF on Hugging Face

The downloaded model was approximately 2.4 GiB on disk.

Initially, I tested it using llama-cli, running prompts directly from the terminal.

This mattered because I wanted to verify that ordinary local inference worked before trying any intervention.

The model ran locally and generated normal responses.

I now had the base model and the extracted SAE direction.

But I still needed a way to connect them.

5. Opening the model's inference process with llama.cpp

I used llama.cpp, an open-source inference runtime that supports local GGUF models.

Its control-vector functionality was the critical piece.

Instead of editing the stored model weights, I could supply a mathematical direction and apply it during inference.

I converted the extracted float32 direction into a GGUF control-vector file containing a layer-specific tensor named:

direction.22

I then used llama.cpp's control-vector options:

--control-vector-scaled
--control-vector-layer-range

The experiment applied the ghost-related direction at layer 22, at strength +16.

Conceptually, the intervention was:

modified activation = original activation + strength × feature direction

This is activation steering.

It doesn't permanently rewrite Gemma's weights, and it doesn't prove that the feature represents a complete, independently stored concept.

But it lets me make an intervention and measure the consequences.

6. Building controls instead of trusting one result

I didn't want to mistake ordinary model sensitivity for evidence of a ghost-specific effect.

So I created five independently seeded random directions, using seeds 2026–2030.

Each random vector was normalized to match the norm of the extracted SAE direction.

That gave me a comparison between the original model, the SAE-derived intervention and several arbitrary directions of the same length.

With the experimental environment configured, I could finally ask the important question:

Does this particular direction produce a distinguishable effect?

Testing Against Five Random Directions

One prompt wasn't enough.

I created and committed a fixed dataset of 20 prompts before evaluating it. The prompts were new to that evaluation, although I had already learned from the exploratory pilot.

I then tested seven conditions:

Unmodified Gemma.
Ghost SAE direction at +16.
Five norm-matched random directions at +16.

That produced 140 recorded prompt-condition observations.

I measured the change in the log probability of the exact " ghost" token relative to the unmodified model.

The Held-Out Results

Direction	Mean Δ log P(`" ghost"`)
Ghost SAE +16	+0.01639
Random 2026	−0.04937
Random 2027	−0.00643
Random 2028	−0.03373
Random 2029	−0.03016
Random 2030	−0.03679

A positive value means the target token became more probable relative to baseline. These numbers are changes in log probability, not percentage-point changes.

The ghost direction had a higher average shift than all five sampled random directions.

It increased the target token's probability on 13 of 20 prompts.

But seven prompts shifted negatively, and on only 6 of 20 individual prompts did the SAE direction outperform every random control on the primary metric.

I also measured the change in ghost-versus-man log preference.

The SAE direction had a positive mean of approximately +0.04222, with 11 of 20 positive prompt shifts.

This wasn't evidence of a reliable ghost switch. It was a small, variable effect in a deliberately selected experimental setting.

Did I Change Anything Else?

My question wasn't only whether a ghost-related prediction could move.

I also wanted to understand whether unrelated predictions changed.

I created another frozen set of 12 prompts spanning geography, colors, language and everyday knowledge.

I compared baseline, ghost steering and one random direction.

That produced 36 additional observations.

Intervention	Mean absolute change in expected-token log probability
Ghost +16	0.04995
Random +16	0.07932

The ghost intervention changed unrelated next-token predictions too.

The random direction produced a larger average absolute shift on this particular probe set, but that doesn't establish that the SAE intervention is generally safer or more selective.

These were exact-token probability measurements, not a complete model-accuracy or general-reasoning benchmark.

I couldn't conclude that all unrelated capabilities were preserved.

Nor could I conclude that the model had been damaged in a broader sense.

What I could conclude was that the intervention had measurable effects outside the target context.

Turning the Investigation Into a Website and Film

Once the scientific measurements were complete, I wanted to make the work understandable without expecting visitors to run a multi-gigabyte language model.

I built the Ghost Hunter's Lab website using:

Python, FastAPI and Jinja2.
Native CSS with locally hosted Poppins.
GSAP and ScrollTrigger for editorial animations.
A verified JSON export of the recorded scientific evidence.

The website is hosted on Render and reads the committed evidence snapshot.

It doesn't run Gemma inference for visitors. The original experimental inference ran locally on my Debian machine.

I also created a cinematic video using Seedance-generated visual illustrations, then combined the footage with accurate scientific findings and a soundtrack.

The model-layer imagery is conceptual artwork, not a scan of real internal activations.

The results and statistics are from the local experiments.

Why Open Innovation Matters

This project would have been fundamentally different with a conventional closed text-generation API.

A hosted API could let me ask a model for a spooky story.

But it wouldn't ordinarily give me the model weights, the ability to inspect an independently published SAE decoder direction, or the ability to inject that direction at a selected internal layer.

The combination of Gemma's accessible weights, Gemma Scope 2's published interpretability checkpoints and llama.cpp's open-source inference runtime let me investigate something below the text response.

I could reproduce the local setup, construct my own controls, measure probability changes, and inspect effects beyond the target prompt.

That's the value of open-weight research: it makes experiments possible that are difficult or impossible through ordinary text-only APIs.

What I Learned

The most useful finding wasn't a dramatic haunted response.

It was seeing how easy it would have been to misinterpret one measurement.

A ghost-related direction increased the probability of a ghost-related token.

But so did a random direction — and by more on the original pilot's absolute probability measure.

Across the larger evaluation, the SAE direction had a stronger mean than the five sampled controls, but its effects remained inconsistent.

And unrelated predictions changed too.

I learned how to explore published interpretability resources, extract an SAE direction, run local Gemma inference, perform activation steering and build reproducible evaluations.

I also learned why good controls and careful limitations matter more than a spectacular-looking demonstration.

I moved an internal signal. I didn't erase a ghost.

Weight-level exorcism remains an experiment for another day.

For Halloween, I think that's a more interesting ending than pretending I found a magic switch.

Project Links and References

Live Ghost Hunter's Lab

Source Code — GitHub

Scientific Evidence and Reproducibility Report

Cinematic Sci-Fi Visualization

Research resources:

Prize Category

Best Use of Gemma — The scientific investigation uses locally running Gemma 3 4B IT, Gemma Scope 2, and activation steering to measure internal interventions.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 4: Ghost in the Machine.

Mr. Pending 🐌 — Even Small Things Can Do Great Things

Mats Gustafsson — Sun, 25 Oct 2026 11:58:59 +0000

One snail. One blue button. An entirely unnecessary engineering department.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Meet Mr. Pending, Chief Engineer of The Department of Unnecessary Engineering.

His mission? Press one blue button.

Most people would simply press it. Mr. Pending is a snail with professional standards. Naturally, he requires blueprints, machinery, testing, repairs and an unreasonable amount of paperwork.

Behind the joke is a real experiment: a small open-weight AI model designs ridiculous machines, and a simulator tests whether they actually work.

If a machine fails, the AI receives feedback and tries to repair it.

You press one button. The Department handles the rest.

Why a snail instead of a sloth?

The Slow and Steady theme immediately made me think of a sloth. But a snail felt even funnier: slow, determined, and completely serious about doing a very simple job in the most complicated way imaginable.

The sloth didn't appreciate being passed over.

So it occasionally interrupts the Department's proceedings.

Fortunately, Mr. Pending has a response:

"This is why we employ snails."

Don't worry. The sloth is only a visual joke. It doesn't interfere with the actual simulation.

Demo

🐌 Visit The Department of Unnecessary Engineering

Press the blue button and watch the machinery come alive!

Watch the promotional video

The public site is a replay, not a hosted AI service: it plays builds recorded on my laptop and re-checks every result in the browser. Gemma runs locally through Ollama, designing new machines and proposing repairs after the simulator tests them. The site lets anyone explore the genuine results.

Code

Moonchichiii/mrpending on GitHub

Open source, with the simulator, evaluation results and local setup instructions included.

How I Built It

The local installation runs on Gemma 4 E2B through Ollama, behind a small Mastra-based agent that owns one loop: design, simulate, repair.

The stack includes:

React 19, TypeScript and Vite+ for the interactive experience.
SVG and CSS animations for Mr. Pending and the machinery.
Zod for structured AI output validation.
A deterministic TypeScript simulator to test every machine.
Render for the public static replay.
ElevenLabs for 20 prerecorded lines in Mr. Pending's Alistair voice.

The process is simple:

Gemma designs → Simulator tests → Gemma repairs.

Gemma places mechanical parts — ramps, seesaws, conveyors, fans, dominoes and catapults — on a grid. The simulator then determines what actually happens.

Gemma cannot simply declare success.

What actually happened?

I tested three model-and-prompt configurations, with 15 headline builds each.

Configuration	Successful button presses
Gemma 4 E2B, prompt v1	0/15
Gemma 4 E2B, prompt v2	2/15
Gemma 4 E4B, prompt v2	4/15

Every successful press came after an AI-proposed repair.

E4B achieved more successes in this small test, but used significantly more memory. I chose E2B with prompt v2 for the release because it was more practical on the test laptop.

Most machines failed. That wasn't a bug in the experiment. It was the experiment!

And whenever a machine succeeded, the simulator—not the AI's confidence—verified it.

One thing I learned the hard way

I spent too much time perfecting infrastructure, tests and agent workflows before properly testing the actual experience.

The code worked. The first interface didn't.

Instead of a funny snail and a blue button, I'd built something closer to an engineering administration portal.

The solution was to return to the original idea: one character, one button and one animated blueprint.

A useful reminder that passing tests and making something enjoyable are two different achievements.

Why Does Open Innovation Matter?

I wanted to explore what a small AI model could accomplish on an ordinary computer.

Running Gemma locally allowed me to experiment with prompts, compare model sizes, inspect failures and reproduce results without relying on a paid cloud inference API.

More importantly, the open approach allowed me to keep the model's role narrow and measurable.

Gemma proposes the engineering. The simulator independently checks it.

The project demonstrates that small models don't need unlimited autonomy to do something interesting.

Sometimes a clearly defined task, useful feedback and another attempt are enough.

My Agent Session

I used Claude Code for implementation and Codex for independent reviews, alongside GitHub issues, CI checks and hands-on browser testing.

The biggest lesson? AI coding agents can produce plenty of technically correct work while still missing the intended user experience.

Human creative direction and actual product testing remain essential.

Even small things can do great things. 🐌💙

Wiggle Outside: weather, nearby places and a little inspiration in one short search

Mats Gustafsson — Sun, 11 Oct 2026 23:52:58 +0000

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

What I Built

Before we can get outside, there's the planning: check the weather, find somewhere nearby, then think of something the kids might enjoy. By the time you've done all three, the moment has often passed.

I signed up for this challenge on Friday evening with one idea: put those steps into one quick search that answers the question a parent actually has: where do we go, what do we do there, and what do I need to bring?

Wiggle Outside is that search. You say who's coming (just you, or you and the kids, with their age groups), how much time you have, how much energy is in the room, whether there's a stroller, and roughly where you are, typed or from your device's location. Optionally, you say what they're into right now, in your own words.

Here's the search from the demo video: Capitol Hill in Seattle, a 3–5-year-old, two gentle hours, a stroller, and "dogs, birds and pointing at everything". Back come up to three outdoor ideas, each an activity from a reviewed list paired with a real nearby park or playground when the map data has one; in the video, Nature bingo and a Leaf colour hunt. Each says why it fits and roughly how far it is, links to the place on OpenStreetMap, and opens a detail page with simple steps, another way to play, a safety line and a question to ask on the way home. Below the ideas, "Before you go" lists what to pack for that forecast, those ages and those activities, with a snack idea.

One thing changed late in the build. Parents often plan in the evening, after the kids are asleep, and my first version simply said "come back tomorrow". Now evening family searches can plan ahead for the next morning, using that outing's forecast and daylight. Between midnight and 04:30 it suggests getting some rest instead.

It's for parents and carers of children up to 12 who want to get out of the door without another round of planning, and for adults on their own who need a small escape.

Demo

Live: wiggle-outside.fly.dev

▶ Watch the demo video (46 s)

The short intro and outro animations in the video are AI-generated; everything in between is a real screen recording of the live app, with the form entry sped up 2×.

A few things worth knowing before you try it:

The weather decides first. If the forecast says thunder, freezing rain, heavy snow or strong wind, you won't get ideas, and the page says why.
Families get daylight-only ideas. Evening family searches can plan ahead for the next morning, using that outing's forecast and daylight. The solo path can offer eligible evening activities, with lit-path notes.
You can search other places too; times, sunrise and sunset follow the place you search, not your device. Map coverage and the ideas available vary from place to place.
While the search runs (it can take up to 20 seconds) you'll see "Tying shoelaces…".
"Before you go" is a reminder built from fixed rules (forecast, ages, time, the chosen activities), not a complete list and not safety advice.

Code

Moonchichiii / wiggle_outside

Wiggle Outside

Find a realistic outdoor activity near you, for the next hour or two, then put the phone away.

Answer five short questions — who is coming, how long you have, how much energy, where you are, anything to account for — and Wiggle Outside offers up to three grounded ideas, each one a nearby place from OpenStreetMap paired with a reviewed activity that suits the forecast, the daylight and the ages you named. If nothing suitable exists right now, it says so rather than padding the list.

Built for the Hacktoberfest Open-Source AI Challenge, Week 1 ("Touch Grass").

Live app: https://wiggle-outside.fly.dev
DEV post: https://dev.to/moonchichiii/wiggle-outside-weather-nearby-places-and-a-little-inspiration-in-one-short-search-25cc
Specification and decisions: docs/, indexed in docs/README.md

Run it locally

Requires uv, bun and PowerShell 7.

uv sync --all-groups
$env:WO_CONTACT_EMAIL = "you@example.org"      # Nominatim's usage policy wants a contact
$env:OPENROUTER_API_KEY = "...

…

View on GitHub

FastAPI and Jinja render plain HTML on the server, with one small script for "Use my location" and the loading state. Tailwind 4 for styles, SQLite for caches and the daily quota, Fly.io for hosting. Around 1,700 automated tests, strict type checking, and an Apache-2.0 licence for the code. (The display fonts are licensed separately and aren't in the repository; a clone falls back to system fonts.)

On an emulated mid-range phone over slow 4G, Lighthouse scored the live form page 100 for performance, accessibility, best practices and SEO.

How I Built It

From concept board to the shipped page

The original concept board, made with ChatGPT. The shipped app keeps its palette, hand-drawn frame and margin illustrations, with a simpler single-column form. The screenshots above are the real app.

Gemma chooses; rules decide what's possible

The design is a split of responsibilities.

Deterministic rules decide what's possible. Each of the 26 activities in the reviewed list (19 for families, 7 for adults alone) carries its own limits: age groups, minimum temperature, maximum wind, rain tolerance, whether it needs daylight, what kind of place it suits. The app fetches the forecast from Open-Meteo and nearby places from OpenStreetMap (Nominatim to find the town, Overpass for parks and playgrounds), then filters everything down to eligible pairs: this activity, at this place or needing none, for this time window.

Gemma chooses among them. When eligible pairs remain and the model is available, Gemma 4 26B A4B receives them as IDs, each with the hooks and reasons it may use, plus the optional "what are they into?" text. It ranks up to three pairs, picks a hook and reasons for each by ID, and maps the family's text to a small reviewed vocabulary of interests. That's the language part: turning "birds and puddles" into tags and putting Nature bingo and the Puddle jumping championship ahead of a Shape safari.

You can see its work on each card: the reasons it picked ("It's close by", "It's the right season for it") and the interests it recognised ("Matches: animals, birds"). Gemma never writes the text on the page and never invents a place: the cards, reasons and interest labels are rendered from reviewed copy, chosen by the IDs it returns. I tried letting it write a short personal note per idea and took it out again the same night: a length limit and a character filter can't make a sentence shown to parents of toddlers safe, so the reviewed-text boundary stayed. Its answer must match a strict JSON schema, and the app then validates every field. Unknown pairs, disallowed hooks or reasons, duplicates and repeated activities are dropped, never repaired, and cards are built only from what survives.

In a controlled run with live geocoding, forecast and model but fixture places, Gemma read "birds and puddles", picked two valid pairs, and the page rendered exactly those two cards; the model call took about 1.8 seconds. The search in the demo video ran fully live against the deployed app: real geocoding, real places, real forecast and the hosted model. The server log for it reads source=model ideas=2: Gemma made the selection. The whole search, measured on the server, finished in about 1.5 seconds, but I had searched the same area while preparing the demo, so places and forecast may have come from cache; it isn't a cold-start time.

From suggestions to a plan you can leave the house with

My first version stopped at the ideas, and it felt flat. A parent doesn't only need what; they need where and what to grab on the way out. So the results page now leads with one short notice instead of a stack of them, shows each idea's reasons and place, links the place on OpenStreetMap by its own map ID (no coordinates of yours in the link), and ends with "Before you go". The packing list is deliberately rules, not AI: weather items come first, then the little ones' essentials, then each activity's own bits, at most ten, with "Your usual age-appropriate snacks and drinks" whenever a baby is in the group.

Hosting the open model, and what it sees

Gemma runs hosted, through OpenRouter, with tight limits:

The API key can call only this one model, with a small spending cap.
Routing is restricted to three providers I chose because OpenRouter's published data policy lists them as neither training on nor retaining prompts. That is the basis of the privacy note, and I describe it that way rather than claiming more.
Requests ask for strict structured output, reasoning off, at most 256 output tokens. A search costs a fraction of a cent.

The request deliberately leaves out your typed town, coordinates and place names: the model sees activity titles, place kinds (park, playground) and distance bands. Your optional interests text is sent as typed, which is why the form asks you not to include personal details. In the app, the raw text stays in server memory with your search for about an hour, as the form says (up to two hours in your session if you had to pick between towns with the same name), and is never written to the database or the logs. What the results page keeps is the recognised interest tags.

A 20-second budget, and what happens when things fail

Every search runs under one 20-second deadline: about 3 seconds to find the place, 9 for places and weather together, 6 for the model, and 2 reserved for building the page. Whatever earlier steps use comes off the later ones, and the overall deadline always wins.

When something fails, the app says so:

Model unavailable or its answer unusable: a deterministic ranking picks from the same eligible pairs, and the page says the AI selection wasn't available.
Nearby places unavailable: if activities that need no particular place are still eligible, Gemma chooses among those and the page says places couldn't be loaded. If nothing remains eligible, the page explains why it can't recommend anything.
The public Overpass instance doesn't answer: the second attempt goes to one alternative public instance, inside the same time budget.
Repeat searches: an identical submission while the first is still running or fresh joins it instead of starting again. Place lookups are cached for days and forecasts for minutes, so OpenStreetMap's free services receive fewer repeat requests while cached data remains fresh.

What I learned when real services pushed back

Overpass timed out. On Sunday afternoon my place queries to the public Overpass instance returned 504s after 7–9 seconds, where the same query had taken 2–3 seconds that morning. That's why the places stage has its own budget, why results are cached, and why the place-free path exists.
Structured output support isn't uniform. My first live calls failed because a provider's constrained decoder didn't support uniqueItems in the JSON schema. I removed it from what's sent and kept uniqueness in my own validation, with tests proving duplicates can't reach the page.
The model needed one more rule. When only place-free activities were left, Gemma read the interests but picked nothing, so every such search fell back. One added prompt rule fixed it, confirmed with live calls on that case.
The rules sometimes say no, and that's correct. My first fully live attempts from London and Dublin in the early evening came back with "Not enough daylight for this one": a one-hour family outing starting at 18:09 would end after sunset. That's also what pushed me to plan ahead for the next morning instead.

How I worked

I built this over the weekend with AI agents; I retained responsibility for product decisions and reviewed the agents' output. Claude Code wrote and tested the code against a written plan, ChatGPT drew the design and reviewed the plan and this post, and every change went through a tracked decision before it landed. The reviews earned their keep: one caught that I was about to call a test run "warm" when nothing had been cached, another that the privacy wording promised more than the code did, and a third talked me out of letting the model write free text on the page. The most useful feedback came from home, though: my partner pointed out that parents plan in the evening, after the kids are asleep, which is why the app now plans ahead for the next morning.

Why Does Open Innovation Matter?

Three different kinds of openness make this app possible, and they matter in different ways.

Open weights. For this entry I use hosted Gemma through OpenRouter. Because the weights are published, the model itself isn't tied to that service: moving inference elsewhere would still take suitable hardware, integration work and fresh testing, but it's an option available under the model's licence terms.

Open data. The places come from OpenStreetMap, mapped by volunteers who decided a playground or a picnic spot was worth recording, and the forecast comes from Open-Meteo. Those services make a small project like this practical. They also create responsibilities: attribution, caching, respecting usage limits, and being honest when data isn't available.

Open code. The application is Apache-2.0 licensed, so the next person can take the rules, the tests or the whole thing.

This version needs an internet connection and depends on hosted services today. The open approach gives me more control over where it goes next; it doesn't make hosting free.

Limitations

The packing list and snack idea are simple reminders from fixed rules, not advice for any particular child.
Distances are straight-line estimates. The app can't check paths, access, hazards or opening times. You choose the adventure and judge the conditions.
The weather is a forecast, and each activity's limits are my own product judgements, not safety standards.
The three activities open to babies have a 5 °C minimum. Two of them are shared with older children, so below 5 °C they disappear for the whole family, and families with a baby will see few or no ideas.
Each activity has one accessibility adaptation line. That's a start, not full inclusive design.
Nearby places depend on the public Overpass service; when it doesn't answer in time, you'll see a labelled message.
The interface is English only.

Prize Categories

Best Use of Gemma. Gemma 4 26B A4B is the selection step: when eligible ideas remain, it reads the family's interests in their own words and chooses among validated activity-and-place pairs, with a strict schema, validation and a labelled fallback, and the reasons and recognised interests it chose are shown on every card.