devchallenge, #hf26challenge
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
Most birding apps want you to stare at your screen while you're trying to listen. I wanted the opposite.
Field Notes is a local-first bird journal that turns a walk into a field log. I start a recording on my phone, put it in my pocket, and go outside. Back at my laptop, an open-weight bird sound model analyzes the recording, logs detected species to a local database, updates my life list, and generates a short journal entry about the walk.
The interface has two main jobs: letting me start a recording and helping me read the recap. Everything in between is designed to stay out of the way.
I built it for people who would rather pay attention to the birds than their screens, and who want to explore AI-assisted birding without sending their recordings and location data to a cloud service.
Demo
Watch Field Notes in action:
โถ Watch the Field Notes Demo
Code
GitHub repository: https://github.com/RAMBO-LC/mlh-d2
The README includes setup instructions, model information, license links, and commands for reproducing the project's tested behavior.
How I Built It
The pipeline is designed to run locally on my 16 GB M5 MacBook, using the CPU rather than a dedicated GPU.
1. Bird identification with BirdNET
Field Notes uses birdnet-analyzer 2.4.0 to analyze audio in three-second windows and identify potential bird species. BirdNET can use location and time of year to narrow its candidate species.
The distinction between model weights and software licenses matters here: BirdNET's code is MIT-licensed, while its model weights are licensed under CC BY-NC-SA 4.0. That means the weights have non-commercial and share-alike conditions; I don't treat them as unrestricted commercial assets.
License: BirdNET Analyzer repository
2. Journal generation
The journal is designed around a locally running language model through Ollama, with Gemma 3 as the intended model.
The journal's job is to turn the detection log into a readable account of the walk, not to invent wildlife sightings.
Model and terms: Gemma ยท Gemma Terms of Use
Before publishing, specify whether the journal was generated by actual Gemma output or by a deterministic template. Don't claim a successful live model run unless you've verified it.
3. Local storage and interface
SQLite stores walks, detections, and the life list. A lightweight local web interface supports recording uploads, journal recaps, exports, and deleting saved data.
The goal is to keep the workflow understandable and the data under the user's control.
4. Development tools
I built the project with OpenCode.
Keeping AI-Generated Journals Grounded
Language models can confidently invent species, so Field Notes is designed with safeguards.
The journal-generation instructions tell the model to:
- Use the detection log as the source of facts about the walk.
- Describe low-confidence identifications as uncertain.
- Label general bird trivia as unverified rather than presenting it as an observation.
A validation step checks the generated journal against the detection log. If it mentions a species that wasn't detected, the system attempts one regeneration before falling back to a plain template.
The test suite includes a case in which the journal invents a Bald Eagle, allowing the validation logic to be checked against a concrete failure.
These safeguards don't establish that every identification is correct. They address a narrower problem: preventing the journal from presenting unsupported species sightings as facts.
The initial synthetic-audio test produced zero detections, as expected. That established a basic test case, not real-world accuracy. Field testing is necessary to evaluate how the system performs with actual outdoor recordings.
Why Does Open Innovation Matter?
It can run locally
The architecture is designed to keep audio analysis, journal generation, and storage on the user's machine. Local inference avoids making a cloud AI service a requirement for every walk.
Important: claim fully offline operation only after testing the complete workflow with external network access blocked.
My recordings and location stay under my control
Recordings and audio clips are stored locally, and the log lives in a local SQLite database. GPS is disabled by default.
The project also provides fieldnotes wipe --yes and a delete-all button for removing saved data. These are intended to make data deletion explicit rather than leaving users to hunt through application files.
No per-walk API charge
The intended workflow doesn't require a paid cloud inference API or an API key. Running locally still requires suitable hardware, storage, and the time needed to download and initialize the models.
Open models require reading the fine print
Open innovation isn't just about being able to download a model. The licenses and terms determine what people can actually do with it.
BirdNET's model weights carry non-commercial and share-alike conditions. Gemma 3 has its own terms of use rather than an OSI-approved open-source license. Both distinctions matter when building something that other people might want to reuse.
The trade-offs are real
Local AI isn't automatically the easiest option.
- Setup takes time. Model downloads can be substantial, and first-time setup is more involved than calling a hosted API.
- Hardware matters. Inference speed depends on the machine and the models being used.
- Detection isn't certainty. Background noise, overlapping calls, and similar-sounding species can make identification difficult.
- Generated prose needs validation. A fluent journal entry isn't proof that the underlying identification is correct.
The project is an experiment in making local AI useful outdoors, not a claim that local models have eliminated these limitations.
The Walk
This is the part that matters most: taking the project outside and seeing what happens when the inputs aren't synthetic.
- When and where: [Date, general location or habitat, and walk duration]
- What it identified correctly: [Species you independently confirmed by ear or with a field guide]
- What it got wrong: [False positives or incorrect identifications, including confidence scores if available]
- What it missed: [Birds you heard but the system didn't log]
- One surprise: [A specific moment, sound, or result from the walk]
- Screen time: [What you actually did with your phone during the walk]
The point isn't to prove that the model is perfect. It's to find out whether the tool helps me spend more time listening and less time looking at a screen.
[Add one closing sentence in your own voice about whether Field Notes made the walk better.]
Prize Categories
- Best Use of Gemma: Include this only if you actually ran Gemma locally and verified its journal output.
- Other challenge categories: Mention any additional category only if the project genuinely qualifies.
Solo submission.
Top comments (0)