DEV Community: ujja

I Love Dogs, But Dogs Scare Me — So I Built Pawsitive with Gemini 🐾.

ujja — Sat, 15 Aug 2026 09:28:28 +0000

This is a submission for Weekend Challenge: Dog Days Edition

There are only two types of people in the world: those who love dogs, and those who love them from a distance. 😂🐶

What I Built

I love dogs.

There, I said it.

And yet, I am also scared of them.

It is a strange combination. I can happily watch dog videos for hours, admire every dog I see on the street, and still instinctively tense up when one suddenly runs towards me.

A lot of that comes from a traumatic experience I had with a dog as a child. You can grow up knowing that one experience doesn't define every dog you will ever meet, but sometimes your instincts don't get the memo.

While thinking about this challenge, I started wondering if the problem was partly not understanding what I was seeing.

If a dog is wagging its tail, what does that actually mean? If it is staring at me, should I move away? If it is barking, is it excited, nervous, protective, or something else? And if a dog is approaching me on a footpath, what should I actually do?

That question became Pawsitive.

Pawsitive is an interactive learning app for people who feel nervous around dogs. Instead of telling people not to be afraid, it tries to make encounters feel less unpredictable by teaching them how to recognise common body-language signals, understand situations, and make calmer decisions.

But then I realised there was another side to the interaction.

A dog owner might see their dog happily walking towards someone and think:

"Don't worry, he's friendly!"

The person approaching might be thinking:

"Please don't let that dog come any closer."

Both people can be looking at the same dog while experiencing completely different situations.

So Pawsitive has two learning paths: people who are nervous around dogs and dog owners.

The first helps people understand dogs and build confidence. The second helps owners recognise when someone might be uncomfortable, why giving people space matters, and why "my dog is friendly" doesn't necessarily make an approaching dog less intimidating.

That became the idea behind the whole app:

Two perspectives. One better interaction.

Demo

Github link: https://github.com/ujjavala/pawsitive

Vercel deployment: https://pawsitive-nine.vercel.app/

Note: The Vercel deployment does not include a Gemini API key. On supported desktop Chrome devices, Understand This Dog falls back to Chrome's built-in Gemini Nano model and analyses the photo privately on-device. You can also run the app locally and add GEMINI_API_KEY to .env.local for server-side Gemini analysis.

The experience begins with three gentle onboarding questions: how comfortable you are around unfamiliar dogs, which situations feel most uncomfortable, and what you want to achieve. Someone who selects "Very nervous" isn't immediately thrown into a stressful scenario. They start by learning the basics, exploring relaxed and tense body language before gradually moving into realistic situations. Their answer also sets an initial confidence score, but it never locks content or forces them into an interaction.

Then comes What Would You Do?

You might be walking down a footpath when a dog approaches with its owner. Instead of reading instructions, you decide how you would respond and then get an explanation of why one choice may lead to a calmer interaction.

The perspective can then switch to the owner's side. The same encounter looks very different when you realise that giving someone space may be more helpful than reassuring them that your dog is friendly.

Finally, Understand This Dog lets users upload a dog photo and use Gemini to explore the visible body-language cues. The result also suggests a possible breed or breed mix, explains which visible features informed the estimate, and shares typical physical characteristics and cautiously worded breed-level behavioural tendencies. It uses the configured server model when a Gemini key is available and falls back to Chrome's built-in Gemini Nano model when the server has no key and the browser supports multimodal on-device AI.

The entire experience is designed to be short enough to explore in a few minutes while still telling the complete story.

How I Built It

I wanted Pawsitive to feel like something you would actually want to use, rather than a clinical safety course.

That led to a bright, playful interface, an animated SVG dog, playful scenario scenes, gentle sounds, small celebrations, and a mascot named Pip who follows the user through the experience.

The app is built with React, TypeScript and Vite, with Tailwind CSS and Radix UI primitives for the interface, Motion for React (the current Framer Motion package) for animation, SVG illustrations for Pip, and Zustand with localStorage for progress tracking. Zod validates structured AI responses at runtime, while Lucide provides the icon system. Server inference uses Google's @google/genai SDK, while private inference uses Chrome's built-in LanguageModel Prompt API without adding another model runtime to the application bundle.

There is deliberately no authentication or database in the MVP. You can open the app and start learning immediately.

The weekend build includes 10 lessons for nervous users, six owner lessons, eight scenarios, eight body-language signals and five gentle achievements. Routes are lazy-loaded so the non-critical learning, scenario and AI screens do not all have to load up front.

Making Pip feel alive

Pip changes depending on what is happening. They can tilt their head during a question, wag their tail after a correct answer, bounce when a lesson is completed, or look confused when something goes wrong.

The animations are deliberately gentle. There are no sudden dogs jumping towards the screen or unexpected barking, because an app designed for nervous dog lovers shouldn't accidentally make them nervous.

The same thinking shaped the sound design. The current build uses short, synthesised feedback tones for correct answers, lesson completion and soft errors. I deliberately left barking and other dog sounds out of the learning flow so the app cannot unexpectedly startle someone. Sound can be disabled, and motion can be reduced from inside the app. Pip also respects the device's own reduced-motion preference.

The goal is simple: make the app feel alive without making it overwhelming.

🧠 The Gemini Experiment

The most interesting part of Pawsitive is Understand This Dog, where I wanted AI to do something more meaningful than power another generic chatbot.

A user can upload a JPG, PNG or WebP photo of a dog, and Gemini analyses the visible signals in the image. The response is structured into six parts:

Possible breed — an appearance-based breed or breed-mix estimate, the visible traits behind it, and an honest visual-confidence level. If the image is not clear enough, the model can simply return Breed unclear instead of forcing a guess.

The breed section also includes typical physical characteristics and possible breed-level behaviours. These are written as broad tendencies using language such as "often", "may", and "commonly"—never as claims about the individual dog. A clear reminder explains that breed cannot predict this dog's personality, emotional state, safety, or future behaviour.

What we can see — observable cues such as posture, ears, tail visibility and body position, each with a visual-confidence level.

What this might mean — cautious interpretations of those signals.

What we can't know — because one photograph cannot tell us everything about a dog's emotional state or predict what it will do next.

What you can do — conservative guidance focused on giving unfamiliar dogs appropriate space.

Safety note — an explicit reminder not to approach an unfamiliar dog based only on an image interpretation.

That last part was especially important to me.

I didn't want to build an AI-powered "Is this dog safe?" detector. A photograph cannot reliably tell you that a dog is safe, friendly, or won't bite.

So the Gemini integration is deliberately designed to acknowledge uncertainty, using language such as "may indicate" and "can be consistent with" rather than making definitive claims. That same principle applies to breed identification: visual similarity can suggest a breed or mix, but appearance alone cannot confirm ancestry or tell us how an individual dog will behave.

That safety work does not rely only on the interface. In the server path, the browser sends the image to a same-origin Vercel Function, so the Gemini key is never exposed to client code. The function rejects unsupported files and images larger than 5 MB before calling Gemini, requests JSON matching a schema, validates the result with Zod, and rejects responses containing certainty claims such as "definitely friendly", "won't bite" or "safe to approach". The UI validates the response again before rendering it as cards, never as model-generated HTML.

The Gemini model is configured server-side with GEMINI_MODEL and checked against an allowlist. The current default is Gemini 3.5 Flash-Lite, and unsupported model IDs fall back to this default rather than being passed through to the provider. For local development, Vite loads only the server-side Gemini environment variables and mounts the same /api/analyze-dog handler used in deployment. That means npm run dev runs the UI and local API together without requiring the Vercel CLI or a Vercel login.

Private on-device fallback with Gemini Nano

When the server reports that no GEMINI_API_KEY is configured, Pawsitive checks Chrome's built-in LanguageModel API with the exact text-and-image capabilities required by the feature. If the model is ready, the selected image is analysed locally. If Chrome needs to download the model first, the interface shows download progress and provides a cancel action.

The on-device session receives the same cautious system instruction as server Gemini, accepts the selected photo as an image Blob, and returns JSON constrained by the same schema. That schema includes the possible breed, confidence, supporting visual evidence, typical characteristics, possible breed behaviours, body-language observations, uncertainty, and safety guidance. Its output passes through the same Zod validation and certainty checks before anything is displayed. The session is destroyed after analysis to release browser resources, and successful results are clearly labelled analysed privately on this device.

What amazed me about the private mode

This became one of the most surprising parts of the whole project. I expected the private on-device mode to be a useful fallback, but I did not expect Gemini Nano to perform this well. In my testing, its observations and cautious interpretations were often remarkably close to the results produced through the API-key-powered server models.

API mode:

Private mode:

That feels like a small glimpse of how quickly AI is advancing: a browser can now examine an image, follow a detailed instruction, produce structured output and respect the same safety constraints—all without an API key and without sending the photo to a server. The privacy benefit is not achieved by giving up the core experience; the result remains genuinely useful.

There are still differences between devices and models, so I would not call the two paths identical or treat my experiments as a formal benchmark. Even so, seeing capable multimodal AI run privately inside Chrome was a real wow moment for me. Gemini Nano started as a fallback and ended up feeling like one of Pawsitive's most exciting features—and a sign of the possibilities that on-device AI is beginning to unlock.

The fallback order is:

Use server Gemini when GEMINI_API_KEY is configured.
Use Chrome's built-in Gemini Nano model when the key is absent and the requested multimodal session is supported.
Show an honest unavailable message and retain the clearly labelled seeded demo when neither option is available.

Prerequisites for private on-device analysis

Chrome's foundation-model APIs are a progressive enhancement rather than universal browser functionality. The current documented requirements are:

Browser: Google Chrome 148 or newer for the web Prompt API.
Operating system: Windows 10 or 11, macOS 13 or newer, Linux, or a Chromebook Plus device. Chrome on Android, iOS, and non-Plus Chromebooks is not currently supported.
Storage: At least 22 GB free on the volume containing the Chrome profile. Chrome removes the model if available storage later drops below 10 GB.
Compute: Strictly more than 4 GB GPU VRAM, or at least 16 GB system RAM and four CPU cores for CPU execution.
Network: An unmetered connection for the initial browser-managed model download. Subsequent inference can run without a network connection.
User activation: The first download must be started after a meaningful user interaction, which Pawsitive provides through the Help me understand button.

For local testing, enable chrome://flags/#optimization-guide-on-device-model and chrome://flags/#prompt-api-for-gemini-nano, then fully relaunch Chrome. Download and model errors can be inspected at chrome://on-device-internals. After the initial download, Chrome states that inference is local and no prompt or image data is sent to Google or another third party.

The AI feature also fails independently from the rest of the product. If neither server nor on-device analysis is available, the user sees a plain explanation and can continue learning. For challenge demos, there is a clearly labelled sample-photo experience with a seeded educational result; it never pretends to be a live result for a photo the user uploaded. Images are processed only after the user presses Help me understand, and Pawsitive does not add them to application storage. On-device analysis keeps the image local; server analysis does not store it.

AI isn't the authority here. It is the teacher.

The Learning Journey

The product principle follows a simple progression:

Understand → Recognise → Respond → Build Confidence

The actual lesson content is organised into Understanding Dogs, Meeting Dogs Safely, and Thoughtful Ownership modules. Users first learn about relaxed and tense body language, tail movement, barking, staring, and why individual signals shouldn't be interpreted in isolation.

They then move into realistic scenarios and make decisions for themselves.

If they get something wrong, Pawsitive doesn't throw a giant red WRONG screen at them. Pip simply tilts their head and encourages them to look at the situation again.

That was intentional.

Someone who is already nervous doesn't need another reason to feel like they're failing.

Progress follows the same principle. Onboarding starts confidence at 20, 40, 50, 70 or 85 depending on the user's own answer. Completing a lesson or correctly answering a new scenario adds five points, while an incorrect answer has no penalty. Rewards are idempotent, so repeating an activity cannot inflate the score. The Progress screen keeps confidence separate from completion and explicitly describes it as a personal reflection, not a clinical measurement.

🐕 The Owner Perspective

The owner experience came directly from thinking about what makes dog encounters uncomfortable.

A dog owner may genuinely have a friendly dog and genuinely believe nothing is wrong. But that doesn't necessarily change how the other person feels.

One scenario asks an owner what they should do when they notice someone moving away from their dog.

The answer isn't to follow them and explain that the dog is friendly. It's simply to create some space.

That captures what I wanted Pawsitive to teach:

A safe interaction isn't just about understanding the dog. It's about understanding the human too.

The paired scenario is linked in both directions in the content model. Completing the person and owner sides unlocks the Perspective Shift achievement, making the product's central idea visible in the progress journey rather than leaving it as marketing copy.

Testing the Safety Net

Because Pawsitive mixes educational content, stateful rewards and model output, I did not want the demo to depend only on a happy-path click-through.

The project uses Vitest and React Testing Library. The current automated suite checks the required lesson, scenario, signal and achievement counts; unique IDs and answer keys; two-way scenario links; confidence clamping and one-time rewards; and the dog-analysis schema. It also contains regression cases for unsafe AI phrases including "definitely friendly", "won't bite", "you can approach this dog" and "safe to approach".

The on-device adapter tests cover unsupported browsers, successful structured multimodal output, browser model-download progress, session cleanup, and rejection of unsafe local-model certainty. A page-level test confirms that a missing server key selects the private path without uploading the image.

Before submission, the strict TypeScript check, all 20 automated tests, ESLint, and the Vite production build pass.

Why I Built It

Pawsitive started with something personal: the slightly ridiculous feeling of loving dogs while still being afraid of them.

I don't expect an app to erase that fear. That wasn't the goal.

I wanted to build something that says:

It's okay if you're nervous. Let's understand what's happening.

Maybe knowing what to look for makes the next encounter feel a little less unpredictable. Maybe understanding that a wagging tail doesn't always mean "hello" gives someone a little more confidence. Maybe helping owners recognise when to create some distance makes the other person feel less alone in the situation.

And maybe, eventually, someone who currently crosses the street when they see a dog can simply keep walking.

For someone who is afraid of dogs, that might not feel like a small thing at all.

🏆 Prize Category: Best Use of Google AI

I'm submitting Pawsitive for Best Use of Google AI because Gemini is part of the core learning experience rather than simply being added as a chatbot.

Through Understand This Dog, Gemini's multimodal capabilities help users explore visible dog body-language cues while deliberately teaching the limits of what can be inferred from a single image. The app can use a securely configured server model or Chrome's built-in Gemini Nano model, with shared structured-output and safety controls across both paths.

A curious dog:

A playful dog:

A rare breed:

That uncertainty is part of the feature, not a limitation hidden from the user.

🔮 Giving Pip a Voice with ElevenLabs

The next piece I would love to add is a voice for Pip using ElevenLabs. ElevenLabs is not part of the current weekend build; this is a deliberate next step rather than a shipped integration.

Right now, Pip is the animated companion reacting to the user's progress. With voice, Pip could become part of the learning journey itself.

Instead of simply reading instructions, Pip could say:

"Okay, let's take this one slowly. You can see a dog coming towards you. What would you do?"

After an answer:

"Good thinking. Giving the dog and its owner a little more space can make this easier for everyone."

And for someone who is nervous:

"There's no rush. Let's look at what's happening first."

The interesting part would be connecting Pip's voice to the user's confidence journey, so the experience gradually feels more encouraging and energetic as their confidence grows.

That brings together three pieces of the experience:

Gemini understands the visual information.

ElevenLabs gives Pip a natural voice.

Motion for React brings Pip to life.

Together, they could turn Pip from an animated mascot into a genuine dog-confidence companion.

I would keep that integration server-side, accept only a small set of approved narration IDs, and cache generated clips. That would protect the API key, control cost and prevent arbitrary text from turning the feature into an open text-to-speech proxy. Narration would remain user-initiated, optional and accompanied by the same visible text.

What's Next?

There are plenty of directions Pawsitive could take, but the core idea would stay the same: gradually move people from illustrations to photographs, videos and increasingly realistic scenarios as their confidence grows.

I also considered Snowflake, but deliberately did not add it to the weekend MVP simply to increase the technology count. Pawsitive does not need a warehouse to teach a lesson or remember local progress. A future opt-in analytics layer could send anonymous events such as lesson completion, perspective switching, Gemini request success and labelled-demo usage to Snowflake—never uploaded photos, model response text or personal details. For now, keeping that out made the privacy story and the architecture simpler.

For dog owners, there could eventually be more personalised guidance around their individual dogs and situations.

But the weekend version is intentionally focused.

Pawsitive is ultimately about closing the gap between two perspectives:

"I don't know what that dog is going to do."

and

"My dog is friendly. Why are they scared?"

There is a lot of space between those two thoughts.

I wanted to build something that helps close it.

And, perhaps selfishly, something that might one day help me stop jumping every time a dog barks.

You don't have to love dogs.

*You just need to understand them.🐾 *

Turning Ayurveda’s Six Rasas Into CSS Art

ujja — Sat, 15 Aug 2026 03:16:21 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

What does comfort food look like when you don't use food photography?

That was the question behind Rasa.

Rasa is an interactive culinary atlas exploring India through Shadrasa, the six tastes described in Ayurveda:

Madhura — sweet
Amla — sour
Lavana — salty
Katu — pungent
Tikta — bitter
Kashaya — astringent

I wanted to turn those six tastes into something visual rather than simply presenting them as text or cards.

The result is a tongue-shaped interactive map.

One important clarification: the familiar "tongue taste map" is scientifically inaccurate. Taste receptors are distributed across the tongue. In Rasa, the tongue is purely a cultural and artistic navigation metaphor, not an anatomy diagram or medical claim.

The idea was to make something that felt like opening an old food journal rather than browsing a database.

The CSS Art

The tongue is probably the most obvious piece of CSS art in the project.

It isn't an image.

It is a layered CSS illustration with:

Six selectable rasa regions
A draggable, bounded CSS 3D orbit
Pointer-responsive lighting
Pan and zoom
Keyboard orbit and navigation
A dedicated control to centre the 3D view
Papillae and surface texture
A median sulcus
Subtle veins and mucosal variation
Rim lighting
Subsurface colour
Counter-scaled labels that remain readable while zooming

The tongue can be explored almost like a little map.

Select a rasa and the camera moves towards that region, revealing the corresponding field notes.

The 3D effect does not use WebGL, canvas or a 3D library. JavaScript only captures pointer and keyboard input and updates a few CSS custom properties. Perspective, depth, lighting, counter-rotation and shadows remain CSS work.

That interaction was important to me.

I didn't want the CSS art to be something you simply look at.

I wanted it to become part of the interface.

Making Food Without Food Images

The other fun constraint was food itself.

Instead of using food photography, every dish has a small declarative plate-art recipe.

The renderer combines things such as:

Vessel
Food form
Colours
Garnishes
Texture
Lighting
Serving temperature

The renderer supports vessels including thalis, plates, bowls, kadhais, clay pots, banana leaves and leaf cones.

Food forms include rounds, stacks, curries, grains, crescents, cones, cubes and strands.

CSS then adds details such as oil sheen, highlights, contact shadows, steam, heat haze, condensation and cold mist.

So a dish isn't a static illustration.

It is data that becomes an illustration.

That was one of my favourite parts of building Rasa.

Six Handcrafted Taste Guides

Each rasa is accompanied by a guide with a distinct silhouette, costume, hairstyle, expression and role:

Guddi, the Culinary Archivist for sweet
Ami, the Fermentation Botanist for sour
Neer, the Coastal Navigator for salty
Tara, the Spice Route Chronicler for pungent
Nima, the Ethnobotanical Elder for bitter
Jamu, the Tea and Tannin Cartographer for astringent

The characters are built from nested HTML and CSS rather than generated avatars, SVG artwork or image files. Gradients, borders, pseudo-elements, clipping and transforms create their faces, clothing, hair, accessories and tools.

They can greet the visitor, scout ingredients and share lore. Their mouths respond while they speak, and gestures such as walking, waving and pointing are finite rather than perpetual. This keeps the characters playful without turning the page into a wall of constant motion.

Making CSS Feel Less Like CSS

A lot of the work was experimenting with the things CSS is surprisingly good at:

gradients + shadows + transforms + masks + pseudo-elements + 3D transforms

Individually, none of those are particularly exotic.

Combined carefully, they can start to feel much closer to illustration.

I also added a small layer of atmospheric "ingredient wind" across the site.

Different rasas get their own ingredient:

Jaggery for sweet
Mango leaf for sour
Salt crystal for salty
Chilli for pungent
Neem leaf for bitter
Jamun for astringent

The ingredients drift across the page like leaves in a breeze.

It is intentionally subtle.

It can also be paused, disappears in forced-colour mode, and respects reduced-motion preferences.

CSS Art With a Purpose

One thing I wanted to avoid was making a collection of pretty CSS experiments that didn't actually help the user.

The visual language is tied to the content.

The tongue represents the six tastes.

The plate art represents the food.

The notebook changes atmosphere depending on the dish.

Hot dishes introduce warmth, steam and heat shimmer.

Chilled dishes introduce condensation, frost and cool mist.

Festival dishes receive restrained gold details.

Street food gets a subtle field-stamp treatment.

The visual effects are therefore part of the storytelling rather than decoration added afterwards.

84 Dishes Instead of Six

The six tastes are only the entry point.

Rasa contains 84 dishes, with 14 primary dishes for each rasa, covering all 28 Indian states and multiple Union Territories across eight culinary macro-regions.

The dataset intentionally goes beyond the usual shorthand for Indian food.

There are:

Everyday meals
Breakfasts
Snacks
Street foods
Festival foods
Temple foods
City specialities
Folk and Adivasi traditions
Fermented foods
Coastal cuisines
Mountain cuisines
Sweets
Drinks
Pickles
Breads
Rice dishes
Curries
Preserved foods

The goal was breadth rather than stereotype.

The Technical Side

Rasa is built with:

React 18
TypeScript 5.7
Vite 6
Tailwind CSS 4
Lucide React
Handcrafted CSS character art
Playwright
axe-core

The application is data-driven.

The six rasas, dishes, regions, festivals, spices and guides are represented as domain models rather than being embedded directly into components.

That makes the CSS renderer reusable.

A Dish can describe what something is, while its PlateArt recipe describes how it should look.

That separation made it much easier to keep adding dishes without creating a new component for every food.

Accessibility Still Applies to CSS Art

One of the interesting challenges was making something visually experimental still behave like a normal application.

The map is keyboard-operable.

The rasa controls, field-note tabs, guide commands, notebook corners and CSS 3D orbit are keyboard-operable.

Interactive controls have accessible names and 44 × 44px minimum targets.

There is a skip link.

Notebook page changes are announced to screen readers.

The experience supports reduced motion, persistent motion controls, forced colours, 200% zoom, text-spacing overrides and 320px reflow. Native dish names carry language metadata, page and guide changes use polite status announcements, and textured-paper text now uses darker ink colours for enhanced contrast.

I also added 13 Playwright accessibility and interaction journeys. They run axe with WCAG 2.0, 2.1 and 2.2 A, AA and AAA tags, exercise all six rasa states and all field-note tabs, and check keyboard selection, reduced motion, text spacing, target sizes, finite guide animation, CSS 3D keyboard orbit and notebook corner navigation.

The latest automated run passes all 13 journeys with no axe violations or unresolved structural ARIA checks. Textured gradients can prevent automated tools from resolving every contrast pair, so the underlying ink-on-paper colour pairs were also reviewed directly. This still is not a claim that automation proves complete WCAG AAA conformance: manual testing remains necessary for reading order, language and pronunciation, cognitive clarity, and real assistive-technology behaviour.

What I Learned

The biggest lesson was that CSS art becomes much more interesting when it has a job.

It is tempting to ask:

"How can I make this look cool with CSS?"

A better question turned out to be:

"What should this visual communicate?"

Once the answer was clear, the implementation became much easier.

The tongue needed depth because it was a map.

The food needed texture because it represented serving and preparation.

The notebook needed page turns because the content was designed as a field journal.

The current notebook has clickable outer page corners as well as conventional Previous and Next controls. Each corner uses a small rounded CSS curl: the right edge lifts subtly upward and left, while the left edge lifts upward and right. The fold, underside, highlight and shadow are all CSS, while the button underneath remains semantic and keyboard accessible.

The motion needed to communicate state instead of simply moving things around.

That became one of the design principles for the entire project:

Motion should explain state or create atmosphere, never prevent reading.

Demo

🍛 Try Rasa: https://rasa-mu.vercel.app/

The source code is available on GitHub:

ujjavala / rasa

Rasa — The Tongue Map of India

An interactive culinary atlas that explores India through Shadrasa, Ayurveda's six tastes: sweet, sour, salty, pungent, bitter, and astringent.

Rasa is a React experience built for the DEV Frontend Challenge themes CSS Art: Comfort Food and Perfect Landing: Comfort Food. It combines an editorial landing page, a zoomable CSS-art tongue map, character-led exploration, regional food history, and a page-turning field notebook containing 84 dishes from across India.

Important: the familiar “tongue taste map” is scientifically inaccurate. Taste receptors are distributed across the tongue. This project uses the tongue only as a cultural and artistic navigation metaphor for the six rasas; it is not an anatomy chart or medical guidance.

Why this project exists

Indian food is often flattened into a small set of restaurant dishes. Rasa was created to show a wider table: home cooking, street food, temple food, festival dishes…

View on GitHub

Youtube link:

What's Next?

There are plenty of things I'd like to explore further:

Ingredient and state-based search
Seasonal food trails
Audio pronunciation for native dish names
More community-reviewed cultural sources
Shareable notebook pages
Deeper VoiceOver, NVDA, TalkBack and keyboard-only testing

For now, Rasa is my little experiment in asking:

How far can CSS go when you stop treating it as styling and start treating it as an illustration medium?

And perhaps more importantly:

Can a website about comfort food make you hungry without using a single food photograph? 🍚

Designing a Landing Page That Feels Like Opening a Food Journal

ujja — Sat, 15 Aug 2026 03:16:15 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing.

What I Built

I built Rasa, an interactive culinary atlas that explores India through the six tastes of Shadrasa:

sweet, sour, salty, pungent, bitter and astringent.

The starting point was simple:

What if a food atlas felt less like a database and more like opening a traveller's field journal?

That idea shaped the entire landing page.

Instead of starting with a grid of dishes or a traditional restaurant-style hero, I wanted the page to feel editorial, tactile and slightly mysterious.

The landing page introduces the six tastes through a CSS-built rasa mandala and then invites the visitor into the atlas.

From there, the experience expands into an interactive tongue map, character-led exploration, regional food history and a page-turning culinary notebook containing 84 dishes.

The Landing Page Is the Beginning, Not the Destination

I approached the hero as an invitation rather than a summary.

The visitor first encounters the concept of Rasa.

Then the six tastes.

Then the tongue.

Then the exploration.

That progression was deliberate.

I didn't want to put every feature into the first screen.

The landing page establishes the mental model first:

Rasa → taste → region → dish → story

Once that relationship is understood, the rest of the application becomes easier to navigate.

Why a Tongue?

There is a familiar visual idea of dividing the tongue into taste regions.

Taste receptors are distributed across the tongue, so Rasa does not present this as an anatomy chart.

Instead, I used the tongue as a visual metaphor.

Six regions.

Six tastes.

Six entry points into a much larger culinary landscape.

The tongue is interactive, zoomable and keyboard accessible. It also supports a shallow, bounded 3D orbit: visitors can drag the backdrop, use arrow keys, hold Shift for larger steps, or press Home and the dedicated centre control to reset the view.

Selecting a rasa moves the camera towards that region and opens its field notes.

The depth effect is still CSS-first. JavaScript captures input and updates CSS custom properties; perspective, layer separation, lighting, shadows and character depth are rendered in CSS. There is no canvas, WebGL or 3D dependency.

So the hero concept eventually becomes the primary navigation mechanism.

From Landing Page to Field Journal

The biggest design decision was to avoid making the experience feel like a food catalogue.

India has far too many food traditions for that approach to feel right.

Rasa explores:

Everyday home cooking
Street food
Festival and temple food
City specialities
Folk and Adivasi traditions
Fermented foods
Coastal cuisines
Mountain cuisines
Regional ingredients and techniques

The current dataset contains 84 dishes across eight culinary macro-regions, representing all 28 Indian states and multiple Union Territories.

Each dish includes context around its history, ingredients, technique, occasions and regional identity.

The landing page therefore needed to communicate exploration, not simply consumption.

Meet the Guides

I also wanted the interface to have some personality.

Each rasa has a guide with a distinct identity:

Taste	Guide	Role
Madhura · sweet	Guddi	Culinary Archivist
Amla · sour	Ami	Fermentation Botanist
Lavana · salty	Neer	Coastal Navigator
Katu · pungent	Tara	Spice Route Chronicler
Tikta · bitter	Nima	Ethnobotanical Elder
Kashaya · astringent	Jamu	Tea and Tannin Cartographer

Each guide can:

Greet
Scout ingredients
Reveal lore

The portraits are handcrafted from nested HTML and CSS. Each guide has a different figure, skin tone, costume, hairstyle, accessories and expression, with Guddi, Tara and Nima represented as women and Ami, Neer and Jamu as men. They use no generated avatar package, SVG character asset or image file.

Their walking, waving, scouting and lore gestures are intentionally finite rather than constant idle animation. Speech bubbles restart for each command, and the mouth moves briefly while a guide talks.

That was another deliberate choice.

I wanted characters to feel responsive rather than noisy.

The Notebook

The deeper you go into the experience, the more the interface changes.

Instead of a conventional card grid, dishes appear in a two-page field notebook.

You can turn pages.

You can also use the lifted outer corners: the right corner turns forward and the left corner turns backward. They are semantic buttons with subtle rounded CSS curls that rise inward like the edge of a real page, while the existing Previous, Next and direct-jump controls remain available.

Jump directly to a dish.

Move backwards and forwards.

See regional and contextual annotations.

Read the native name with appropriate language metadata.

Follow the dish to further context.

The notebook also changes atmosphere based on the food.

A piping-hot dish can introduce warmth, steam and heat shimmer.

A chilled dish can introduce frost, condensation and cool mist.

Festival foods receive restrained gold detailing.

Street foods receive a subtle field-stamp treatment.

This was my way of making the interface feel like a physical object rather than another collection of UI cards.

Designing for Accessibility From the Start

A visually heavy landing page can very quickly become inaccessible.

So accessibility wasn't treated as something to check after the animations were finished.

The application includes:

Semantic landmarks and headings
A skip link
Keyboard-operable navigation
Roving tab navigation
Visible focus states
Accessible icon controls
44 × 44px minimum interactive targets
Screen-reader announcements
Reduced-motion support
Persistent pause/play motion control
Forced-colour support
200% zoom support
320px reflow
Text-spacing resilience
Keyboard control for the CSS 3D orbit and notebook corners
Enhanced ink-on-paper contrast
Automated axe checks through Playwright across all six rasa states and every field-note tab

The principle was simple:

The experience should remain useful when the visual effects disappear.

If someone disables animation, uses keyboard navigation, zooms the page or doesn't have pointer input, the content and navigation still need to make sense.

The current suite contains 13 accessibility and interaction journeys and passes in Chromium. It runs axe using WCAG 2.0, 2.1 and 2.2 A, AA and AAA tags, and now rejects unresolved structural ARIA findings as well as violations. Automation still cannot certify every AAA success criterion, especially where manual judgement, language, pronunciation, reading clarity or real assistive technology is involved, so manual review remains part of the roadmap.

Motion With Meaning

There is quite a lot of movement in Rasa.

But every type of movement has a reason.

Guide movement communicates an interaction.

The camera movement communicates navigation.

Notebook movement communicates page direction.

Steam and heat haze communicate serving temperature.

Ingredient wind creates atmosphere.

And the global motion control lets the user pause the experience.

The application also respects prefers-reduced-motion.

This led to one of my favourite principles from the project:

Movement should explain state or create atmosphere, never prevent reading.

The Visual Language

I wanted the interface to feel somewhere between:

a field journal + an old map + a recipe notebook + a museum exhibit.

Brass.

Paper.

Ink.

Food vessels.

Spice textures.

Map controls.

Shadows.

Atmospheric movement.

Most of those visual elements are created with CSS rather than remote food photography.

That constraint ended up becoming one of the most interesting parts of the project.

Technical Stack

The application is built with:

React 18
TypeScript 5.7 in strict mode
Vite 6
Tailwind CSS 4
Lucide React
Handcrafted HTML and CSS character art
ESLint
Stylelint
Playwright
axe-core

The application is deliberately data-driven.

Rasas, dishes, regions, festivals, spices and explorers are represented as data models.

React components are responsible for rendering those models rather than containing the cultural content themselves.

That made it possible to build a fairly elaborate experience without turning the components into giant collections of hard-coded content.

What I Enjoyed Most

The most satisfying part was seeing a landing-page idea evolve into an actual world.

At first it was just:

six tastes.

Then:

six tastes → six regions → six guides.

Then:

guides → dishes → regions → festivals → spices.

Eventually it became an atlas containing 84 dishes and multiple ways to explore them.

That progression made the project feel much more like a small product than a challenge submission.

What I Would Improve Next

There is still plenty I would like to add.

Some ideas are:

Search by ingredient, state, season and technique
Audio pronunciation for native dish names
User-created food trails
Shareable notebook pages
More community-reviewed citations and oral-history sources
More manual accessibility testing with VoiceOver, NVDA and TalkBack
Additional contrast review for complex textured and gradient surfaces

Demo

🍛 Explore Rasa: https://rasa-mu.vercel.app/

Source Code

The project is open source on GitHub:

ujjavala / rasa

Rasa — The Tongue Map of India

An interactive culinary atlas that explores India through Shadrasa, Ayurveda's six tastes: sweet, sour, salty, pungent, bitter, and astringent.

Important: the familiar “tongue taste map” is scientifically inaccurate. Taste receptors are distributed across the tongue. This project uses the tongue only as a cultural and artistic navigation metaphor for the six rasas; it is not an anatomy chart or medical guidance.

Why this project exists

Indian food is often flattened into a small set of restaurant dishes. Rasa was created to show a wider table: home cooking, street food, temple food, festival dishes…

View on GitHub

Youtube link:

Final Thought

I started with a comfort-food challenge.

I ended up building a small interactive atlas.

That was probably the most enjoyable part of the challenge.

Instead of asking:

"How do I make a landing page about food?"

I asked:

"How would a food atlas feel if you could walk into it?"

Rasa is my attempt at that answer.

A little paper.

A little spice.

A little CSS magic.

And a very large table. 🍛

You Know What's Worse Than Not Being Able to Log In?

ujja — Thu, 13 Aug 2026 12:38:44 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

You Know What's Worse Than Not Being Able to Log In?

Being told everything worked right up until you try to actually use your account.

Yes, that was a real bug.

And, somehow, I ended up being pulled into another authentication mystery. At this point, I’m starting to think authentication bugs have a personal grudge against me. 😅

In my previous Smash Story, I wrote about a bug where users simply couldn't log in. This time, the problem was sneakier because most of the flow looked completely healthy. The user was approved, the background task ran, the email and SMS arrived, and Cognito had a user.

Then the user actually tried to use their account.

And everything fell apart.

It Started With Two User Pools

The authentication setup was fairly large and had evolved over time, so there wasn't one shiny User Pool doing everything.

We had an older Cognito User Pool supporting existing authentication flows, including mobile-based signup, while a newer User Pool handled a newer flow where users received an email containing their PIN. Both pools were intentional because they supported different parts of the authentication journey.

That wasn't the problem.

The interesting part was that the application database had its own representation of a user, while Cognito had another. On top of that, some of the work connecting those two systems happened asynchronously.

As long as everyone agreed about who the user was, nobody cared.

The moment they disagreed, authentication became very interested.

The Tiny Timing Window

The problem appeared in the partner and dependant journey.

A member could create a partner or dependant during signup or later from the member details area. A relevant non-member user would then approve the account, which scheduled an asynchronous task called SendingEmailsAfterApprovalBot in a TaskList database table.

That task ran every 15 minutes, and once it executed, the partner or dependant received an email and SMS containing a code. They could then confirm their account, set a password and sign in.

Sounds reasonable, right?

Now imagine this.

A partner gets approved at 10:01 AM, so the background task is scheduled and everyone moves on with their lives. At 10:05 AM, before the task has run, the partner changes their name.

That tiny change matters because the username for partner and dependant accounts is derived from their details. The database now has the new username, while Cognito may still know about the old username.

Nothing has visibly broken yet.

The task is still waiting patiently in the database, completely unaware that the identity it is about to process has changed underneath it.

Then, 15 minutes later, it wakes up.

Cognito Says, "I've Seen This Email Before"

The background task tries to create the Cognito user using the latest username stored in the database.

Cognito rejects the creation because the email address is already associated with an existing user, but that user has a different username.

And there is an important detail here: the Cognito username is immutable.

So we weren't dealing with a simple "just update the username" situation. We had two systems describing the same person with different usernames, and Cognito was quite reasonably refusing to create another user with the same email.

The database was saying:

"This is the current username for this person."

Cognito was effectively saying:

"I already know this email, and it belongs to someone with another username."

Same human.

Different digital identity.

And that mismatch was enough to break the journey.

Everything Looked Fine... Until It Didn't

What made this bug particularly sneaky was what happened next.

The user could still receive the expected email and SMS. There was no obvious failure screaming for attention. The asynchronous task had run, notifications had gone out and Cognito already had a user associated with the email.

So the user did what any reasonable person would do: they followed the instructions.

They entered their code, tried to confirm their account and attempted to set their password.

Except the identity represented in Cognito didn't match the latest identity represented in the database.

The user wasn't looking at a database synchronisation problem. They weren't thinking about immutable Cognito usernames or asynchronous jobs. They had received a perfectly legitimate code and were simply trying to finish creating their account.

From their perspective, the system had basically said:

"Here's your code. Everything is ready!"

Then:

"Actually... never mind."

That was the bug we had to chase.

Enter Sentry

By this point, we knew something was going wrong somewhere between the database, the background task and Cognito, but knowing where it broke was another story.

This is where Sentry became extremely useful. The error context gave us the details around the Cognito failure, while the breadcrumbs helped reconstruct the events leading up to it. Instead of seeing a Cognito error in isolation and assuming we simply had a duplicate-user problem, we could look at what happened before the failure and connect it back to the user's journey.

The important clue was that Cognito was rejecting the user creation because the email was already associated with an existing user. That told us what Cognito didn't like, but the surrounding context helped explain why we had reached that point in the first place.

We could see the relevant user and operation context around the failure, follow the activity leading up to the Cognito call, and use the correlation ID to connect the same operation across services and logs. That made it much easier to piece together the timeline rather than chasing individual log entries and hoping they belonged to the same request.

And once the timeline was visible, the problem suddenly made sense:

approval → delayed task → name changed → username changed → Cognito already has the email → creation rejected → identities drift apart → confirmation fails

That was the moment the bug stopped looking mysterious.

The code told us what should happen. Sentry's error context, breadcrumbs and correlated logs helped us see what actually happened.

And honestly, that's one of the best parts of having good observability during an authentication investigation. The error tells you where the system complained; the breadcrumbs help you understand the story that led it there.

The Fix Was Simpler Than the Investigation

Once we understood the problem, the fix was surprisingly straightforward.

We already checked whether a Cognito user existed for the email, but we were treating that as enough. Instead, we changed the logic to ask: "Does the correct Cognito user for the current database record exist?"

If the email existed in Cognito but belonged to an outdated username, we deleted that user and recreated it with the latest username from the database. Since Cognito usernames are immutable, recreating the user was necessary to bring the two systems back into alignment.

The important change wasn't the delete-and-recreate itself. It was recognising that the database was the source of truth for the current username, while Cognito could still be holding an older representation of the same person.

The Weird Scenario Was the Important One

The happy path already worked, so the interesting tests were the ones where state changed between steps.

We tested the normal signup flows, partner and dependant creation, existing Cognito users, missing Cognito users and, most importantly, the scenario that exposed the bug: a partner or dependant was approved, changed their name before SendingEmailsAfterApprovalBot ran, and then the background process tried to create their Cognito user using the latest database state.

We then verified the part that actually mattered: could they receive their PIN, confirm their account, set their password and successfully sign in?

Because nobody cares about our beautifully synchronised identity records. They just want to get into their account.

The Interesting Part Wasn't Actually Cognito

Looking back, this wasn't really a Cognito bug. The database wasn't broken, and neither was the scheduled task. Each component was behaving according to its own rules.

The problem was the assumption connecting them: that the identity we started processing would still be the identity we needed when the asynchronous process eventually ran.

Then someone changed their name.

That small change was enough to make the database username different from the immutable username already held by Cognito. Since the email was already taken, Cognito rejected the new user creation and the two systems drifted apart.

That's the lesson I took from it: whenever identity exists in multiple systems, you need to be explicit about which system is the source of truth and what happens when those representations disagree.

Because eventually, they will.

Someone will change their name. A background job will run later. A legacy system will already have a record. And Cognito will quite reasonably tell you that it has seen that email before.

And That's What Made This Bug So Sneaky

The approval worked, the task ran, the notification was sent, Cognito had a user and the user followed the instructions. Yet somewhere between those perfectly reasonable steps, the identity had drifted.

From the user's perspective, none of the underlying details mattered. They didn't know there were two User Pools, that the old pool handled mobile signup while the newer one sent the email PIN, or that a background task ran every 15 minutes.

They simply knew they had done everything they were asked to do and still couldn't get into their account.

Which brings me back to the opening question.

What's worse than not being able to log in?

Being told everything worked right up until you try to actually use your account.

At least a failed login is honest. This bug was more like:

"Congratulations! Everything worked!"

"Really? Because I'm still locked out."

And that's probably the biggest lesson I took away from it: when debugging authentication, don't just look at the login screen. Follow the identity through the entire system, use your observability tools to reconstruct what actually happened, and find the moment when the different pieces stopped agreeing about who that user was.

Because sometimes the authentication bug isn't hiding at login.

Sometimes it's hiding in a background job, quietly waiting for someone to change their name.

Auth strikes again. 🔐🐛

You Know What Happens When There's a Bug in Authentication? Absolutely Nothing.

ujja — Thu, 30 Jul 2026 14:23:19 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Everything Stops

You know what happens when there's a bug in authentication?

Nothing.

Seriously... absolutely nothing.

Not because nothing is broken, but because users simply can't get past the front door. They can't log in, which means they can't access the application, complete a booking, view their information, or do whatever they came there to do in the first place.

Normally that's annoying.

But what if the application isn't just another website?

At the time, I was part of the authentication engineering team responsible for rolling out Multi-Factor Authentication (MFA) for government service centres across the state. These weren't internal dashboards or social media apps. These were systems used every day by frontline staff helping thousands of citizens.

No login meant staff couldn't process driver's licence applications or renewals. They couldn't register births, deaths or marriages. They couldn't update identity records. During emergencies, they couldn't access systems used to support disaster relief efforts.

The application itself was perfectly healthy. The backend was running. APIs were responding. Databases were online.

But none of that mattered.

Authentication is the front door. If the front door doesn't open, it doesn't matter how well the rest of the house is built.

A Rollout We Thought Was Perfect

Because authentication is so critical, we treated the rollout with the level of care you'd expect.

We had unit tests, integration tests, end-to-end tests, security reviews and user acceptance testing. We tested happy paths, failure scenarios, edge cases and everything in between.

Everything passed.

The rollout went live.

For a while, everything looked great.

Then a few support tickets started appearing.

Some users couldn't log in.

The strange part was that it only affected a handful of people. Most users authenticated successfully, while a small group consistently received a server error.

Those are the bugs every engineer dreads.

If nobody can log in, you usually know where to start.

If only some users can't log in, every assumption suddenly becomes a possibility.

Was it their browser?

Their location?

Their account?

A feature flag?

Some weird cached session?

We checked everything.

We dug through authentication logs, replayed requests, inspected network traffic, reviewed configuration, and read the login code more times than I'd like to admit.

Everything looked correct.

Stop Looking at Logs. Watch People.

Eventually, our team decided to do something different.

Instead of staring at dashboards and log files, we visited one of the service centres and watched people use the application.

Within minutes, we noticed something.

The users clicking the Login button with their mouse authenticated successfully every single time.

The users navigating with the keyboard, pressing Tab and then Enter, consistently hit the server error.

That tiny observation immediately felt important.

As the feature lead developer for the MFA rollout, something clicked.

This wasn't random.

This wasn't infrastructure.

This wasn't the backend.

It had to be the browser.

The Smallest Bug with the Biggest Impact

The culprit?

One missing line.

e.preventDefault();

For anyone unfamiliar with it, e.preventDefault() prevents the browser from performing its default action.

In a React Single Page Application, forgetting it during form submission means the browser performs a traditional form submission instead of letting React handle the authentication flow.

Our React application was being bypassed completely.

Instead of executing our login logic, the browser submitted the form directly to the backend.

Mouse clicks happened to work through our React event handler.

Keyboard submissions didn't.

Every automated test had passed.

Every security review had passed.

And yet government service centre staff couldn't access the systems they needed simply because one line of code was missing.

The Lesson Wasn't About `e.preventDefault()`

I'm proud that once I saw someone press Enter, I immediately suspected browser default behaviour and tracked the problem back to the missing e.preventDefault().

But honestly, that wasn't the biggest lesson.

The biggest lesson was about users.

We spend a lot of time talking about AI-assisted development, automated testing and improving engineering productivity.

I'm a huge believer in all of them.

AI helps me write better code, generate tests, review pull requests and explore solutions much faster than I could a few years ago.

But AI only validates the scenarios we think to test.

Real users don't.

Some never touch a mouse.

Some navigate entirely with a keyboard.

Some use assistive technologies.

Some interact with software in ways we'd never think of while sitting at our desks.

No amount of automation can replace watching someone actually use your application.

Final Thoughts

Whenever people ask me about memorable production bugs, I don't think about distributed systems failures or obscure race conditions.

I think about a missing e.preventDefault().

One line of code.

A rollout that had passed every test.

And government service centres where staff couldn't help citizens because someone pressed Enter instead of clicking a button.

Sometimes the smallest bugs have the biggest impact.

Passion Atlas: A Living Map of Human Curiosity

ujja — Sun, 12 Jul 2026 15:32:47 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built Passion Atlas — an AI-powered map of human curiosity that helps people discover how their interests, experiences, cultures, and ideas connect.

The idea started from something I noticed about myself: I have never had a single passion.

Throughout my life, my interests kept evolving — from anime to dance, boxing to travel, food, culture, and understanding how people live around the world. For a long time, I thought this meant I lacked focus.

But I eventually realised my interests were not random; they were connected.

Anime introduced me to storytelling and different cultures. Dance connected me to movement and expression. Boxing taught me discipline and human psychology. Travel connected everything through food, history, traditions, and people's stories.

Maybe humans are not designed around one fixed passion. Maybe curiosity itself is the passion.

Our minds naturally explore, combine, and connect ideas. The most meaningful discoveries often happen when seemingly unrelated interests come together.

Passion Atlas was built around this idea:

Your interests are not separate islands. They are a connected universe.

Introducing Passion Atlas

Passion Atlas creates a personal Passion Genome — a living representation of someone's curiosity.

Instead of asking:

"What is your passion?"

It asks:

"What are all the things that make you curious, and how do they connect?"

A user might enter:

Travel
Food
Photography
History

Instead of generating a generic recommendation list, Passion Atlas creates connections:

Travel

↓

Cultural Exchange

↓

Local Food Traditions

↓

Storytelling

↓

Heritage Preservation

↓

Traditional Crafts

The goal is not to tell people what they should like.

The goal is to reveal connections they never noticed.

Passion Genome: Your Curiosity Fingerprint

Every person has a unique combination of experiences.

Two people can love the same thing but have completely different curiosity paths.

For example:

Person A:

Photography
+
Travel
+
History

=

Cultural Storytelling

Person B:

Photography
+
Nature
+
Science

=

Environmental Documentation

The same interest can evolve into completely different worlds.

Passion Atlas captures these unique intersections.

The Passion Butterfly Effect

Small moments can create unexpected journeys.

A single experience:

"I attended a traditional tea ceremony in Japan."

Could become:

Tea Culture

↓

Japanese Aesthetics

↓

Ceramics

↓

Traditional Crafts

↓

Sustainable Design

A small spark creates a larger curiosity path.

Passion Atlas helps reveal these hidden chains.

Curiosity Wormholes

Most recommendation systems optimise for similarity.

Passion Atlas optimises for meaningful surprise.

Instead of:

"People who like hiking also like camping."

It explores:

Hiking

↓

Mountain Ecosystems

↓

Indigenous Knowledge

↓

Ancient Navigation

↓

Astronomy

Because sometimes the best discovery is something you were never searching for.

Preserving Human Stories

Passion is not only about consuming knowledge.

It is also about preserving it.

Across the world, thousands of traditions, recipes, crafts, and personal stories risk disappearing.

Passion Atlas creates Passion Time Capsules.

People can contribute:

personal stories
cultural memories
recipes
artisan knowledge
images
audio recordings
videos

AI transforms these into connected cultural experiences.

A grandmother's recipe is not just a recipe.

It is connected to:

migration
family history
geography
tradition
identity

Every story becomes part of the global curiosity map.

How I Built It

Passion Atlas is an AI-native application built using specialised agents.

Passion Extraction Agent

Transforms human stories into structured curiosity data.

It identifies:

interests
emotions
motivations
cultural context
related concepts

Example:

Input:

"I love making traditional food with my grandmother."

Output:

Cooking

Family Heritage

Traditional Knowledge

Cultural Preservation

Curiosity Graph Agent

Builds relationships between:

passions
stories
locations
cultures
experiences

The graph continuously evolves as more people contribute.

Discovery Agent

Finds unexpected connections.

It considers:

novelty
relevance
emotional connection
cultural depth

Cultural Preservation Agent

Transforms human experiences into meaningful knowledge:

summaries
translations
context
connected discovery paths

Demo

The app currently runs on local as it needs environment values. However, a simulation version is deployed on Vercel.

passion-atlas.vercel.app

Code

ujjavala / passion-atlas

🌌 Passion Atlas

A living map of human curiosity.

Passion Atlas is an AI-powered map that helps people discover how their interests, experiences, cultures, and ideas connect. Instead of asking "What is your passion?", it asks "What are all the things that make you curious — and how do they connect?" and renders the answer as a personal Passion Genome: a constellation of your curiosity where unexpected bridges between seemingly unrelated interests light up.

Your interests are not separate islands. They are a connected universe.

Built for the dev.to Weekend Challenge: Passion Edition.

✨ Features

Each screen is a different lens on the same living curiosity graph:

Screen	What it does
🌌 Atlas (Canvas)	Enter a passion and watch it expand into a constellation. Drill into any node to discover its connections; claim ownership of a discovery path on-chain.
🧬 Genome	Your personal "Passion Genome" — the

…

View on GitHub

Prize Categories

🏆 Best Use of Google AI

Google Gemini powers the reasoning layer.

It helps:

extract hidden passions from stories
understand semantic relationships
generate Passion Genomes
discover unexpected connections

Gemini enables the system to reason across thousands of possible curiosity pathways.

🏆 Best Use of Snowflake

Snowflake powers the global Passion Graph.

It stores and analyses:

passion relationships
cultural stories
discovery patterns
human curiosity trends

Over time, the system can uncover patterns like:

"People interested in ceramics often explore gardening, architecture, and sustainable design."

The graph becomes richer with every contribution.

🏆 Best Use of ElevenLabs

Passion is emotional.

A story is not always the same when read as text.

ElevenLabs enables:

voice-based memories
multilingual storytelling
emotional narration

A craftsperson can share their knowledge in their own voice.

A family story can remain human.

🏆 Best Use of Solana

Passion Atlas introduces a contribution layer.

Human knowledge creates value, but contributors are often invisible.

Solana enables:

transparent recognition
contributor rewards
community incentives

Example:

Traditional Weaving Story

↓

500 people discovered this tradition

↓

Contributor recognised

↓

Community preservation supported

The goal is not to financialise every passion.

The goal is to recognise people who preserve and share human knowledge.

Why Passion Atlas?

The internet already connects:

people
places
products
information

But it does not connect something deeply human:

curiosity.

Maybe having many passions is not a lack of direction.

Maybe it is a different way of exploring the world.

Our interests are not random dots.

They are a map.

Passion Atlas helps us discover the connections.

Because every passion leads somewhere.

And every person carries a universe of curiosity waiting to be explored.

How I Built a Turing inspired Treasure-Run Game Where Australia Saves the Sun

ujja — Wed, 10 Jun 2026 08:41:06 +0000

This is a submission for the June Solstice Game Jam

What I Built

For this game jam, I built Dawn Dashers, an adventure runner set during the June Solstice, the longest night of the year in Australia.

The idea started with a simple question:

What if the longest night didn't end?

In Dawn Dashers, a rogue machine called the Turing Engine has stolen the sunrise and scattered seven Sun Fragments across Australia. Players race through deserts, bushland trails, coastal cliffs, and hidden ruins to recover the fragments and bring daylight back.

The game takes inspiration from the June solstice, but with an Australian treasure-hunting twist. Along the way, players dodge obstacles, collect relics, unlock animal abilities, and solve quick logic puzzles inspired by Alan Turing.

One thing I wanted to avoid was making the solstice just part of the story. Instead, it's part of the gameplay itself. At the start, the world is trapped in darkness. As players recover Sun Fragments, the environment gradually becomes brighter, warmer, and more alive until the final sunrise returns.

The goal was simple:

Build something fun first, while using the June Solstice as the heart of the adventure.

Video Demo

You can also try:

Running through the Australian Outback
Discovering treasure clues
Solving Turing-inspired logic challenges
Collecting Sun Fragments
Unlocking animal abilities
Watching the world transform from the longest night back into daylight

... directly through the deployed game (using Vercel)

dawn-dashers.vercel.app

Code

GitHub Repository

Built with:

Vanilla JavaScript — game.js is the entire game engine (~6500+ lines)
Three.js — 3D terrain rendering behind the 2D gameplay HUD
Web Audio API
HTML/CSS — index.html, inline UI modals, HUD
GitHub Copilot

How I Built It

I started by focusing on the core gameplay loop:

Run → Dodge → Collect → Discover → Restore Light

Once movement felt fun, I started layering in everything else.

Making the Solstice Matter

The biggest design decision was making the June Solstice an actual game mechanic rather than just background lore.

The game begins during the longest night of the year. Every Sun Fragment recovered pushes the world closer to dawn.

As players progress:

Darkness slowly recedes
New areas become visible
Lighting becomes warmer
The world feels more hopeful

By the end of the game, the player has literally restored the sunrise.

Building an Australian Adventure

Rather than using generic fantasy locations, I wanted the game to feel distinctly Australian.

The adventure takes players through:

Outback ruins

Bushland trails

A quirky roadside servo

Coastal lighthouse cliffs

Mangroves

Blue Mountains

Nullarbor

Observatory

Aurora-lit Tasmania

Each region introduces new obstacles and visual themes while keeping the action moving.

A Nod to Alan Turing

Since June is also Alan Turing's birth month, I wanted to include a tribute without turning the game into a history lesson.

The game's antagonist, the Turing Engine, believes that endless night is the most logical state of existence.

Players encounter quick puzzles based on:

Pattern recognition
Binary switches
Signal routing
Light circuits

The puzzles are short and designed to support the action rather than interrupt it.

TM Corridors — Turing's Run

At three points in the expedition, the world stops being a runner and becomes a Turing Machine you operate by hand. The level fades away and you step into a glowing sci-fi corridor rendered in one-point perspective — a hallway that is the tape, charging toward a vanishing-point portal.

The story is told in three chapters, framed as Alan Turing bypassing three sealed gates:

Corridor	Machine	The gate demands
I of III	Bit Flipper	Invert every bit until the blank
II of III	Parity Checker	Open only for an even number of `1`s
III of III	Even-Length Protocol	Accept only an even-length message

Art Direction

One of the biggest pivots during development was moving away from a bright arcade aesthetic and leaning into a treasure-hunting adventure style.

The world uses:

Warm desert colours
Ancient ruins
Dust particles
Golden sunlight effects
Treasure-map inspired UI

This direction helped tie together the themes of the solstice, exploration, and treasure hunt.

Technology

The game was built using:

Vanilla JavaScript — game.js is the entire game engine (~6500+ lines)
Three.js — 3D terrain rendering behind the 2D gameplay HUD
Web Audio API
HTML/CSS — index.html, inline UI modals, HUD
Vercel Deployment
GitHub Copilot for development acceleration

The focus throughout was on keeping the project lightweight, responsive, and playable directly in the browser.

Prize Category

Best Ode to Alan Turing

Dawn Dashers is a love letter to Alan Turing, the mathematician, codebreaker, and father of Theoretical computer scientist who was born on 23 June 1912.

Rather than focusing on historical events, I wanted to celebrate the ideas that made his work so influential: logic, patterns, problem-solving, and computation.

The Turing Engine serves as the main antagonist, and players overcome its challenges through quick puzzles inspired by computational thinking.

P.S. For fellow nerds (like me 😄), each puzzle comes with a little extra bit of knowledge. Just click "Learn why this puzzle matters".

In the characters

The 27 playable dashers are all Australian animals and each character's power and quirk are inspired by
concepts from Turing's work:

Emu — relentless forward motion (Turing's unstoppable curiosity)
Wombat — burrow-dodge (evasion, steganography)
Echidna — spiny defence (cryptographic hardening)
Cassowary — apex predator speed (Colossus, the world's first electronic computer)

The "special" dashers can only be unlocked by solving enough treasure puzzles — a direct nod to
the idea that Turing's deeper insights were hidden behind layers of prior work.

In the Game engine

The game's lifecycle is modelled as a real Turing Machine (see Architecture below).
States are labelled q_*, input symbols σ_*, and every transition is written to a tape
with a head that advances R, stays S, or — on a level abort — rewinds L.
This isn't just a metaphor: the implementation is a literal δ(q, σ) → (q′, dir) transition table.

┌─────────────────────────────────────────────────────────────────────┐
│  Browser                                                            │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  game.js  (core)                                             │   │
│  │                                                              │   │
│  │   Run loop / input                                           │   │
│  │        │                                                     │   │
│  │        │  sendFlow(σ_*)        ┌─────────────────────────┐   │   │
│  │        ├─────────────────────► │   game-state.js         │   │   │
│  │        │  ◄── state flags ──── │                         │   │   │
│  │        │                       │   Turing Machine        │   │   │
│  │        │                       │   Q  states  (q_*)      │   │   │
│  │        │                       │   Σ  symbols (σ_*)      │   │   │
│  │        │                       │   δ  transition table   │   │   │
│  │        │                       │   tape[]  head ptr      │   │   │
│  │        │                       └─────────────────────────┘   │   │
│  │        │                                                      │   │
│  │        ├── Puzzle pick & dedup ──► puzzle-tracker.js          │   │
│  │        │                               │                      │   │
│  │        │                          puzzle-filter.js            │   │
│  │        │                               │                      │   │
│  │        │                          puzzle-data.js              │   │
│  │        │                          ├── questions-easy.js       │   │
│  │        │                          ├── questions-medium.js     │   │
│  │        │                          └── questions-hard.js       │   │
│  │        │                                                      │   │
│  │        ├── Three.js + Canvas render                           │   │
│  │        │        └── terrain-styles.js                         │   │
│  │        │                                                      │   │
│  │        └── Config reads                                       │   │
│  │             ├── character-config.js                           │   │
│  │             ├── game-data.js                                   │   │
│  │             └── game-settings.js                              │   │
│  │                                                               │   │
│  │  game-ui.js ──ctx callbacks──► game.js                        │   │
│  └──────────────────────────────────────────────────────────────┘   │
│                                                                     │
│  index.html  (loads all modules via <script> tags)                  │
└─────────────────────────────────────────────────────────────────────┘
         ▲
         │  served by
┌────────┴────────┐
│  Nginx (Docker) │
│  docker-compose │
└─────────────────┘

Best Google AI Usage

I'm also submitting for Best Google AI Usage.

I'll be honest: I'm much more comfortable building systems and writing backend code than designing beautiful interfaces.

One of the challenges during this project was figuring out how to make Dawn Dashers feel cohesive visually. I had a rough idea of the atmosphere I wanted—an Australian treasure-hunting adventure, but translating that into colours, layouts, typography, and UI design isn't my strongest skill.

That's where Google Stitch helped.

I used Stitch to explore rapidly:

UI layouts and screen structure
Menu and HUD designs
Colour palettes
Typography combinations
Visual hierarchy
Overall art direction

What impressed me most was how easy it was to iterate. Instead of spending hours moving elements around in a design tool, I could describe the feeling I wanted and quickly generate multiple directions to evaluate.

For example, I started with a fairly generic arcade-style look, but through a few iterations in Stitch, I landed on a much stronger visual identity built around:

Warm desert colours
Treasure-map inspired UI
Gold accents
Weathered parchment styling
Adventure-game aesthetics

Those explorations directly influenced the final design language of the game.

I also used Gemini extensively during the design phase.

One challenge was incorporating Alan Turing-inspired puzzles without making the game feel like a classroom exercise. I wanted puzzles based on logic, patterns, and computation, but they also needed to feel like they belonged in an Australian treasure-hunting adventure.

Gemini helped me brainstorm and refine puzzle concepts such as:

Pattern recognition challenges
Binary switch puzzles
Signal routing mechanics
Treasure clues tied to Australian locations and wildlife
Turing-inspired logic challenges that could be solved quickly during gameplay

For example, I used Gemini to take abstract puzzle ideas and re-theme them into Australian contexts, turning generic logic puzzles into clues involving lighthouses, Outback landmarks, wildlife, and hidden Sun Fragments.

The combination of Stitch and Gemini helped bridge two areas where I typically spend a lot of time: design exploration and content creation. Instead of starting from a blank page, I could rapidly iterate on ideas, evaluate options, and focus more of my time on building and polishing the game itself.

The AI tools didn't replace the creative decisions—they helped me reach better ones faster.

As a solo developer, having a tool that could help bridge the gap between "I know what I want it to feel like" and "I know how to design it" was incredibly valuable. It let me spend more time building gameplay while still ending up with a much more polished visual experience.

Google Stitch didn't replace the design decisions—it helped me discover and refine them much faster.

Happy Dashing !!!

Thanks for checking out Dawn Dashers 🌅

It was a lot of fun combining the June Solstice, Australian landscapes, treasure hunting, arcade runners, and a small nod to Alan Turing into one adventure.

Is Zero Trust Enough for Agentic Systems?

ujja — Tue, 02 Jun 2026 13:45:15 +0000

I’ve always had a soft spot for authentication systems.

About seven years ago, I started working on auth, and something just clicked. What began as login flows slowly turned into a deeper curiosity about identity, permissions, and how systems decide who gets to do what.

Over time, I’ve worked with tools like Keycloak, Auth0, Okta, and Ping Identity. Different platforms, same core idea kept showing up:

Never trust. Always verify.

For a long time, that felt like the finish line.

Lately, though, it’s starting to feel more like the starting point.

The moment systems stop responding… and start acting

During a recent hackathon, I built something called PlanetLedger. The idea was simple: upload your bank statement to see your environmental impact.

But under the hood, it didn’t behave like a typical app.

An upload didn’t just return a response. It kicked off a series of actions. First, it parsed transactions. Then, it categorised vendors. Next, it calculated a score. It also generated insights and triggered notifications. Finally, it updated a memory timeline for future runs.

All of that started from a single call:

await openClawChainedTrigger(session.user, previousScore);

Which quietly unfolded into:

transactions_uploaded → score_calculated → insights_generated → score_improved

At some point while building this, I realised something had changed.

This wasn’t a request-response system anymore.

It was a system that kept acting.

Where Zero Trust fits perfectly… and where it doesn’t

From a security perspective, I did everything by the book.

Every API route checks whether the agent is allowed to perform an action:

export function canPerform(scopes, resource, action) {
 const required = FGA_RULES[resource]?.[action];
 return required ? scopes.includes(required) : false;
 }

Scopes are tightly defined. Every action is verified. Nothing runs without permission.

If you look at this through a Zero Trust lens, it’s solid.

And yet, the most interesting problems I ran into had nothing to do with access.

They showed up after access was granted.

The real question isn’t “can it act?” — it’s “should it keep acting?”

Take something as simple as a high-impact alert:

export async function highImpactAlert(event) {
 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,
 });
 }
 }

Everything here is valid.

The user is authenticated. The system has permission. The action is allowed.

But there’s a more subtle question hiding underneath:

Should this alert be triggered right now?

Because that depends on things Zero Trust doesn’t see.

Maybe the score calculation was slightly off. The categorisation step earlier in the pipeline may have misfired. Maybe the context wasn’t complete yet.

Each step is correct individually.

But the outcome might still be… wrong.

When valid steps create questionable behaviour

One of the most interesting things about the OpenClaw pipeline was how easy it was to compose behaviour.

You can attach multiple workflows to the same event:

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

On their own, these are harmless.

One generates insights. The other sends alerts.

But together, they begin to shape how a user interprets their financial behaviour. Add weekly reports, detect patterns, and make recommendations. Then, the system starts to influence decisions.

And that’s where things get tricky.

Because even if every individual step is valid, the overall direction can drift.

Zero Trust doesn’t track that. It validates moments, not trajectories.

Intent is where things start to slip

PlanetLedger uses a RAG layer to generate insights grounded in user data:

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

This works surprisingly well most of the time.

But occasionally, you’ll see something slightly off. A recommendation that technically makes sense but doesn’t quite match what you’d expect. A pattern that’s overemphasised. A suggestion that feels a bit… disconnected.

Nothing is broken.

But something feels misaligned.

That’s the gap.

Zero Trust ensures the system is allowed to act. It doesn’t ensure the system is acting with the right intent.

The part that surprised me: drift

The more I worked with chained workflows, the more I noticed this subtle effect.

If something is slightly off early in the pipeline — say, a categorisation edge case — that error doesn’t stay isolated. It propagates.

It affects scoring. Which affects insights. Which affects alerts. Which affects what the user sees.

By the time it surfaces, it’s no longer obvious where it started.

Everything along the way was technically valid.

But the outcome feels wrong.

That’s drift.

And it’s not something traditional access control is designed to catch.

So what actually helps?

I didn’t sit down with a framework for this. Most of these ideas came from trying to make PlanetLedger behave more predictably.

One thing that helped was thinking beyond request-level authorisation.

Because the pipeline continues after the initial API response, decisions are being made in a flow, not a single moment. That means authorisation needs to become aware of state, timing, and sequence — not just whether a token is valid.

Another thing that made a difference was leaning into deterministic rules where it mattered. The scoring system, for example, is intentionally simple and explainable. Not because an LLM couldn’t do it, but because predictability is a form of control.

The structure of OpenClaw itself also acts as a constraint. It’s deliberately minimal — no retries, no replay, no distributed guarantees. At first, that feels like a limitation, but it actually forces the system to operate within clear, bounded behaviour. It can only do what the registered workflows define.

Logging was another area that evolved quickly. Moving from plain logs to structured outputs made it easier to trace what happened. But even that surfaced a deeper need: understanding why a decision was made, not just what happened.

And then there’s step-up.

In traditional systems, step-up authentication is about verifying identity at critical moments. But in systems like this, identity isn’t usually the weak point. The question isn’t “is this really the user?”

It’s “Should this decision go through?”

That shift—from checking identities to validating decisions—looks small. But it changes how you make safeguards.

What this starts to look like in practice

After building something like PlanetLedger, the architecture stops being just about access control.

Zero Trust still sits at the base, making sure only the right actors can do the right things.

But on top of that, you start layering systems that understand behaviour over time. Systems guide actions. They spot patterns and notice when things feel off. Sometimes, they bring a human back in when the stakes are high.

None of these replaces Zero Trust.

They fill in the gaps that it was never designed to cover.

Final thought

Zero Trust is still essential.

Without it, systems like PlanetLedger wouldn’t hold up for a second.

But once systems move from simply responding to requests to continuously making decisions…

Trust stops being something you verify once.

It becomes something you evaluate, quietly and continuously, across everything the system does.

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.

DEV Community: ujja

I Love Dogs, But Dogs Scare Me — So I Built Pawsitive with Gemini 🐾.

What I Built

Demo

How I Built It

Making Pip feel alive

🧠 The Gemini Experiment

Private on-device fallback with Gemini Nano

What amazed me about the private mode

Prerequisites for private on-device analysis

The Learning Journey

🐕 The Owner Perspective

Testing the Safety Net

Why I Built It

🏆 Prize Category: Best Use of Google AI

🔮 Giving Pip a Voice with ElevenLabs

What's Next?

Turning Ayurveda’s Six Rasas Into CSS Art

Inspiration

The CSS Art

Making Food Without Food Images

Six Handcrafted Taste Guides

Making CSS Feel Less Like CSS

CSS Art With a Purpose

84 Dishes Instead of Six

The Technical Side

Accessibility Still Applies to CSS Art

What I Learned

Demo

ujjavala / rasa

Rasa — The Tongue Map of India

Why this project exists

What's Next?

Designing a Landing Page That Feels Like Opening a Food Journal

What I Built

The Landing Page Is the Beginning, Not the Destination

Why a Tongue?

From Landing Page to Field Journal

Meet the Guides

The Notebook

Designing for Accessibility From the Start

Motion With Meaning

The Visual Language

Technical Stack

What I Enjoyed Most

What I Would Improve Next

Demo

Source Code

ujjavala / rasa

Rasa — The Tongue Map of India

Why this project exists

Final Thought

You Know What's Worse Than Not Being Able to Log In?

It Started With Two User Pools

The Tiny Timing Window

Cognito Says, "I've Seen This Email Before"

Everything Looked Fine... Until It Didn't

Enter Sentry

The Fix Was Simpler Than the Investigation

The Weird Scenario Was the Important One

The Interesting Part Wasn't Actually Cognito

And That's What Made This Bug So Sneaky

You Know What Happens When There's a Bug in Authentication? Absolutely Nothing.

Everything Stops

A Rollout We Thought Was Perfect

Stop Looking at Logs. Watch People.

The Smallest Bug with the Biggest Impact

The Lesson Wasn't About e.preventDefault()

Final Thoughts

Passion Atlas: A Living Map of Human Curiosity

What I Built

Introducing Passion Atlas

Passion Genome: Your Curiosity Fingerprint

The Passion Butterfly Effect

Curiosity Wormholes

Preserving Human Stories

How I Built It

Passion Extraction Agent

Curiosity Graph Agent

Discovery Agent

The Lesson Wasn't About `e.preventDefault()`