FIELD_NOTES.md

# No signal, no GPU, no second chances: building an AI for the woods

Picture the worst possible place to run a machine learning model. No cell signal.
No cloud to phone home to. No GPU, just a Raspberry Pi and a little accelerator
chip the size of a stamp, running off a battery I've been babying since sunrise.
And the user? The user is standing in a damp forest about to decide whether to put
something in their mouth.

That's foraging. That's the actual deployment target. I'm not shipping a chatbot
that gets to be wrong in an interesting way. I'm shipping a thing that, if it's
confidently wrong, helps somebody have the last bad afternoon of their life.

So when people ask why my models are so small, I laugh a little. Small isn't the
compromise here. Small is the only thing that survives contact with the woods. The
whole project is a study in constraints, and honestly, the constraints did most of
the design work for me. I just had to stop fighting them.

Here's the stack: a domain router plus three expert classifiers, all
`tf_efficientnet_lite2`, about nine million parameters each. Four models, roughly
0.04 billion parameters total, which in the year of our lord 2026 is a rounding
error. They run offline on the device and they run on a plain CPU, no GPU required.
That's not me being humble. That's me being a forager with a dead phone two miles
from the trailhead. The "edge" everybody name-drops is, for me, just Tuesday.

## Constraint number one: the model is not allowed to vote

My first real architecture was clever and I was proud of it, which is usually the
tell that something is about to go wrong. The router would decide a photo was a
"plant," then I'd run two expert models on it and take whichever was more
confident. Max confidence wins. Democratic. Elegant.

It also tried to feed people poison hemlock.

Here's the failure, and it's a beautiful one. A deadly plant — say, poison hemlock —
gets routed to "plant." My high-value forageables expert has never seen hemlock in
its life, but it has seen ramps, and hemlock and ramps are cousins that have killed
people who confused them. So the high-value model looks at a deadly plant and
announces, at 0.9 confidence, that it's ramps. Delicious ramps. Meanwhile my
medicinals expert, the one that actually knows hemlock is death, correctly flags it
as deadly at lower confidence. Max confidence wins. The confident idiot
out-votes the cautious expert. In my tests this leaked deadly-as-edible about six
percent of the time, and not one of my per-model benchmarks caught it, because no
single model was ever wrong. The *system* was wrong.

So I killed the vote. Now the router picks exactly one expert and that expert owns
the call, full stop. The mushroom expert never sees a plant, so it can never call a
plant anything. On top of that, any "deadly" verdict vetoes a more-confident "safe"
one, because in this domain a false reassurance is the only error that actually
matters. Deadly-as-edible dropped from around six percent to half a percent. The
constraint — keep it small, keep it dumb, keep the experts in their lanes — turned
out to be the safety feature.

## Constraint number two: being safe is really easy if you don't mind being useless

Now the push and pull. Once you've been spooked by a near-miss, the temptation is to
crank every safety dial to the max. Refuse by default. When in doubt, abstain. Very
responsible. Very noble.

It's also how you build a tool nobody uses. I pushed the confidence gate up and
watched the thing turn into a coward. It started abstaining on blackberries.
Blackberries. At the safe-but-useless end of the curve it would refuse on roughly
half of perfectly edible finds, which is a fantastic way to teach your users that the
gadget is a paperweight and their own guessing is faster. And here's the part that
took me an embarrassing while to accept: you cannot gate your way to zero. I mapped
the whole curve. Loosen the gate and you get a decisive, useful tool that
occasionally calls something dangerous safe. Tighten it and you get a safe tool that
cries "I don't know" at a raspberry. There is no magic threshold that gives you both,
because the residual risk isn't low confidence — it's the model being confidently,
specifically wrong, and no confidence knob catches that.

Tightening the screw was a dead end. So instead of asking the model to be more sure,
I started asking it for more evidence.

The move we landed on — and I'll be straight, this lives in a test harness right now,
not in the shipped app yet — is to stop treating one photo as the whole story. Show
the model the same subject from a couple of angles, or even just a few augmented crops
of the one shot, and fuse the results before it commits. In our harness this was
close to a free lunch: the multi-angle version drove deadly-as-edible toward zero on
the domains we tested while *lifting* accuracy on the safe stuff, not crushing it.
Even better is making the second photo a targeted ask — only when the top guess is a
safe-looking thing that has a deadly twin. The app turns to you and says "okay,
photograph the stem before I sign off on this." The friction is the feature. The
moment of "hang on, show me more" is exactly the moment a careful forager would slow
down anyway. We're not nagging with a banner nobody reads; we're building the caution
into the interaction. That part's still being wired in, and I'll write it up properly
when it is.

## The one-line bug that told me my safety net was broken

A short detour into humility, because this is a field notes post and field notes
should include the faceplants.

For ages I believed my out-of-distribution detector didn't work. This is the piece
that's supposed to notice when you point the camera at, I don't know, a car, or your
own shoe, and say "that's not food, I'm not playing." I was using an energy score for
it, and every time I measured the thing it scored about 0.25 AUROC, which for the
non-nerds means it was worse than a coin flip. Inverted. Useless. I shelved it and
moved on, mildly betrayed.

Then I actually read my own code. The energy formula subtracts the max value for
numerical stability and is supposed to add it right back. Mine subtracted it and
forgot to add it back. One term. That single missing piece didn't just make the
number wrong, it flipped its meaning, so my detector was confidently pointing the
wrong direction the entire time. Fixed the one line, re-ran it, and the same detector
jumped to around 0.90 AUROC on my hardest domain. It had been working all along. I
had been reading the dial upside down.

The lesson I keep taped to the inside of my skull now: when a detector says it's
failing, check that you're not holding it backwards before you believe it. SHOCKING,
I know.

## The actual thesis

Here's why I think the constraints were a gift and not a punishment. When you've got
a giant model and infinite compute, you can paper over hard calls. You can be a
little wrong everywhere and call it nuance. Out here, on a stamp-sized chip in a
forest, there's nowhere to hide. Every tradeoff has to be made out loud: do I want
decisive or do I want safe, and where exactly do I put the line, and who gets hurt at
each setting. The edge didn't limit the engineering. It made the engineering honest.

Which, now that I say it out loud, is the whole reason I'm doing any of this. When
everything else goes digital and frictionless and confident, the stuff that keeps you
alive is still physical, still slow, still asks you to look twice. I built a machine
that's good enough to be worth beating. The goal was never to replace the forager. It
was to keep them sharp.

Or so I tell myself, two miles from the trailhead, photographing a stem.

What would you have done at the safety-versus-useful fork — held the line on refusing,
or chased the second photo? And what's the dumbest one-line bug that ever cost you a
week?