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

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:

1. Open the Bureau of Pending Affairs.
2. Select one of the built-in Try examples and submit it.
3. Mark a task as complete.
4. Download the .ics to-do list.
5. 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.