DEV Community: Raj Ambolikar

MD

Raj Ambolikar — Sat, 31 Oct 2026 18:02:41 +0000

Role

You are the primary delivery engine. Backend correctness, data integrity, and stable APIs are the foundation everything else depends on. Deliver these first and completely before frontend work begins on any feature.

Responsibilities

Inspect the current persistence architecture before writing any code. Implement only the assigned backend/data scope:

Schema and migrations: define the data model correctly; write forward-only, idempotent migrations; preserve history when plans or routines change; use stable identifiers and appropriate indexes.
APIs and persistence: implement endpoints/handlers with proper validation, ownership checks, authorization, and error handling; use transactions for multi-record updates where supported; make writes idempotent where possible.
Event integrity: prevent duplicate completion/progress events; ensure calendar markings, streaks, goal contributions, and heatmap data are derivable from the same persisted event log.
Notifications integration: expose the data and triggers notification-engineer needs; make activity completion/edit/deletion observable by the notification layer.
Tests: write tests for normal behavior, boundary cases, authorization failures, idempotency, and concurrent writes.

Rules

Never leak secrets or weaken authorization.
Never reset production data or perform destructive deployments.
Never claim a migration succeeded without running it and inspecting the exit code.
Coordinate schema/API contracts and file ownership with the Project Director before parallel work.
Adapt to the actual stack: inspect the existing ORM, database driver, and migration tool before writing anything.
Report exact migrations run, commands, exit statuses, and results.

Letter Decoder: Your AI Friend for Scary Official Letters (Runs 100% Offline)

Raj Ambolikar — Sun, 18 Oct 2026 18:11:47 +0000

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

What I Built

Letter Decoder — a local-first, open-source app that reads your official letters and explains them in plain language.

Tax notices. Fines. Insurance rejections. Bank letters. Landlord warnings. Drop one in as a photo, PDF, screenshot, or pasted text, and get back an answer card:

✅ A one-line verdict ("you owe X by Y — act soon")
⏳ A deadline countdown with a .ics calendar export
🔴 A severity rating
📋 Three concrete next steps
📄 A document checklist
✍️ An editable draft reply

Every date and amount links back to the exact line of the original letter it came from. If the model can't verify a claim against the extracted facts, it says so — no confident hallucinations.

Who would pay for this? Anyone who has ever frozen looking at a government envelope, hired a solicitor at £150/hour just to be told "this is a routine payment reminder", or simply had a letter in their second language. The realistic addressable market is anyone who receives official correspondence — which is everyone.

The letter never leaves your device. No accounts, no cloud, no telemetry. That's the product differentiator and the privacy guarantee rolled into one.

Demo

	URL	Notes
Frontend	https://letter-decoder.vercel.app	React 19 app, deployed on Vercel
Public API	https://letter-decoder-api-qvxs.onrender.com	FastAPI — runs in `ENGINE_MODE=mock`, replays 14 canonical examples through the full SSE pipeline with realistic delays

For real decoding with a local model, clone the repo and run with Ollama (see below). The public endpoint intentionally uses mock mode so no real letters are ever uploaded to a server.

Code

RAMBO-LC / letter-decoder

Local-first, open-source app that explains official letters in plain language with open-weight models on your own machine. No cloud, no telemetry, no accounts.

Letter Decoder

"A patient friend read it for me, and now I know what to do."

A local-first, open-source app that explains official letters in plain language.

Tax notices, fines, insurance rejections, bank letters, landlord notices — drop one in as a photo, PDF, screenshot, or pasted text, and get back an answer card: a one-line verdict, a deadline countdown, severity, three concrete next steps, a document checklist, and an editable draft reply. Every date and amount links back to the exact line of the original letter it came from.

No cloud calls. No telemetry. No accounts. The letter never leaves your device.

Live Demo

URL	What it is
Frontend	https://letter-decoder.vercel.app	React app (Vercel)
API	https://letter-decoder-api-qvxs.onrender.com	FastAPI engine (Render)

The public API runs ENGINE_MODE=mock, replaying canonical examples through the same endpoints and SSE event streams with realistic delays. For real decoding with an open-weight model, run it locally…

View on GitHub

Quick start with a real model:

# Terminal 1 — start the inference server
ollama serve
ollama pull qwen2.5:7b

# Terminal 2 — start the app
git clone https://github.com/RAMBO-LC/letter-decoder.git
cd letter-decoder
uv sync --all-extras
uv run python -m api.main

Open http://127.0.0.1:8000 — everything runs fully offline from here.

How I Built It

The core design principle is: code finds facts, the model explains them.

The Pipeline

[Input] → Preprocess → Extract Text → Deterministic Facts → Classify → Notice Pack → LLM Explain → Verify → Answer

Preprocess (engine/preprocess.py) — OpenCV deskew and denoise for photos/scans.
Extract text (engine/extract_text.py) — native PDF text extraction, falling back to Tesseract OCR.
Deterministic extraction (engine/deterministic_extract.py) — regex + dateparser pull every date, amount, and reference number from the raw text. The LLM never sees a blank slate: facts are pre-extracted before it is invoked.
Classify (engine/classifier.py) — keyword and embedding matching identifies the notice type and loads the right notice pack (a YAML file per country/type in notices/).
LLM Explain (engine/llm_constrained.py) — Ollama runs locally; the default model is Qwen 2.5 7B (fully open weights). JSON-constrained output means the model can only produce the schema the verifier expects.
Verify (engine/verifier.py) — every factual claim in the LLM output is checked against the deterministically extracted facts. A fact the model invented that wasn't in the source text fails verification — you get a clean error, not a confident lie.

Open-Source AI Stack

Layer	Tool	License
Local inference	Ollama	MIT
Default model	Qwen 2.5 7B	Apache 2.0
OCR	Tesseract	Apache 2.0
Image processing	OpenCV	Apache 2.0
API framework	FastAPI	MIT
Frontend	React 19	MIT

Every layer is open source. You can swap qwen2.5:7b for Gemma, Llama, Mistral, or a fine-tuned checkpoint by changing one environment variable.

Contributing is Data, Not Code

Most contributions to this project are YAML files, not Python PRs. Adding support for a new country is:

# notices/fr/tax_reminder.yaml
name: "Avis de rappel fiscal"
keywords: ["Trésor public", "DGFIP", "avis d'imposition"]
severity_default: act_soon
mock_simple: "This is a French tax reminder."

That's it. CI validates it against the JSON Schema automatically.

Why Does Open Innovation Matter?

A letter contains income, legal status, financial history, and sometimes your immigration situation. Explaining it with a closed API means uploading it.

There is no enterprise tier, privacy toggle, or data-processing agreement that un-does the fact that your letter travelled to someone else's data center. With an open local model:

The letter structurally never leaves the machine. This isn't a policy — it's enforced: tests/test_local_only.py fails the CI build if any code path attempts an outbound network call.
Zero marginal cost. A family that gets ten letters a year pays nothing extra after the initial setup.
Auditability. The verifier that proves "the model never invents a deadline" is code you can read, fork, and run yourself. You don't have to trust a vendor's marketing copy.
Swappability. Communities can fine-tune a small model on their country's letter formats — a GDPR-compliant, locally-hosted specialist — without any API negotiation.

Open weights made this project's privacy guarantee credible. A closed API could promise the same guarantee; open weights prove it.

My Agent Session

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle

Field Notes: A Bird Journal That Writes Itself, Offline, While I Keep My Phone in My Pocket

Raj Ambolikar — Sun, 11 Oct 2026 15:27:09 +0000

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.