DEV Community: Yash Anand

Dead Air: six records, two deductions, and a voice the archive almost lost

Yash Anand — Wed, 28 Oct 2026 16:47:36 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

An abandoned radio station has a story on file. Its own records give you a reason to doubt it.

Dead Air: The Last Sign-off is a short, original browser mystery set around a fictional station's final broadcast. Tune three channels, recover six records, and support two deductions with evidence. The tension comes from a disagreement between sources: which account deserves to become the official story?

For “Ghost in the Machine,” I chose a quiet haunting: a voice preserved in an archive, waiting for someone to read the evidence carefully. There are no jump scares. The player restores what the records support, while accepting that some things remain unknown.

The practical goal is modest and specific: give someone a complete, low-friction mystery they can play in a browser during a short break. No account, microphone, API key or installation is required. The full story can be read without sound. Optional local AI helps a player find source passages in their own words; a comparison desk lets them place two recovered records side by side. The final reasoning stays theirs.

Demo

Play Dead Air on Vercel · Read the spoiler-free player guide

Watch the approximately 40-second scripted preview. This demonstrates the interface; it is not a human playtest. It stops before the ending.

Allow roughly 10–15 minutes for a first play; that is a suggested time allowance, not a measured player average.

To try it:

Select Enter the archive, then explore the three channels using the station buttons or frequency slider.
Open the available records. Revisit their transcripts in Your evidence.
Choose a conclusion and exactly two supporting records, then select Check the evidence.
Follow the records unlocked by your deduction. Hints are available if you get stuck; later hints reveal the solution.

A wrong answer preserves progress. The investigation saves in this browser when local storage is available, so you can leave and return on the same device and site. Reset asks for confirmation.

Optional AI: select Enable on-device AI, ask about the discovered records, then inspect the retrieved passages and open their full source records. First use downloads about 44 MB of model and runtime files. If that is inconvenient, the manual topic buttons let you finish the whole case without downloading the model.

Sound is optional. Receiver ambience is synthesized; transcript narration, where available, uses a local device voice. The interface also offers reduced motion and keyboard controls.

Code

Source code, setup instructions and license

The application is MIT-licensed. Model, runtime and font notices are included separately. It is a static React/TypeScript application built with Vite and hosted on Vercel, with a GitHub Pages deployment as well.

How I Built It

A bounded role for an open model

Dead Air uses the open-weight Xenova/all-MiniLM-L6-v2 embedding model through Transformers.js and ONNX Runtime in a browser worker. Pinned model and runtime files are served with the application.

The model searches 12 exact passages from the six authored records. Only records the player has already recovered enter the search corpus. Results show up to three excerpts from distinct source records, each linked to its full transcript. Authored search descriptions help index the passages, but only verbatim evidence is displayed.

The flow is:

Question → local embedding → recovered-passage ranking → exact excerpts and source links → player interpretation.

Story progression follows a separate path:

Selected conclusion + two selected records → deterministic validation → next stage.

That separation keeps retrieval from rewriting a clue or accepting an unsupported conclusion. Source permissions are checked before inference and again when results are displayed. Questions are processed in the browser rather than sent to an inference service.

The test that changed the interaction

An earlier version automatically opened the best-matching topic. On a small diagnostic set, it routed only 14 of 23 in-scope questions to the expected topic; a simple keyword comparator managed 15 of 23. That was a reason to change the interaction.

An intermediate design presented topic suggestions for confirmation. Expected-topic recall was 21/23 on the same in-scope queries. Because those queries informed development, this is a diagnostic result, not independent validation or evidence of a general advantage over keyword search. Suggestions can still miss the player's intent, which is why manual topics remain available.

The October 29 upgrade gives retrieval a more concrete task: finding passages rather than routing to one of four topic buttons. A new 12-query authored diagnostic found an expected source among the first three results in 12/12 semantic queries and 10/12 keyword queries; the top result was an expected source in 9/12 and 6/12 respectively. The corpus is tiny and the questions are development diagnostics, so these results are not independent validation or a measurement of player benefit.

What has been verified

22 automated tests cover progression, retrieval permissions, invalid scores and the worker boundary.
A browser check completed both deductions and reloaded the saved ending.
Public Vercel checks covered mobile width, reduced motion, reset cancellation, actual model inference and exact source-passage retrieval, with no page errors.
One fresh Vercel browser check loaded the model in 5.3 seconds. An earlier GitHub Pages check took 43.6 seconds. These are individual connection measurements, not a performance promise.

The build now emits only one copy of the runtime WASM, removing about 21.6 MB of deployment output. That is not a claim that each player transfers 21.6 MB less. In the guide, an explicit Save game for offline play action caches the app, fonts, model and runtime. Browser checks then disconnected the network, reloaded the game, restored progress and ran actual model search. Storage can still be cleared or evicted, and the first preparation needs internet.

My contribution and the human decisions

I selected the radio-mystery direction and set the priorities for the experience: a complete story, a distinctive interface, practical play instructions and careful review. I requested successive UI and usability refinements, the in-app guide, and a Vercel deployment so someone could try the game directly. I brought in an external audit and requested staged improvements aimed at the weakest part of the project: useful AI and evidence comparison. I am also arranging a friend playtest to challenge the assumptions that automated checks cannot test.

AI agents assisted with research, implementation, writing and automated verification. Those contributions are part of the build process. My role has been to choose the direction, question the result, set the quality bar and decide what needs another pass. The friend trial is still pending; I am not claiming player feedback or measured enjoyment yet.

Why Does Open Innovation Matter?

For this project, open tools make the question-to-evidence interaction inspectable and self-hostable. Someone can examine the authored evidence, the matching policy and the model revision, then run or adapt the game without an inference-service account or per-question charges.

Local inference also keeps a player's questions out of an external AI service. Hosting the model with the application avoids relying on a live model provider to keep this particular interaction available.

There is a tradeoff: a small mystery still asks for a substantial first model download. A closed API might reduce that download, but would introduce a remote inference dependency. Here, local inference is optional, and the authored topic route keeps the game accessible when the download is a poor fit. Offline play requires successful preparation on that browser, and remains dependent on its stored files being retained.

What Comes Next

The next useful evidence is a first-time player's experience: where they hesitate, whether the records make sense, and whether AI suggestions help. A friend trial is planned before the final revision of this entry.

Dead Air currently contains one English-language case. Replay value is limited once you know the solution, and device narration varies by browser. Its purpose is a small, finished investigation—not an endless generator of mysteries.

If you try it, tell me where you first became unsure what to do. That is the feedback most likely to make the next version better.

ReviewRadar: the request, a possible reply, and a calmer review session

Yash Anand — Sat, 24 Oct 2026 09:29:13 +0000

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

What I Built

Two reviews on my Visdom #1954 PR ask for different things: avoid mutating options that may be reused, and avoid calculating contour limits when those values are unused. A later author reply discusses the changes. When returning to that conversation, I need to recover the specific request, find the relevant reply and decide what to inspect in the diff.

ReviewRadar prepares that reading session. Local Gemma proposes reviewer requests beside possible later author responses, with exact source passages attached. I can inspect the context, save a next-inspection note and export a source-linked sheet. The app never writes to GitHub, verifies a code fix or certifies maintainer satisfaction.

For Slow and Steady, the intended saving is less context hunting before resuming work. Whether the preparation and correction cost actually saves a contributor effort remains unproven.

A routine for returning to a PR

Open Saved analyses and search loaded readings by account, repository, PR number or title. Load older readings when needed. The source capture date is separate from the analysis date.
Choose Check these PRs again. The importer is prefilled, but fetching is explicit. It creates a new capture; yesterday's reading and notes stay unchanged.
Compare each proposed request with its possible reply and full source. Record the next inspection you intend to perform. Marking a card reviewed organizes your reading; it does not approve the PR.
Save, return later or export the Markdown sheet. A refreshed capture starts independent decisions, so an old reviewed state cannot quietly apply to changed evidence.

The full local app supports one to five selected public PRs authored by the chosen account. Imported snapshots support offline reading. Private repositories and automatic background monitoring are outside this release.

Demo

Try the public historical replay · Read the daily routine · Inspect an exported sheet.

The public site is saved evidence and saved model output, not hosted inference or a live inbox. Choose Original example or Mixed evidence example. Both retain capture dates and coverage limits. Decisions in the replay stay in the browser.

The original Eventyay example shows a screenshot request and a possible author response. The mixed Visdom #1919 example retains an insufficient test-pass reply and a missed branch-update ask. Choose Reply not relevant, save your next-inspection note and download the sheet. Your assessment remains separate from the original output.

When the model misses a request

The 25 October live check on my open PRs captured 13 source objects across WPFAevent #368 and Visdom #1954. Gemma found the min/max request and a relevant later explanation, but duplicated its all-NaN rationale and missed the options-mutation request. Exact quotations did not make the extraction complete.

That is why the app exposes reviewer comments without a request card. In a zero-card result, Read reviewer comments without AI explicitly creates a separate chronology reading list. It includes approvals and context, performs no request extraction or response matching, and supports its own notes, reviewed/reopen choices and export. The original model result stays saved.

An agent-operated HTTP check used that path to retain the original screenshot request, save/reopen a next-inspection note and export it. Another check refreshed my current PR selection and verified that the older snapshot and note were unchanged. These are engineering demonstrations, not a human productivity study.

Code

Source, setup and model manifest · Daily-use audit.

Original application code is MIT licensed. Attributed discussion excerpts, model weights and runtime retain their own rights and terms. The application license does not relicense other people's comments.

How I Built It

React and TypeScript provide the workbench. FastAPI imports public discussions through the GitHub CLI and stores immutable captures and analyses in SQLite. Human notes and decisions are separate records. Gemma 4 E2B runs through a pinned llama.cpp service on loopback; no GitHub credential is sent to the browser.

Gemma selects existing passage keys for requests and possible later author responses. The app reconstructs exact text and validates source identity, actor and chronology. Each generation checks its actual templated token budget. Oversized or failed inputs remain visibly incomplete. These checks prevent invalid references; they do not establish semantic correctness.

The alternative is a simple chronology of reviewer comments. Gemma's substantive contribution is interpreting asks and proposing response associations. The source-reading path remains usable when that interpretation is wrong.

What the checks established

The daily-use upgrade fixed a practical history defect: after 100 analyses, older notes still existed in SQLite but their readings disappeared from the UI. Keyset pagination now keeps them reachable, with source-bound titles and dates. New regressions cover tied timestamps, new inserts between pages and preservation of old notes.

The release checks passed 174 backend tests and 34 subtests, plus 71 local frontend and six replay tests, type/build, focused lint and a dependency audit. Two agents cross-reviewed the daily-use changes. These are structural and workflow checks, not model-accuracy measurements. On 26 October, an agent operated the browser workflow against my actual public PRs: reopened a saved note, marked/reopened it locally, explicitly refreshed the selection, created a separate chronology reading, saved a next-inspection note and downloaded its source-linked sheet. This confirms that bounded flow, not a full accessibility audit or a participant trial.

The evaluation record retains missed asks, duplicates and weak replies. In the frozen v13 six-PR study, five of eight assistant-labelled actions were covered. Later candidates were archived rather than promoted. A 25 October controlled diagnosis recovered one exposed request with an earlier prompt, but a broader 20-PR regression retained misses and introduced other errors. The default remains v13 with those limitations disclosed. These small studies use one contributor's history and assistant annotations, not independent human ground truth.

Why Does Open Innovation Matter?

Open weights let saved discussions be processed locally without a per-request model API bill. Open code makes passage selection, validation, storage and disagreement handling inspectable. The model and reading workflow can be changed independently, and failed experiments can be retained for scrutiny.

This control has a setup cost. The pinned weights are approximately 2.84 GB, with Python, Node and runtime dependencies needed for installation. Fresh GitHub imports require internet. Saved-source processing can run offline after setup. Hardware, electricity and installation still cost something.

The Mac launcher keeps a dedicated Terminal session open. A user-started session was observed healthy, but an actual ChatGPT-quit survival result has not been established. The later session was found stopped; an agent-owned session restored availability for checks. Readiness does not prove permanent availability.

The Human Role

I supplied my real contribution history, chose the product direction, asked for a free/local workflow and repeatedly challenged usability and premature readiness claims. Those inputs shaped the product. AI agents substantially assisted research, design, implementation, testing and this article; they also operated the engineering examples.

During use, the contributor reads the sources, records disagreement and chooses the actual next action. No model suggestion becomes approval automatically.

A GitHub trial request and one DEV tester invitation are published. The self-guided trial prepares feedback locally without uploading answers automatically. We have no completed independent contributor trial, testimonial or measured time saving. That is the next product test, not something a larger test suite can manufacture.

Prize Categories

Overall and Best Use of Gemma. Gemma performs actual request extraction and response association. No category is claimed for an unused integration.

HandoffReady: the folder looks finished. Does it fulfill the brief?

Yash Anand — Sat, 17 Oct 2026 15:32:39 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

A client asks for a transparent logo, three launch images and instructions for updating their website's contact email. The delivery folder has all the right-looking filenames. The freelancer is ready to send it.

Except the logo is opaque, two launch images are identical, and the guide contains a welcome message instead of instructions.

That is HandoffReady's synthetic demonstration. It is a local review desk for freelancers and small agencies delivering exported brand/web assets and written guides: connect the agreed brief to outgoing files, examine what each file actually supports, and export a client record of what is ready and what still needs work.

Gemma proposes a checklist and relevant files. The person doing the handoff confirms the scope, judges the work and decides what to share. The useful result is a record they can explain to a client, with unresolved work still visible.

Where it would fit into a working day

These are intended workflows within the supported exported-file scope; they have been exercised with synthetic materials, not validated with paying clients.

Delivery	What HandoffReady helps check	What the person still decides
Logo or brand exports	Whether the selected originals include the requested formats, and whether a PNG actually has nonopaque pixels	Whether the artwork is correct and usable; transparency alone cannot establish that
A campaign image pack	Dimensions and byte-identical duplicates, alongside the approved quantity	Whether the images are the distinct designs promised in the brief
A client update guide	Readable text in a native PDF, TXT or Markdown file, with proposed supporting passages	Whether the instructions really explain the requested task
A corrected delivery	Changed inputs make old reviews stale; a fresh export preserves the new review while the previous snapshot stays unchanged	Whether the revision resolves the problem, and how to describe remaining work

This fits just before sending exported assets and documentation. It does not execute a website, inspect a running app or certify visual design quality. The client can read the exported HTML or Markdown record without joining another project-management system. The actual files must be sent alongside it; the record identifies supporting originals and does not contain their bytes.

The human work behind the project

My role was product direction. I chose the web development/design freelancer context, required a free/local approach and asked for a complete workflow rather than an interface-only demo. Across iterations I pushed for clearer usability, more careful audits and an explanation of what a real freelancer would gain from it.

AI coding agents carried out implementation, interface work, testing, evaluation and documentation, including assistance with this post. The agents also operated the synthetic demonstration.

The human role inside the product is equally concrete: check the extracted scope against the agreement, correct omissions, read the proposed evidence, record a judgment and choose client-facing wording. A model suggestion never becomes approval on its own. That is especially important when the suggestion is plausible and wrong, as the demo shows.

Demo

Watch the 90-second walkthrough · Inspect the recorded findings · Read the exported client record

The silent video is an edited sequence of actual interface captures from the 17 October local workflow. It is not continuous footage of inference or its waiting time. Actual local extraction and matching succeeded in that session. The separate explorer preserves an explicitly dated earlier recording. Neither public page runs Gemma in your browser. Materials and decisions are agent-operated synthetic examples.

The important sequence is a partial correction:

Confirm the brief. Check the proposed requirements, including formats, quantities and omitted details.
Review the packet. The logo has no nonopaque pixels. Two launch files have identical bytes. The welcome-only guide does not explain changing the contact email.
Replace the logo. The packet changes, so earlier reviews become stale and need checking again.
Export a fresh record. The old snapshot stays unchanged. The new record retains the duplicate-image and guide gaps.

A corrected file should not silently make the whole delivery look complete. The saved record explains the review and outstanding work; it is not client acceptance.

Who might pay, and what remains unproven?

The first buyer I would test is a designer or small-agency lead who repeatedly checks delivery packets. The possible service is a local pre-delivery review with a repeatable client record. Its value would be catching an omission before sending and making the remaining work easier to discuss. The current project is free, open-source software; this is a service hypothesis, not a launched paid offering.

No completed freelancer trial, payment, measured time saving or willingness-to-pay result has been recorded. The next test is whether a freelancer can review one real packet with little help, finds the record useful and wants to repeat the process. That result should determine the next feature, and whether the service deserves to exist.

Code

HandoffReady on GitHub · Download v0.2.1 with the built interface

The project began on 13 October, during Week 2. Application code is MIT-licensed; original synthetic fixtures are CC0. Gemma, llama.cpp and dependencies retain their respective licenses and are credited in the repository. The release still needs Python dependencies and explicit optional model installation. It is not a hosted inference service or a one-click standalone executable.

How I Built It

React and TypeScript provide the review desk. FastAPI, SQLite and bounded file inspectors handle projects and originals locally. Gemma 4 E2B runs through llama.cpp. No remote model API account is needed for supported inference after installation.

Three judgments remain separate: Gemma's suggestion, an inspected file fact and the reviewer's assessment. Marking a requirement satisfied cannot erase a failed technical check. Changing the brief, confirmed scope or packet invalidates earlier reviews. If a file replacement fails, the previous original is preserved.

The interface follows that repeat-review loop: saved projects summarize outstanding attention, evidence can be searched, and “Save and next” advances through unreviewed or stale items, then opens the draft record. Private review notes are separated from deliberate client notes. Titles and check descriptions also appear in client records, so their wording needs review before sharing.

What Gemma contributes, and where it fails

Dimensions, format and identical bytes are ordinary file checks. The model's job is different: extract a draft checklist from prose and connect a requirement to a relevant file even when its filename does not give it away.

On ten authored synthetic packets containing 27 files, an association experiment supplied approved requirements separately. A locked filename-plus-inspected-text baseline found 13 of 19 keyed supporting file pairs. Captured Gemma output found all 19, plus two incorrect format substitutions. The inspected-format guard removed those two substitutions from the same outputs.

For example, Gemma connected distribution.txt—instructions to place an announcement near a stall entrance and on the community board—to a flyer-placement guide requirement. The baseline missed it. That is a narrow gain of six supporting pairs on this set, not general accuracy or evidence that the complete automatic workflow is reliable.

Extraction was weaker: 15 of 21 mandatory obligations met the predefined coverage rules; six proposals missed required format details. In the actual app, Gemma also proposed the welcome-only guide as support for contact-email instructions. An authentic quotation did not make that association useful. The demonstration retains the mistake and records the guide as needing work.

Methods, captured-result identity and limitations separate the model experiments, workflow checks and customer outcomes. They are different kinds of evidence.

Final audit: two actual fixes

The 18 October v0.2.1 audit found that a second launcher could interfere with another process's data folder. The supported launcher now acquires an exclusive folder lock before recovery or cleanup. A process-level regression checks that refusal and recovery after the owner stops.

It also found that “Save and next” could revisit reviewed items before an unreviewed one. Navigation now finishes pending reviews before opening the record, while preserving the saved gaps.

Remote verification passes 254 backend and 75 interface tests, static checks and the production build. Separate real-model smoke calls succeeded. Test counts do not measure model accuracy or customer usefulness. The video remains the dated 17 October recording, before these two audit fixes.

Why Does Open Innovation Matter?

A freelance packet may contain material its owner has not authorized uploading to an external AI service. Local inference offers another route. The supported app and model services bind to loopback, and no remote model API is required after setup. There is no per-request model API bill, although hardware, installation and electricity still cost something.

Open code makes the review rules inspectable: what was measured, what the model suggested, which originals support a decision and when that decision became stale. Open weights let the model run locally; the model, inspectors and workflow can be adapted independently. That control is useful even when the model is imperfect.

The validated environment is a single local user on Apple Silicon macOS. Setup has a real cost: Python dependencies and, for inference, roughly 8 GB of free disk for model/build artifacts. Local storage is not encrypted by the application. Live website execution, PSD/Office/ZIP review and scanned-PDF OCR are outside this release. These boundaries keep the promise specific enough to examine.

Prize Categories

Best Use of Gemma. Local requirement extraction and file association are recorded model tasks at the center of the workflow, with measured gains and retained failures. I am also entering the overall challenge.

Soundwalk Atlas — a listening walk, with AI that waits until you get home

Yash Anand — Fri, 09 Oct 2026 18:44:09 +0000

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

What I Built

During development, our audio model heard “Running water” and “Rain” in a generated noise sample. There was no stream and no rainy walk. The inference had run correctly; its interpretation was still something a person needed to question.

That failure became the centre of Soundwalk Atlas: listen first, let AI offer a second perspective later, and keep the human observation authoritative.

I chose the listening-journal concept, supplied my own recordings of page turns and footsteps as development examples, and directed repeated refinements to the interface and scroll motion. AI agents handled implementation and automated checks. My work focused on choosing the experience, reviewing its presentation and bringing real inputs into development.

Soundwalk Atlas is a private listening journal built around that principle. Prepare a few stops and a printable listening card, put the screen away, and write what you hear. A short phone recording is optional. Once home, an open-weight audio model offers a second perspective on your recordings. You replay them, accept or reject its suggestions, and keep your own interpretation.

The order matters: observation first, AI afterwards. A written note without audio is a complete observation. You decide which labels belong in the journal, including when none fits or several sounds overlap. An unreviewed suggestion never becomes something you supposedly heard.

Return another day and compare the same stops: your notes, recording context and reviewed sound labels. The goal is to make a familiar place worth noticing again, without turning a walk into a classification score.

Demo

Open the pocket listening journal · Try the no-install review walkthrough · Watch the working app demo

The new pocket journal works in a phone browser: choose familiar stops, take written observations, save them on this device, then return for another visit and compare. The optional timer is a prompt to put the screen away. There is no account, GPS or microphone permission. A seated listening session is welcome. Export a copy to keep it; clearing browser data may remove local notes. It is a small useful activity even without a model download.

The interactive walkthrough lets you write an observation, inspect a saved real-model result and make your own review. It uses a labelled synthetic sample; it does not run live inference or store a private journal. Vercel hosts the static pocket journal, sample exercise and recorded demo. Pocket notes stay in this browser and do not sync to the separate desktop journal. Recording import and CLAP inference run locally on your Mac. Vercel is not running an inference backend for this project. GitHub Pages mirror is also available.

The captioned 72-second video is an edited walkthrough of captured app screens, including saved results from real local inference. It does not show continuous interaction or inference wait times. Its recordings are clearly labelled procedural synthetic fixtures, not an outdoor trip. No completed outdoor trial or independent field-accuracy result is claimed.

Code

Source, setup instructions and review evidence on GitHub

The application source is MIT licensed. Setup instructions, synthetic fixture provenance, model preparation and evaluation tools are included. Private journals and model assets stay outside the repository.

How I Built It

The public field guide uses lightweight HTML, CSS and an original SVG landscape, with a scroll-driven trail marker, daylight/dusk and a motion pause. No 3D engine is needed. The pocket journal uses browser-local storage and portable exports. The design follows a simple sequence—arrive, listen, return—and keeps animation away from writing. Design research and limitations record the sources and decisions.

React and TypeScript provide the desktop journal interface. Scrolling draws an illustrated trail and moves a marker through the listening ritual; it is decorative, not location tracking. Focus mode, motion controls and reduced-motion support keep the working forms accessible. A local Python/FastAPI service stores visits, observations and reviews in SQLite, retaining original recordings for replay.

The AI is LAION CLAP, which compares audio and descriptive text in a shared embedding space. It matches a selected interval of up to ten seconds against eleven versioned sound prompts, then offers two candidates. Model revision, prompts and analysed interval travel with the result. The waveform comes from decoded audio, and changing the selected interval does not silently alter an existing prediction.

The noise example in the opening is preserved in the repository’s actual model benchmark. It is a reproducible failure case, not an outdoor measurement.

That is why human labels start empty, raw similarities are not called confidence, and “none fits,” multiple sounds and uncertainty are separate choices. A useful suggestion might prompt you to replay a detail you missed; an incorrect one can prompt a correction. Neither replaces listening. Digital silence produces no candidates, while amplitude warnings help spot quiet or clipped recordings.

Review also covered cancellation, draft recovery and private backup restoration. ZIP imports validate checksums, audio and record relationships before adding fresh IDs without overwriting existing visits. The repository's dated upgrade review distinguishes automated checks from real-model execution and records their limits. Benchmark results measure a specific synthetic fixture and machine, not field accuracy.

What the model actually did

A follow-up run used the pinned local model on two private development recordings I supplied and three generated controls:

Input	Observed result	What it tells us
My page-turning recording	Paper rustling was the first candidate	A relevant suggestion on a known development example
My walking recording	Footsteps was the first candidate	Another relevant suggestion; this clip was already used during prompt development
Generated noise	Rain and running water were suggested	A non-environmental input can receive plausible environmental labels
A generated pure tone	People and machinery were suggested	Unsupported sounds are not reliably rejected
Exact digital silence	No candidates	The silence check abstains; it does not measure environmental quietness

Expected descriptions were not passed into inference. These two personal clips previously informed our prompts, so this is a development check, not an independent accuracy test. The originals remain private. Methods and limits explain what was run.

The useful interaction is therefore a question, not a verdict: does the suggestion make me replay and notice a detail, or does it need rejecting? Whether that helps on an actual walk still needs testing.

Why Does Open Innovation Matter?

A recording can reveal someone's routines or conversations. It should not need to leave their laptop to receive suggestions. After explicit dependency and model downloads, inference uses prepared local assets without a remote API fallback. Local computation still costs memory, storage and processing time.

Open weights make the model inspectable and replaceable. The prompts are visible source code; the model revision and weight checksum are pinned. A surprising result can be reproduced and questioned rather than accepted as an opaque service response.

This release uses a phone's ordinary recorder followed by file transfer; it does not run inference on the phone. It cannot identify species, separate sound sources, measure noise exposure or assess environmental health. Unsupported sounds may still receive plausible labels. Independent recordings and outdoor use remain the next validation step.

My Agent Session

My role

I chose Soundwalk Atlas from the proposed concepts and set its direction. I supplied my own recordings of book pages turning and footsteps as development inputs, with descriptions of what I recorded. These short development examples helped examine model suggestions; they do not establish an outdoor trial or independent accuracy study, and the recordings remain private.

I reviewed the presentation and requested repeated refinements to the interface, scroll animation and overall quality. I wanted the experience to feel seamless while keeping human judgment central: suggestions should invite listening and correction, rather than manufacture certainty.

Working with agents

I used OpenAI Codex, Gemma 4 , Claude, Gemini, qwen and research, audio, backend and interface subagents to help plan, implement, test and review the project. Codex and the subagents produced the code and automated checks; integration review corrected defects. The repository contains stage reviews and engineering evidence, without publishing private recordings or session transcripts.
There is a web app Deployed on Vercel as well that you can access through my GitHub

Prize Categories

Overall challenge.