DEV Community: Simran Kaur

Department of Unnecessary Affairs: I built a government office to help me avoid doing things

Simran Kaur — Sun, 25 Oct 2026 16:31:00 +0000

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

I had a problem. I had a list of things to do, most of which I did not particularly want to do, and no shortage of ways to reorganise that list instead of actually doing anything.

I decided to build an application for that.

It's called the Department of Unnecessary Affairs (DUA). You bring it your administrative problems, and it directs them to the appropriate office. There are five offices, each handling a different kind of problem, and one very relaxed Sloth Officer.

The Sloth Officer looks a little...

...well. Let's not make this about his appearance.

Behind the questionable personnel decisions is a small Django application that uses Gemma to handle everyday administrative tasks. The idea is ridiculous. The engineering, considerably less so.

To be clear, I am not claiming that DUA can do things ChatGPT or Claude cannot. Most of its tasks can already be handled by existing AI assistants.

The main objective was to make a troll of an application. Giving mundane problems an entire government department, complete with official verdicts, fictional permits, unnecessary paperwork, and a Sloth Officer, seemed funnier than building yet another serious productivity tool.

Naturally, I then spent a questionable amount of time making sure the joke actually worked.

What I Built

DUA gives everyday administrative problems their own government office. Need to organise your notes? There's an office for that. Overwhelmed by your to-do list? Another office will issue its verdict. Difficult email to write? Complicated document to understand? Minor decision to outsource to a fictional government? There's a department for each.

1. Morning Docket Office

Paste your notes, to-do list, or chat export. You can also upload .txt, .md, and text-based .pdf files.

The office identifies your three most important tasks, what can wait, and what is coming up. Each item includes a quotation from your original notes, so you can check where the recommendation came from.

For a test, I exported a WhatsApp conversation with a friend. She had asked me to call her the next time I came online and had also asked when IGNOU assignments were due. I had responded to neither question.

The office had some paperwork to do.

I uploaded the exported conversation:

And got these results:

It identified both unanswered messages as immediate action items. It also brought up a keychain discussion from earlier in the conversation, because apparently that matter was still pending.

The office also generates a Notice of Daily Obligations, which is essentially a ridiculously legalistic summary of your request and its response.

2. Bureau of Pending Affairs

Give it a list of tasks, and each task receives one of five verdicts: do_now, schedule, delegate, defer, or deny.

The Bureau suggests a next step and the minimum effort needed to consider the task complete. Deferred and denied tasks come with a procrastination permit and a fictional excuse.

You can mark tasks as complete, track progress, and carry unfinished tasks into a new plan. Only the remaining tasks are replanned, so completed tasks do not return for another hearing.

There is one restriction: the Bureau cannot talk you out of a real deadline just because ignoring it would be convenient. That rule is enforced in Python.

3. Office of Correspondence Avoidance

This office handles messages you have been meaning to reply to.

Enter your rough notes, choose a tone (professional, friendly, firm, apologetic, or casual), and get a draft with two alternatives.

The more interesting feature is reply mode. Paste an incoming message, and the office identifies its questions using the original wording. Each question is marked as answered in the draft or still needing your input.

If you haven't provided a name, price, or other specific detail, the application uses a placeholder instead of letting the model invent one.

A confidently written email containing a date you never agreed to is not particularly helpful. Even the Department has some standards.

4. Commission for Unnecessarily Complicated Documents

Paste a notice, lease, or terms and conditions, or upload a document.

The Commission produces a plain-language summary and identifies deadlines, actions, requirements, and unclear points. Each claim needs a quotation from the original document, and Python checks those quotations before the claims are displayed.

The word count, average sentence length, and reading level are calculated from the actual text. The complexity rating is fictional and labelled accordingly. At least one department is honest about the nature of its assessments.

The full document is not stored. Only a 200-character preview is retained.

For a demo, I uploaded a PDF about Latent Space and the Geometry of AI Representations. The application returned a short summary and key points from the document.

Since the PDF did not contain any direct action items for me, the deadlines section was empty. Under "What you are asked to do", it extracted these points:

Test the actual downstream task when evaluating representations.

Source in your document: “A sensible evaluation should test the actual downstream task, inspect failure cases, and check performance across different groups and settings.”

Treat similarity scores as model-dependent signals.

Source in your document: “Similarity scores should be treated as model-dependent signals, not objective measurements of truth or meaning.”

I also got a rating of how complicated the document was:

Was a separate government commission necessary to summarise a PDF? Almost certainly not. But now it exists.

5. Tribunal for Minor Inconveniences

Pizza or sushi? Reply tonight or tomorrow?

Tell the Tribunal what matters to you, and it produces two to five options, their pros and cons, a recommendation based on your stated preferences, and a mock ruling.

You can appeal the decision. The same judge hears the appeal and dismisses it.

The Tribunal has limits. Questions involving health, law, money, or safety are redirected without the jokes. Inputs indicating self-harm are intercepted before they reach the model and receive a fixed, supportive response.

The application is meant to be absurd about minor inconveniences, not to pretend a local language model should be making high-stakes decisions for someone.

A few things shared across the offices

Every completed case has a page that can be revisited. Cases belong to the visitor's browser session, and there is a button to delete a case.

You can also retry a case if the model produces a bad result.

Completed cases can be downloaded as Markdown, with the source quotations preserved. Pending plans can be exported as .ics files for calendar and task applications.

The calendar exports deliberately have no due dates. If your task says "finish this by Friday", the application preserves that wording in the task description rather than guessing which calendar date Friday refers to.

And now, the part that is probably more consistent with the original vision:

The Department's questionable personnel and activities

There are eight hidden secrets around the application.

Type sloth anywhere on a page without a text box selected, and the Sloth Officer walks across the screen at his own pace.

Alternatively, enter the Konami code:

↑ ↑ ↓ ↓ ← → ← → B A

The Department initiates an Emergency Efficiency Drill. Stamps rain down the screen, a banner announces that everyone must work faster, and the drill is cancelled because nobody is interested.

There are six other secrets. I will leave those to the public.

Demo

Try it: https://dua-demo.onrender.com

Repository:

arkia09 / DUA

Department of Unnecessary Affairs

A Django app where you hand a fictional, deadpan government office a problem and get real help back. A local open-weight model (gemma4:e4b, served by Ollama) does the thinking. Nothing you type leaves your machine.

The rule behind every office: the help is serious and the jokes are separate. Plans, drafts, summaries and comparisons are plain and useful. The humour lives in clearly labelled notices, excuses and stamps.

There is also a demo mode that needs no model, so the app can be hosted as a public demo. See Demo mode.

The five offices

Office	You give it	You get back
Morning Docket Office (`/briefing/`)	A pile of notes, to-dos, messages or a chat export (paste, `.txt`, `.md` or text-based `.pdf`)	Today's top three, what can safely wait, what is coming up, each item with a quote from

…

View on GitHub

The hosted demo is designed to be tried without installing anything.

A quick way to explore it:

Open the Bureau of Pending Affairs.
Select one of the built-in Try examples and submit it.
Mark a task as complete.
Download the .ics to-do list.
Enter the Konami code if you want to see the Emergency Efficiency Drill.

One important distinction: the hosted demo does not run Gemma.

It has 12 built-in sample inputs with saved model outputs. When you submit one of those samples, the application processes the saved output through the same validation functions used for live model responses.

If you enter your own input, the demo cannot process it and returns a refusal.

This lets people try the application without requiring the hosting server to run an AI model. It also means the demo exercises the validation code rather than displaying pre-rendered results without running the application logic.

To run the full application with live inference, you need Ollama and Gemma on your own machine:

ollama pull gemma4:e4b
pip install -r requirements.txt
python manage.py migrate
python manage.py runserver

Set DEMO_MODE=true in your environment if you want to run the application without Ollama.

How I Built It

The stack is Django, SQLite, plain JavaScript without a frontend framework, and Gemma 4 E4B served locally through Ollama.

The division of responsibilities is straightforward:

Django handles HTTP requests, application logic, sessions, and server-side processing.
SQLite stores application records.
JavaScript handles the browser interfaces and interactions.
Ollama runs Gemma locally and provides the interface through which the application sends prompts and receives responses.
Gemma 4 E4B handles the language tasks for the five offices.

When a user submits something, the relevant Django view prepares the input and sends it to the appropriate model operation. The model returns structured JSON. Python validates that output before the application presents it to the user.

The important part is that valid JSON is not necessarily correct information.

A response can have every expected field and still contain an invented deadline. It can return a plausible summary and attach a quotation that never appeared in the document.

I wanted the application to check the parts that could be checked rather than relying entirely on a better prompt.

1. Gemma proposes. Python decides.

Take the document-analysis office.

Each claim must include a quotation from the source document. The application normalises the text, checks that the quotation is long enough, and verifies that it appears in the original text.

The core check looks like this:

def quote_in_source(quote, source_words, min_words=MIN_QUOTE_WORDS, min_chars=0):
    q = words(quote)
    if len(q.split()) < min_words or len(q) < min_chars:
        return False
    return f" {q} " in f" {source_words} "

The minimum length matters because a short, generic phrase is not useful evidence for a claim about a document.

If the quotation fails validation, the associated claim is removed, and the interface reports how many claims were rejected.

This does not prove that the model interpreted a quotation correctly. A real quotation can still be used to support the wrong conclusion.

It does, however, prevent the application from presenting an invented passage as a verbatim quotation from the source.

That is a specific safeguard, not a solution to hallucinations as a whole.

2. The Bureau cannot approve every excuse

The Bureau of Pending Affairs has a similar rule.

Gemma can recommend that a task be deferred or denied, but Python can override that recommendation:

# Safety guard: never let the model excuse someone from a deadline or a high-stakes task.
if verdict in ("defer", "deny") and (deadline or urgency in ("high", "critical")):
    verdict = "do_now" if urgency == "critical" else "schedule"

If a task has a deadline or high urgency, the model cannot simply dismiss it. Critical tasks are moved to do_now, while the other matching tasks are scheduled.

I chose to enforce this in code rather than rely exclusively on instructions in the prompt. A model may fail to follow an instruction. A deterministic check gives the application a separate way to enforce the rule.

The application also preserves deadlines from the user's input rather than accepting invented ones. User input is passed as data inside tags, with closing tags neutralised to reduce the risk of the input interfering with the surrounding instructions.

This is one layer of protection, not a claim that prompt injection has been solved.

The test suite contains 244 tests. The model is mocked during these tests, so they verify how the application handles different outputs without requiring live inference for every test.

That includes malformed, incomplete, and invalid responses.

3. Demo mode uses the same checks

The hosted demo has a separate requirement: it must work without Ollama.

I implemented demo mode by recording model outputs for 12 built-in sample inputs. The application stores those outputs and uses them when the corresponding examples are submitted.

The saved responses still pass through the regular validators. A test checks that the sample outputs survive validation and that every Try button has a corresponding sample.

I can regenerate the sample data after running the real model locally:

python manage.py record_demo

This gives me a way to update the demo without hosting inference on the public server.

The distinction matters because a demo that displays saved responses directly would not exercise the same application logic as a live model call. DUA's demo still runs the checks that determine which claims and recommendations are allowed through.

4. Deploying Django on Render

The public demo runs on Render.

I wanted a public URL that people could open immediately, without installing Python, downloading Gemma, or configuring Ollama. Running the model on a hosting server would have introduced additional resource requirements, so I kept the model out of the hosted deployment and used demo mode instead.

The deployment is a Django web service rather than a static site. Django needs to process requests, manage sessions, run the office logic, and retrieve the saved demo outputs.

The service runs under Gunicorn. Its build process installs the Python dependencies, collects static files, and applies database migrations:

pip install -r requirements.txt
python manage.py collectstatic --noinput
python manage.py migrate

The application starts with:

gunicorn dua.wsgi:application

I also added a render.yaml Blueprint to the repository. Render generated the initial configuration for the deployed service, and I committed that configuration so the deployment setup lives alongside the application code.

That makes the deployment easier to reproduce and review than relying entirely on settings entered manually in a dashboard.

The service's environment variables handle deployment-specific settings, including demo mode, the allowed host, the Django secret key, and HTTPS-related configuration. Sensitive values belong in Render's environment settings, not in the repository.

Getting the application to start was not the same as getting it to serve requests correctly. At one point, the service started successfully, but requests returned HTTP 400 because the deployed hostname was missing from Django's allowed-host configuration. I added the hostname and checked the related HTTPS and CSRF settings.

There is also a deliberate limitation to the hosted setup. The demo does not provide unrestricted AI inference, and the deployed application clears case data when the service restarts. This keeps the public demonstration simple, but it is not a substitute for persistent storage and a more complete data-retention design.

For this project, I prioritised making the core experience publicly accessible without incurring the cost of hosting the model.

That is what Render contributes to DUA: a deployed, publicly accessible application with its own server-side logic, rather than a screenshot of an interface that only works on my machine.

5. The bugs that changed the implementation

The first serious issue was case ownership.

In the initial implementation, anyone who knew a case number could open, export, or delete another visitor's case. Case numbers were sequential, and the application did not check ownership before allowing those operations.

I changed the ownership model so that cases belong to the visitor's browser session. The server also clears cases when it restarts.

Fixing the ownership problem exposed another issue. When a model call failed, Django returned a 5xx response without sending the session cookie. For a new visitor, that could leave them unable to access their own failed case.

I added middleware to ensure the session cookie was sent in that situation as well.

The lesson was that assigning data to a session is not enough if the error-handling path breaks the session flow.

I also changed Gemma's prompts while trying to make its jokes blunter. The result was that the responses became dull. The legal drama was part of the application's personality, and the revised prompts had stripped too much of it away.

I restored the earlier wording.

Sometimes the old version was better.

These issues were not solved by asking the model to behave better. They required changes to application logic, HTTP handling, and the prompts themselves.

6. Running the model locally

Ollama makes the local version relatively straightforward to run.

Once Gemma is downloaded, Django can send requests to the local Ollama service without depending on a paid model API.

The application uses the OLLAMA_MODEL environment variable to select the model. That means the model choice can be changed through configuration rather than hard-coded into every office.

Local inference also has trade-offs. The model needs to be downloaded, the machine needs enough resources to run it, and inference speed depends on the hardware.

A larger hosted model might produce better summaries or funnier excuses. A local model does not become reliable simply because it runs on your own computer.

That is why the validation layer exists independently of the model.

Why Does Open Innovation Matter?

I could make a case for the practical advantages of open-source technology here, but I don't think DUA needs to pretend it solves a problem that existing AI assistants have failed to solve.

You can already ask ChatGPT or Claude to organise your tasks, draft replies, or summarise a document. I haven't benchmarked DUA against those tools, and I have no evidence that it does those jobs better.

The reason I built DUA was primarily to make a ridiculous application, then see how far I could take the idea technically.

Open-source tools made that experiment accessible. I could run Gemma locally through Ollama, change prompts and application logic, inspect the outputs, and build validation rules around the parts I didn't want to trust blindly. Running the model locally also avoids per-request model API charges, although it comes with hardware and setup costs.

The project is open for other people to inspect and modify. They can disagree with my implementation, change the rules, replace the model, or build something more useful on top of it. That freedom matters more to me than claiming that DUA is a necessary replacement for a general-purpose assistant.

There is a local-inference option for people who prefer not to send their inputs to a remote model API. The full local version can process inputs through Ollama on the user's machine, subject to the application's actual data flows and configuration. The hosted demo is different: it uses saved sample responses and should not be treated as a privacy guarantee for arbitrary user input.

Open-source software does not automatically make an application secure, accurate, or useful. It does make the implementation available for people to examine and change.

And sometimes the experiment doesn't need to change the world. Sometimes it can just be an unnecessarily complicated joke that taught me something about building and deploying an AI application.

What's Next?

I have a few improvements in mind, though I'm not pretending all of them are urgent matters of public administration.

Improve the model's reliability. The current validation catches specific classes of invalid output, but it cannot guarantee that every interpretation is correct.
Improve case persistence. The current deployment clears cases on restart. A more complete version would need persistent storage and a clearer data-retention policy.
Make the hosted demo more informative. The sample-based setup demonstrates the application logic, but visitors cannot submit arbitrary input to a live model.
Test the offices against more real inputs. The existing tests verify application behaviour with mocked model responses. More systematic evaluation of actual Gemma outputs would help identify where the model still fails.
Keep the unnecessary parts unnecessary. The Sloth Officer and the hidden secrets are part of the point. I would rather keep the application's personality than turn it into a generic dashboard.

I have not benchmarked DUA against doing these tasks manually, so I will not claim that it saves a particular percentage of time.

On the built-in to-do example, the Bureau turns five tasks into one real deadline and two permits to ignore.

The sample document is 84 words long and receives a reading-ease score of 40, which the Commission classifies as difficult. It identifies two deadlines, one action, two requirements, and four unclear points, each accompanied by a quotation that passes the source check.

For an 84-word notice, the time saved may be negligible. A longer document might be a different story, but I have not tested that.

I could try to turn those numbers into a productivity claim. I could also create a sixth office to investigate the matter, issue a report, and leave it unread.

The second option feels more faithful to the project.

Prize Categories

Best Use of Gemma

Gemma 4 E4B is the model behind the five offices. It runs locally through Ollama, returns structured JSON, and provides the content that Python subsequently validates. The application uses code-side checks to reject specific kinds of invalid output rather than treating every model response as trustworthy.

Best Use of Render

The public Django application is deployed on Render through a Blueprint. The hosted service runs under Gunicorn, collects static files, applies migrations, and serves the sample-based demo using DEMO_MODE=true.

Keeping inference out of the hosted deployment avoids the additional resources needed to run Gemma on the server. Render makes the application publicly accessible, while the full local version remains available to anyone willing to install Ollama and download the model.

Best Use of GitHub Copilot (GitHub Actions)

The GitHub Actions workflow runs linting, Django's system check, the 244-test suite, and a production collectstatic build step on every push.

The tests use a mocked model, so they check how the application handles different outputs without requiring live inference for every test.

Try the hosted demo: https://dua-demo.onrender.com

Explore the code: https://github.com/arkia09/DUA

The Officer S. Loth is still employed.

Nobody has filed the paperwork to replace him.

I fine-tuned Qwen3.6 on Tinker to read my neighbours’ khata: 98% credit/payment accuracy for $0.38

Simran Kaur — Mon, 19 Oct 2026 04:43:52 +0000

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

What I Built

My neighbours run a grocery shop. Like thousands of small shops, they sell a lot on credit and keep track in a khata: a paper ledger where every row is a customer, a date, an item, and either udhar (the customer took goods on credit) or jama (they paid something back).
It works until you need an answer. Who owes what? Who hasn't paid in over a month? The answer is somewhere in the pages, and finding it means turning them over by hand.

So I built Ledgerly. You photograph a page. A vision model reads every row. You get a review screen with your photo beside the extracted rows, fix whatever it got wrong, confirm, and the app keeps running balances per customer, with an aging report: who is over 30 days.

The part I care about most is the loop. Every page you confirm carries your corrections, and those corrections are the training data for the next fine-tune (python ft/train.py --from-db). Using the app produces training data.

It reads Hindi (Devanagari), English, and the mixed pages that real ledgers actually are.

Demo

The demo covers gemma running locally and extracting entries from a handwritten ledger page and other functionalities of Ledgerly web app.

What my neighbours said

I asked my neighbours to try it. They found the screens easy to understand almost immediately: the photo next to the rows, the big buttons, the "owes money" and "over 30 days" filters. Their own khata is laid out differently from the pages I trained on, so they couldn't run their book through it yet. They told me they would definitely use it if I rolled it out as an app.

That told me what to build next. The model has to learn their page, and that is what fine-tuning is for: photograph a few pages, label them, and train again for about forty cents.

The side hustle

Who would pay: small shops that sell on credit and still run their books on paper, like my neighbours. They don't need another accounting suite. They need to stop turning pages to find out who owes what.

What I'd sell: the model and the pipeline are open and stay free. I'd charge for the convenience: a hosted version where the shopkeeper photographs a page and the ledger is ready, plus the part that matters most, teaching the model that shop's own page layout. My neighbours' khata looks different from mine, so a one-time setup is exactly what they need: a few photographed and labelled pages, then a fine-tune. The compute for my 9-page run cost about forty cents.

Pricing:: I asked my neighbours what would feel fair for an app like this, and they said ₹100 to ₹150 a month. So I'd offer a free tier of about 20 pages a month, so a shop can try it on its own khata, then roughly ₹120-₹130 a month per shop. A one-time setup would teach the model that shop's own page layout. That's a few rupees a day, far less than the hours lost to the paper book, and in line with what small shops already pay for billing apps.

The price comes from one shop's answer and the idea hasn't been tested beyond that, but they told me they would use it.

Code

arkia09 / Ledgerly

Ledgerly

Photograph a page of a paper credit ledger. A local Gemma model (via Ollama) reads it, you correct mistakes, and the app reports who owes what and for how long.

Layout

extraction/ Step 1: model prompt, schema, single/batch runners, scoring
backend/ Step 2: Django API (SQLite, no login)
frontend/ Step 3: React + TypeScript app (Vite)
finetune/ Optional: fine-tune a vision model on Tinker and compare with the baseline (see its README)
data/pages/ test photos (gitignored: may contain customer data)
data/ground_truth/ your hand-written correct answers, one JSON per photo
data/outputs/ model outputs per run (gitignored)

Setup (Windows PowerShell)

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
ollama pull gemma4:e4b

Step 1 workflow

Put photos in data/pages/ (page01.jpg, page02.jpg, ...).
For each, copy data/ground_truth/_template.json to page01.json and fill in the true rows Set "page_type" to neat, messy or mixed.
Edit the layout line in extraction/prompt.txt to match your ledger.
…

View on GitHub

Django + SQLite backend, React + TypeScript frontend, and an extraction/ft/ folder that holds the whole fine-tuning pipeline: dataset.py, train.py, sampler.py, evaluate.py, compare.py.

How I Built It

photo ──▶ preprocess
      ──▶ vision model ──▶ JSON { rows: [ {date, name, item, amount, type, struck_out} ] }
      ──▶ pydantic schema check
      ──▶ review screen (you fix rows) ──▶ confirm ──▶ ledger + aging report
                                                │
                    corrections ◀───────────────┘  (next training run, --from-db)

Each row has exactly six fields. type is credit (udhar) or payment (jama), and struck_out is true when the shopkeeper has crossed a row out, so it is stored but not counted:

{ "date": "15/10", "name": "Ramesh Kumar", "item": "Atta (5 kg)",
  "amount": 240, "type": "credit", "struck_out": false }

Step 1: the baseline, with a local Gemma

The first version ran Gemma 4 e4b locally through Ollama. Nothing leaves the computer, which matters for a book full of customers' names and debts. It works, but it takes about 159 seconds per page on my CPU.

Step 2: the data (the boring part that decides everything)

I labelled 14 pages by hand (took me 2 hours), one JSON of ground truth per photo. Then I split them so the model is judged on pages it has never seen:

Held out (5 pages, 50 rows): page02, page04, page06 (my original neat, messy and mixed pages) plus page09 and page10.
Trained on (9 pages): the rest.

I picked page09 and page10 as test pages on purpose. Several of my new pages repeat each other's customers and amounts (page 8 and page 14 are nearly identical). If a test page has a twin in training, the score is inflated. Those two had no twins.

Nine pages is tiny, so dataset.py adds three augmented copies of each page (small rotation, brightness, contrast and crop). That makes 36 training examples, 79,764 tokens per epoch.

Step 3: fine-tuning on Tinker

Choosing the model

The input is a photograph, so I needed a vision model. My first choice, Qwen3-VL-30B-A3B, died on the first real run with 400: base_model ... is not supported. The public docs still listed it. So I asked the server what my key could use (ServiceClient().get_server_capabilities()), and the list had moved on to Qwen3.5 and Qwen3.6, plus Nemotron and others.

I picked Qwen3.6-35B-A3B: a mixture-of-experts model with about 3B active parameters, which keeps training and sampling cheap, in the same size class as the model I'd planned. A free --dry-run rendered every example with the real tokenizer and image processor before I spent anything, and the renderer it chose (qwen3_5) matched what tinker_cookbook recommends for that model.

I used Tinker to LoRA fine-tune it with the settings in train.py:

Setting	Value
Method	LoRA, rank 16
Epochs / batch size	4 / 4, so 36 steps
Learning rate	1e-4, decaying to 1e-5
Renderer	`qwen3_5` (matches `get_recommended_renderer_name`)
Training cost	about $0.38 of credit ($10.00 to $9.62)

Every example is a (photo, correct JSON) pair.

epoch 1/4 step 1/36  loss/token 0.1466
epoch 1/4 step 9/36  loss/token 0.0185
epoch 2/4 step 18/36 loss/token 0.0050
epoch 3/4 step 27/36 loss/token 0.0013
epoch 4/4 step 36/36 loss/token 0.0008

I'm not treating that curve as a result. It's loss on training pages the model saw four times each, so it says the run was healthy, not that the model is good.

Step 4: the evaluation

ft/evaluate.py runs the untouched base model and the fine-tuned model on the five held-out pages and scores both with my own score.py. Each true row has to be matched to a predicted row, and then name, amount, date, type and crossed-out flag are checked. A row counts as "full" only when all five are right.

The base model scored 0%. I want to be precise about why. It did not read the pages badly. On all five pages it failed to produce valid JSON for my schema (wrong shape, no JSON object at all, or text after the JSON). score.py can only score what it can parse, so every page became "found 0 rows". That number measures instruction-following on one schema, not handwriting, so I'm not using it as my "before". Gemma is my baseline, because it produces valid output.

Fine-tuned Qwen against local Gemma, 50 rows, same pages, same checker:

	Gemma 4 e4b (local)	Qwen3.6 fine-tuned (Tinker)
Full row correct	41/50 (82%)	44/50 (88%)
Name	46/50	45/50
Amount	48/50	49/50
Date	47/50	49/50
Type (credit vs payment)	44/50 (88%)	49/50 (98%)
Crossed out	47/50	48/50
Extra rows invented	0	0
Seconds per page	159 s (laptop CPU)	12 s (Tinker cloud GPU)

Fully right rows by kind of page (this is the part I'd look at before trusting any single percentage):

Page type	Rows	Gemma 4 e4b (local)	Qwen3.6 fine-tuned
Neat (page02, page09, page10)	30	26 (87%)	28 (93%)
Messy (page04)	10	7 (70%)	10 (100%)
Mixed Hindi/English (page06)	10	8 (80%)	6 (60%)

What stands out:

Credit versus payment went from 88% to 98%. In a ledger that is the field that matters most: mixing up udhar and jama flips the sign on someone's balance.
Three more rows fully right out of 50 (82% to 88%), with dates, amounts and crossed-out flags all a little better and no invented rows.
12 seconds a page instead of 159. That compares a cloud GPU with my laptop CPU, so read it as "hosted versus on my machine", not as a model-size result.
Where it's level or behind: names (45 against Gemma's 46) and my one mixed Hindi/English page (6 of 10 rows against 8). On the neat and messy pages it got 28 of 30 and 10 of 10 rows fully right.

With 50 test rows, a one or two row gap is noise, so I trust the type and speed results most.

Two details from walking through every row in compare.html:

One label was my mistake. On page06, row 7, my ground-truth JSON said the row was crossed out, but I never crossed it out on the paper. Both models said "not crossed out", so both were marked wrong for being right. I corrected that one label after seeing the results and rescored both models, so the numbers above include the fix.
One real miss: the fine-tuned model wrote "Pooja" in Latin letters where the ledger has the name in Devanagari. It's the same person, but the tool is meant to copy what's written, so I left it counted as wrong. Several of the other name misses were rows Gemma read correctly.

Step 5: seeing the mistakes, not just the percentages

ft/compare.py builds one HTML page: my photo, my ground truth, and every model side by side, with wrong fields in red and the correct value underneath. I used it to find that the mixed page was where the fine-tuned model lost rows.

Using it in the app

One environment variable decides who reads the page:

$env:LEDGERLY_EXTRACTOR = "tinker"   # default is the local Gemma via Ollama

The default keeps every photo on the computer. With tinker, each photo is sent to Tinker's cloud to be read by the fine-tuned model, and the README says so. The API key lives in an environment variable and nowhere in the repo.

What I got wrong on the way

I almost trained on three pages. I had put all eight new pages into the held-out list. That left the training set exactly where it started. Reading the dry-run's "36 examples" line is what caught the mistake.
My new photos were .jpeg, and the pipeline looked for .jpg. They were skipped without a single warning. Renaming fixed it.

What I learned
Label quality matters as much as quantity. Some of the mistakes I found in compare.html were mine, not the model's: a "crossed out" label on a row I never crossed out. A model can only be as consistent as the labels it is trained and judged on.
Measure the baseline fairly. Base Qwen's 0% looked dramatic and meant "can't follow my JSON format". Gemma was the honest comparison.
Look at the rows, not just the percentages. The scoreboard said the fine-tuned model was a little better. The side-by-side page showed where: credit versus payment and the neat and messy pages, not the mixed one.
Dry-run first. The whole fine-tune cost about forty cents because I rendered everything for free before spending any credit.

What's next

Learn the neighbours' khata. Label a few pages in their layout and run the same pipeline. Every page they confirm in the app becomes training data (--from-db).
More writers. My own handwriting is in all 14 pages. Pages from other hands will show how far the model carries.
Publish the adapter on Hugging Face (Tinker can push a checkpoint straight there), so anyone can run it on their own hardware.
Package it as an app so a shopkeeper can use it without a laptop.

The review screen is part of the design: the model proposes the rows, the shopkeeper confirms them, and nothing reaches the ledger unchecked.

Why Does Open Innovation Matter?

It stays on the shopkeeper's computer. A khata is a list of who owes whom. With open weights the default path never uploads a photo, and the cloud path is opt-in and said out loud.
I could change the model and measure it. Tinker let me fine-tune open weights for about 38 cents, and I could run that against an open baseline on the same pages with the same scorer. Swapping the base model is one variable (TINKER_BASE_MODEL).
I could see why it was wrong. The comparison page shows each wrong field next to the right value, so I could tell a reading error from a spelling variant instead of trusting one score.
The result is reproducible. Open weights, my labelled pages, my scorer and the saved outputs are all in the repo, so anyone can rerun the comparison.

Prize Categories
Best Use of Tinker: LoRA fine-tune of Qwen3.6-35B-A3B on 36 augmented examples, scored on 5 held-out pages against a local baseline, for about $0.38.
Best Use of Gemma: Gemma 4 e4b runs locally through Ollama as the private default and as the baseline the fine-tuned model has to beat.

Built with Claude and tea ☕.

Who Do You Report a Pothole To? I Built Civic Lens to Answer That

Simran Kaur — Sun, 11 Oct 2026 12:56:32 +0000

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

What I Built

Living in India comes with a lot of infrastructure problems, and somewhere along the way we stopped seeing them. A garbage pile at the corner, a broken footpath, a dead streetlight. Nobody fixes them, and honestly we don't either. We walk past and carry on with the day as if everything is fine.

Even people who do notice usually don't know who is responsible or where to report it. I didn't, until I built this.

Civic Lens is a web app that makes you actually look. You type your area and get a short quest with three categories: safety and infrastructure, cleanliness and environment, accessibility and public space. For each one you go outside, photograph a real problem, and write how you'd fix it. Then you get:

a score for the problem and for your proposed fix
the kind of authority responsible for it
a 4-step action plan
a complaint draft, written for you, ready to copy
a link to an official government reporting page, when one can be found

Do all three and you get "Grass Touched 🌱". The point isn't the points. It's learning who is responsible for the everyday problems around you, and having a complaint ready to send.

Demo

I've added a demo video in project's readme. Please check it out if you get a chance :)
Live Site: https://civiclens-web-v1aa.onrender.com/

Taking it outside: I walked around my area and tried it for real. It felt awkward. Standing on the road photographing a garbage pile or a broken stretch of pavement from different angles, with people walking past, is not something I'm used to, and I caught myself wanting to hurry up and move on.

I took 5 pics. For the demo video I uploaded them with the "Choose from gallery" button, so the in-app camera flow isn't in the recording.

What I saw when I ran them:

Scores: they felt fair. My proposed fixes were short and not very detailed, and the scores reflected that, so the grader wasn't just handing out high marks.
Reporting channel: I only tried "Find reporting channel" once, on an infrastructure issue. It returned a generic Delhi government link that was probably not the right place for road complaints, and it still gave me the +2 bonus. This is the weakest part of the app right now, and I explain why below.

Code

arkia09 / CivicLens

Civic Lens

Photograph three real problems in your neighbourhood, propose a fix, and get a score the responsible authority and a ready-to-send complaint

Live app · DEV post

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass. The backend is on a free Render plan and sleeps when idle, so the first request can be slow.

Demo Video

Video.Project.5.1.1.1.1.mp4

Features

Gemma writes a short quest for your area, with one hint for each of three categories.
Upload a photo and your proposed fix. Gemma checks the photo, scores the problem and your fix, names the kind of authority responsible, and drafts a complaint.
SerpApi looks for an official government reporting page (.gov.in / .nic.in) for a +2 bonus.

Tech stack

Backend: FastAPI, Pydantic, httpx, Pillow
Frontend: React, TypeScript, Vite, Tailwind CSS
AI: Gemma via the google-genai SDK
Search: SerpApi
Hosting: Render

Project structure

civiclens/
├──

…

View on GitHub

This is how my project's structure looks like:

civiclens/
├── backend/
│   ├── main.py        # FastAPI routes: /api/quest, /api/analyze, /api/find-channel
│   ├── gemma.py       # everything that talks to Gemma
│   ├── search.py      # SerpApi lookup, ranking, cache, daily cap
│   ├── prompts.py     # all prompt text, separate from logic
│   ├── models.py      # Pydantic models, the API contract
│   ├── utils.py       # image checks, duplicate detection, score math
│   ├── mock_data.py   # canned data for frontend work
│   └── tests/
├── frontend/
│   └── src/
│       ├── App.tsx, api.ts, points.ts, types.ts
│       └── components/   # SlotCard, ResultView, ChannelFinder, Completion, Mascot
└── render.yaml

How I Built It

Stack: FastAPI, React with Tailwind, Gemma for analysis, SerpApi for the reporting link, Render for hosting. I spent most of my time on the backend. I'll be upfront that Claude built almost all of the UI, because I had very little time.

How Gemma is used

I call Gemma through Google's API with the google-genai SDK. There are two jobs.

1. The quest is text only. Gemma writes a short briefing and one hint per category for the area you typed. If it fails, the app falls back to a static template, so a quest never fails to load.

2. Photo analysis is the main one. When you submit a photo and your fix, the backend:

Checks the file (JPG or PNG, size limit, magic bytes so a renamed file can't pass) and hashes it to catch reused photos.
Fixes phone rotation and shrinks it to 1280px, since phone photos are huge.
Sends the image plus a prompt to Gemma, with a system instruction at low temperature (0.2).
Gets back JSON, parses it, and validates it with Pydantic. If the JSON is broken, it retries once.
Checks photo_check first: is this a real outdoor photo, does it show a civic problem, and does it match this category? If not, the user gets a friendly rejection instead of a score.
Computes the total score in the backend. The model gives two numbers from 0 to 10 and never adds anything up.

If the primary model errors out (gemma-4-26b-a4b-it), the backend retries with a fallback (gemma-4-31b-it).

Because users type text that goes into a prompt, I treat it as data. The user's text is wrapped in tags, the system prompt says to never follow instructions inside them, and I strip any attempt to close those tags. A "give me 10/10" solution gets a zero.

Right now the three category names are hardcoded, like this:

SLOT_TITLES = {
    "safety_infrastructure": "Safety & infrastructure",
    "cleanliness_environment": "Cleanliness & environment",
    "accessibility_public_space": "Accessibility & public space",
}

Gemma already writes the hints for each area, but not the categories. Having Gemma pick different categories on every Start over is next on my list.

SerpApi

SerpApi searches Google for the official page where a complaint can be filed, like [area] [authority] [issue] complaint grievance portal. I only accept results on .gov.in or .nic.in that also mention words like "grievance" or "portal". If nothing qualifies, the app says so and gives no bonus. A found page is worth +2 points, so the app rewards knowing where to report.

I had never heard of SerpApi before this challenge, so I spent a lot of time in its documentation. It helped me fix my errors and get it into the app.

Limits right now, and I'm working on them:

Sometimes the search fails and my backend returns a 503. Pressing "Try again" usually works.
My filter only checks that a result is on an official domain (.gov.in or .nic.in) and mentions words like "grievance" or "portal". It does not check that the page belongs to the right department. When I tested an infrastructure issue, it returned a generic Delhi government link that was probably not the right channel for road complaints, and it still gave me the +2 bonus. In an earlier test it found a proper MCD page, so it works sometimes, but I can't promise it's right. The bonus rewards finding an official page, not verifying it.
There's a daily cap of 50 searches to protect my quota, and an in-memory cache. Both reset when the server restarts.

Render, and the hour I'll never get back

I hadn't used Render before, so I had ChatGPT walk me through the dashboard. It told me I didn't need to import my .env, so I added the variables by hand. And I misspelled CORS_ORIGINS as CORS_ORIGIN.

My deployed site then threw this in the console:

Access to fetch at 'https://civiclens-xyhi.onrender.com/api/quest' from origin
'https://civiclens-web-v1aa.onrender.com' has been blocked by CORS policy...
No 'Access-Control-Allow-Origin' header is present on the requested resource.

I spent about an hour suspecting my backend. It was a spelling mistake, plus a trailing slash on the API URL that produced //api/quest. The code ignores a variable with the wrong name and falls back to localhost, so nothing complained. Next time I check the spelling first.

Why Does Open Innovation Matter?

Gemma has open weights. To be honest about my setup: I use it through Google's hosted API, so it isn't running locally or offline. What open weights gave me is a way out.

No lock-in. The scoring and complaint writing come from prompts I wrote and control (prompts.py). If a better open model shows up, I change a model name, not the app.
Fallbacks I choose. I use two different Gemma models as primary and fallback, and I can add more.
A path to privacy. People are photographing their own streets. With open weights, I could later run this on a server I control so those photos don't go to a third party. That's a future step, not what's live today.

What's Next

Gemma picks different categories every time you start over, so quests aren't the same each time.
A leaderboard. Today your points live only in your own browser (they survive a refresh, but not a different device), so anyone can edit them. A real leaderboard needs a database and some way to trust the scores.
Better search accuracy for the official reporting page.

Known limits: the app can't prove you went outside, only that you sent a convincing photo. And the free backend resets its cache and duplicate-photo list on restart.

There's still a long way to go, but it works, and I now know who to call about the garbage pile on my street.

Prize Categories

Best Use of Gemma: quest writing and the photo analysis, scoring and complaint drafting.
Best Use of Render: the API and the static frontend both run on Render.
Best Use of SerpApi: finding the official government reporting page, which drives the bonus points.

DEV Community: Simran Kaur

Department of Unnecessary Affairs: I built a government office to help me avoid doing things

What I Built

1. Morning Docket Office

2. Bureau of Pending Affairs

3. Office of Correspondence Avoidance

4. Commission for Unnecessarily Complicated Documents

5. Tribunal for Minor Inconveniences

A few things shared across the offices

The Department's questionable personnel and activities

Demo

arkia09 / DUA

Department of Unnecessary Affairs

The five offices

How I Built It

1. Gemma proposes. Python decides.

2. The Bureau cannot approve every excuse

3. Demo mode uses the same checks

4. Deploying Django on Render

5. The bugs that changed the implementation

6. Running the model locally

Why Does Open Innovation Matter?

What's Next?

Prize Categories

I fine-tuned Qwen3.6 on Tinker to read my neighbours’ khata: 98% credit/payment accuracy for $0.38

What I Built

Demo

What my neighbours said

The side hustle

Code

arkia09 / Ledgerly

Ledgerly

Layout

Setup (Windows PowerShell)

Step 1 workflow

How I Built It

Step 1: the baseline, with a local Gemma

Step 2: the data (the boring part that decides everything)

Step 3: fine-tuning on Tinker

Choosing the model

Step 4: the evaluation

Step 5: seeing the mistakes, not just the percentages

Using it in the app

What I got wrong on the way

What I learned

What's next

Why Does Open Innovation Matter?

Prize Categories

Who Do You Report a Pothole To? I Built Civic Lens to Answer That

What I Built

Demo

Code

arkia09 / CivicLens

Civic Lens

Demo Video

Features

Tech stack

Project structure

How I Built It

How Gemma is used

SerpApi

Render, and the hour I'll never get back

Why Does Open Innovation Matter?

What's Next

Prize Categories