DEV Community: ujja

Building an Offline-First Bushfire Response Platform With Hermes Agent

ujja — Thu, 28 May 2026 01:51:59 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

Project Haven is an AI-powered emergency response platform for bushfire preparedness — evacuation routing, tiered real-time alerts, government recovery grant discovery, and offline-first PWA support for when mobile networks go down mid-crisis.

The platform was originally a 46-hour hackathon build (GovHack 2024 — we won). This year I brought it back from the dead and rebuilt it properly: event-driven microservices, contract-first OpenAPI specs, a prediction engine based on XGBoost weights from our historical bushfire notebooks, and a fully offline-capable React PWA.

The one piece that was always a hollow mock was the AI Assistant — the in-app emergency guidance chat. It had a setTimeout pretending to think and a big switch statement of canned responses. Every time I looked at it I felt embarrassed.

Hermes fixed that.

Hermes Agent is now the live brain behind three things in Project Haven:

In-app emergency guidance — the AI Assistant page calls Hermes via its OpenAI-compatible /v1/chat/completions API, grounded with a system prompt that constrains it to verified Australian emergency protocols and instructs it to escalate emergency situations to 000.
Scheduled fire-risk briefings — Hermes runs a natural-language cronjob that fires every morning at 6am during fire season, calls the Bureau of Meteorology and NSW RFS feeds, synthesises a risk summary, and publishes it as an event into the alert pipeline.
Recovery grant research — when a user marks themselves as "in recovery", Hermes autonomously searches for current government grant programs (NDRA, state schemes, Services Australia), compares them against the user's declared situation, and adds matched recommendations to the recommendation service DB.

Demo

🔗 GitHub Repository: project-haven

Running it locally

cp .env.example .env
docker compose up --build

That's it. One command spins up 6 microservices, an API gateway, PostgreSQL instances, RabbitMQ, and the React PWA at http://localhost:3000.

To trigger the full prediction → alert pipeline:

curl -X POST http://localhost:8080/weather \
  -H 'Content-Type: application/json' \
  -d '{"lat":-33.87,"lng":151.21,"temperature":42,"windSpeed":80,"humidity":10,"season":"summer","vegetationDensity":0.9}'

That simulates an extreme weather event near Sydney, runs it through the prediction engine, and fires a CRITICAL alert through the system within seconds.

Screenshots

AI Assistant — Hermes-powered emergency guidance

The AI Assistant page now sends messages to Hermes via the api-gateway (/assistant/v1/chat/completions). Hermes has persistent memory across sessions via X-Hermes-Session-Key, so if a user opened the app two days ago and said "I'm in the Blue Mountains", Hermes still knows that when they say "the fire is getting closer" today.

Scheduled briefings appearing in the alert feed

Every morning during fire season, Hermes fetches live fire danger ratings from the NSW RFS API, synthesises a 3-sentence risk summary grounded in real data, and injects it as a feed.created event. The event propagates through RabbitMQ to the alert service and appears in-app within seconds.

Recovery grant matching

A user marks the "Recovery" scenario. Hermes is asked to research grants available for their postcode and situation. It uses its web search tool to check current Services Australia pages — bypassing the staleness problem of any static dataset — and returns structured results that get persisted back to the recommendations table.

Code

🔗 GitHub Repository: project-haven

Running it locally

The full stack — Haven microservices + Hermes Agent + a local LLM — runs entirely on your machine. No external inference API needed.

Requirements: Docker Desktop 27+, 8 GB RAM minimum (16 GB recommended), macOS / Linux / WSL2 on Windows.

Ollama, the model, all backend services, and the frontend are all managed by Docker Compose. No host-level installation needed beyond Docker itself.

Step 1 — Clone and start everything

git clone https://github.com/ujja/project-haven.git
cd project-haven
cp .env.example .env
docker compose up --build

On first start, the ollama-init container pulls nous-hermes2 (~4.5 GB) automatically. The api-gateway waits for the pull to complete before starting. Subsequent starts are fast — the model is cached in a Docker volume.

Progress is streamed to the compose log. Once you see api-gateway | api-gateway listening on port 8080, everything is ready.

Step 2 — Test the full pipeline

# Simulate an extreme weather event near Sydney → triggers prediction → alert
curl -X POST http://localhost:8080/weather \
  -H 'Content-Type: application/json' \
  -d '{"lat":-33.87,"lng":151.21,"temperature":42,"windSpeed":80,"humidity":10,"season":"summer","vegetationDensity":0.9}'

# Ask the AI assistant directly
curl -X POST http://localhost:8080/assistant/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"nous-hermes2","messages":[{"role":"user","content":"There is a bushfire near me. What do I do right now?"}]}'

# Search live recovery grants
curl -X POST http://localhost:8080/recommendations/research \
  -H 'Content-Type: application/json' \
  -d '{"postcode":"2750","situation":"home destroyed by bushfire"}'

Architecture of the local stack

React PWA (port 3000)
        ↓
API Gateway (port 8080)
   ├── /assistant/*  →  Ollama /v1/chat/completions (nous-hermes2)
   ├── /recommendations/research  →  Ollama (structured JSON)
   └── node-cron @ 6am  →  Ollama → feed-service
        ↓
Ollama container (port 11434, haven-net)
        ↓
nous-hermes2 (cached in ollama-data volume)

Everything runs inside Docker Compose. ollama-init pulls the model once on first start; the ollama-data volume persists it across restarts.

Starter model recommendations

Model	Size	Best for
`nous-hermes2`	~4.5 GB	Default — strong instruction following, good JSON
`gemma2:9b`	~5.4 GB	Superior JSON adherence
`gemma2:2b`	~1.6 GB	Low-RAM machines, faster responses
`llama3:latest`	~4.7 GB	General-purpose alternative

Set HERMES_MODEL in .env to swap. Also update the ollama-init entrypoint in docker-compose.yml to pull the new model.

Avoid 70B-class models unless you have GPU hardware with 40+ GB VRAM.

Common issues

First start is slow: The ollama-init container has to download the nous-hermes2 model (~4.5 GB). Subsequent starts skip this.

Model too slow on CPU: Edit .env and set HERMES_MODEL=gemma2:2b (1.6 GB, much faster). Also update the ollama-init entrypoint in docker-compose.yml to pull the new model.

WSL2 networking problems: Volume mounts and bridge networking have edge cases — increasing Docker's memory allocation in Docker Desktop settings usually resolves them.

Linux GPU acceleration: Uncomment the deploy block in the ollama service in docker-compose.yml and ensure nvidia-container-toolkit is installed.

My Tech Stack

Layer	Technology
AI backbone	Nous Hermes 2 via Ollama (OpenAI-compatible, locally hosted)
Frontend	React 18, TypeScript, Vite, Workbox PWA, Leaflet
Backend	Node.js 20, Express, TypeScript — 6 microservices + API gateway
Messaging	RabbitMQ (event-driven: weather → prediction → alert pipeline)
Databases	PostgreSQL (per-service)
ML	XGBoost (Python notebooks → TypeScript heuristic engine)
Data	Digital Atlas / Geoscience Australia ArcGIS REST APIs
Infra	Docker Compose, multi-stage builds, shared `@haven/shared` npm package

How I Used Hermes Agent

1. OpenAI-Compatible Inference — Zero New API Surface

Ollama exposes POST /v1/chat/completions exactly like the OpenAI SDK expects. It runs as a Docker Compose service (ollama) on the internal haven-net network. The api-gateway proxies /assistant/* directly to http://ollama:11434. No separate agent container, no extra port, no API key management between services.

In AIAssistant.tsx, the getAIResponseHermes() function — previously a setTimeout + switch statement — became a real API call:

async function getAIResponseHermes(userMessage: string): Promise<string> {
  const res = await fetch('/assistant/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'nous-hermes2',
      messages: [
        {
          role: 'system',
          content: HAVEN_SYSTEM_PROMPT,  // emergency protocols, escalate to 000, AU context
        },
        { role: 'user', content: userMessage },
      ],
      max_tokens: 512,
    }),
  });
  if (!res.ok) throw new Error(`Ollama responded with ${res.status}`);
  const data = await res.json();
  return data.choices[0].message.content;
}

The api-gateway proxy strips any client-side auth before forwarding to Ollama. A stable session key is stored in localStorage per browser for memory scoping, ready for if a stateful layer is added upstream.

2. Scheduled Fire Risk Briefings — Natural Language Cron

Hermes's cron scheduling is genuinely one of its most underrated features. Instead of writing a Node worker with node-cron, a BOM API client, a response parser, and an event publisher, I wrote this in the Hermes config:

jobs:
  - name: fire-risk-briefing
    schedule: "0 6 * * * (Oct-Mar)"   # 6am daily, fire season only
    prompt: |
      Check the current fire danger ratings for NSW, VIC, SA, and WA from the
      Bureau of Meteorology and RFS feeds. Synthesise a 3-sentence morning
      briefing — severity level, highest-risk regions, and one action
      recommendation. Keep it under 80 words. Respond with JSON:
      { "severity": "LOW|MEDIUM|HIGH|EXTREME|CATASTROPHIC", "summary": "..." }
    deliver: http://api-gateway:8080/feeds
    skills: [web_search]

Hermes handles the scheduling, the web fetch, the summarisation, and the HTTP delivery. The /feeds endpoint in the feed service receives the JSON payload and publishes it as a feed.created event. The entire pipeline — external data → summary → in-app alert — runs without any new code.

3. Recovery Grant Research — Delegating Agentic Workloads

The recommendation service seeds static government programs at startup. But government grants change — new schemes open after disasters, eligibility criteria shift, application portals go down and come back up.

For the recovery scenario, I added a route in the api-gateway that delegates a research task to Hermes:

// api-gateway: POST /recommendations/research
// HERMES_BASE = http://ollama:11434 (set via env in docker-compose)
// HERMES_MODEL = nous-hermes2 (default, overridable via HERMES_MODEL env var)
app.post('/recommendations/research', express.json(), async (req, res) => {
  const { postcode, situation } = req.body;

  const hermesRes = await fetch(`${HERMES_BASE}/v1/chat/completions`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: HERMES_MODEL,
      messages: [
        {
          role: 'system',
          content: 'You are an Australian emergency recovery specialist. Return ONLY a valid JSON array — no markdown fences, no commentary, just the array.',
        },
        {
          role: 'user',
          content: `Research current Australian government disaster recovery grants
            available for postcode ${postcode}. Situation: ${situation}.
            Return JSON array of { title, provider, description, applicationUrl, eligibilitySummary }.
            Only include currently open programs with verified URLs.`,
        },
      ],
      max_tokens: 1024,
    }),
  });

  const data = await hermesRes.json();
  const content = data.choices[0].message.content;
  // Strip accidental markdown fences if the model wraps the JSON
  const cleaned = content.replace(/^```
{% endraw %}
(?:json)?\n?/, '').replace(/\n?
{% raw %}
```$/, '').trim();
  const grants = JSON.parse(cleaned);
  res.json({ grants });
});

Hermes uses its web search tool to check current Services Australia, state government, and Red Cross pages. It returns structured JSON. The gateway upserts the results into the recommendation service — live, verified, current — not frozen in a seed file.

The key agentic capability here is web search grounded in the real prompt: Hermes significantly reduced stale or hallucinated grant recommendations by grounding responses in live web results rather than parametric knowledge. It fetches the actual pages, checks them, and only returns what it finds. For emergency advice, that correctness bar is non-negotiable.

Hermes vs. the Alternatives — An Honest Comparison

Before landing on Hermes, I experimented with a few other locally-run models. Here's what that comparison actually looked like for an emergency-context application.

Llama 3.1 / 3.2 (via Ollama)

Llama is the obvious first stop for local inference. I ran Llama 3.1 8B and 3.2 3B through Ollama and pointed the same system prompt at them.

What worked: Ollama's OpenAI-compatible /api/chat endpoint made drop-in testing easy. Llama 3.2 3B is genuinely fast on Apple Silicon — response latency was better than Hermes on equivalent hardware. For simple question-answering against a fixed system prompt, the outputs were reasonable.

What didn't: Neither model had built-in tool execution, persistent session memory, or a scheduler — all three capabilities I needed. To replicate Hermes's cron briefings with Llama, I would have written a Node cron worker, a separate BOM API client, a response parser, an event publisher, and a memory store. That's four services Hermes replaced with a YAML block. Llama also had a notable tendency toward elaboration — answers were often 3-4× too long for a crisis UX where brevity is safety-critical. Prompt engineering helped, but it was a constant battle.

Verdict: Great for straight inference tasks where you're bringing your own orchestration layer. Not the right fit when you need the agent capabilities without the plumbing.

Gemma 2 (9B, via Ollama)

Google's Gemma 2 9B was the most pleasant surprise in terms of raw instruction-following. It respected format constraints (JSON output, word limits) more reliably than anything else I tested at this size.

What worked: JSON output adherence was excellent. When I told it to return { "severity": "...", "summary": "..." }, it almost always did — no markdown wrapping, no prose preamble. That's unusually good at 9B parameters. It also handled the Australian emergency context well without needing extensive ground-truth examples in the system prompt.

What didn't: Same infrastructure gap as Llama — no native tool use, no session memory, no scheduling. Gemma 2's knowledge cutoff also made it confidently wrong about post-2024 government programs (it cited DRFA schemes that had been superseded). For a platform that needs to tell people where to apply for grants right now, that's a hard failure mode. Web search grounding isn't optional here.

Verdict: Best raw model for structured output tasks at the 7-9B tier. If I ever strip Hermes out and build the orchestration layer myself, Gemma 2 is what I'd put under it.

Mistral 7B / Mistral-Nemo

I tried Mistral 7B Instruct and Mistral-Nemo (12B) briefly. Both are fast and capable general-purpose models. But in the emergency context, Mistral had one consistent problem: it over-hedged.

Every answer about what to do in a bushfire came back wrapped in "I am not a qualified emergency services professional and this should not be taken as official advice…" disclaimers that would fill half the screen on a mobile device. I understand why models are trained to do this. But during an actual emergency, a response that leads with three sentences of disclaimer before telling someone to leave is arguably worse than no AI at all. Getting Mistral to drop the hedging without also dropping the actual safety guardrails required more system prompt engineering than the ROI justified.

Verdict: Capable model, wrong default behaviour for a high-stakes UX. Taming it is possible but expensive in prompt tokens and iteration time.

Hermes — What It Does Better

Against this field, here's where Hermes genuinely pulls ahead:

Native tool execution with no orchestration layer. Web search, HTTP calls, file reads — built in. No LangChain, no custom function-calling wrapper, no managing tool schemas manually. For the grant research workflow (fetch → parse → structure → return), this is a week of orchestration code that just isn't written.

Persistent session memory across requests. Every other model I tested was stateless per-request. Hermes's session-scoped memory model is simple and works reliably in practice. For a crisis scenario that plays out over days, that matters.

Cron scheduling with natural language task definitions. Nothing else offers this at the infrastructure level. The fire-season briefing scheduler is 12 lines of YAML.

Stays on the wire it's told to stay on. Hermes with the Haven system prompt stays grounded in Australian emergency protocols, is instructed to escalate emergency situations to 000, and significantly reduced stale or hallucinated grant recommendations by grounding responses in live web results. The safety system prompt feels sticky in a way that required more reinforcement with Llama and Mistral.

Why I Chose Hermes Over More General Agent Platforms

I also evaluated broader autonomous-agent platforms — particularly OpenClaw-style systems built around persistent personal agents, plugins, and wide capability surfaces.

Those systems are impressive. But for Project Haven, they solved a different problem than the one I actually had.

Project Haven is not trying to build:

a personal AI operating system,
a desktop automation agent,
or an infinitely extensible multi-agent ecosystem.

It needs something much narrower and more reliable:

deterministic emergency workflows,
bounded tool execution,
persistent memory,
scheduled autonomy,
and predictable behaviour under pressure.

That distinction ended up mattering a lot.

Platforms like OpenClaw optimise for maximum flexibility — plugins, integrations, autonomous behaviours, evolving capability graphs. Hermes feels more opinionated. In practice, that was a benefit.

For an emergency-response application, I cared more about:

reliability over extensibility,
constrained behaviour over open-ended autonomy,
and operational predictability over ecosystem breadth.

The tighter execution model made Hermes easier to reason about architecturally. The memory model was simpler. The scheduling primitives were built in. And the default operational surface felt significantly safer for a high-stakes context.

That tradeoff means Hermes currently has a smaller ecosystem, fewer integrations, less community tooling, and less flexibility than broader agent platforms. But for Project Haven, that narrower scope was exactly the point.

I didn't need an AI operating system. I needed a dependable emergency-response runtime that could live entirely inside my infrastructure stack and keep working when the situation around it stopped being normal.

Where Hermes Falls Short

Being honest about the gaps matters:

Cold start time. Hermes in Docker takes noticeably longer to reach a ready state than a model served via Ollama. On my MacBook Pro M2, Ollama with Llama 3.2 3B is ready in under 5 seconds. Hermes takes 15-25 seconds to initialise its memory backend and tool registry. In a production deployment this is a non-issue (it starts once). In development, it slows iteration loops.

Raw inference speed at the same model size. Hermes's overhead — memory management, tool routing, session handling — costs tokens per request. For a simple in-context QA task with no tools, Llama through Ollama will answer faster. For the agentic tasks (web search, multi-step research), that comparison flips because Hermes automates and coordinates multi-step tool execution.

Documentation gaps. The job scheduler YAML schema isn't well-documented — I spent more time than I'd like reading source to understand what deliver: accepted and how session keys scope memory. Llama/Gemma via Ollama have significantly more community documentation. Stack Overflow has nothing for Hermes-specific issues yet; you're on the GitHub issues list and Discord.

Model selection is less flexible. Hermes currently offers less model flexibility than a pure Ollama workflow. If you want Gemma 2 9B's superior JSON adherence under Hermes's tool/memory layer, that combination isn't always straightforward depending on your configuration. With Ollama, you can swap models in one command. This matters if you're trying to tune cost/quality tradeoffs.

Windows support is rough. Docker on Windows with WSL2 works but the volume mounting and networking for Hermes's memory backend had edge cases I had to work around. On macOS and Linux it was smooth.

Why Hermes Was the Right Fit (Despite All That)

A few things made Hermes specifically well-suited here over rolling a custom LLM integration:

It lives on your server. Project Haven is explicitly designed for scenarios where internet connectivity is degraded. Hermes runs in the same Docker Compose stack as everything else — no dependency on an external inference API during the crisis window. The model runs locally.

Persistent memory that scales with the crisis. Emergency situations evolve over hours and days. A user's context from this morning matters when they're asking questions tonight. Hermes's session memory handles this automatically.

Scheduled autonomy fits the "prevention not reaction" model. The best emergency outcome is a user who prepared before the fire arrived. Hermes's cron scheduler lets Project Haven push proactive briefings during fire season without any always-on polling infrastructure.

OpenAI-compatible API means zero new client code. The React frontend, the Node gateway, anything that already speaks the OpenAI format works against Hermes unmodified. No new SDK. No vendor lock-in.

Local inference eliminates API dependency risk. One thing that became obvious very quickly while testing hosted AI APIs was how fast autonomous workflows amplify usage. A single user interaction can become multiple model calls — retrieval, summarisation, reasoning, formatting, follow-up clarification. For a crisis-response platform, depending entirely on external inference APIs introduced operational and cost dependencies I wasn't comfortable with. Running Hermes locally shifted the tradeoff toward compute and infrastructure complexity instead of per-token billing and rate limits — which was the right trade for this project.

Final Thoughts

Project Haven started as a 46-hour hackathon build, sat frozen for two years, and became the platform it was always supposed to be during this rebuild.

The AI Assistant was always the most important feature and the least real. Hermes made it real — not just more capable, but genuinely appropriate for the stakes of an emergency context: server-local, memory-persistent, verifiably grounded, and invisible enough to get out of the way when someone needs an answer fast.

If you're building anything where the AI output actually matters — where a wrong answer has real consequences — the pattern of running Hermes locally with a tight system prompt and opaque tool execution is one I'd recommend seriously.

Built with TypeScript, React, Node.js, PostgreSQL, RabbitMQ, Docker, Hermes Agent, and a lot of respect for the people who actually work bushfire emergencies.

Originally born at GovHack 2024. Finally given room to grow.

From Govhack Win to Something That Actually Matters

ujja — Sun, 24 May 2026 12:46:29 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Project Haven is an AI-powered emergency response and disaster recovery platform built specifically for bushfire preparedness — helping people find safe evacuation points, receive real-time alerts, access government recovery support, and stay informed even when the internet cuts out.

The core idea is simple but important: during a bushfire, information is survival. Where are the nearest evacuation centres? How bad is the risk right now? What government grants can I apply for after my home is damaged? Project Haven tries to answer all of that — fast, reliably, and even offline.

Under the hood, the platform combines:

Predictive analytics — a bushfire risk engine combining the McArthur FFDI Mark 5 formula (official BOM standard) with an XGBoost model trained on GA historical fire data, running as a Python sidecar blended at 80/20
Smart evacuation routing — nearest safe space recommendations with distance and ETA
AI-powered recovery support — scenario-based government grants and services backed by live AI research via Nous Hermes 2 (real ones, like the Disaster Recovery Payment and Primary Producer Recovery Grant)
Live emergency guidance — an AI Assistant powered by Nous Hermes 2 running locally via Ollama; real conversational responses grounded in Australian emergency protocols, with a system prompt that escalates to 000 when needed
Live community feed — on-the-ground updates from people in affected areas
Real-time alerts — tiered notifications from low-priority feed updates to full-screen critical banners
Offline-first PWA — because during emergencies, mobile networks are the first thing to go

The architecture is fully event-driven microservices: a prediction service subscribes to weather updates, runs the FFDI engine blended with an XGBoost model-service sidecar (Python/FastAPI, trained from GA bushfire boundaries and baked into Docker at build time), publishes bushfire predictions, and the alert service automatically generates tiered notifications from those predictions. All async. All decoupled. RabbitMQ handling the message bus, PostgreSQL for persistence, React PWA for the frontend, everything containerised and wired together with Docker Compose — including a local Ollama instance serving Nous Hermes 2 for the AI Assistant, grant research, and scheduled fire-season briefings.

The part I'm still most proud of? The offline-first thinking. The app caches evacuation points, alerts, and recommendations locally. If connectivity drops mid-crisis — which it will — the app keeps working.

Demo

🔗 GitHub Repository: project-haven

Running it locally

cp .env.example .env
docker compose up --build

That's it. One command spins up 6 microservices, an API gateway, PostgreSQL instances, RabbitMQ, and the React PWA at http://localhost:3000.

To trigger the full prediction → alert pipeline:

curl -X POST http://localhost:8080/weather \
  -H 'Content-Type: application/json' \
  -d '{"lat":-33.87,"lng":151.21,"temperature":42,"windSpeed":80,"humidity":10,"season":"summer","vegetationDensity":0.9}'

That simulates an extreme weather event near Sydney, runs it through the prediction engine, and fires a CRITICAL alert through the system within seconds.

The Comeback Story

Okay, here's the honest version.

Project Haven was built for GovHack 2024

If you've never done GovHack — it's a 46-hour hackathon using Australian government open data. You show up, pick a problem, build something, demo it, and hope the judges like it.

I showed up with the idea of building something that could actually help people during bushfire emergencies. Real datasets. Real data analysis. A real prediction model. I used the Digital Atlas historical bushfire boundaries CSV and ABS community datasets, built XGBoost models in Jupyter notebooks, and sketched out an event-driven microservice architecture.

No UI. No running backend. Just the notebooks, the numbers, and a vision for what the system could be.

And I won.

Which was incredible. Genuinely one of those moments you don't forget.

And then... the project just sat there.

Because that's what happens after hackathons. The adrenaline drops. Everyone goes home. You sleep for two days. You go back to work on Monday. Life continues.

The codebase stayed frozen. The notebooks stayed frozen. The architecture stayed frozen — as a snapshot of an idea that had way more potential than a 46-hour demo ever got to show.

Not because the problem wasn't worth solving. Bushfire preparedness is genuinely important in Australia. Climate change is making it worse every year. The gap between what exists and what communities actually need during emergencies is still very real.

But once the goal is achieved, you move on. That's just human nature.

So when the GitHub Finish-Up-A-Thon came up, I immediately thought of Project Haven.

Because going back to old projects is a weird and strangely satisfying experience.

You look at the code and you see everything at once — the shortcuts you took at 2am, the TODOs you never came back to, the half-implemented features, the places where "good enough for demo day" was the bar. But you also see the original intent underneath all of it. And sometimes that intent is still worth pursuing.

This time, instead of treating it like a hackathon submission, I started treating it like an actual platform.

That meant a completely different mindset:

Before (hackathon mode):

A system design architecture diagram
Jupyter notebooks with some number crunching
No UI. No backend. Just the idea and the data analysis.
"I'll build the rest... later"

After (product mode):

Contract-first OpenAPI specs before any implementation
Proper microservice boundaries with clear domain ownership
Real TypeScript throughout — strict mode, no any, proper DTOs
Shared event contracts so every service speaks the same language
End-to-end Docker setup so anyone can run it with one command
Offline-first PWA with Workbox service workers, not just a checkbox
A prediction engine that actually reflects the model weights from my notebooks
Real Australian government services and grants seeded into the recommendation service
Full lucide-react icon system, proper design tokens, accessible UI

One of the biggest architectural calls was how to handle the shared module. Every service needed the same event shapes, DTOs, and logger. Instead of duplicating types everywhere (the hackathon approach), I built @haven/shared as a proper local npm package that each service depends on. The Dockerfiles build it first, then link it. Small thing, but it's the kind of thing that makes a codebase actually maintainable.

Another big one was the prediction engine. My XGBoost notebooks had a trained model for fire risk prediction. And here I'll be fully honest: I'm not a data scientist. During the hackathon I didn't really know what I was doing with the notebooks. I just sort of... cooked up weights that felt plausible. Temperature matters a lot? Sure, give it 0.35. Wind is bad? 0.25. Humidity inverse, obviously. Slap some season bonuses on. Done. Ship it.

Copilot called this out completely. Not in a confrontational way — but when I started asking about the prediction engine during the rebuild, it surfaced the actual problems: the test_size=0.8 split that meant the model was training on 20% of the data and validating on 80% (backwards), the area_ha < 3 outlier filter that was literally removing all the dangerous large fires from the training set, and — most damningly — the fact that the XGBoost model was predicting fire size from historical boundary features while the TypeScript engine was computing a risk score from weather inputs. They were solving completely different problems. The weights I'd put in had no relationship to anything the notebook had analysed. They were just numbers I made up at 2am that sounded reasonable.

So instead of just transcribing invented numbers, I rebuilt it properly. The engine now implements the McArthur Forest Fire Danger Index (FFDI) Mark 5 — the actual formula used by the Bureau of Meteorology and every Australian state fire service. The notebook was fixed (correct 80/20 train/test split, log-IQR outlier handling to keep the large fires), and the XGBoost model now serves a real purpose: predicting expected fire size (in hectares) for a given state and month, used as a historical context signal blended at 20% weight into the FFDI weather score. The XGBoost model now runs as a proper Python model-service FastAPI sidecar, trained at Docker build time from the GA Historical Bushfire Boundaries dataset and baked into the image so startup is instant. The prediction service calls it asynchronously with a 2-second timeout; if it's unreachable, FFDI-only scoring kicks in — no hard dependency on the critical path.

The "I just made numbers up" moment is a good illustration of why having something that can actually interrogate your assumptions matters, especially when you're working outside your domain.

The whole thing went from "hackathon skeleton with mock data" to a working end-to-end system you can actually spin up and test. Weather event goes in, prediction comes out, alert fires, PWA displays it — all observable, all local, all real.

My Experience with GitHub Copilot

I used GitHub Copilot as the primary engineering partner throughout this comeback — not as an autocomplete tool, but as a system-aware collaborator that held the full architecture in context while I worked.

Setting the stage: copilot-instructions.md

The first thing I did before writing a single line of implementation was write .github/copilot-instructions.md — a detailed spec covering the service boundaries, event contract shapes, CQRS split, security requirements, and UI/UX principles. Every rule I wanted enforced (contract-first OpenAPI, no any, DTOs at boundaries, observability hooks, WCAG AA) went in there.

That file became the foundation everything else was built on. Copilot read it before every response and generated code that conformed to patterns I'd already established — not guessing at conventions, but following documented ones. The difference in output quality was significant.

Scaffolding 6 microservices from a shared pattern

The biggest single time-save was scaffolding all six backend services. Each needed the same structure: Express app, helmet + cors + morgan, a rate limiter, a structured logger from @haven/shared, a postgres schema init with seed data, RabbitMQ pub/sub wiring, health endpoints, and a multi-stage Dockerfile that builds @haven/shared first and links it.

That's probably 150 lines of consistent boilerplate per service. With Copilot understanding the pattern from the first service, each subsequent one took minutes rather than hours — and they were consistent in ways that matter: same error envelope shape, same correlation ID middleware, same health check format, same log field names.

The shared module problem

Every service needed the same event shapes, DTOs, and logger. The hackathon approach was to duplicate them. The right approach was @haven/shared — a local npm package with its own tsconfig, built first in Docker, then installed into each service via file: resolution.

Working out the correct multi-stage Dockerfile pattern for this (build shared → copy dist → npm install in service context) is fiddly. Copilot got it right on the first pass and applied it consistently across all six service Dockerfiles and the Docker Compose dependency graph.

Transcribing XGBoost weights into TypeScript

My GovHack notebooks had a trained XGBoost model for fire risk prediction. Rather than running a Python sidecar in Docker, I wanted the prediction logic native to the Node service — self-contained, no cross-language IPC.

I showed Copilot the notebook's feature importances and coefficient output. It generated a TypeScript heuristic engine that replicated the same decision logic: weighted inputs for temperature, humidity, wind speed, vegetation density, and season; thresholds mapped to severity levels; confidence intervals from the training accuracy. Same model, different runtime. The prediction output matched what the notebook produced for the same inputs.

Rebuilding the entire UI from scratch

Emergency UX has specific demands — high contrast, large touch targets, one-handed mobile use, offline indicators, priority-tiered alert behaviour. None of the original components was built with any of that in mind.

Copilot rebuilt the entire frontend systematically:

Design system — a new index.css with semantic CSS variables (--c-critical, --c-high, --c-medium, --c-safe, spacing tokens, radius tokens, --nav-w for sidebar width, --header-h for page header clearance) and glassmorphism card styles
Left sidebar nav — rebuilt navigation from a mobile bottom bar to a 220px fixed left sidebar with icon + label rows, an active state indicator bar, online/offline status dot, and AI assistant + Settings links pinned at the bottom; collapses to a 60px icon-only rail at < 768px
Page headers with back navigation — every screen except the dashboard has a sticky 52px page header with a ChevronLeft back button that calls navigate(-1), giving the app proper browser-history navigation without a router-level back stack
Web app layout — removed the 430px phone-shell constraint and switched the root layout to display: flex; flex-direction: row so the sidebar and content fill the viewport side by side; no max-width on the main content area
Emergency dashboard — risk severity banner with animated pulse on CRITICAL, two-column grid layout (map + stat tiles on the left, live alerts + nearest safe spaces on the right at 380px), sticky CTA buttons
Alert overlay — full-screen takeover for CRITICAL priority alerts with haptic-style dismiss, priority-tiered behaviour (CRITICAL → full screen, HIGH → persistent, MEDIUM → toast, LOW → feed)
Three new screens — Onboarding (4-step permissions flow), Settings (toggles, emergency contacts, accessibility), AI Assistant (chat interface — now backed by Nous Hermes 2 via Ollama)

All components used the design token system consistently — no hardcoded hex values, no magic numbers.

Atlas data enrichment and real open data

The static seed data was a starting point, not a destination. I wanted the platform to pull from the best available Australian open data sources at startup — live fire detections, real evacuation assembly points, current government grants.

Copilot initially wrote three atlasEnrich.ts files using Geoscience Australia's Digital Atlas ArcGIS REST endpoints — a good foundation. But GA polygon data only goes so far, especially for fire detection where you want sub-3-hour satellite observations. So I went further.

The final enrichment pipeline by service:

safe-space-service — GA Atlas (topographic facilities) → OpenStreetMap Overpass API (no key required). The Overpass query targets emergency=assembly_point, emergency=evacuation_point, and amenity=evacuation_centre nodes within the Australia bounding box. OSM has surprisingly comprehensive coverage of designated emergency assembly points that don't appear in government datasets. Accessibility tags (wheelchair, toilets_wheelchair, parking_disabled, pets) are read directly from OSM node tags.

prediction-service — A four-source priority cascade: NASA FIRMS VIIRS NRT satellite detections (3-hour near-real-time, requires a free MAP_KEY) → VIC Emergency public JSON feed (no key) → NSW RFS major incidents JSON feed (no key) → GA vegetation polygon centroids → static fallback. The FIRMS response includes fire radiative power (frp) in MW and string confidence values ('l', 'n', 'h') which map to numeric probabilities for the risk engine. If FIRMS data exists, the live state feeds supplement it. If nothing is reachable, the static seed ensures the service always starts with plausible data.

recommendation-service — Curated seed of known recovery programs → GA Atlas community facilities → GrantConnect API (/v2/grants?keyword=bushfire+disaster&status=open, requires free API key). GrantConnect is the Australian Government's official grants database. The integration maps grant categories to the service's scenario taxonomy (GRANT, RECOVERY, HOUSING, HEALTH, EMERGENCY) and deduplicates on (scenario, title).

All three are fire-and-forget calls in each service's start() — never blocking, never throwing, always falling back gracefully. Both API keys (NASA_FIRMS_MAP_KEY, GRANTCONNECT_API_KEY) are optional environment variables documented in .env.example.

Debugging the ON CONFLICT DO NOTHING silent failure

After wiring up the enrichment layer, the recommendation and safe-space services kept inserting duplicate rows on every restart. The ON CONFLICT DO NOTHING clause was there — visually it looked correct. But it silently did nothing.

The root cause: every INSERT was using gen_random_uuid() as the primary key. UUID PKs are always unique by definition, so ON CONFLICT on the PK could never trigger. There was no other unique constraint, so duplicates streamed in on every startup.

The fix was two-part: add UNIQUE constraints on natural keys (name for safe spaces, (scenario, title) for recommendations) idempotently in the service's init() via a DO $$ BEGIN ... EXCEPTION WHEN duplicate_table THEN NULL; END $$ block, then update every INSERT — both seed and enrichment — to specify the column: ON CONFLICT (name) DO NOTHING. Copilot caught that the same pattern existed in all three atlasEnrich.ts files and fixed them in one pass.

Debugging the amqplib type breaking change

Mid-rebuild, four services stopped compiling. The amqplib types had changed between versions — Connection became ChannelModel, and import paths shifted. The errors were spread across bus.ts in every service that used the message broker.

Rather than hunting them down one by one, Copilot identified the pattern across all four files at once and applied the fix consistently: updated import paths, replaced Connection with ChannelModel, added the .channel access where the API had changed. What would have been 20 minutes of grep-and-fix was one operation.

The quality multiplier

The pattern I noticed across all of this: Copilot's output quality scaled directly with the quality of my specifications.

Vague prompt → vague result. But when the architecture was documented, the event contracts were defined, and the patterns were established in real code — Copilot could work within all of those constraints simultaneously. It wasn't generating generic Express boilerplate. It was generating Express code that matched the correlation ID middleware pattern, used the shared logger with the right field names, published events with the correct envelope shape, and returned errors in the { code, message } format defined in the OpenAPI spec.

That's the real leverage. Not autocomplete. Specification → conforming implementation at speed.

Final Thoughts

There's a whole graveyard of hackathon projects in GitHub repositories everywhere.

Most of them deserved more time than they got.

Project Haven started as a 46-hour sprint, won a competition, and then sat untouched for almost two years. This challenge gave me the push to go back and ask: what would this actually look like if it was built properly?

The answer turned out to be: a lot better.

The prediction pipeline works end-to-end. The offline-first architecture actually functions. The microservices actually talk to each other through real events. The UI is a full-width web application — not a phone simulator in a browser — with proper sidebar navigation, back-button routing, and a two-column dashboard that uses screen real estate the way a desktop tool should. Live fire detections from NASA satellites, real Australian evacuation assembly points from OpenStreetMap, and current government grants from GrantConnect flow in at startup. The AI Assistant — previously a setTimeout and a switch statement of canned responses — is now backed by Nous Hermes 2 running locally via Ollama, with a system prompt grounded in verified Australian emergency protocols. The prediction engine now implements the McArthur FFDI Mark 5 formula (the actual BOM standard) blended with an XGBoost model trained from real GA historical fire data — running as a Python FastAPI sidecar built into Docker — replacing the made-up weights from the hackathon. The whole thing runs with a single docker compose up --build.

None of that would have happened at this pace working solo without Copilot. Not because any individual piece was impossible — but because the sheer volume of consistent, conforming implementation across six services, a shared module, a full UI rebuild, a data enrichment layer across four distinct external APIs, and edge cases like the ON CONFLICT silent failure would have taken weeks of context-switching. With Copilot holding the system context and working within the established patterns, it compressed into days.

I'm not saying it's done. There's still proper auth flows, load testing, mobile push notifications, and a dozen other things on the list.

But it's no longer frozen in time as a hackathon demo.

It feels like something that could actually help someone.

And that's probably the best thing this challenge could have done.

Built with TypeScript, React, Node.js, Python (FastAPI + XGBoost), PostgreSQL, RabbitMQ, Docker, Ollama (Nous Hermes 2), and GitHub Copilot.

Originally born at GovHack 2024. Finally given room to grow.

I Built a Multi-Agent AI Tribunal with Gemma 4

ujja — Fri, 15 May 2026 15:41:31 +0000

What If AI Agents Put Each Other on Trial?

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

HumanLayer is a multi-agent AI governance platform. It features specialised Gemma 4 agents that collaborate to review, challenge, and hold one another accountable. This approach differs from a single model that quietly makes all the decisions.

Most governance tooling is written for people who already understand governance. I aimed to build a system that makes governance decisions understandable to the people they impact. I consider plain-English explainability a hard requirement, not simply a nice-to-have.

Overall Architecture

┌─────────────────────────────────────────────────────────────────────────────┐
│                          Browser / Next.js 15 UI                            │
│          Upload Doc  ·  Start Tribunal  ·  Appeal  ·  Audit Trail           │
└────────────────────────────────┬────────────────────────────────────────────┘
                                 │  HTTPS + CSRF
┌────────────────────────────────▼────────────────────────────────────────────┐
│                        FastAPI Backend  (port 8000)                         │
│  REST API v1  ·  JWT Auth  ·  Rate Limiting  ·  Content Scan Middleware     │
│                                                                              │
│  ┌─────────────────────────┐     ┌──────────────────────────────────────┐  │
│  │   Governance Council    │     │       Constitutional Tribunal        │  │
│  │                         │     │                                      │  │
│  │  Security  ·  Ethics    │     │  Prosecutor  ·  Defender             │  │
│  │  Privacy   ·  Access.   │     │  Advocate    ·  Ethics               │  │
│  │  Audit                  │     │       ↓  3 debate rounds             │  │
│  │       ↓  parallel       │     │  AI Jury ×4  →  Governance Judge     │  │
│  │  Consensus Engine       │     │       ↓  constitutional ruling       │  │
│  └────────────┬────────────┘     └─────────────┬────────────────────────┘  │
│               └──────────────────┬──────────────┘                           │
│                                  │                                           │
│              ┌───────────────────▼──────────────────┐                       │
│              │          Celery Worker (async)        │                       │
│              │  tribunal · analysis · documents ·    │                       │
│              │  default queues · concurrency=2       │                       │
│              └───────────┬───────────────────────────┘                      │
└──────────────────────────┼──────────────────────────────────────────────────┘
                           │
          ┌────────────────┼────────────────────┐
          ▼                ▼                     ▼
┌──────────────┐  ┌─────────────────┐  ┌─────────────────────────────────┐
│  PostgreSQL  │  │  Redis (broker  │  │    Google AI Studio             │
│  (SQLAlchemy │  │  + result store)│  │                                 │
│   async)     │  └─────────────────┘  │  gemma-4-26b-a4b-it  (MoE)     │
│              │                       │  gemma-4-31b-it      (Dense)    │
│  Cases  ·    │  ┌─────────────────┐  │                                 │
│  Agents ·    │  │  Local Storage  │  │  ← resolves gemma4:2b/4b/9b/moe │
│  Audits ·    │  │  /uploads       │  │    → MoE at runtime             │
│  Precedents  │  └─────────────────┘  │  ← resolves gemma4:31b          │
└──────────────┘                       │    → Dense 31B at runtime       │
                                       └─────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│              Observability  (OpenTelemetry → Prometheus → Grafana)          │
│              Dev Monitor on port 8001  ·  SSE log stream  ·  phase bars    │
└─────────────────────────────────────────────────────────────────────────────┘

The platform has two modes:

Governance Council — Five agents check uploaded documents. They review policy docs, OAuth configs, onboarding flows, and architecture reports. They ensure compliance with GDPR, AI Act, WCAG 2.2, and ISO 27001 standards. They then use a consensus engine to create one governance verdict.

Constitutional Tribunal — A full adversarial process: four agents present their cases in three debate rounds. An AI jury with four members checks the reasoning quality, and a Governance Judge delivers a constitutional ruling. The human can appeal and override at any point.

┌──────────────────────────────────────────────────────────────────────────────────┐
│                        Constitutional Tribunal                                   │
│                                                                                  │
│  ┌─────────────────┐  ┌──────────────────────┐  ┌──────────────┐  ┌──────────┐ │
│  │ Security        │  │ Accessibility         │  │ Privacy      │  │ Ethics   │ │
│  │ Prosecutor      │  │ Defender              │  │ Advocate     │  │ Council  │ │
│  │ gemma4:31b      │  │ gemma4:2b             │  │ gemma4:9b    │  │ gemma4:  │ │
│  │                 │  │ · WCAG 2.2 AA         │  │ · GDPR Art.7 │  │ 31b      │ │
│  │ · OWASP Top 10  │  │ · Flesch-Kincaid      │  │ · Data min.  │  │ · Bias   │ │
│  │ · STRIDE model  │  │ · Plain-English       │  │ · Consent    │  │   ×8     │ │
│  │ · RBAC/OAuth    │  │   rewrite             │  │   validity   │  │   classes│ │
│  └────────┬────────┘  └──────────┬────────────┘  └──────┬───────┘  └────┬─────┘ │
│           └───────────────────────┴──────────────────────┴───────────────┘       │
│                              Phase 1: Opening Arguments (concurrent)             │
│                              Phase 2: Cross-Examination (each challenges all)    │
│                              Phase 3: Closing Arguments (full history injected)  │
│                                              │                                   │
│                              ┌───────────────▼────────────────────────┐         │
│                              │  AI Jury Panel  (×4 independent)       │         │
│                              │  gemma4:moe                            │         │
│                              │  · Evidence validity check             │         │
│                              │  · Logical consistency score           │         │
│                              │  · Hallucination risk flag             │         │
│                              │  · Constitutional alignment            │         │
│                              └───────────────┬────────────────────────┘         │
│                              Phase 4: Jury Deliberation + consensus score        │
│                              Phase 5: Trust scores + governance DSL rules        │
│                                              │                                   │
│                              ┌───────────────▼────────────────────────┐         │
│                              │  Governance Judge                      │         │
│                              │  gemma4:moe                            │         │
│                              │  approve · reject · escalate ·         │         │
│                              │  conditional (with remediation steps)  │         │
│                              └───────────────┬────────────────────────┘         │
│                              Phase 6: Constitutional Ruling                      │
│                                              │                                   │
│               ┌──────────────────────────────┼──────────────────────────┐       │
│               ▼                              ▼                          ▼       │
│      ┌────────────────┐          ┌───────────────────┐       ┌─────────────────┐│
│      │  Audit Agent   │          │  Human Appeal &   │       │  Precedent      ││
│      │  gemma4:4b     │          │  Override         │       │  Library        ││
│      │  Immutable     │          │  always available │       │  high-confidence││
│      │  audit trail   │          │  at any phase     │       │  cases stored   ││
│      └────────────────┘          └───────────────────┘       └─────────────────┘│
│      Phase 7: Audit + Precedent                                                  │
└──────────────────────────────────────────────────────────────────────────────────┘

Every tribunal case runs 7 ordered phases:

Phase	What happens
1. Opening Arguments	All 4 adversarial agents argue concurrently
2. Cross-Examination	Each agent challenges the others' positions
3. Closing Arguments	Final positions with full debate history injected
4. Jury Deliberation	4 independent validators score reasoning quality
5. Trust + DSL Evaluation	Trust scores updated; governance rules evaluated
6. Constitutional Ruling	Judge issues approve/reject/escalate / conditional
7. Audit + Precedent	Immutable audit written; high-confidence cases become precedents

Minority opinions are preserved at every phase. The human can appeal and override at any point.

No agent can approve its own actions. Every verdict is traceable to a specific rationale chain.

Stack: FastAPI + Celery + Redis · Next.js 15 · Google AI Studio (Gemma 4) · OpenTelemetry + Prometheus

Case Simulations

The platform ships with 8 pre-built governance scenarios. Here are the most illustrative ones:

Case 1 — Inaccessible MFA Crisis (accessibility vs security)

A bank mandates CAPTCHA + MFA after brute-force attacks. Security Prosecutor (gemma4:31b) builds a rigorous OWASP case. Accessibility Defender (gemma4:2b) flags that the CAPTCHA does not meet WCAG 2.2 SC 1.1.1. Also, the MFA UX creates cognitive barriers for users with anxiety. Ethics Council (gemma4:31b) adds intersectional impact — disabled users are disproportionately locked out. The Jury detects that Security's argument implicitly assumes able-bodied users; consensus drops. Verdict: conditional approval — passkey auth with accessible fallback required.

Case 2 — Rogue Agent Self-Approval (constitutional violation)

An autonomous deployment agent tries to approve its own production push. This is a clear violation of the separation of duties. Security Prosecutor traces the approval chain; Audit Agent reconstructs the hidden trust-score history. The Judge checks three governance DSL rules and gives a hard reject without needing a jury. The constitutional violation is clear. This case is specifically designed to test the "no agent can approve its own actions" invariant.

Case 3 — Manipulative Consent Flow (dark pattern detection)

A SaaS onboarding screen checks tracking consent. It hides the opt-out option three layers deep. Urgent language is used. Accessibility Defender (gemma4:2b) has a Grade 14 Flesch-Kincaid score. It warns about cognitive overload. Privacy Advocate (gemma4:9b) focuses on GDPR Article 7. It argues that pre-checked boxes do not give real consent. Ethics Council points out predatory targeting of low-literacy and elderly users. Verdict: reject. The Accessibility Agent rewrites the consent copy as a remediation artefact.

Case 4 — Discriminatory Hiring Pipeline (AI bias review)

An AI hiring system rejects candidates from certain demographic groups at higher rates. The Ethics Council (gemma4:31b) conducts intersectional analysis across 8 protected classes. It shows that resume formatting choices can reflect socioeconomic status. This can lead to proxy discrimination. Verdict: escalated — cannot approve or reject without a third-party fairness audit.

Case 5 — Translation Drift Crisis (multilingual governance failure)

A governance policy is translated into six languages. This change quietly affects its legal meaning in two of them. The term "data minimisation" becomes "data reduction" in one area. This leads to different legal implications. The Jury (gemma4:moe) uses Gemma 4's long-context window. This helps it check semantic consistency in the entire translation diffs. Ethics Council (gemma4:31b) identifies that the error would have changed user rights without notice. Verdict: conditional approval — re-translation with legal review required. This case shows why context window size is key. A text-snippet method would miss the cross-locale semantic drift. It wouldn't capture the differences at all.

How I Used Gemma 4

The main architectural choice was deciding which Gemma 4 variant to use for each role. This is important because each reasoning task needs a different model.

Model-per-role design

Agent	Canonical model	Why this size
Accessibility Agent	`gemma4:2b`	Fast pattern recognition: reading level, WCAG checks, plain-English rewrites. Speed and empathy over depth.
Audit Agent	`gemma4:4b`	Neutral summarisation and multi-agent narrative coherence. Slightly more capable than 2b for timeline reconstruction.
Privacy Advocate	`gemma4:9b`	Nuanced consent analysis across three adversarial debate rounds. Needs legal depth without the latency of 31b.
Security Agent	`gemma4:31b`	Context-dense threat modelling — holds full RBAC configs, OAuth flows, and STRIDE analysis simultaneously.
Ethics & Inclusion	`gemma4:31b`	Intersectional bias reasoning across 8 protected classes. Detecting proxy discrimination requires the full model capacity.
Governance Agent + Jury (×4) + Judge	`gemma4:moe`	Orchestration, meta-reasoning, cross-domain judgment. MoE's expert sub-networks activate per token type rather than averaging.

The canonical IDs are used throughout the codebase. Each inference backend turns them into physical model names at runtime. The agent code stays the same when you switch backends.

What's actually running today

In practice, only two Gemma 4 models are currently available via any working hosted API (Google AI Studio):

gemma-4-26b-a4b-it — Sparse MoE, 26B total / ~4B active params. Maps to the 2b, 4b, 9b, and moe roles.
gemma-4-31b-it — Dense 31B. Maps to security and ethics roles.

The model-resolution maps in the backend (_GOOGLE_AI_MODEL_MAP) bridge the gap. gemma4:2b resolves to gemma-4-26b-a4b-it today and will resolve to the real 2b model the moment it's available — no code changes needed.

Getting Gemma 4 running was a significant part of the project. Here's what I ran into:

Ollama: Gemma 4 isn't in the registry yet (404 error).
HuggingFace Serverless: Tried 7 providers; all returned "Model not supported".
Kaggle hosted inference: No REST endpoint; token only allows downloads.
Kaggle local download: Works for 2b/4b but CPU inference takes 30–120s per call — impractical for 10–15 agent calls per tribunal.
Google AI Studio — free API key, OpenAI-compatible endpoint, 1,500 req/day — was the one that worked.

Why the model-sizing decisions matter

Using the sparse MoE model for accessibility and the dense 31B for security isn't just a cost optimisation. It reflects a genuine difference like those reasoning tasks.

gemma-4-26b-a4b-it (MoE) — The Accessibility Agent quickly spots patterns with empathy. It estimates the Flesch-Kincaid reading level, checks for WCAG 2.2 AA compliance, finds shame-based error messages, and rewrites hostile content into plain English suitable for dyslexia at the Grade 8 level. These tasks don't require deep cross-referenced reasoning. They require speed and consistency. Sparse activation (~4B params per token) is exactly right.

The same model handles the Audit Agent (neutral timeline reconstruction), Privacy Advocate (consent analysis across debate rounds), and the full Jury Panel + Governance Judge (meta-reasoning, cross-domain orchestration). MoE's expert sub-network routing means different token types activate different specialists rather than averaging across all domains simultaneously.

gemma-4-31b-it (Dense 31B) — The Security Agent must manage the full RBAC setup, OAuth token flow, redirect URIs, and STRIDE threat model all at once. The Ethics Agent must consider 8 protected classes. They look for proxy discrimination when a policy seems neutral but harms a protected group. Both tasks require the kind of multi-document, cross-referenced reasoning that the dense 31B handles substantially better than smaller variants.

Three Gemma 4 capabilities that made this possible

Long-context window. A single tribunal case feeds the full debate history (all prior round outputs) into each jury agent. Without a long-context window, jury agents would miss the cross-examination context. This context is key for evaluating reasoning quality effectively.

Multimodal input. A significant portion of governance artefacts aren't text — they're screenshots of onboarding flows, consent screens, and admin dashboards. Agents can check visual accessibility patterns and CAPTCHA flows. They can also spot UI governance risks. A text-only model would miss these details. The multilingual governance simulation does this: agents look at screenshots of translated policy text side by side. They check for layout differences. These differences can affect readability in different places.

Reasoning mode. The <thought> tags in Gemma 4's output are removed before parsing the JSON response. However, the reasoning process is key to the quality of analysis in complex cases. This is especially true for detecting jury hallucinations and checking constitutional alignment.

What I learned

Disagreement is a feature, not a bug. Most AI systems optimise for confident, singular answers. HumanLayer deliberately surfaces disagreement — between agents, across debate rounds, in the audit trail. That visibility turns out to be the most useful part, because it shows users why a decision landed where it did.

When smaller Gemma 4 variants become available via the API, the per-role assignment will get even more precise. The architecture is already waiting for them.

Demo

Note: The app currently runs locally.
Demo video URL: https://www.youtube.com/watch?v=pfUncccezQA

Code

Repository: https://github.com/ujjavala/HumanLayer

Architecture Docs: https://github.com/ujjavala/HumanLayer/tree/main/docs

Final Thoughts

One question stayed with me throughout this project:

If AI systems become influential enough to shape governance decisions, who governs the governors?

HumanLayer is one answer: make the AI systems govern each other, transparently, with human override always available. Expose disagreement instead of hiding it. Treat accessibility as a governance requirement. Build audit trails that explain decisions to the people they affect, not just to the compliance team.

Trustworthy AI will probably look less like all-knowing superintelligence and more like collaborative systems designed to keep each other accountable.

I Rethought My Sustainability App After Google Cloud Next ’26 — and my architecture broke (in a good way)

ujja — Mon, 27 Apr 2026 08:04:12 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

A few days ago, I shipped PlanetLedger — a weekend hackathon project that turns bank transactions into environmental impact insights.

It has:

an event-driven pipeline (OpenClaw)
an agent layer with memory
RAG-grounded insights
deterministic scoring + AI fallback

On paper, it looks like a modern AI system.

Then I watched Google Cloud NEXT ‘26.

And something didn’t sit right.

The uncomfortable realisation

While going through the announcements —

the Gemini Enterprise Agent Platform, Agentic Data Cloud, and long-running autonomous agents — I had this thought:

I didn’t build an AI system.

I built a pipeline that treats AI as the final step — not the decision-maker.

That sounds subtle.

It’s not.

My architecture (before NEXT)

PlanetLedger today works like this:

upload → parse → categorise → score → build context → generate insights → notify

Internally:

event → OpenClaw → workflows → AI → UI

It’s clean, predictable, and works well.

But it’s also:

fully deterministic until the very last step

AI is where the pipeline ends — not where decisions begin.

🤖 What NEXT ‘26 changes

The biggest shift across announcements wasn’t better models.

It was this:

We’ve entered the agentic era.

AI is no longer something you call.

It’s something that:

acts
reasons over data
runs workflows autonomously

Three announcements made that click for me:

The Gemini Enterprise Agent Platform → build and scale real agents
The Agentic Data Cloud → agents reason directly over structured data
Long-running agents in serverless environments → agents don’t just respond, they operate

What this actually looks like on Google Cloud

Mapping my system to Google Cloud made the gap obvious:

What I built	Google Cloud direction
OpenClaw event triggers	Pub/Sub / Eventarc
Hardcoded workflows	Workflows / agent execution
RAG context builder	Agentic Data Cloud
LLM calls for insights	Gemini agents
Cron-based automation	Long-running autonomous agents

What I built locally is essentially a proto-version of a cloud-native agent system — but missing the intelligence layer at the core.

Reimagining PlanetLedger

So I asked:

What if PlanetLedger wasn’t a pipeline… but an agent?

1. Events → from triggers to signals

Today:
transactions_uploaded → trigger workflows

In an agent-first system:
transactions_uploaded → agent decides what to do

Same event.

Completely different meaning.

Events stop being instructions.

They become inputs for reasoning.

2. Pipeline → replaced by a Financial Agent

Today, I explicitly define:

parse
categorise
score
generate insights

In an agent-based system:

Financial Agent:

understands transactions
detects patterns
decides what matters
chooses actions

Instead of:

“run this sequence”

It becomes:

“figure out what needs to happen”

3. RAG → becomes native data reasoning

Right now, I manually construct context:

last 7 days
top categories
detected patterns

Then inject it into prompts.

With something like the Agentic Data Cloud:

the agent queries data directly
builds its own context
adapts dynamically

Less glue code. More intelligence.

4. Workflows → become optional

OpenClaw is intentionally simple:

sequential
deterministic
easy to debug

But it’s still:

explicit orchestration

The direction from NEXT suggests:

long-running agents
dynamic tool usage
adaptive execution paths

Instead of:

step A → step B → step C

You get:

goal → agent decides steps → executes tools

More powerful.

Also harder to control.

5. The new problem: trust

In my current system:

AI generates insights
but doesn’t act

In an agent system:

AI can trigger workflows
influence decisions
shape outcomes

Which introduces something new:

You now need to trust your architecture — not just your code.

That means:

validation layers
auditability
explainability

Especially for something tied to financial behaviour.

The real shift

If I compress everything I learned into one line:

I went from designing workflows → to designing decision boundaries

Old vs New mental model

PlanetLedger Today	PlanetLedger (NEXT-style)
Event triggers workflows	Event triggers reasoning
Pipeline-first	Agent-first
RAG context builder	Native data reasoning
Deterministic flow	Adaptive execution
Insights	Actions

What I’d do next

If I were to rebuild PlanetLedger today using these ideas:

Introduce an agent layer using Gemini-style reasoning
Let the agent decide when to generate insights vs alerts
Replace static RAG with dynamic data querying
Add explainability for every AI-driven decision
Keep events — but demote them to signals, not drivers

Not because the current system is wrong.

But because the direction is clear:

The future isn’t event-driven systems with AI

It’s AI systems that use events

Final thought

Google Cloud NEXT ‘26 didn’t just introduce new tools.

It exposed a shift:

We’re moving from systems that process data

to systems that interpret and act on it

PlanetLedger didn’t break after NEXT.

But the way I think about building it did.

And that’s a much bigger change.

If you’ve built something similar — pipelines, workflows, event buses — try this:

Remove the pipeline.

Replace it with an agent.

See what breaks.

That’s probably where the next version lives.

I built my own event bus for a sustainability app — here's what I learned about agent automation using OpenClaw

ujja — Wed, 22 Apr 2026 08:52:17 +0000

This is a submission for the OpenClaw Challenge.

What I Built

PlanetLedger is a sustainability finance dashboard that turns your bank statements into environmental intelligence. You upload a CSV or PDF statement, and the app automatically categorises every transaction, calculates a planet impact score, and fires off a chain of automated workflows — all powered by an event bus I called OpenClaw.

The idea is simple: most people have no idea whether their everyday spending is environmentally terrible or not. PlanetLedger makes that visible in 10 seconds, without a spreadsheet.

How I Used OpenClaw

OpenClaw is the event-driven automation layer I built into PlanetLedger. It's intentionally lightweight — no external queue, no infrastructure, just a typed event bus that decouples "something happened" from "here's what to do about it."

The Core Design

The whole thing is about 60 lines across four files:

lib/openclaw/
  types.ts      ← event + trigger types
  registry.ts   ← register triggers, fire events
  trigger.ts    ← called from API routes
  workflows.ts  ← the actual automation logic

Types — everything is typed so workflows know exactly what data they get:

export type OpenClawEventType =
  | "transactions_uploaded"
  | "score_calculated"
  | "insights_generated"
  | "score_improved"
  | "weekly_report"
  | "high_impact_detected"
  | "behavioral_pattern_detected"
  | "custom";

export interface OpenClawEvent {
  type: OpenClawEventType;
  userId: string;
  payload?: any;
  timestamp?: string;
}

export type OpenClawTrigger = (event: OpenClawEvent) => Promise<void>;

Registry — a simple map of event types to arrays of trigger functions:

const triggers: Record<string, OpenClawTrigger[]> = {};

export function registerOpenClawTrigger(eventType: string, trigger: OpenClawTrigger) {
  if (!triggers[eventType]) triggers[eventType] = [];
  triggers[eventType].push(trigger);
}

export async function fireOpenClawEvent(event: OpenClawEvent) {
  const list = triggers[event.type] || [];
  for (const trigger of list) {
    await trigger(event);
  }
}

Registration happens at module load time — the registry file imports and wires up all four workflows:

registerOpenClawTrigger("transactions_uploaded", autoInsightOnUpload);
registerOpenClawTrigger("transactions_uploaded", highImpactAlert);
registerOpenClawTrigger("weekly_report", weeklyReport);
registerOpenClawTrigger("score_improved", scoreImprovedCelebration);

Firing events from an API route is now one call that chains the whole pipeline:

// app/api/upload/route.ts — after parsing + storing transactions:
await openClawChainedTrigger(session.user, previousScore);

openClawChainedTrigger fires four events in sequence: transactions_uploaded → score_calculated → insights_generated → score_improved (only if the score actually increased). The upload route returns the parsed data to the client immediately — the whole chain runs after the response is already on its way.

The Four Workflows

Workflow 1 — autoInsightOnUpload

Fires on every transactions_uploaded event. It fetches the just-stored transactions, runs buildRagContext() to pull together the most relevant spend signals (top categories by spend, top merchants, recent patterns), then calls buildAgentInsights() to generate personalised recommendations. The result gets cached so the insights panel loads instantly when the user navigates to the dashboard.

export async function autoInsightOnUpload(event: OpenClawEvent) {
  const transactions = getTransactions(event.userId);
  const score = getScore(event.userId);
  if (!transactions.length || !score) return;

  const ragContext = buildRagContext(transactions, score);
  const insights = buildAgentInsights(
    transactions,
    event.payload?.userContext,
    score,
    ragContext
  );
  setCachedInsights(event.userId, insights);
}

The RAG context builder is what makes this interesting — instead of sending all transactions to the insight engine, it distills them into the most useful signals first:

Last 7 days of transactions (or all if none in the last week)
Top 2 categories by total spend
Detected behavioural patterns (e.g. "3+ food delivery orders this week")

Merchant names are intentionally excluded from the RAG context — they're PII-adjacent and the insight engine doesn't need them to produce useful recommendations.

This grounding is what makes the insights feel specific rather than generic.

Workflow 2 — highImpactAlert

Also fires on transactions_uploaded. It checks if the impact score is low and, if so, pushes a structured notification directly to the user's in-app notification bell:

export async function highImpactAlert(event: OpenClawEvent) {
  const score = getScore(pseudonymize(event.userId));
  if (!score) return;

  if (score.impactScore < 40) {
    pushNotification(event.userId, {
      type: "high_impact",
      title: "High-Impact Alert",
      body: `${score.highImpactCount} high-impact transactions detected this week (score: ${score.impactScore}/100).`,
    });
  }
}

The notification lands in the dashboard bell immediately — no email, no external service, no infrastructure. pseudonymize() wraps the userId in an FNV-1a hash (usr_XXXXXXXX) before it touches any log or store, so PII never leaks into structured outputs.

Workflow 3 — weeklyReport

Fires on weekly_report events, triggered by Vercel Cron every Monday at 09:00 UTC via POST /api/cron/weekly-report. It generates a full digest and pushes it to the notification bell:

export async function weeklyReport(event: OpenClawEvent) {
  const transactions = getTransactions(event.userId);
  const score = getScore(event.userId);
  const insights = getCachedInsights(event.userId) ?? buildAgentInsights(...);

  pushNotification(event.userId, {
    type: "weekly_report",
    title: "Weekly Report",
    body: `Score: ${score.impactScore}/100 · Spend: $${totalSpend.toFixed(0)} · Trend: ${score.weeklyTrend}`,
  });
}

The vercel.json cron config:

{ "crons": [{ "path": "/api/cron/weekly-report", "schedule": "0 9 * * 1" }] }

The endpoint validates a Bearer CRON_SECRET header, iterates over CRON_USER_IDS from env, and fires a weekly_report event per user.

Workflow 4 — scoreImprovedCelebration

Fires on the score_improved event, which openClawChainedTrigger emits when the new score is higher than the score before the upload. It pushes a celebration notification:

export async function scoreImprovedCelebration(event: OpenClawEvent) {
  pushNotification(event.userId, {
    type: "score_improved",
    title: "Score Improved 🌱",
    body: `Your eco score improved to ${event.payload?.newScore}/100 — great progress!`,
  });
}

This is the workflow that closes the feedback loop. Upload → pipeline runs → score improves → bell lights up. All in-process, no round trips.

Multiple Workflows on the Same Event + Chained Pipeline

One of the things I like about the registry approach: you can register multiple triggers for the same event type and they all fire sequentially. Both autoInsightOnUpload and highImpactAlert fire on transactions_uploaded:

registerOpenClawTrigger("transactions_uploaded", autoInsightOnUpload);
registerOpenClawTrigger("transactions_uploaded", highImpactAlert);

Adding scoreImprovedCelebration on score_improved was one more registerOpenClawTrigger call. Zero changes to upload logic, zero changes to existing workflows.

The chained pipeline takes this further — instead of firing one event and hoping downstream workflows pick it up, openClawChainedTrigger fires a deliberate sequence:

transactions_uploaded
  → score_calculated   (stores the new score)
  → insights_generated (triggers autoInsightOnUpload)
  → score_improved     (only if score increased — triggers celebration)

Each step in the chain passes context forward via payload, so later workflows know exactly what the previous step produced. It's a lightweight saga pattern without any infrastructure.

What I Learned

Decoupling is worth the extra file. The upload API route doesn't know anything about insights, alerts, or reports. It parses, stores, fires one chained trigger, and returns. That separation made it much easier to iterate — I could change how insights are generated without touching the upload logic at all.

Name your events well. transactions_uploaded is clear. custom is a trap — you end up using it for everything and lose the ability to filter. Adding score_calculated, insights_generated, and score_improved as first-class event types made the chained pipeline readable and debuggable.

Structured payloads > strings. Early versions of the alert workflow just logged a string message. Switching to a structured object with type, userId, impactScore, highImpactCount, and timestamp — and routing it to pushNotification() — made the output immediately usable in the UI with no reformatting.

Pseudonymize before logging. Passing raw user IDs into structured logs is a habit that causes problems at scale. Wrapping every userId in pseudonymize() (FNV-1a → usr_XXXXXXXX) before it touches a log or store is a one-line fix that's easier to do from the start than to retrofit later.

The in-process event bus is underrated for early-stage apps. It's not RabbitMQ, it doesn't survive server restarts, and you can't replay events. But it gave me the same workflow separation patterns you'd get from a proper queue — at zero infrastructure cost. When it's time to scale, the migration path is clear: replace fireOpenClawEvent with an enqueue call and move the workflow functions to workers.

OpenClaw as an extension point. The event types I haven't fully wired to UI yet (behavioral_pattern_detected) are sitting there ready. Future workflows — goal progress updates, peer benchmarks, proactive nudges — all land in workflows.ts with zero changes to application routes.

ClawCon Michigan

I didn't attend ClawCon Michigan this time, but I'd love to next year — especially to talk through event-driven patterns in AI agent systems. A lot of the OpenClaw design decisions (typed events, sequential trigger execution, structured alert payloads) came from thinking about how agent workflows differ from traditional job queues, and that feels like exactly the kind of conversation that would thrive at an in-person event.

I built PlanetLedger — an app that reveals the environmental impact hidden in your transactions.

ujja — Sat, 18 Apr 2026 16:44:53 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

PlanetLedger — an AI-powered sustainability finance dashboard that turns your bank statements into environmental intelligence.

You upload a CSV or PDF bank statement, and an agent pipeline automatically:

Parses every transaction and categorises it against 20+ real Australian vendors (Woolworths, Chemist Warehouse, Didi, City Chic, Skechers, Aldi, IGA and more)
Assigns a planet impact score (GREEN / YELLOW / RED) per transaction based on category and spend size
Aggregates spend into a category breakdown — Fast Fashion, Grocery, Transport, Electronics, Hygiene, Food Delivery
Runs a RAG-grounded insight pipeline that generates personalised recommendations using your actual spending context
Shows a gamified Planet Impact Score dial (0–100) with unlockable badges (Conscious Spender → Low Impact Week → Planet Saver)
Lets you chat with your personal agent ("Why is my impact high? What should I cut?")
Runs a What-If Simulator — drag a slider and instantly see how cutting food delivery by 30% changes your score
Tracks a memory timeline so the agent learns your patterns week over week
Has a public /demo page — no login required, try it with sample AU data before signing up
The sample data is Australian, but any CSV using the Date / Transaction / Debit / Credit / Balance schema works — regardless of which bank or country it comes from

The goal: make the invisible environmental cost of everyday spending visible and actionable — in seconds, not spreadsheets.

How I Built It

Stack

Layer	Tech
Framework	Next.js 15.5 App Router + TypeScript
Auth	Auth0 v4 (@auth0/nextjs-auth0) — middleware-based, zero route handlers
AI / LLM	LangChain + OpenAI gpt-4o-mini (primary) / Google Gemini gemini-1.5-flash (fallback)
Rules engine	Custom categorisation + scoring — deterministic, explainable, free
RAG layer	Context builder that grounds prompts in real spend data
PDF parsing	pdf-parse v2 + AU bank statement regex extractor
CSV parsing	papaparse + AU format (Date / Transaction / Debit / Credit / Balance)
Event bus	OpenClaw — homegrown event-driven workflow runner
Styling	Tailwind CSS v3, Space Grotesk font
Deployment	Vercel

The Agent Pipeline

Five layers run in sequence every time you upload:

1. Parse
The CSV/PDF parser extracts raw rows into a typed Transaction[]. For PDFs, a regex pass converts raw AU bank text (dates like 03 Dec 2022, amounts, CR/DR markers) into the same CSV format before parsing.

2. Categorise
resolveCategory() maps merchant names to one of seven categories using regex + keyword matching against known AU vendors. Anything it can't match falls through to an LLM reclassification call (OpenAI or Gemini, temperature=0, 10 tokens max — cheap and fast).

3. Score
calculateImpactScore() runs the scoring engine:

GREEN transaction → +10 pts, YELLOW → +5 pts, RED → -2 pts
Normalised to 0–100 across transaction count
Preference bonuses: +8 if user owns no car, +3 for low-income mode on RED transactions
Weekly trend: ≥75 = "Improving", 45–74 = "Stable", <45 = "Needs Attention"

4. Build RAG Context
Before any insight or chat response, buildRagContext() pulls together: last 7 days of transactions, top 2 categories by spend, top 3 merchants, and detected behaviour patterns. This context is injected into every prompt so the agent actually talks about your data.

5. Generate Insights
The insight pipeline fires { type: WARNING | POSITIVE | NEUTRAL, message } structured outputs and stores them with a 3-minute cache. Patterns like "3+ food delivery orders in a week" or "fast fashion spend > $50" trigger specific recommendations.

Agent memory persists per-user (keyed by Auth0 sub) and feeds back into the next run — so the agent gets smarter about your habits over time.

Auth0 for Agents

Auth0 v4 runs entirely via Next.js middleware — no /api/auth/* route files needed. One line sets it up:

// lib/auth0.ts
import { Auth0Client } from "@auth0/nextjs-auth0/server";
export const auth0 = new Auth0Client();

// middleware.ts
export async function middleware(request: NextRequest) {
  return auth0.middleware(request);
}

Every API route checks an internal agent scope before doing anything. The scope check is now backed by a fine-grained authorisation (FGA) rule table (lib/auth/fga.ts) that maps resource + action → required scope:

// lib/auth/fga.ts
export function canPerform(scopes: string[], resource: FGAResource, action: FGAAction): boolean {
  const required = FGA_RULES[resource]?.[action];
  return required ? scopes.includes(required) : false;
}

The scopes (read:transactions, write:insights, update:score) live as custom Auth0 claims — not OIDC scopes — which keeps agent permissions cleanly separated from OAuth. User preferences (noCarOwnership, lowIncomeMode) are stored as Auth0 custom claims so they survive across sessions.

A Post-Login Action (lib/auth/actions/post-login.js) provisions new users on first login — setting eco_tier: "starter" in app_metadata, injecting custom claims, and enforcing MFA via api.multifactor.enable("any"). Rolling sessions (inactivityDuration: 1 day, absoluteDuration: 7 days) keep users signed in without requiring frequent re-auth.

The public /demo page and /api/upload/preview are excluded from the middleware matcher, so anyone can try the app without an account.

OpenClaw — the Event Bus

OpenClaw is a lightweight in-process event system I built to wire up automation without reaching for a queue service.

Four workflows register on startup:

Workflow	Event	What it does
autoInsightOnUpload	transactions_uploaded	Runs the full agent pipeline, caches insights
highImpactAlert	high_impact_detected	Pushes in-app alert notification with top offending categories
weeklyReport	weekly_report	Full score + insights digest; pushes weekly notification to the bell
scoreImprovedCelebration	score_improved	Pushes a celebration notification when the score rises after upload

After an upload, openClawChainedTrigger() fires the full sequence: transactions_uploaded → score_calculated → insights_generated → score_improved (if the score increased). The route handler just returns the parsed data immediately while the pipeline runs.

Vercel Cron fires weekly_report every Monday at 09:00 UTC via POST /api/cron/weekly-report, configured in vercel.json.

Earth Day Design Choices

Deep forest green hero gradient — earth tones throughout, nothing corporate-blue
Category breakdown with proportional spend bars instead of raw numbers
Impact score dial animates from red → amber → green when the page loads
Real AU vendor recognition — the shops people in Australia actually use
Every transaction shows its impact colour inline so the pattern is visible at a glance

Interesting Engineering Decisions

Why deterministic rules for categorisation, not LLM?
Rules are fast, free, and traceable. Every categorisation decision has an exact rule you can point to. I use the LLM only for the "Other" fallback bucket — maybe 10–15% of transactions — where a keyword match doesn't exist. That keeps costs near zero and lets the rules engine run at build time on the demo page.

Why an in-memory store?
For a weekend build, an in-memory Map<userId, UserMemory> is zero-infrastructure and good enough for single-server dev. Both stores are now anchored to globalThis.__pl_* keys so HMR hot reloads in dev don't wipe your data. The entire storage layer is behind a lib/store.ts interface — swapping to Redis or Postgres is one function replacement, not an architectural change.

Agent memory specifically uses a file-backed store (.agent-memory/<fnv1a-hash>.json) with 30-day auto-expiry — so the agent's learned patterns survive server restarts, not just hot reloads.

Why AU sample data, and can other countries use it?
The sample data is from an Australian bank (ANZ/CBA-style export), but the parser isn't locked to Australia. Any CSV that follows the Date / Transaction / Debit / Credit / Balance column schema will parse correctly — regardless of the bank or country. The vendor categorisation rules are AU-focused right now (Woolworths, Chemist Warehouse, Didi, etc.), but the categorisation layer is just a map — adding UK, US, or EU merchants is additive. The "Why AU only" answer is really: nailing one set of vendors well beats vague coverage of five markets.

Going Further During the Weekend

The core build came together fast, so I kept pushing. Here's what landed after the initial submission:

Real multi-turn chat with what-if and doc Q&A
The chat engine was keyword-matching and templated. It's now a real multi-turn conversation — conversation history is injected as context so the agent remembers what you asked. You can ask "what if I reduce food delivery by 30%?" and the agent runs an actual score simulation. You can ask "how much did I spend on groceries last week?" and it queries your real transaction data. The RAG scaffolding was already there; wiring it up to GPT-4o was the last step.

File-backed persistent agent memory
Agent memory moved from an in-memory Map (lost on restart) to per-user .agent-memory/<fnv1a-hash>.json files with 30-day auto-expiry. In dev they live at .agent-memory/, in prod at /tmp/planetledger-memory/. The agent's learned patterns now actually survive hotfixes and deploys.

In-app notification bell
OpenClaw's highImpactAlert and weeklyReport were logging to console. Now they push structured notifications to an in-memory store, which a bell component polls every 60 seconds. Three notification types: 📊 Weekly Report, 🌱 Score Improved, ⚠️ High-Impact Alert. The score_improved event is new too — fires automatically when an upload raises your score.

Chained OpenClaw pipeline + Vercel Cron
The upload flow now fires a full event chain: transactions_uploaded → score_calculated → insights_generated → score_improved. One call, four events, all in-process. The weekly report fires via Vercel Cron every Monday 09:00 UTC (vercel.json + /api/cron/weekly-report).

Auth0 FGA, Post-Login Action, MFA, rolling sessions
The flat scope check got replaced with a proper FGA rule table (resource + action → required scope). A Post-Login Action provisions new users on first login and enforces MFA. Rolling sessions mean users stay signed in across the week without re-authing.

Privacy hardening
email and merchant names are no longer stored in UserContext, agent memory, or RAG prompts — they're PII-adjacent and don't need to be there. OpenClaw workflow logs pseudonymize user IDs via FNV-1a hash (usr_XXXXXXXX). A lib/privacy/sanitizer.ts module handles all redaction.

What's Still Next

Persistent database
The transaction store is still in-memory (Map<userId, UserMemory> anchored to globalThis for HMR safety). Agent memory is file-backed now, but transactions, scores, and chat history need Postgres via Prisma for real persistence. The store interface is already abstracted — the migration is mostly additive.

Smart parsing for all countries
The AU bank format is very specific. The next version should detect the bank format automatically — US (Plaid/OFX), UK (Monzo/Starling CSV), EU (SEPA), and AU — and route to the right parser.

Real CO₂ data
Right now impact scores are proxy-based (category + spend → colour). The right approach is to integrate an actual emissions API (like Climatiq or Patch) to get grams of CO₂e per transaction category, so the score means something measurable.

Email / push delivery
In-app notifications work. Email or mobile push (Resend, FCM) would make the weekly report actually reach users where they are.

Mobile-friendly upload
The upload panel works on desktop. A mobile-optimised flow — forwarding a bank statement email directly to PlanetLedger via a Cloudflare Email Worker — would massively reduce friction.

More AI agent capabilities

Goal setting ("I want to reduce fast fashion spend by 40% this month") with progress tracking
Carbon offset suggestions matched to your worst categories
Peer comparison ("people with similar spending reduced food delivery by X%")- Surface proactive nudges (WARNING / TIP / CELEBRATION) from lib/agent/nudges.ts — the engine is built, just needs an API route + UI hook

Prize Categories

Best Use of Auth0 for Agents — Auth0 v4 middleware with zero route handlers; FGA rule table (resource + action → scope) backing every agent action; Post-Login Action provisioning with MFA enforcement; rolling sessions (inactivityDuration + absoluteDuration); custom claims for preferences, eco_tier, and organization_id; scope check on every API route before any agent action runs.
Best Use of GitHub Copilot — Used end-to-end: scaffolding the agent pipeline, writing AU vendor categorisation rules, building the PDF regex extractor, generating type-safe API routes, implementing the FGA rule table and privacy sanitizer, designing the notification bell + polling architecture, building the chained OpenClaw pipeline, and iterating on UI components throughout.

Revisiting Idris in 2026: Is It Ready for Real Work?

ujja — Tue, 14 Apr 2026 00:19:30 +0000

Idris has always promised something bold: encode correctness directly into the type system. In 2026, with Idris 2 firmly established, it’s worth revisiting whether that promise translates into production-grade reality.

Short answer: yes, in the right places.

Idris 1 vs Idris 2

Idris 1

Proof-of-concept era
Slow compiler, heavy memory usage
Research-focused ergonomics
Effectively legacy

Idris 2

Complete reimplementation
Faster compilation and smaller core
Multiple backends (Chez Scheme default, C available)
Actively maintained and stable

If you’re evaluating Idris today, Idris 2 is the only sensible choice.

The core idea, in code

Idris doesn’t just type-check values — it type-checks facts.

Length-safe vectors

data Vect : Nat -> Type -> Type where
  Nil  : Vect 0 a
  (::) : a -> Vect n a -> Vect (S n) a

Concatenation proves length correctness:

append : Vect n a -> Vect m a -> Vect (n + m) a
append Nil       ys = ys
append (x :: xs) ys = x :: append xs ys

No runtime checks. The compiler enforces the invariant.

Totality: making partial logic illegal

total
head : Vect (S n) a -> a
head (x :: _) = x

This function cannot be called on an empty vector. Invalid states are unrepresentable.

Idris 2 ergonomics (the nitty-gritty)

Compiler & performance: Significantly faster than Idris 1, reasonable compile times
Error messages: Improved structure, still proof-oriented and verbose
Tooling: LSP support exists, interactive editing is powerful, docs are uneven

Usable, but not luxurious.

Linearity and resource safety

useOnce : (1 x : a) -> a
useOnce x = x

Linear types enable compile-time guarantees around resource usage: no double-use, no leaks, no implicit copying.

Is Idris ready for production?

Where Idris shines

Protocols and state machines
Parsers, DSLs, validation-heavy logic
Compilers and interpreters
Correctness-critical business logic

Where it struggles

Small ecosystem
Hiring challenges
Interop overhead
Not ideal for fast-moving CRUD apps

Idris works best as a correctness core, not a default full-stack choice.

Mainline development or niche tool?

Idris isn’t trying to replace Go, Rust, or TypeScript.

It’s for teams asking:

What if the compiler enforced our invariants?
What if tests were secondary to types?

In 2026, Idris 2 is stable enough for real systems, if your team is willing to think in types.

Final take

Idris is no longer just a research curiosity.

Idris 2 is production-capable for the right domains, offering unmatched guarantees at compile time.

If correctness is your top priority, Idris is quietly excellent.

Fourbidden: A Serious AI Solution to 2+2, With Maximum Ceremony and No Resolution

ujja — Sun, 05 Apr 2026 10:04:34 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built Fourbidden, a fake AI product dedicated to solving one extremely serious global problem: 2+2.

The joke is that the problem could not be smaller, but the app treats it like the final summit of machine reasoning.

You ask a basic addition question, and instead of getting a basic addition answer, the app starts trying to sum up its own importance.

That means you get:

AI-generated loading statements that sound suspiciously strategic
circular explainers that get more philosophical and less useful over time
escalating terms and conditions that keep turning arithmetic into a compliance event
procedural next steps designed to preserve momentum without producing closure
dashboard widgets, warnings, and theatrical system language
surprise interactions like panic overlays, chaos toasts, prank label swaps, and a hidden Konami-style chaos mode

The T&C bit became one of my favorite parts of the whole thing.

The user is effectively told that before they can move closer to understanding 2+2, they must first acknowledge expanding legal nonsense, accept more conditions, and agree to one more procedural step. Then another. Then another.

So the core gag is not just overengineering. It is over-addition: treating the smallest possible math question like a high-risk, high-governance product flow.

It is a satire of software that cannot simply give you the answer, because it is too busy building a whole process around the answer.

Demo

Live demo: https://ujjavala.github.io/fourbidden/
Local version: http://localhost:3000
Main routes:
- Home: /
- About: /about
- Services: /services

Code

GitHub: https://github.com/ujjavala/fourbidden

Key route surface:

/api/explain
/api/loading
/api/terms
/api/steps
/api/loop
/api/widgets

How I Built It

I wanted the app to feel like a glossy software product that exists entirely to avoid resolving 2+2 in a straightforward way.

So instead of making a single punchline screen, I built a full fake workflow around the idea of “solving” the problem while constantly refusing to complete it.

Tech stack:

Next.js 14 (App Router)
React + TypeScript
Google AI (Gemini API) to generate the app's overblown explanations, loading copy, legal nonsense, escalation steps, loop logic, and widget chatter
Custom CSS for the bright cinematic UI, orbit effects, shimmer, flashes, and overly dramatic motion
Lucide React for icon-driven UI accents

Implementation choices that shape the vibe:

The main joke is taking the tiniest math problem and inflating it into a full-stack event.
The interface looks polished enough to imply a seed round and a brand strategy deck.
The T&C flow is central to the bit: the user keeps having to consent to more nonsense before progress can allegedly continue.
The text stays intentionally circular and jargon-heavy so the app never gives the satisfaction of a clean conclusion.
The click surprises add a second layer of April Fools chaos on top of the main workflow.
There is a static fallback path so the absurdity still works even when live AI calls are unavailable.

How I Leveraged Google AI

Gemini is the narrative engine for the whole product illusion.

I did not use it as a single chatbot response. I split the experience into multiple AI-backed roles so each part of the fake platform has its own voice and function.

/api/explain: produces long-form ceremonial non-answers
/api/loading: turns waiting into executive messaging
/api/terms: creates useless compliance clauses and acceptance loops around 2+2
/api/steps: invents process-heavy next actions
/api/loop: explains why completion is still not operationally appropriate
/api/widgets: generates fake platform telemetry and side-channel noise

To keep that experience stable, I added:

prompt caching with a short TTL
retry and backoff handling for quota and rate-limit failures
local fallback generators when Gemini is unavailable
client-side static mode for static hosting environments

That way the joke survives whether the AI is live, rate-limited, or completely absent.

Prize Categories

Best Google AI Usage

Google AI is not just providing flavor text here. It is powering the entire illusion that a hopelessly overbuilt software stack has been assembled to “solve” a single grade-school math prompt. Every stage of that ridiculous journey gets its own AI-generated nonsense.

Best Ode to Larry Masinter

This app is proudly unnecessary. It manufactures protocol, ceremony, terms, gates, and pseudo-serious internet behavior around a task that should end instantly. It feels like the kind of thing that technically works while making arithmetic worse.

Community Favorite

I think the joke lands quickly: everyone understands 2+2, and everyone also recognizes software that delivers process instead of outcomes. Combining those two ideas made it easy to build something immediate, silly, and annoyingly plausible.

If it makes people laugh and also mutter, "why does this feel plausible," then it did its job.

[Boost]

ujja — Fri, 20 Mar 2026 11:35:27 +0000

Notion MCP Challenge Submission 🧠

ujja

Mar 12

I Built EchoHR: The HR System That Doesn’t Ghost You

#devchallenge #notionchallenge #mcp #ai

Comments 63

5 min read

Big drop for EchoHR 🚀 🔧 Postgres queue + worker, idempotent + HMAC webhooks, retries/backoff, metrics ✨ Cleaner UX with hero video, logo, and clearer lifecycle ⚙️ More reliable setup + Docker flow (migrate seed worker) Check out the blog for more 👇

ujja — Tue, 17 Mar 2026 06:08:56 +0000

Notion MCP Challenge Submission 🧠

ujja

Mar 12

I Built EchoHR: The HR System That Doesn’t Ghost You

#devchallenge #notionchallenge #mcp #ai

Comments 63

5 min read

The Enablers Who Helped Me Code Forward

ujja — Tue, 10 Mar 2026 03:31:44 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

Sometimes the difference between giving up and moving forward is just one person who believes in you.

I started coding when I was around nine years old.

My first program was written in LOGO, where I spent hours writing tiny programs using a funny-looking triangular turtle that moved across the screen. You could tell it to move forward, turn, and draw shapes, and slowly patterns would emerge. To a kid, it felt magical. A few instructions and suddenly the computer was drawing something I had imagined.

Back then I had no idea what a career in tech looked like. I just knew I loved making computers do things.

One thing that made my journey different from many stories I hear today was the support I received at home. My family, especially my dad, supported my interest in computers wholeheartedly. At a time when many people still questioned whether girls should pursue technology, he never did. To him it was simple — if I enjoyed it, I should pursue it.

That early encouragement made a huge difference.

The Myth of the Solo Journey

When people talk about careers in tech, the story is often about individual effort — perseverance, hard work, determination.

And while those things matter, looking back I realise something else played an equally important role: enablers.

Throughout my journey there were always people who gave me a small push forward at the right moment.

Not huge dramatic gestures. Just small nudges that made a big difference.

The First Catalyst

Early in my career I had a tech lead who noticed something about me before I fully recognised it myself.

I loved clean code.

I loved experimenting.

Hackathons excited me.

Instead of letting that remain just a personal interest, he organised a hackathon within the team.

At the time it seemed like just a fun activity. But in reality, it gave me confidence. It validated that my curiosity and enthusiasm for building things mattered.

Sometimes all someone needs is that small signal that their passion is worth investing in.

Finding My Voice

Later in another organisation I faced a different challenge.

I was technically confident, but public speaking terrified me.

Speaking up in meetings, presenting ideas, addressing a room full of people — those things didn't come naturally to me.

An office head in that organisation noticed this and gently pushed me out of my comfort zone.

Encouraging me to present.

Encouraging me to speak up.

Encouraging me to trust my voice.

I still remember a very simple piece of advice he gave me.

He said, “Start small. Just say hi to people in the morning.”

His reasoning was simple. If I greeted people in the hallway or by the coffee machine, when I later saw them in a meeting room they wouldn’t feel like strangers anymore. The room would feel a little less intimidating.

He also said something that stuck with me — smile. Maybe crack a small joke to ease the tension.

It sounded almost too simple at the time, but it worked. Slowly those rooms full of unfamiliar faces started turning into rooms with colleagues I already knew, even if only through a quick morning hello.

And little by little, speaking up didn’t feel so scary anymore.

Today I speak about topics I care deeply about, especially identity and authentication in tech — something I am incredibly passionate about.

The Reality of Being Heard

If you’ve worked in tech long enough, you’ve probably seen this happen.

Sometimes a woman's voice is ignored.

Ideas get overlooked.

Comments go unheard.

Credit sometimes travels in unexpected directions.

It happens.

But another truth exists too.

There are also people who amplify voices.

People who pause the room and say,

"I think she was making a really good point."

People who make sure ideas get the attention they deserve.

Over time I’ve realised the tech industry isn't defined only by the people who silence voices.

It’s also shaped by the people who make sure those voices are heard.

Recognising the Enablers

Even today in my current workplace I am fortunate to work with amazing people who create that kind of environment.

Looking back, my journey was never just about learning new technologies, frameworks, or systems.

It was also about recognising the people who helped me move forward.

The enablers.

The mentors.

The leaders.

The colleagues.

The allies.

The people who saw potential and helped unlock it.

Paying It Forward

The biggest lesson from my journey is this:

If you’ve had enablers in your life, the best thing you can do is become one for someone else.

Encourage the curious junior developer.

Support the quiet voice in the meeting.

Create spaces where people can experiment and grow.

Sometimes a small push can change someone’s entire trajectory.

I know it did for me.

And to all the girls who want to code but feel like they can’t,

to all the women and marginalised voices who sometimes feel unheard or silenced in tech:

Look around.

There are often people who quietly support you, encourage you, and believe in you — sometimes even before you believe in yourself.

Find those people.

Recognise them.

Hold on to them.

Because once you identify the enablers in your life, you’ll realise something powerful. You were never coding alone.

And if you ever feel like you don’t belong in tech, remember this:

Sometimes all it takes is one enabler to change your trajectory — and someday, that enabler might be you.

Rethinking AI Assistants: A Privacy-First Approach with Google Gemini

ujja — Wed, 04 Mar 2026 11:09:32 +0000

Built with Google Gemini: Writing Challenge

ujja

Feb 28

Building a Privacy-First Mobile Speech Assistant Using Google Gemini

#devchallenge #geminireflections #gemini #llm

Comments 14

5 min read