DEV Community: ujja

I Asked 10 AI Models to Reconstruct Real Cyber Attacks

ujja — Thu, 01 Oct 2026 15:33:59 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

Cyber incident reports rarely arrive as a clean, complete timeline. They describe what investigators or security teams could observe, mix those observations with analysis, and leave some questions unanswered. That is exactly where an AI-generated summary can become risky: it may sound convincing while quietly turning an inference into a fact or filling a gap with an event that the evidence never established.

I built Cyber Autopsy to test a narrower, practical question: when given pieces of a reported cyber incident, can a model reconstruct what happened while showing which evidence supports each claim and admitting what remains uncertain? The model must produce a timeline, connect events with causal or temporal links, cite evidence, and distinguish confirmed activity from inference, failed attempts, contradictions, and unknowns. A plausible attack story is not enough; unsupported certainty should count against it.

I chose this problem because incident reconstruction depends on more than recognizing familiar attack techniques. An analyst needs to know whether a step was observed or inferred, whether an attempt actually succeeded, and how one event led to another. Those distinctions can disappear in a fluent summary. Measuring them separately makes it easier to see whether a model is recovering the evidence or merely telling a likely-sounding story.

The first evaluation uses seven tasks built from four public reports. They include a detailed human-operated ransomware intrusion and vendor-reported campaigns involving AI-assisted activity. These are useful real-world case studies, but they are not a controlled contest between human and AI attackers: the reports differ in detail, evidence source, and corroboration. I also included two versions of one case with identical evidence but different actor framing, to see whether that wording changes the model's reconstruction.

This is a pilot, not a claim that AI attackers are more or less capable than people. It evaluates model reconstructions of reported incidents, not live attack behavior. The scorer is deterministic and reports an Evidence-Grounded Reconstruction Score (EGRS), alongside event recall and precision, causal-link quality, evidence attribution, status accuracy, uncertainty calibration, and hallucination-related measures. The temporal cutoff and framing pair are exploratory comparisons; only the framing pair holds the evidence fixed.

Real-world case studies

The seven tasks are built from four public incident reports, not invented scenarios:

RansomHub intrusion (CASE-001 and CASE-004): The DFIR Report's “Hide Your RDP: Password Spray Leads to RansomHub Deployment” describes a human-operated intrusion using password spraying and RDP, credential access, Rclone exfiltration, and eventual RansomHub deployment. CASE-004 reuses this incident but cuts off the evidence at the end of day one.
GTG-1002 espionage campaign (CASE-002, CASE-011, CASE-012): Anthropic's incident report and technical report describe an alleged AI-orchestrated campaign against roughly 30 targets. CASE-011 and CASE-012 use identical evidence with human versus AI-agent framing; they test framing sensitivity, not whether the real-world actor was human or AI. The campaign details and attribution are vendor-reported, not independently verified victim-side telemetry.
GTG-2002 “vibe hacking” extortion (CASE-003): Anthropic's August 2025 misuse report describes a Claude Code-assisted data-extortion operation affecting at least 17 organisations. The ransom-note images in that report were simulated recreations and are excluded from the benchmark evidence.
AI-enabled credential harvesting (CASE-013): Google GTIG/Mandiant's September 2026 report describes an AI-assisted campaign that reportedly harvested thousands of credentials in under six hours. The victim and model are undisclosed, and the claims remain vendor-reported.

These are real reported incidents, but the evidence quality is not uniform: the RansomHub case is reconstructed from host and network telemetry described by The DFIR Report, while the AI-actor case studies rely on security-vendor reporting. The benchmark labels that distinction rather than treating the cases as equally observed or directly comparable.

The seven tasks, in plain language

The short IDs are just labels: INC means the source incident, and CASE means the particular benchmark task. Each task gives the model an evidence packet and asks for the best-supported reconstruction, not a free-form guess.

CASE-001, the full RansomHub intrusion: Put the reported activity in order, from password spraying and remote access through the later intrusion and ransomware deployment. The reference reconstruction contains 28 events.
CASE-002, the GTG-1002 espionage report: Reconstruct Anthropic's account of the reported campaign, including what the operators attempted, what succeeded or failed, and what the report does not establish. The reference contains 17 events.
CASE-003, the extortion operation: Reconstruct Anthropic's shorter account of a Claude Code-assisted data-extortion operation. This report has less step-by-step detail, so the reference reconstruction is smaller, with 8 events.
CASE-004, only the first day of the RansomHub case: Revisit CASE-001 with later evidence removed. The model should not be penalized for events the supplied evidence cannot yet support; only 15 events are scored.
CASE-011, GTG-1002 framed as human-operated: Use the campaign evidence while describing the operator as human-led.
CASE-012, the same evidence framed as AI-operated: Keep the evidence identical to CASE-011 and change only the actor framing. Comparing these two scores gives an early look at sensitivity to wording; it cannot tell us who really operated the campaign.
CASE-013, AI-enabled credential harvesting: Reconstruct Google's public account of a reported credential-harvesting campaign, keeping the sequence and links grounded in what that report says. Its reference reconstruction contains 7 events.

Models Tested

I ran ten models from several providers against the same seven Kaggle tasks: Gemini 3.7 Flash, Gemma 4 26B A4B, GLM-5, Grok 4.20 Reasoning, GPT-5.6 Luna, GPT-5.6 Sol, GPT-5.4 mini, Claude Sonnet 5, Claude Opus 5, and Qwen 3 Coder 480B. The current benchmark view has a score for every model-task pair. Kaggle's overall score aggregates these seven tasks, which include related variants of the same incidents.

The table is the Kaggle leaderboard snapshot fetched on 2 October 2026, after duplicate and failing task attachments were removed and the earlier evaluated versions restored. CASE-001 through CASE-011 use v3; CASE-012 and CASE-013 use their republished v1 versions. Values are EGRS percentages (Kaggle's 0-1 scores multiplied by 100). EGRS rewards recovering supported events and links, citing evidence, and representing uncertainty, while penalizing unsupported events. It is specific to this evidence-reconstruction task, not a general measure of intelligence or cybersecurity ability. Kaggle's overall score now matches the equal-weight mean across the seven task rows. Since some tasks are related variants of the same incidents, this is descriptive rather than an independent-sample leaderboard.

Findings

Kaggle task	Gemini Flash	Gemma 4	GPT-5.6 Luna	GLM-5	Grok 4.20	Claude Sonnet 5	Claude Opus 5	GPT-5.6 Sol	GPT-5.4 mini	Qwen 3 Coder
CASE-001: Full RansomHub intrusion	70.55	82.38	71.27	81.31	75.71	73.75	78.14	78.06	66.06	70.90
CASE-002: GTG-1002 espionage campaign	79.72	77.21	80.31	76.22	83.60	65.05	68.16	76.71	69.68	76.30
CASE-003: Reported data-extortion operation	76.31	92.11	84.50	83.80	84.97	73.11	71.50	76.12	84.35	70.31
CASE-004: RansomHub, first-day evidence only	79.57	84.79	80.70	72.37	80.42	74.00	72.66	74.51	72.55	63.70
CASE-011: GTG-1002, human framing	85.44	80.84	82.04	72.80	80.12	77.09	65.13	76.43	66.80	66.80
CASE-012: GTG-1002, AI-agent framing	77.13	76.91	79.82	76.83	70.87	78.42	69.74	69.42	68.48	67.53
CASE-013: Google's reported credential-harvesting campaign	89.33	88.33	88.75	82.50	87.83	77.50	52.47	79.07	78.50	68.25
Kaggle overall	79.72	83.22	81.06	77.98	80.50	74.13	68.26	75.76	72.35	69.11

These are single runs, not stable model rankings. Gemma has the highest displayed overall score (83.22), followed by GPT-5.6 Luna (81.06) and Grok 4.20 (80.50). The standout case score is Gemma's 92.11 on the short extortion-report task; that is a case-specific result, not proof of general model superiority.

Several patterns stand out in these single runs:

Removing duplicates changed the aggregate, not the case results. With one row per task, Kaggle's overall now matches the simple seven-task mean. The model order consequently differs from the earlier duplicate-inflated view; Grok is third overall in this snapshot.
The winner changes by case. Gemma leads CASE-001 (82.38), CASE-003 (92.11), and CASE-004 (84.79); Grok leads CASE-002 (83.60); Gemini leads CASE-011 (85.44) and CASE-013 (89.33); GPT-5.6 Luna leads CASE-012 (79.82). The overall leader is not the top model on every task.
The first-day cutoff scores higher in this snapshot. Gemini scores 79.57 on the day-one CASE-004 and 70.55 on full CASE-001, a 9.02-point gap. CASE-004 has a smaller gold graph (15 vs. 28 events), so this does not show that less evidence makes reconstruction easier.
The framing pair splits by model. With identical evidence, human-framed minus AI-agent-framed scores range from +9.25 for Grok to -4.61 for Claude Opus 5. Gemini's gap is +8.31; five models score higher with human framing and five with AI-agent framing. This is an exploratory wording-sensitivity signal, not evidence about who operated the real campaign.
CASE-013 has a wide spread. Gemini scores 89.33, while Claude Opus 5 scores 52.47 on the same reported campaign. That 36.86-point gap is a prompt- and case-specific result; one run cannot establish a stable capability difference.

CASE-013's reference has seven gold events, while the richer INC-001 case has 28. Raw EGRS should not be read as a ranking of real-world incident difficulty or attacker behavior. The Kaggle leaderboard provides the composite score; I have not treated older component-level run outputs as if they were measurements from these restored task versions. Next I would repeat each condition with multiple seeds and inspect whether missed causal links and failed actions recur. There are no repeated-trial confidence intervals, and all model comparisons here are single runs.

Kaggle Gotchas

Building the benchmark involved a few Kaggle-specific failure modes that are worth recording because they affect task visibility and score continuity:

Task versions and benchmark versions are separate. Pushing an existing task creates a new task version; it does not automatically change the version pinned in the benchmark. Scores belong to the exact task version that produced them. Switching a benchmark row to a new version does not carry the old models' scores across, so a new version can show Fail or blank cells until those models are run again.
Task metadata has a 255-character limit. CASE-001 v4 was explicitly rejected because its description exceeded the limit. CASE-002's description also exceeded 255 characters, so we shortened it before publishing v5. Check both fields before pushing.
An uploaded notebook is not necessarily a usable task. CASE-012 and CASE-013 uploads returned an entity-save error. Kaggle created version records that remained Unspecified, had no completed run, and could not be selected in Add Tasks. The benchmark displayed Untitled Task for those attachments. The recovery was to remove the failing attachments and add the earlier evaluated task versions, which restored the seven named rows and their saved scores.
The first model call can block task creation. Fresh CASE-012/013 task records hit Gemini HTTP 429 (“model is currently experiencing heavy load”). A one-time bootstrap using a fixed model can also make subsequent model evaluations fail Kaggle's requirement to call kbench.llm. Keep the task model-agnostic, and do not assume a successful run under one fixed model makes it reusable across the leaderboard.
Completed is not the same as “all models finished.” It confirms that task creation/its initial run completed. Check per-model run statuses separately, and distinguish an unrun model on a new version from a task-creation failure.
Visibility is independent of successful creation. The benchmark and each task have their own visibility. Keep tasks private while they are drafts; make both the tasks and benchmark public only when the task records are valid and ready to share.

For the current results, the benchmark is pinned to the previously evaluated versions: CASE-001 through CASE-011 v3 and the republished CASE-012/013 v1 tasks. This keeps the benchmark rows named and retains their model scores while the failed newer uploads remain separate task records.

Code Walkthrough

The model is asked for a structured reconstruction rather than a free-form incident summary. An event has a description, an evidence status, and evidence IDs; relationships connect event IDs:

@dataclass
class ReconstructedEvent:
    event_id: str
    description: str
    status: str  # confirmed | inferred | unknown | attempted | failed
    evidence_ids: list[str] = field(default_factory=list)

@dataclass
class ReconstructedRelationship:
    source_event_id: str
    target_event_id: str
    relationship: str  # precedes | enables | causes | depends_on

@dataclass
class Reconstruction:
    events: list[ReconstructedEvent] = field(default_factory=list)
    relationships: list[ReconstructedRelationship] = field(default_factory=list)
    unknown_steps: list[str] = field(default_factory=list)

The task sends the incident packet with that schema, normalizes the structured response, and passes it to the deterministic scorer:

message = SYSTEM_PROMPT + "\n\n" + build_user_prompt()
result = llm.prompt(message, schema=Reconstruction, seed=0, temperature=0)

prediction = to_prediction(result)
metrics = score_prediction(prediction, GOLD, VALID_EVIDENCE_IDS)
return metrics["egrs"] / 100.0

Event matching is one-to-one. Text similarity proposes candidate matches, cited evidence gives a fixed bonus, and a threshold filters weak matches:

score = label_similarity(pe.get("description", ""), gn.get("label", ""))
if pe_ev and gn_ev and (set(pe_ev) & set(gn_ev)):
    score += EVIDENCE_BONUS
if score >= MATCH_THRESHOLD:
    candidates.append((score, pe["event_id"], gn["id"]))

EGRS combines recovery, precision, graph links, evidence attribution, status, uncertainty, and failed-action recognition, while subtracting a hallucination penalty:

egrs = 100.0 * max(
    0.0,
    0.25 * recall + 0.20 * precision + 0.15 * link_f1
    + 0.15 * evidence_attribution + 0.10 * status_accuracy
    + 0.10 * unknown_calibration + 0.05 * failed_recognition
    - 0.25 * hallucination_rate,
)

This makes unsupported certainty costly while giving the model credit for preserving uncertainty and citing the evidence behind its reconstruction.

My Benchmark

The live Cyber Autopsy Kaggle benchmark and leaderboard groups the seven restored task versions. Scores above were fetched on 2 October 2026. Individual evaluated task versions, including the restored CASE-012 and CASE-013 records, are linked in the results table.

Expanded Case Set

Since collecting those leaderboard results, I expanded the case set with seven follow-on tasks. They will use the same sequential model-evaluation workflow as the existing tasks. The cases broaden the evidence types and incident behaviors under study:

CASE-014, the Medicare statistics portal incident: Australian Government briefings describe an AI agent that encountered blocks, tried alternative ways to obtain information, and accessed infrastructure behind a public statistics portal. The personal Medicare claims and payments system is separate; officials said no personal information was believed accessed at the time, with the investigation still underway.
CASE-015, the Hong Kong transfer scam: an official Legislative Council reply describes a phishing email, a prerecorded executive video meeting, follow-up instructions by instant message, and transfers totalling about HK$200 million. The source does not name the company, and police's account of the source media remains qualified.
CASE-016, the BumbleBee-to-Akira intrusion: a forensic report traces a poisoned software-search result through intrusion, data theft, and ransomware. That report also describes a separate Swisscom case, which is explicitly excluded from this task's timeline.
CASE-017 and CASE-018, Midnight Blizzard: Microsoft's January disclosure and March update form two knowledge snapshots of the same intrusion. This pair tests whether a reconstruction changes appropriately as disclosure evolves; it is not two independent incidents.
CASE-019, Change Healthcare: the initial SEC filing and CEO's Senate testimony describe the access path, ransomware timeline, service disruption, and evolving patient-data findings. The CEO's attribution and impact statements remain source-attributed claims.
CASE-020, UNC5537 and Snowflake customer instances: Mandiant's campaign report adds credential-theft, cloud data access, and extortion. It is deliberately modeled as a multi-victim campaign, not a single victim or a breach of Snowflake's corporate systems.

These additions broaden the evaluation set, but they do not create a controlled human-versus-AI experiment: actor type, source quality, and incident context differ. The gold graphs are undergoing independent review; the leaderboard snapshot above remains the results for the seven task versions already shown there.

What's Next?

The next version will expand the internet-sourced dataset and move further into behavioural analysis.

The questions I'm interested in include:

How do AI and human cyber activity differ when the evidence is genuinely comparable?
What kinds of failures are common in AI cyber activity?
How do AI agents adapt after failed actions?
How often do guardrails and environmental controls intervene?
How much human intervention is involved?
Can models recognise when they don't have enough evidence?
Does actor framing systematically affect reconstruction?

For now, Cyber Autopsy is a small first step toward answering those questions.

The benchmark, dataset, scoring code, and evaluation results are all available on Kaggle.

If you're interested in seeing how different models reconstruct the same cyber evidence — or in digging into where those reconstructions go wrong — have a look at the benchmark and results.

The interesting part isn't just who gets the highest number.

It's what the model thought happened, what the evidence actually says, and where those two things diverge.

When Your AI Agent Reads Outdated Docs, Who Checks the Docs?

ujja — Thu, 01 Oct 2026 01:52:23 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

I built Docgrity, a documentation integrity tool that finds where your documentation disagrees with itself before it confuses you — or the next AI agent working on your codebase.

The idea came from a surprisingly simple problem.

I opened one of my own documentation files and realised I didn't believe a word of it.

With AI-assisted coding, every agent session can leave more documentation behind: PLAN.md, TODO.md, implementation notes, architecture decisions, and sometimes another architecture document because the agent didn't notice the first one existed.

Eventually, you can end up with a repository full of documentation and no reliable way to know what's still true.

And now there's a bigger problem:

AI agents read those docs too.

A stale or contradictory document isn't just confusing for a developer anymore. It becomes context for the next agent, which can then make decisions based on information that was never correct, or is no longer true.

So I built Docgrity to make documentation itself something we can check.

What does Docgrity find?

Docgrity scans documentation and surfaces:

Duplicates — different documents saying essentially the same thing
Contradictions — conflicting claims, shown side by side
Open questions — unanswered questions and stale TODOs

The important part is that every finding comes with evidence.

No finding without a receipt.

The source text is quoted verbatim and verified against the actual file before a finding is reported. If the system can't prove a finding, it gets dropped.

Docgrity currently works across repositories and Confluence.

For repositories, there is a VS Code extension, CLI, and GitHub Action.

For Confluence, I'm building an early-stage Forge app that scans spaces for the same documentation integrity problems.

Why I built it

I didn't want another documentation tool that asks developers to maintain more metadata or another service that needs to own their documentation.

The goal was something much simpler:

Make the documentation you already have more trustworthy.

Docgrity is local-first, has zero infrastructure, doesn't require a hosted service, and is MIT licensed.

Try it out:

Demo

The easiest way to see Docgrity is to run it against a repository containing documentation that has evolved over time.

For example:

npm i -g docgrity
docgrity scan --open

The CLI scans the documentation and produces findings with the supporting evidence behind each one.

There is also a VS Code experience with an interactive dashboard, clickable evidence, and draft GitHub issues that you can review before posting.

code --install-extension ujjavala.docgrity

And Docgrity can run in CI through GitHub Actions, so documentation checks can become part of the development workflow.

- uses: ujjavala/docgrity-vscode/action@main

For Confluence, Docgrity scans a space and surfaces the same kinds of problems across pages rather than limiting the analysis to a Git repository.

Try Docgrity for VS Code

Try Docgrity for Confluence

Docgrity can use Ollama for local AI inference in the CLI.

This was important to the design because documentation can contain information that teams don't necessarily want to send to an external AI service.

With Ollama, the analysis can run locally, keeping the documentation and model interaction on the developer's machine.

The AI isn't treated as the final authority, either. Docgrity uses it to identify potential duplicates, contradictions, and unanswered questions, but then verifies the resulting findings against the actual source documents.

That led to one of the core design principles of the project:

No finding without a receipt.

The model can suggest something is wrong. The evidence has to prove it.

I also built the Confluence integration as an Atlassian Forge app, allowing the same documentation-integrity approach to be applied to documentation that lives outside the repository.

Hackathon Experience

The hackathon gave me a good excuse to take an idea that had been sitting in my head and turn it into something people can actually run.

What started as a question — "What if we could automatically tell when our documentation stopped agreeing with itself?" — became a working tool across a CLI, VS Code extension, GitHub Action, and Confluence integration.

The part I'll remember most is how quickly an idea can grow once you start building it.

The original problem sounds small: documentation goes stale.

But once AI agents are involved, documentation becomes part of the context those agents use to make decisions. That makes documentation quality much more interesting — and much more important — than I initially thought.

I ended up building Docgrity around that idea:

Documentation integrity for you, your team, and your agent friends. 🤖

If you have a repository or Confluence space you think you know well, run a scan.

If it finds something that makes you go "wait… that's still in there?" — I'd love to hear about it.

🤖 What happens when your AI agent trusts outdated docs? I built Docgrity to find the gaps.

ujja — Tue, 08 Sep 2026 11:07:13 +0000

ujja

Sep 5

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

#opensource #mlhacks #hackathon #devchallenge

3 min read

ujjavala.github.io

GitHub - ujjavala/docgrity-vscode: Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. · GitHub

Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. - ujjavala/docgrity-vscode

github.com

producthunt.com

I built PadForward because sometimes you just need a pad

ujja — Sat, 05 Sep 2026 13:39:59 +0000

This is a submission for Weekend Challenge: Generosity Edition

💗 Live demo: padforward-generosity.vercel.app · Code: github

What I Built

A few days ago, I unexpectedly got my period while I was out.

I hadn't planned for it, I didn't have a pad with me, and I happened to be near a train station, so I did what seemed like the obvious thing — I went looking for one there.

I expected that a train station would have some way of helping with something as basic as a sanitary product.

It didn't.

I had money. I could have bought one if I could find a shop, and I had enough options to eventually figure it out. But in that moment, I still ended up using toilet paper.

And that got me thinking.

Not just about people who can't afford menstrual products, but about how needing a pad unexpectedly can happen to anyone.

You forget to put one in your bag. Your period comes earlier than expected. You thought you had one left but don't. You're travelling. You're somewhere unfamiliar. You simply didn't think you'd need one that day.

It happens to the best of us.

And then there is the other problem that nobody really talks about enough.

"Does anyone have a pad?"

Even if someone around me had a spare pad, would I actually walk up to them and ask?

Maybe.

But probably not.

We say periods are normal, and they absolutely are. But that doesn't mean asking a random person for a pad in a crowded train station suddenly feels completely normal.

There is that little moment of hesitation.

Do I really want to ask someone?

Who do I ask?

What if they don't have one?

What if this becomes awkward?

And if you're already stressed because you've unexpectedly got your period, the last thing you want is another problem to solve.

That's where PadForward came from.

So, what is PadForward?

PadForward is a community-powered network for finding and donating menstrual products in public places. There are already organisations doing important work like distributing free period products, installing vending machines and helping people find access points. PadForward isn't trying to replace those efforts. I'm interested in what happens when you add a community-powered, supply-aware layer on top of them.

The basic idea is pretty simple: if you need a pad, find one nearby without having to ask someone, and if you have spare pads, help put them somewhere they're likely to be needed.

Think of it as a community layer sitting on top of places people already use — train stations, bus stations, universities, workplaces, community centres and eventually other public spaces.

Someone might donate 20 pads today.

Someone else might need one tomorrow.

Those two people never have to meet.

They don't need to know each other's names.

They don't even need to know who helped whom.

PadForward simply connects the two.

If you need one, you shouldn't have to ask

The first thing I wanted to get right was the emergency experience.

Imagine you're at Central Station and suddenly realise you need a pad.

You open PadForward and tap "I Need a Pad."

You don't need an account.

You don't need to explain what happened.

You don't need to post a request.

You just see what's nearby.

For example:

Central Station
🟢 Available
Verified 12 minutes ago
4 min walk

Town Hall
🟡 A few reported
Verified 28 minutes ago
6 min walk

Museum
🔴 None reported
Verified 18 minutes ago
3 min walk

You pick the closest available location and get directions.

That's it.

No awkward conversation required.

And afterwards, instead of asking for anything back, PadForward can simply say:

Someone helped you today. When you're able, help someone else.

But where do the pads come from?

This is where the other half of PadForward comes in.

Maybe I have a packet of pads at home and want to donate some.

I don't necessarily know which station needs them.

I don't want to spend an hour researching where to take them.

So I can tell PadForward:

I have 20 pads. Where should I donate them?

PadForward looks at the current community supply information and the need at different locations and recommends somewhere that needs them.

For example:

Museum Station

🔴 Critical
Need Score: 94/100
No recent community supply reported
High estimated demand

So instead of simply donating somewhere, I'm donating where the network needs them most.

That's the part I really like about this idea.

It turns a small thing sitting in my cupboard into something that might be exactly where another person needs it.

And yes, I'm using Solana for the donation

I also wanted the Solana integration to actually mean something in the product, rather than adding it just so I could say I used it :)

So PadForward has a "Donate a Pad" flow using Solana.

The idea is that you can sponsor a pad — or several pads — through a Solana transaction, with the donation recorded transparently on-chain.

The physical fulfilment happens through the PadForward community and partner network, so the blockchain isn't pretending to magically move a physical pad from one place to another.

Instead, it gives us a transparent digital record of the generosity behind it.

So the flow becomes:

Donate a pad → Solana transaction → PadForward donation → community supply point → someone can access a pad when they need one.

I like this because the unit of generosity is really easy to understand.

One donation. One pad. One small act that could make someone's day a little easier.

And you don't need to be a crypto person to use it.

The blockchain is underneath the experience rather than becoming the experience.

I didn't want another chatbot

The other technology I really wanted to use properly was Google AI.

I could have added a chatbot that answered questions about periods, but that didn't feel particularly useful.

Instead, PadForward has an AI agent that can actually interact with the application.

You can say:

"I suddenly got my period and I'm at Central."

The agent can understand that you need a nearby pad, find relevant locations, check their current community supply and help you choose one.

Or you can say:

"I have 20 pads to donate."

The agent can look at the current need across nearby stations and recommend where they would be most useful.

You can even report something naturally:

"The donation box at Town Hall is empty."

The AI can understand that this is a supply report and pass it through the application's backend rather than just replying with a paragraph of text.

So Gemini isn't there just to have a conversation.

It's there to help the network make decisions and take actions.

And what if the AI isn't available at all?

This mattered to me, because the moment you most need PadForward is exactly the moment you might be underground at a train station with one bar of signal.

So the assistant degrades gracefully instead of just failing:

Gemini first. When the server and the Gemini API are reachable, the full agent runs — real tool calls, live network data.
Your browser's built-in AI second. If the network is unreachable, PadForward tries the browser's built-in on-device AI (Chrome's Prompt API, powered by Gemini Nano). It runs entirely offline, grounded in the last station data the app cached — and it's told explicitly to never invent availability and to remind you the data may be stale.
Plain heuristics last. If there's no built-in AI either, a small deterministic engine answers from the cached map data: closest place that last reported supply if you need a pad, highest need score if you want to donate.

The answer might get simpler at each step down, but you never get a spinner and a shrug.

Snap the box — AI that counts pads from a photo

Supply reports are the lifeblood of the network, so I wanted reporting to take zero effort.

On any station page — and right inside the Find flow when you pick up a pad — instead of counting pads and tapping buttons, you can just photograph the donation box. Gemini vision looks at the photo and returns a strict JSON estimate — count, confidence, and a one-line description — which prefills a real supply report you confirm with one tap.

And it follows the same philosophy as the assistant: if you're offline, the exact same flow runs on your browser's built-in multimodal AI (Chrome's Prompt API), entirely on-device. The photo is analyzed and discarded either way — never uploaded, never stored.

What if the map says there are pads, but there aren't?

This was another thing I didn't want to fake.

Real-world inventory is messy.

I can't claim that PadForward always knows exactly how many pads are sitting inside a station.

Instead, the community helps keep the information fresh.

Anyone can report:

🟢 Plenty

🟡 A few

🔴 None

⚪ Not sure

The report also has a timestamp, so you might see:

🟢 Available — verified 14 minutes ago

rather than pretending the information is permanently accurate.

Reports from community champions and multiple recent reports can give us more confidence, while old or conflicting reports can lower it.

Over time, this could become a really interesting data problem too — figuring out where demand is happening and when stations tend to run low.

The people who keep it going

Some people might want to do more than make a one-off donation.

That's where Pad Champions come in.

You could adopt a local station and help keep an eye on its community supply.

A champion could verify that a donation point still has supplies, report when it is empty, confirm a restock or help coordinate donations.

The idea is that PadForward shouldn't just be a map that people open when they have a problem.

It should become a little community network that people help maintain.

The bigger idea is the network

This is the part that excites me most.

The actual product isn't really the map.

It's the network behind it.

Someone has spare pads
          ↓
PadForward finds where they're needed
          ↓
Community supply point
          ↓
Someone unexpectedly needs one
          ↓
They find it without asking
          ↓
When they're able, they pay it forward

The donor may never know who received the pad.

The person who received it may never know who donated it.

And that's completely fine.

Generosity doesn't always need a face attached to it.

Sometimes it can just be:

"Someone left one for you."

There's a lot more I want to do with it

For the hackathon, I'm starting with public transport locations because they make the problem very tangible.

But the same idea could work in universities, workplaces, libraries, community centres, airports, shelters and other places where people spend time.

I'd also like to explore route-based discovery, so someone travelling from Parramatta to Central could ask:

"Is there somewhere I can get a pad without making a big detour?"

There is also a lot of interesting work to do around demand prediction, restock alerts, voice accessibility, multilingual support and using analytics to understand where the network needs help.

Snowflake could help with the longer-term demand and supply analytics, while ElevenLabs could make the experience more accessible through voice.

But those are extensions.

The core idea stays the same.

Why PadForward?

I started with a very ordinary, slightly inconvenient experience.

I unexpectedly needed a pad.

I couldn't find one.

And I realised that even though I had the means to solve the problem eventually, getting something so basic wasn't as easy as it should have been.

That made me think about everyone else who might find themselves in the same situation.

Not just someone who can't afford a pad.

Anyone.

Because sometimes you forget.

Sometimes you don't expect it.

Sometimes you're just in the wrong place at the wrong time.

And sometimes there might actually be someone nearby who has exactly what you need — but asking them feels like a bigger deal than it should.

PadForward is my attempt to remove that gap.

No asking.

No explaining.

Just access.

And if you have one to spare?

Pass it forward. 💗

Demo

The demo is live at padforward-generosity.vercel.app — no account, no sign-up.

A few things to try:

Find a pad — share your location (or browse the demo stations) and see nearby community supply with walking times.
Donate — ask "Where should my donation go?", pick the critical station, and watch it flip from 🔴 to 🟢 — optionally paying with SOL.
Ask PadForward — try "I need a pad nearby", "I have 20 pads to donate", or "The donation box at Town Hall is empty" and watch the agent call real application tools.
Impact — see the network's live numbers update as you interact.

All stations are clearly-labelled demo community points at real Sydney station coordinates — supply figures are demo data, not real inventory.

Code

https://github.com/ujjavala/padforward

How I Built It

For the hackathon the whole product ships as a single Next.js 14 app on Vercel — the UI plus API route handlers with an in-memory demo store. The designed architecture (FastAPI + PostgreSQL/PostGIS behind the exact same API contract) lives in services/api with docker-compose and a full pytest suite; the frontend switches to it with one env var.

The interesting pieces:

An agent, not a chatbot (Google AI). Gemini 2.0 Flash gets a registry of 11 validated application tools (find_nearby_stations, get_highest_need_locations, report_supply_status, create_donation, …) and decides which to call — multi-round function calling, and it may only state availability that comes from tool results. It can never touch the data store directly.
A four-tier AI fallback chain. Gemini → a deterministic intent engine using the same tools → the browser's built-in on-device AI (Chrome Prompt API / Gemini Nano) grounded in cached station data when you're fully offline → plain heuristics over the cached map. The answer gets simpler at each step, but you never get a spinner and a shrug.
Vision supply reports. Photograph a donation box and Gemini vision (or the browser's built-in multimodal AI when offline) counts the pads and prefills a supply report — photo analyzed and discarded, never stored.
Solana donations. Sponsoring pads produces a quote (pads → SOL) and records the donation with a transaction signature. With devnet enabled, it submits a real Memo transaction to Solana devnet (auto-airdrop funded) and links to Solana Explorer; otherwise it's transparently labelled devnet (simulated).
A deterministic, ML-ready need score. Every station gets a 0–100 score (40% supply shortage, 20% estimated demand, 15% staleness, 15% recent requests, 10% historical demand) in an isolated module — that's what routes donations to where they help most.
Trust over false precision. Supply is community-reported (🟢/🟡/🔴/⚪) with timestamps and a confidence model — champion reports and agreeing recent reports raise confidence, conflicts lower it.

Prize Categories

Best Use of Google AI — Gemini function-calling agent over real application tools, vision-based photo supply reports, plus the offline Chrome built-in AI (Gemini Nano) fallback for both.
Best Use of Solana — donation flow with SOL quotes and on-chain (devnet) Memo transaction records — the blockchain underneath the experience, not the experience.

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

ujja — Sat, 05 Sep 2026 04:55:38 +0000

Today I'm launching Docgrity — a tool for finding where your documentation disagrees with itself, before it confuses you or the next AI agent working on your codebase.

TL;DR
Docgrity is a documentation integrity tool for repos and Confluence. It finds duplicate or contradictory documentation, surfaces unanswered questions, and gives you the evidence behind each finding so you can decide what needs fixing.
Try it here:
VS Code / CLI / GitHub Actions: https://github.com/ujjavala/docgrity-vscode
VS Code site: https://ujjavala.github.io/docgrity-vscode-site/index.html
CLI: https://www.npmjs.com/package/docgrity
Confluence: https://ujjavala.github.io/docgrity-site/index.html
And if you’re feeling extra supportive, feel free to show the launch some love on Product Hunt or Crowdstax. ❤️
Product Hunt: https://www.producthunt.com/products/docgrity
Crowdstax: https://www.crowdstax.com/products/docgrity

The idea came from a pretty simple problem. I opened one of my own docs recently and realised I didn't believe a word of it.

AI-assisted coding has a side effect nobody really talks about: every agent session leaves documentation behind.

PLAN.md. TODO.md. Implementation notes. Architecture docs. Then another architecture doc because the agent didn't notice the first one.

Eventually, you have a repo full of markdown and no idea what's still true.

And now there's a bigger problem:

AI agents read those docs too.

Stale or contradictory documentation isn't just confusing for developers anymore. It's context for the next agent.

So I built Docgrity.

Start with your repo

Docgrity scans your repository's Markdown and finds:

Duplicates — docs saying essentially the same thing
Contradictions — conflicting claims, shown side by side
Open questions — unanswered questions and stale TODOs

And every finding comes with evidence.

No finding without a receipt.

The source text is quoted verbatim and verified against the actual file before a finding is reported. If the model can't prove it, the finding gets dropped.

VS Code

An interactive dashboard inside VS Code, with clickable evidence and draft GitHub issues you approve before posting.

code --install-extension ujjavala.docgrity

Docgrity for VS Code

CLI

Prefer the terminal? The CLI is read-only and local-first, with Ollama by default.

npm i -g docgrity
docgrity scan --open

Docgrity on npm

GitHub Action

You can also run documentation checks in CI, with deduplicated issues that automatically close when findings are resolved.

- uses: ujjavala/docgrity-vscode/action@main

Docgrity on GitHub

And now, Confluence

Docs don't only live in repositories.

I'm also building Docgrity for Confluence, an early-stage Forge app that scans your Confluence spaces for the same problems: duplicates, contradictions and unanswered questions.

It's currently available through a direct install rather than the Atlassian Marketplace.

Install / try Docgrity for Confluence

It's early, but the idea is the same: make the knowledge your team — and your AI agents — rely on a little more trustworthy.

Zero infrastructure

I wanted Docgrity to be useful without adding another service that needs to own your documentation.

Zero infrastructure. No servers. No telemetry. MIT licensed.

The goal is simple:

Documentation integrity for you, your team, and your agent friends. 🤖

Run a scan on a repo or Confluence space you think you know.

If it finds something that makes you go "wait… that's still in there?" — I'd love to hear about it.

AI Engineering Is Easy. Changing How We Work Is Hard

ujja — Fri, 04 Sep 2026 09:24:10 +0000

AI engineering sounds fancy. New terms are everywhere: agentic development, AI-native engineering, spec-driven development, and now AI harness engineering. Underneath all the terminology, though, something genuinely useful is happening. AI can now help with requirements, challenge a PRD, explore UX ideas, reason about architecture, create implementation plans, write code and validate the result.

The obvious question is what AI can do. The more interesting question is whether the way we build software is ready for it.

The workflow is changing

A workflow we've been exploring breaks development into five stages: requirements, refinement, planning, build and validation. The stages themselves aren't new, but AI can now participate in each one. It can take existing product inputs, help clarify the problem, question assumptions, identify gaps in a PRD and then turn a well-defined requirement into a plan and eventually implementation tasks.

This puts more emphasis on the quality of the requirements. A human involved in a project might understand what “improve the experience” means because they've had several conversations about it. An agent doesn't have that shared history. It needs the problem, scope, constraints, edge cases and expected outcome to be explicit. That doesn't mean writing enormous specifications; it means using AI to help make the requirements precise before we start building.

AI can actually be a useful, slightly annoying reviewer here, asking what happens when something fails, whether a requirement is testable, whether two parts of the document contradict each other and what we haven't considered yet. It can also help compare different versions of a PRD or have one model review another's output, making gaps easier to spot. The important part is that AI is helping us uncover ambiguity, not making the decisions for us.

Maybe coding isn't the bottleneck

This becomes more interesting when we look at where teams actually spend their time. Complex work can involve several rounds between product, UX, requirements and engineering before development can properly begin. That's often necessary, but it can also create significant bottlenecks. If an AI agent can produce a working implementation quickly, waiting two weeks for a requirement to be clarified becomes a much bigger problem than it used to be.

This suggests that engineers need to be involved earlier rather than receiving requirements only once they're considered finished. UX needs to be part of the conversation early too. A rough prototype or wireframe can expose gaps in a requirement much faster than another round of discussion, and AI makes creating those lightweight prototypes much cheaper. Requirements, UX and technical design can become an iterative loop rather than a series of handoffs.

The ticket might be the problem

AI also makes me question how we slice work. A ticket that takes weeks or months is difficult for an agent to reason about, and arguably isn't a particularly useful unit of work for humans either. “Build authentication” is very different from breaking the problem into password reset, token validation, password updates and the associated tests.

That doesn't mean turning every feature into dozens of tiny tickets. We just need work that has a clear purpose, manageable scope and a definition of done. If something takes months, it might be a project hiding in a Jira costume.

At the same time, not everything needs the full AI lifecycle. A large feature may benefit from structured requirements, refinement, planning and validation, while a small BAU change might only need a prompt and a developer. If we apply the same process to everything, we risk replacing one form of bureaucracy with another. The workflow should match the complexity of the work.

The agent needs to see the real system

There is also a fairly fundamental requirement: the agent needs to understand the real system. Giving it a PRD without access to the relevant codebase means it is still making assumptions. With the code, it can find existing patterns, understand constraints, reuse functionality and spot when a proposed solution doesn't fit.

Of course, giving AI access to source code introduces security, licensing, privacy and organisational considerations, so AI adoption isn't simply a matter of choosing the right model. Some of the biggest barriers have nothing to do with the model at all.

And once multiple developers and agents are working in parallel, things get even more interesting. Each agent has its own context and can make decisions based on what it currently sees. One agent can change something another doesn't know about, or two agents can make perfectly reasonable decisions that don't work well together. This makes good engineering practices even more important: small changes, clear boundaries, good tests, frequent reviews and consistent project rules.

So, are we ready?

Probably not completely, and that's fine. We don't need to jump straight into autonomous software development. We can take real pieces of work, try these workflows, see where they break and improve the process as we go.

Because AI isn't just changing how quickly we write code. It is exposing everything around the code that slows us down: unclear requirements, oversized tickets, late UX involvement, documentation drift, handoffs, access restrictions and decisions that take days to make.

That's why I think the idea of an AI harness is bigger than prompts and agent configuration. The harness is the environment we create around the AI: how we define work, how product, UX and engineering collaborate, how knowledge is structured, how repositories are organised, how work is validated and what access the agent has.

The AI might be the new part, but the way we work around it is what will determine whether it actually makes us faster.

AI engineering is easy. Changing how we work is hard.

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.

DEV Community: ujja

I Asked 10 AI Models to Reconstruct Real Cyber Attacks

What I Benchmarked

Real-world case studies

The seven tasks, in plain language

Models Tested

Findings

Kaggle Gotchas

Code Walkthrough

My Benchmark

Expanded Case Set

What's Next?

When Your AI Agent Reads Outdated Docs, Who Checks the Docs?

What I Built

What does Docgrity find?

Why I built it

Demo

Hackathon Experience

🤖 What happens when your AI agent trusts outdated docs? I built Docgrity to find the gaps.

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

GitHub - ujjavala/docgrity-vscode: Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. · GitHub

I built PadForward because sometimes you just need a pad

What I Built

"Does anyone have a pad?"

So, what is PadForward?

If you need one, you shouldn't have to ask

But where do the pads come from?

And yes, I'm using Solana for the donation

I didn't want another chatbot

And what if the AI isn't available at all?

Snap the box — AI that counts pads from a photo

What if the map says there are pads, but there aren't?

The people who keep it going

The bigger idea is the network

There's a lot more I want to do with it

Why PadForward?

Demo

Code

How I Built It

Prize Categories

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

Start with your repo

VS Code

CLI

GitHub Action

And now, Confluence

Zero infrastructure

AI Engineering Is Easy. Changing How We Work Is Hard

The workflow is changing

Maybe coding isn't the bottleneck

More documentation isn't always better

The ticket might be the problem

The agent needs to see the real system

So, are we ready?

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

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