DEV Community: Reet Singh

Ask an AI for your home loan EMI and it will be off by ₹10. Every month.

Reet Singh — Sun, 11 Oct 2026 14:06:52 +0000

This is a submission for the Kaggle Benchmarking Challenge

Last week I built a little app about Ananya. She's made up, but you know someone like her. She's 31, she's been saving for eight years, and she's about to sign for a ₹72 lakh 2 BHK whose brochure says 1,050 sq ft. The registration says the carpet area is 720.

While I was building it I kept asking chatbots for help with the numbers: what's ₹72 lakh in crore, what's the price per sq ft of carpet, what's the EMI on the loan. The answers sounded confident. I had no idea whether they were right.

So I benchmarked it. Then my benchmark turned out to be too easy, so I made it harder. That second part is where the real findings are.

What I Benchmarked

Lakh, Crore and Carpet Area is 100 deterministic questions about the money and property maths Indian buyers actually do. Every answer was computed in Python, not by hand.

Tier	Group	Cases	Example
Core	Conversion	15	"₹1.2 crore minus ₹45 lakh, in lakh?"
Core	Area	15	"Super built-up 1,300 sq ft, carpet 910. Loading as a % of carpet?"
Core	EMI and tax	15	"₹72,00,000 at 8.4% for 25 years. Monthly EMI?"
Core	Format	15	"Write 98765432 with lakh/crore commas" → 9,87,65,432
Hard	Multi-step loans	15	prepay ₹5 lakh after 36 EMIs, keep the EMI: how many EMIs are left?
Hard	Tax rules	7	80C and 24(b) caps, LTCG with cess, circle rate vs agreement price
Hard	Regional land units	8	guntha, cent, Chennai ground, bigha-biswa, Punjab vs Haryana marla
Hard	Hinglish	10	"72 lakh ka flat hai, 20% down payment, baaki 8.5% pe 20 saal. EMI kitni?"

Each prompt asks for at most five lines of working, then ANSWER: <value>. Numbers are checked against the true value (a rupee or two of slack where rounding is involved, an exact string match for the format group). Tax questions state the rule inside the prompt, so they test arithmetic, not whether a model knows this year's tax law. The scorer also flags any response that slips into Western grouping (7,200,000 instead of 72,00,000), even when the final answer is right. I call that western comma drift.

Why this matters to me: hundreds of millions of people think in lakh and crore, and property listings in India are famous for blurring carpet and super built-up area. If a model is going to sit inside a home-buying assistant, these are its first questions, not edge cases.

Models Tested

A spread you'd actually reach for in a product, across three providers and two price tiers: Gemini 3.7 Flash, Gemini 3.1 Pro Preview, Claude Haiku 5.5, Claude Sonnet 4.6, Gemma 4 31B (open-weight) and GPT-5.4 mini.

Findings

1. My first benchmark was too easy

Version 1 was just the 60 core questions. Every model scored between 0.92 and 1.00:

Model	Core score (60)
Gemini 3.7 Flash	1.00
Gemini 3.1 Pro Preview	0.98
Claude Haiku 5.5	0.98
Claude Sonnet 4.6	0.95
Gemma 4 31B	0.95
GPT-5.4 mini	0.92

A benchmark where everyone gets an A tells you nothing about which model to ship. So I added 40 harder cases, the kind of questions a buyer asks after the first EMI: prepayments, rate hikes, balance transfers, tax caps, regional land units, and the same maths in Hinglish.

2. The hard tier opened a 35-point gap

Model	Score (100)	Hard tier (40)	Multi-step loans	Tax rules	Regional units	Hinglish	Comma drift
Claude Haiku 5.5	0.97	37/40	12/15	7/7	8/8	10/10	16%
Gemini 3.7 Flash	0.94	34/40	10/15	6/7	8/8	10/10	8%
Gemini 3.1 Pro Preview	0.94	34/40	11/15	6/7	8/8	9/10	10%
Gemma 4 31B	0.87	31/40	8/15	6/7	8/8	9/10	22%
Claude Sonnet 4.6	0.85	29/40	7/15	7/7	7/8	8/10	13%
GPT-5.4 mini	0.77	23/40	2/15	7/7	7/8	7/10	6%

On the core 60, these four were 8 points apart. On the hard 40, they're 35 points apart, and the ranking flipped: Flash, the v1 winner, is now second.

3. Multi-step loans break everyone

Models that nailed single EMIs still stumbled once the loan had a history. Even the best model missed 3 of 15. GPT-5.4 mini got 2 of 15.

The scariest miss was l13: "You can afford an EMI of ₹50,000 at 8.5% for 20 years. What's the largest loan you can take?" The answer is about ₹57.6 lakh. GPT-5.4 mini said 537,000. That's roughly ₹5.4 lakh, a tenth of the real figure, delivered with the same confidence as everything else.

The near-misses are worse in a quieter way. On e04 (₹72,00,000 at 8.4% for 25 years) the correct EMI is ₹57,492. In v1, Claude Sonnet 4.6 said ₹57,487 and Gemini 3.1 Pro Preview said ₹57,482. None of them said "approximately". (1 + r)^300 is exactly where mental arithmetic slips.

What this changed for me: in anything I ship now, the model explains the formula and a tool computes the EMI.

4. The bigger model lost to the cheaper one

Claude Haiku 5.5, the small tier, beat Claude Sonnet 4.6 by 12 points overall, and by 8 cases on the hard tier. Price tier was a worse predictor of accuracy than I expected, so test the model you actually plan to pay for.

5. What I thought would be hard, wasn't

I predicted regional land units would be the bloodbath, since bigha and marla change meaning from state to state. But when the conversion is given, models handle it: 30 of 32 right across the four models. Tax rules stated in the prompt were nearly perfect too (27 of 28). The only tax miss was Gemini 3.7 Flash on t02, which forgot the buyer had already used ₹90,000 of their 80C limit and answered ₹3,30,000 instead of ₹2,40,000.

The difficulty is in chaining steps, not in unfamiliar units.

6. Hinglish costs accuracy for some models

Haiku and Flash got all 10 Hinglish questions right. Sonnet dropped 2 and GPT-5.4 mini dropped 3, on sums like total interest and carpet-from-loading that are routine in English. If your users type "EMI kitni banegi?", test in that language.

7. Models drift into Western commas even in an Indian question

Every model aced the format group when asked directly. Yet 6–16% of responses still wrote something like 4,000,000 somewhere in their working. It doesn't make the answer wrong, but it's exactly the slip that makes "₹40 lakh" read as "₹4 crore" to a tired buyer at 11 PM.

8. My benchmark lied to me first

My first run said Claude Opus 5 scored 0.08, and GPT-5.5 errored completely. I almost wrote a post about it.

Then I opened the run logs. Every failure was a 403 PermissionDeniedError: max estimated cost exceeds your available quota. I'd fired cases in parallel, the expensive models blew through the quota, and my scorer counted each errored call as a wrong answer. Opus 5's printed table actually showed 100% on every group it got to answer.

I fixed it: sequential calls, per-case progress logging, and every run prints answered: X of 100 before any score. I dropped the two most expensive models rather than publish a number I can't stand behind.

The lesson: a benchmark score is only as honest as its error handling. If a leaderboard can't tell you how many questions were actually answered, don't trust the leaderboard.

What I'd measure next

Give the models a calculator tool. Do the multi-step loan errors vanish, or do models skip the tool when they feel confident?
Leave the unit definition out. Ask "2 bigha in sq ft?" with no state, and score whether the model asks which state instead of guessing.

My Benchmark

Benchmark: https://www.kaggle.com/benchmarks/reet22/lakh-crore-and-carpet-area
Task: https://www.kaggle.com/benchmarks/tasks/reet22/lakh-crore-carpet-area
Notebook (all 100 cases and the scorer): https://www.kaggle.com/code/reet22/lakh-crore-and-carpet-area

Fork it, add your city's stamp duty, and tell me which model gets your home loan right.

Wanderlore: What if your next walk had a plot?

Reet Singh — Sun, 11 Oct 2026 12:32:16 +0000

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

The first time I tried to test my walking app properly, I couldn't even get it to find me.

I was on my laptop, staring at another location timeout. I kept wondering what was wrong. How was I supposed to build a story that followed a walk if it couldn't tell where I was?

Then I tried it on my phone. It detected my location and picked up my movement. After all that testing at a desk, the part that finally worked was the part that meant leaving it.

That little moment made Wanderlore feel real to me.

I wanted a walk to have a little anticipation: a reason to notice something, a character to follow, a small mystery waiting around the next chapter. If you've ever wanted a reason to step outside but couldn't quite find one, this is the feeling I built it around.

What I Built

Wanderlore turns a walk into a narrated, interactive story.

You choose folklore, mystery, or fantasy, decide how long you want to wander, and tell it what the weather looks like. The page responds too: choose rain and the scene gains drizzle, with rain ambience after you enable sound.

When you begin, Gemma writes a short chapter and a narrator reads it aloud. In location mode, each new chapter uses your latest position and nearby named places when your selected map pack covers the area. Your earlier chapters and decisions help shape what happens next.

The choices are small invitations into the story. Do you look more closely at the lantern? Ask its keeper a question? Offer to help? Your answer becomes part of the next chapter's context.

Some days you might want to make every decision. Other days, you might just want to listen. Continue automatically lets the storyteller choose and starts the next chapter after narration finishes. Keep the browser visible while using it; background and locked-screen continuation are still future work.

When you're done, save the walk, leave a reflection, and export your story. I like the idea of coming home with a small memory of what you noticed.

Demo

Open the live preview

The hosted walk currently requires a private demo access code. The screenshots below show the live experience without exposing a personal route.

Mobile layout, captured at 390 × 844 pixels in a browser. Real location and movement were also tested on my phone.

This chapter uses Sample walk: its route and place names are fictional. It was generated and voiced in 3.8 seconds in this particular test.

For a first try, choose ten minutes and whichever genre you feel like hearing. On a phone, allow location and use Use my location. On a laptop, Sample walk lets you explore the storytelling without relying on desktop location services.

The sketch records the story's route; it doesn't provide walking directions. The current Lucknow map pack covers central and adjoining areas. You can import a GeoJSON pack for another area; without matching nearby places, the story uses general surroundings.

Code

Wanderlore on GitHub

The app uses Python, FastAPI, and a responsive HTML/CSS/JavaScript frontend. The application code is GPL-3.0; model and map data have their own terms. OpenStreetMap contributors provide the underlying place data. I used Codex to help implement, debug, and test the project.

How I Built It

Gemma is the story engine. The local setup supports Gemma 3 through Ollama. The hosted preview uses gemma-4-26b-a4b-it through Google AI Studio because the small free hosting instance cannot run the local model stack. Chapters carry forward the previous story, selected choices, genre, weather, and available place context.

ElevenLabs supplies the hosted narration. I wanted the voice to feel like someone telling you a story, with enough warmth to keep listening. The hosted version uses the Roger voice. The local setup also supports Kokoro after downloading its voice assets.

Tiger Data supplies a small, sourced place-context pack. I stored four summaries of public Lucknow sources in PostgreSQL with pgvector. Keyword and vector results are combined with reciprocal rank fusion. A verified retrieval produced context for Rumi Gate and Janeshwar Mishra Park, which is exported for the storyteller to read. This is a prepared context pack; walking doesn't trigger a database query for every step. The resulting tale is fiction, even when it includes a real place.

Sentry makes the wait visible. I instrumented the chapter pipeline with a wanderlore.chapter transaction and spans for generation and speech. One verified development trace for Gemma generation measured 3.28 seconds. Seeing where time goes helps me assess the pauses between chapters. The trace integration exports timing and model metadata while excluding prompts, story text, GPS, cookies, and request bodies.

Render hosts the HTTPS preview on its Free plan. That made phone testing possible without running the server on my laptop. The hosted version needs internet for generation and narration. Free hosting can sleep and reset saved files, so exporting a walk matters.

Verification included 29 passing Python tests, five automatic-continuation scheduler tests, and a live browser check where a second chapter started without selecting a choice or pressing Next. My phone detected location and movement; desktop location remained unreliable on my setup.

Why Does Open Innovation Matter?

For Wanderlore, it means having a path to storytelling on your own machine. Gemma's available weights let the local version generate chapters through Ollama, and Kokoro provides a local voice option. After the models and assets are downloaded, that setup can work offline with the local server running.

The hosted preview trades that independence for easier access. It sends story context and nearby place names to Google, and narration text to ElevenLabs. Raw landmark coordinates are stripped from the generation payload, although the hosted server still processes GPS. These are different ways to run the same idea, with different privacy and connectivity needs.

I also want people to be able to improve the experience: bring their own map pack, experiment with a narrator, or make the choices more interesting. Open application code makes those changes possible.

Prize Categories

I'm entering these categories based on the integrations above:

Best Use of Gemma — context-aware chapter generation, with local and hosted inference paths.
Best Use of ElevenLabs — spoken narration for generated chapters.
Best Use of Tiger Data — pgvector and keyword retrieval for sourced place context.
Best Use of Sentry Agent Tracing — instrumented generation and narration, with trace evidence shown above.
Best Use of Render — the deployed HTTPS web experience used for phone testing.

If there's a familiar path near you, that's where I'd start. Pick a mood, give yourself ten minutes, and see what you notice when there's a story waiting for you.

I'd love to hear which genre you'd take on your first walk—and what you would want to happen next.

Maa ka Drawer: finding my mother’s bills with Tiger Data and open multilingual search

Reet Singh — Mon, 05 Oct 2026 05:53:57 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

A receipt can be saved and still be hard to find. You remember the washing machine, the shop, or what broke, not necessarily the filename or invoice number.

I built Maa ka Drawer for my mother: a small household receipt finder that combines open multilingual embeddings with Tiger Cloud PostgreSQL keyword and vector search. The goal is to make “find that bill” a smaller job.

I chose the problem for this prototype. I have not yet tested it with her, so I cannot claim that it has saved her time or quote feedback she has not given.

The app opens onto a drawer of illustrated cards. Hovering lifts and tilts a card; tapping or clicking opens the receipt. Search works over the saved text, and an original PDF or photo can stay attached. If the receipt does not state a warranty expiry, that field stays blank.

Less typing: upload or speak

A JPG, PNG or PDF upload now extracts text and suggests a recognised bill type. A synthetic electricity bill became Electricity bill → Services, retaining its INR 400 amount and original image. Tesseract.js reads English/Hindi text on the app server. PDF.js reads embedded text directly; scanned-page OCR is implemented, limited to the first three pages, but its browser retest is still pending. Photos and embedded-text PDFs passed functional checks. Blurred photos, handwriting and unfamiliar bill layouts can fail.

Speak receipt records a short Hindi or Indian English note, or accepts an audio file. Local Whisper-small, via the ONNX conversion and Transformers.js, transcribes the audio. A conservative parser suggests the item and explicitly stated amount. A synthetic Hindi development recording produced Electricity bill · ₹400; the imperfect transcript remains visible for correction. Voice notes are labelled as notes, not original invoices. The recording is temporary; only reviewed text is saved.

The voice verification record uses two Murf-generated development fixtures, not a held-out accuracy test or my mother's feedback. Transcription and cloud save/reload were verified separately. Further live-microphone and noisy-household testing remains pending. Murf Isha provides the Indian English demo narration; Murf does not transcribe user notes.

Demo

Watch or download the narrated demo video.

The video is a captioned walkthrough with Murf Isha Indian English narration assembled from screenshots captured during real interactions with the app. It shows Hindi search, receipt evidence, a no-match query, uploading a receipt photo with OCR, Hindi voice transcription, an attached PDF, archive, undo, and persistence after reload. It is not a continuous screen recording. Every demonstrated receipt is fictional.

Demo release and setup notes · Expanded scene notes

Code

Browse the complete source on GitHub.

The repository includes the app, MIT license, PRD, schema, tests, evaluation queries and results. Run it locally with Node.js 22+, npm ci, npm run build, and npm start.

How I Built It

The useful AI task here is retrieval. A Hindi query such as कपड़े धोने वाली मशीन can find an English washing-machine receipt even when the exact query words are absent.

The model is multilingual-e5-small, using Xenova’s ONNX conversion through Transformers.js. Quantized inference runs on the app server. Queries and receipt chunks become normalized, 384-dimensional vectors.

PostgreSQL stores source text, metadata, full-text search vectors and pgvector embeddings. Exact words and invoice identifiers matter, so keyword search remains part of the system. Reciprocal rank fusion combines keyword and semantic rankings. A similarity gate filters weak or ambiguous semantic matches. These scores are not probabilities.

The interface uses React and Vite; Express serves the API and built app. PDF.js renders originals inside the receipt view. Codex helped implement and test the project, and generated appliance illustrations provide visual cues. The illustrations are not photographs of my mother’s possessions.

Tiger Data is the live data layer. A dedicated free Tiger Cloud service stores receipt text and 384-dimensional embeddings in pgvector. A live verification run passed saving, exact invoice retrieval, vector search, reconnect persistence, archive exclusion and undo. The verification record includes the timestamp and pgvector version. The original gallery/PDF walkthrough and retrieval benchmark used local PGlite. The new OCR and voice-entry captures were taken with the app connected to Tiger Cloud. Cloud persistence was verified separately.

The free service presents a private Timescale certificate authority. I pinned that CA locally on first connection and kept chain and hostname checks enabled for subsequent connections. This initial trust-on-first-use step is disclosed in the README; it is not a publicly authenticated certificate chain.

What worked—and what did not

I ran a fixed evaluation over six fictional receipts and 18 queries:

Search mode	Correct first result on 14 positive queries	Correct no-match responses on 4 negative queries
Keyword	8/14	4/4
Vector	11/14	4/4
Hybrid	12/14	4/4

The full query set and outcomes are public. This is a small, builder-authored evaluation. A Hindi washing-machine phrase was rejected, and a Hinglish ceiling-fan query returned the purifier. Those failures limit how confidently I can hand this to someone else.

All 21 automated tests pass, covering retrieval, identifiers, validation, source-file serving, archive/undo, database persistence, actual image OCR and conservative voice-note parsing. Desktop and phone layouts were checked in the browser.

Why Does Open Innovation Matter?

The open model gives this project a retrieval component I can run, inspect, replace and test without a hosted generative API. After the weights are downloaded, local mode keeps receipt data and inference on the laptop. The verified Tiger Cloud mode stores receipt text and embeddings remotely, while model inference and original attachments stay on the app server. That mode is not fully offline.

The model does one limited job: help locate existing evidence. It does not write an answer about warranty coverage. A user can open the saved text and original document and see what the receipt actually says.

That distinction shaped the rest of the app. Text extracted from a receipt or transcribed from speech stays editable and requires review. Dates are confirmed by the user. Archiving is reversible. The prototype is for one household and has no public account system.

My next step is a real trial with my mother: ask her to find a bill, observe the words she uses, and improve retrieval against those examples. That feedback will matter more than adding another animation.

Prize Categories

Best Use of Tiger Data — real receipt text and open-model embeddings are stored in Tiger Cloud PostgreSQL with pgvector. The application combines full-text and vector rankings, and the public verification record demonstrates the live integration.

The brochure said 18 floors. The registration said 12.

Reet Singh — Sun, 04 Oct 2026 08:12:55 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Let me introduce you to Ananya. She's made up, but you probably know someone exactly like her.

She's 31, works in Pune, and has spent eight years saving for her first flat. One Sunday she walks into a sales office for a project called Nimbus Greens. The brochure is gorgeous. Four towers rising to eighteen floors, a rooftop pool, possession in March 2027, a 2 BHK of 1,050 square feet for ₹72 lakh "all-inclusive", parking free. The broker is friendly and in a hurry. If she pays 20% today, the price is locked.

Here's the part nobody tells her. Everything she needs to make this decision is already public. Every project in India has to be registered with the state's Real Estate Regulatory Authority (RERA), and that registration is what the builder is legally held to. Then there's the draft agreement for sale, and the RERA Act itself. Nobody reads those three next to the brochure. So nobody notices that they tell a different story:

What the brochure says	What the record says
4 towers, G+18	3 buildings, sanctioned for Ground + 12
Possession from March 2027	Completion on 31 December 2028
2 BHK, 1,050 sq ft	690 sq ft carpet area
Rooftop pool, amphitheatre, EV charging	Not in the registered common areas
₹72 lakh all-inclusive, free parking	₹81,55,000 in the agreement, ₹4,50,000 of it for parking
All approvals in place	Environmental clearance applied for, still awaited
Pay 20% on booking	Section 13(1) of the Act allows 10% before a registered agreement

Nimbus Greens is fictional. Every row in that table isn't. These are the tricks Indian buyers find out about years later, once the money is gone and the building has stopped at twelve floors.

So I built Home Truth. You give it a project's documents and it lays them side by side, finds every place they disagree, and shows you the exact sentence from each document so you don't have to take its word for anything. It turns the gaps into a checklist of questions to ask the builder. And it has an agent you can ask the kind of question a broker throws at you on the phone: "I'm being offered flat B-1502, is that okay?"

Why this needed structured content

I tried the obvious version first in my head: dump the documents into a search index and let a model answer. Ask it "how many floors does Nimbus Greens have?" and the loudest, most confident answer in the pile is the brochure's "G+18". It's repeated, it's in large type, and it's wrong.

Getting it right takes knowledge that isn't written in any single document. You have to know that a registration outranks a brochure. You have to know that the law caps a booking amount at 10%, so a request for 20% is a violation, not a detail. And you have to know that "1,050 sq ft" and "690 sq ft carpet" are the same flat, measured two ways, and the brochure picked the flattering one. That knowledge lives in how the content is modelled. That's the bit I built in Sanity.

Demo

Live: https://home-truth-theta.vercel.app. No sign-in. Open Nimbus Greens and try the chat.

If you'd rather click around yourself, here's the two-minute tour.

Start on the home page and drag the building. It's drawn from the data: twelve solid floors are what the sanctioned plan covers, and the six translucent red ones on top only ever existed in the brochure. Scroll down and you can flip through the brochure itself in 3D, with the 20% line highlighted and Section 13(1) of the Act quoted right beside it.

Open the full report. Ten of twelve facts don't hold up, and five of those are critical. Every finding says why it matters to a buyer, and every one has a Show the exact words drawer with the quote from each document. One click on Questions to ask the builder turns all of it into a printable checklist that names the document to ask for.

Then ask the chat about flat B-1502. It goes to Sanity, checks the registration, sees that Building B is sanctioned for Ground + 12, and tells you a fifteenth-floor flat has no approved plan. Open How I checked under the answer and you'll see every query it ran.

Code

Reet24-del / home-truth

Compare builder promises with registered documents through cited findings and an interactive 3D building.

Home Truth

Before you pay for a flat, check the builder's promises.

Home Truth compares what a builder advertises (brochures, websites, broker messages) with what is registered with the state Real Estate Regulatory Authority (RERA), what the draft agreement for sale says, and what the Real Estate (Regulation and Development) Act, 2016 requires. Every finding shows the exact words it came from.

Built for the DEV x Sanity Challenge, Path One: an agent that queries real content through Sanity Context.

Why it needs structured content

Ask a keyword search "how many floors does Nimbus Greens have?" and the brochure answers "G+18" with total confidence. Home Truth knows three things a search engine doesn't:

Which document outranks which. The registration is what the builder is legally held to; the brochure is marketing. The sanctioned plan says Ground + 12, so floors 13 to 18 have no approved plan.
What the…

View on GitHub

studio/ holds the Sanity Studio, the schema, the comparison engine and the scripts. web/ is the Next.js 16 site, the three.js scenes and the agent.

How I Used Sanity

I started with the schema, because the schema is the product

Before any UI, I sat down with the question "what is a fact, here?" and ended up with five document types.

A sourceDocument is one document's full text, plus a kind: registration, agreement, marketing or law. That one field is what lets the system know who to believe.

An attribute is something a buyer cares about, like floors per building, carpet area or the possession date. It also says how that fact should be compared: the unit, a tolerance, a controlled vocabulary, and whether it's checked for equality or against a legal limit. "Floors" and "booking amount" behave very differently, and the attribute is where that difference lives.

A claim is one document's version of one attribute, together with the exact words it came from and where they appear. The demo project has 28 of them. A finding is the verdict once all the claims for an attribute are compared: match, mismatch, violation, or only one source. And a project ties it all together.

The rule I cared most about was that nothing gets paraphrased. Every claim carries a quote, and npm test checks each demo quote word for word against its source document. When Claude extracts claims from a new document, they go through the same check and land in the Studio's Claims to verify view, marked unverified, until a person approves them.

Code decides who's wrong, not the model

I didn't want an LLM deciding whether a builder broke the law. So findings come from a small comparison engine, studio/lib/compare.ts. It ranks the sources (Act, then registration, then agreement, then marketing), applies the tolerances and vocabularies, and checks legal limits. The same claims always produce the same findings, which means every line of the report can be traced back to a quote. The model's job comes later, and it's a narrower one: explain.

Pointing Sanity Context at it

This is where it got interesting.

I created a Knowledge Base in the Context app and pointed it at my own dataset, using a GROQ source query to pull in every document that has a body:

*[_type == "sourceDocument" && defined(body)]{
  title, kind, publisher, publishedAt, "project": project->name, body
}

For the Knowledge Base's purpose I wrote it the way you'd brief a person: who's going to ask questions (homebuyers in India), what should lead (buyer rights, registered facts, agreement clauses, red flags), and what's out of scope.

Then I hit Build entries, and Context came back with six issues. Every one of them was a conflict between the brochure and the registration. The floors, the number of towers, the possession date, the sizes of both flat types, and a jogging track advertised at 1 km that's registered at 600 m. Reading through them felt a bit like watching the product work on itself. I resolved each one in favour of the registration, and Context saved every decision as an instruction that future builds keep.

But "the registration wins" on its own throws away something useful. A buyer needs to know what they were promised as well as what's true, because that gap is exactly what they'll raise with the builder. So I added one instruction by hand:

When a marketing document contradicts a registration document, treat the registration as correct, but keep the marketing claim in the entry, labelled "Advertised", with its source.

Now the agent can say "you were told March 2027, but the builder is held to 31 December 2028", which is the sentence that actually helps.

I'll be honest about one gap. I meant to add the RERA Act as a PDF, as a second source. The government site wouldn't serve the file to my machine, so for now the law lives in the dataset as quoted claims, Section 13(1) on booking amounts and Section 14(3) on defect liability, and the agent reaches it through GROQ.

Two endpoints, two jobs

The agent talks to Sanity through two Context MCP endpoints, and keeping them separate was deliberate. An endpoint that has both a dataset and a Knowledge Base attached quietly serves only the dataset.

home-truth-data runs in GROQ mode and answers exact questions. Each chat narrows it to the current project by adding a groqFilter to the endpoint URL, so the agent only sees that project, the attribute definitions and the law. Context combines that filter with the endpoint's own, so it can only ever narrow access, never widen it. I also cut its tool list down to groq_query, schema_explorer and array_field_reader. The system prompt already explains the schema, so initial_context was just spending tokens.

home-truth-kb runs in Knowledge Base mode. That's where the agent goes for "what does this clause mean" and "what are my rights if possession is late". It calls initial_context once to get the outline, then knowledge_base_read for the entries it needs.

What the agent actually does

The agent runs on Groq with openai/gpt-oss-120b, using Groq's Responses API. Groq connects to both endpoints as remote MCP servers and runs the tool calls itself, so my server just sends the conversation and passes each step back to the page.

When I asked it how many floors the towers are registered for and what the brochure claims, it first ran:

*[_type == "finding" && attribute->label match "*floor*"]{status, severity, summary, "fact": attribute->label, entries}

Then it pulled the two claims behind that finding, opened the Knowledge Base outline, and read the possession and delays and buyer rights entries. The answer quoted the sanctioned plan ("Ground + 12") against the brochure ("G+18"), called it a critical mismatch, summarised Section 18 on delayed possession, and finished with what to ask the builder for and what not to pay yet. All five steps sit under How I checked.

The system prompt is short on personality and strict on rules. Trust the Act, then the registration, then the agreement, then marketing. Never invent a quote, a section number, a date or an amount. If neither source knows, say so and send the buyer to the state RERA portal or a lawyer.

The parts that bit me

Project tokens don't work for Context. I got a 403 until I made an organization token with Context Viewer.

Deploying the schema wasn't enough, either. The GROQ endpoint kept saying "No Studio application found" until I ran sanity deploy and the Studio went live. Then everything turned green at once.

The model has habits. gpt-oss leaves markers like 【result[0].quote】 in its prose and drops <br> into table cells, so both get stripped before an answer reaches the page.

And the chat didn't start on Groq. I first built it on Claude's MCP connector, then moved it over. Because both run MCP on their side, the switch touched one file of about 90 lines. Claude still does the claim extraction for new documents.

Sanity Project Details

The project ID is f5y6g2q3, and the production dataset is public. You can query it straight away: every project, or all the findings. The demo has 4 source documents, 12 attributes, 28 claims and 12 computed findings. The Studio is at https://home-truth.sanity.studio (sign-in required).

Ananya didn't pay 20% that day. She went home with a list of questions instead.

If you're about to book a flat in India, look the project up on your state's RERA portal first. Home Truth explains what the documents and the law say. It isn't legal advice.

Pani Kaisa Hai? A golgappa map that warns a neighbourhood about bad water, but only after a human checks

Reet Singh — Sun, 04 Oct 2026 07:50:29 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

Every golgappa wala in India gets asked the same thing before the first bite: pani saaf hai na? Is this water clean?

Nobody asks that about their own tap, borewell or tanker, even though contaminated supply is one of the most common ways a whole neighbourhood falls sick at once. The signs show up early (a sewage smell, yellow water, two kids in the same lane with loose motions) but they stay scattered across WhatsApp groups until it is too late.

Pani Kaisa Hai? collects those signs in under a minute, adds them up per neighbourhood against India's drinking water standard (IS 10500) and, only when the risk is real, asks a local health worker to confirm before anyone is warned.

Every neighbourhood is a golgappa on the map:

	State	What it means
🟢	Crisp	No credible signal
🟡	Soggy	Complaints rising, boil or filter first. This one is automatic
🔴	Phoot gaya	Contamination confirmed by a named person. Never automatic
✨	Fresh batch	Fix recorded, area recovering

The rule the whole thing rests on: software can make a golgappa soggy, only a person can make it burst. An AI check can score a case and push it as far as "needs verification". It can never confirm or dismiss one. Every red alert carries the name of the person who confirmed it and the reason they gave.

It is for residents, ASHA workers and residents' association volunteers in Indian cities. The demo runs on sample data for Indore.

Demo

Live: https://pani-kaisa-hai.vercel.app

/ the golgappa map, the stall and Shake the golgappa, a simulator that runs the app's real scoring code. Pile on signals and watch it go soggy on its own, then notice the "health worker confirms" button stays locked until there is evidence for a person to look at
/area/sector-14 an area page with the state, the reason and the arithmetic behind it
/report the four step report form
/control the verifier queue. Passphrase: pani-demo
/studio the embedded Sanity Studio

A 98 second walkthrough told as a story. The frames are the live site, captured by a script; the narration is Murf's Hindi voice Shweta.

Early warning from residents, not a lab test. All data in the demo is sample data.

Code

https://github.com/Reet24-del/pani-kaisa-hai

Next.js 16 (App Router, TypeScript, plain CSS Modules), Sanity Studio v6 embedded at /studio, an App SDK control room in control-room/, a Workflows definition in sanity/workflows/, a scheduled Sanity Function in functions/daily-tick/, Leaflet with OpenStreetMap tiles. 33 tests cover the risk score, the case rules (including "only a person can confirm"), the daily tick, the report input rules, the workflow definition and a lint for GROQ date comparisons.

My Build Process

I built this with Claude Code over about seven sessions between 19 September and 4 October and I kept a build log the whole way (BUILD_LOG.md in the repo), including the parts that went badly. This section is the short version.

Day 1: schema first, then the whole spine before the backend existed

I started with the data model, not the UI, because the product only works if evidence and decisions are kept apart:

report is one resident's observation and it is append-only. Corrections are new reports, never edits. An edited evidence trail is not evidence.
waterCase groups reports in one area and carries the verification status.
alert is a confirmed warning and cannot exist without a verifiedBy and a written reason.
safetyLimit and riskSettings hold the rules as content. IS 10500 thresholds carry their clause as a citation, so a wrong number is a content fix in the Studio, not a deploy.
waterSource.areasServed stores the source to area link once and areas read it back with references().
Area state is derived but stored, with a reason and a timestamp, so the map is one query and every golgappa can explain itself.

Nine document types, written by hand. The Studio desk is laid out the way work arrives: Needs verification → Active alerts → Unmapped reports, then reference data.

Then I asked Claude to stop following the day-by-day plan and just build, before I even had a Sanity project. That worked because of one early decision: when the Sanity env vars are missing, the home page renders setup steps instead of crashing. One guard (sanityConfigured) decides whether any query runs at all, so the whole UI could be built against the schema first.

In that session: the map and area pages, the four step report form, the report API (whitelisted fields, clamped numbers, a salted device hash instead of IP addresses, 3 reports per device per area per day), the risk score as pure functions with tests, the case engine and both control rooms.

What went wrong on Day 1:

defineLive comes from next-sanity/live, not the package root.
next build failed because the env module threw at import time, so a build with no Sanity project was impossible. I rewrote it to fall back to a placeholder project id.
Node's test runner needed allowImportingTsExtensions before --experimental-strip-types would accept .ts imports.

Reaching past the Studio: Workflows, the App SDK and Functions

Workflows. The verification flow lives in sanity/workflows/waterCase.ts as data: intake → score → watch or needs verification → human decision → alert → resolved → closed. The AI check is a system actor that can move a case as far as verification. Confirming or dismissing sits in a decide activity whose actions are gated on the verifier role. An agent and a person use the same transitions, only the person can take the last one.

The engine's own validator rejected my first version twice. The workflow name had to match ^[a-z0-9][a-z0-9-]*$ and every activity needed an action carrying status: 'done' or the stage gate wedges. That is how I know the definition is real and not decorative.

Being honest about where it stands: Workflows is in early access and the engine is not deployed on my project yet. Until it is, the same stages and the same human-only guard run through sanity/lib/cases.ts, which the report route and both control rooms call. The workflow file passes defineWorkflow's validator and has tests.

App SDK. control-room/ is a custom app for the Sanity Dashboard: the verifier queue with live data, the evidence for each case and the confirm or dismiss decision. Confirming writes the case decision and the alert in one transaction. There is also a /control page in the Next app behind a passphrase, so judges can try it without a Sanity login. Both write the same fields.

Sanity Functions. The daily tick (quiet cases close, a Fresh batch goes back to Crisp after its quiet days, every golgappa is re-derived) is a scheduled Sanity Function in functions/daily-tick/, deployed from sanity.blueprint.ts with its own robot token that only has Editor rights on this project. It calls the same runTick as the app, which takes any Sanity client, so the function and the old Vercel cron share one tested implementation. The cron stays as a backup 15 minutes later; a second run changes nothing. Its first deployed run timed out at the 10 second default, because re-deriving every area takes longer than that from Sanity's servers, so the blueprint now gives it 120 seconds.

Custom Studio input. Readings are drawn against their limit in the Studio, using the same component the control room uses, so an editor sees "780 mg/L, over the 500 acceptable limit" instead of a bare number.

Day 2: the theme and a hard lesson about drawing people

The first palette was cool mint, which is wrong for a golgappa. I rebuilt the tokens from the stall itself: sand, tamarind, saffron, roasted brown, imli pani, fried puri.

What failed. I wanted a girl at the stall, pouring pani into a golgappa and reacting to each section as you scroll. Claude hand-drew her in SVG over three passes. The face worked, the arms never did: stroked limbs with separate hand shapes leave a lump where the outlines cross. After the third try the honest call was that hand-authoring a natural human figure in raw SVG paths was not going to get good, so we stopped iterating.

What worked. I generated her instead. One reference image from a detailed prompt, then three more moods generated from that image as the reference, changing only pose and expression, which is what kept her the same person. Backgrounds were cut out locally with sharp (flood-fill from the border, clear the big white gaps in the hair, keep small ones like eye whites, recolour the feathered edge so there is no white fringe on the dark theme). About 42 KB per pose as WebP. The image tool's schema was opaque, the free plan allowed one job at a time and I ran out of credits after four images, so the fifth mood reuses a pose.

Scroll bug. The first version used an IntersectionObserver and got silently stuck, because the figure itself carried data-mood so the observer kept picking her own mood. Then the footer never triggered because it is too short to reach the middle of the screen. One check per animation frame replaced both.

Day 3: dressing the page as an actual stall

Feedback was that the girl was right but the page still read like a SaaS template. So it became a thela: a scalloped awning with bunting in pure CSS, a signboard headline with पानी painted huge behind it, an LED ticker reading every area's state off Sanity, a chalkboard "Aaj ka menu" with the action where the price would be and the Shake the golgappa simulator running the real scoreReports from lib/risk.ts.

Bug caught by clicking, not by reading: three fast clicks on "+" counted two, because the stepper computed value + 1 from a stale render. Functional updates fixed it.

Deploy day

Vercel refused the first deploy: the Hobby plan only allows daily cron jobs and my vercel.json ran the case tick every 15 minutes. The tick only closes quiet cases and returns recovered areas to Crisp, so daily is enough.
I finally checked the IS 10500 numbers I had written from memory on Day 1. Every value was right, but two citations were wrong (chlorine is in Table 2, bacteria in Table 6). Because limits are content, the fix was a three document patch, not a code change. That was the schema decision paying off.
The hero said "Indore · live" right under a banner saying "Sample data". It now says demo.

3 October: auditing the decision path

I asked Claude to rate the project as a judge would. It gave functionality a 7, so I asked what would make it a 9.5. The answer was an audit of every path from report to alert, and it found real bugs:

The App SDK control room only ever wrote drafts. @sanity/sdk edits the draft unless the document handle says liveEdit: true. Confirming in the Dashboard made a draft alert the public site never saw. Now the decision, the alert and the area turning red go in one live-edit transaction.
"Mark fixed" had no button, so Fresh batch was unreachable from the control room.
A case could be confirmed twice, which made two alerts. Decisions now act only on cases waiting for a person, every write is guarded by the case _rev, and the alert id is derived from the case.
Server actions trusted the page. Server actions are public endpoints, so each one now checks the sign-in itself.
A reporter's phone number was one GROQ query away on a public dataset. Contact details now live in private.contact.<reportId> documents. Ids with a dot sit on a path that Sanity never returns to unauthenticated requests.
A date filter never matched. submittedAt is a string, and comparing it to dateTime(now()) without dateTime() was always false. Area pages showed no reports and the rate limit never fired. There is now a test that scans every GROQ string for that mistake.

The case rules became pure functions with tests, so "the scorer can raise a case to needs verification and never past it" is tested directly. Tests went from 11 to 29.

The last evening: a check from a stale copy

On the last evening I asked a local Claude Code session "what is left". It read an old copy of the project on my Mac that had no git remote and stopped at 21 September, so its first answer was confidently wrong. The mistake surfaced when a CLI deploy from that folder was blocked by Vercel: its commits were authored with an email the Hobby plan doesn't accept. That block saved me, because the deploy would have replaced the day's fixes with week-old code. Comparing the blocked deploy's metadata with the live one showed where the real repo was.

It still found things worth fixing. /api/cron/tick would run for anyone, because the secret check only ran if CRON_SECRET was set, and it wasn't. Now the secret is set and the route fails closed on any deployment. The citation fix had been written but never run against the live data. Two old write tokens from before the rotation were still active, and are now deleted. Then I confirmed the Sector 14 case myself in the control room and watched the area go red on the map.

What I deliberately did not build

Photo upload on reports. Asset uploads need the write token path designed properly and a reading carries more weight than a blurry photo.
A Hindi interface. The content is bilingual (area names, advice, alert precautions), the UI chrome is still English.

Sanity Project Details

Project ID: ya4g5th1
Dataset: production (public)
Schema: sanity/schemaTypes/ (9 types), workflow: sanity/workflows/waterCase.ts, App SDK app: control-room/, scheduled Function: functions/daily-tick/ with sanity.blueprint.ts

I built The Repair Line: turning small repairs into shared relief

Reet Singh — Mon, 07 Sep 2026 08:04:32 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

I built The Repair Line, a community-repair platform for the small shared things that keep a neighbourhood moving: a broken public hand pump, a leaking roof above a ration counter, a damaged study desk, or a clinic fan that has stopped working.

The goal is to make generosity visible and practical. Someone uploads a clear photo of a repair need, receives an AI-assisted assessment, and can add it to a local repair line where people can see the impact, the directional cost, and the amount already pledged.

Each repair includes:

a real repair photo and a short explanation
severity, people affected, and a directional INR cost range
funding progress
a before-and-after proof-of-repair concept

The experience is designed to feel warm and community-led rather than like a generic fundraising dashboard. It starts with local repairs, but the city selector supports Lucknow, Kanpur, Prayagraj, Varanasi, and an all-cities view.

Demo

Live app: The Repair Line

Try the flow:

Choose a city from the location selector.
Browse local repair needs or click Show all repairs.
In Assess a repair, upload a clear photo of a broken shared item.
Receive an assessment of severity, plausibility, likely repair cost, and reasoning.
Add the assessed repair to the line.

Code

The project is built with React and Vite, with API routes prepared for Vercel Functions.

Repository: github.com/Reet24-del/the-repair-line

Key pieces of the implementation:

React interface and location-aware repair feed
Gemini-backed server-side assessment endpoint
Snowflake-backed repair, pledge, sort, and city-filtering queries
Vercel deployment and API routes

How I Built It

Starting with a small but meaningful problem

I wanted to focus on generosity that is easy to understand. Not every community need requires a huge campaign. A ₹2,000–₹10,000 repair can make a real difference when it restores a shared tap, desk, roof, or fan.

The product flow became: photo in, fixed out.

AI assessment with Google Gemini

The repair assessor accepts a photo and sends it to a server-side Gemini route. Gemini is asked to return structured JSON with:

{
  "severity": "Low | Medium | High",
  "cost": "a directional INR range",
  "plausibility": "Likely genuine | Needs review | Unclear",
  "reasoning": "a concise explanation"
}

I require a photo before an assessment can run. This prevents the interface from creating a confident-looking repair result without visual evidence. The cost is intentionally presented as directional guidance rather than a quote.

Repair feed and Snowflake

Repair records include the repair title, location, severity, estimated cost, people helped, reason, image, and pledged amount. The Snowflake schema and query layer support feed filters for city, severity, and sorting.

The feed initially keeps the page focused by showing a smaller set of repairs. A Show all repairs control expands the complete list, while the city selector changes the listings and heading to keep the experience locally relevant.

Deployment

The frontend is deployed on Vercel, while Vercel Functions host the assessment, repair, and pledge endpoints. Sensitive credentials stay in server-side environment variables rather than the browser bundle.

Prize Categories

Best Use of Google AI

The project uses Google Gemini to analyse an uploaded repair photo and produce a structured, user-facing assessment. Gemini helps translate a visual problem into understandable severity, plausibility, repair guidance, and an INR cost range.

Best Use of Snowflake

Snowflake provides the repair data layer for listings and pledges. The app is designed to query repairs by city, severity, and priority, so a growing local repair line remains filterable and useful.

The Repair Line is a small idea on purpose: make a modest, shared repair easy to see, trust, and complete.

The Answer Looked Right. That Was the Problem.

Reet Singh — Sun, 30 Aug 2026 16:28:44 +0000

I started building The Verifier because of a slightly uncomfortable thought:

What if an AI gives you a perfectly written answer based on yesterday's truth?

Not a hallucination. Not an obviously fake source. Just an answer that used to be correct.

That felt more dangerous.

A polished lie is easy to fear. An outdated fact wearing a confident suit? That one can quietly walk straight into reports, presentations, articles, and important decisions.

So I decided to build something that would not simply answer a claim.

It would argue with itself first.

Meet The Verifier

The Verifier is an evidence-first research assistant for public claims.

You give it a claim such as:

Verify that Brian Niccol is the CEO of Starbucks.

Instead of immediately producing a confident paragraph, it investigates the claim from two opposing directions.

One research lane looks for evidence supporting the claim. Another actively searches for credible evidence contradicting it.

This matters because normal search behaviour has a bias: once we find one convincing source, we usually stop looking.

The Verifier does not get that luxury.

It has to search both sides, place the evidence next to each other, and show its work.

Then Starbucks created the perfect plot twist

The Starbucks leadership example turned out to be a great demonstration.

One public source identifies Brian Niccol as Starbucks' current chairman and CEO.

Another Starbucks source names Laxman Narasimhan as CEO.

Both sources are real. Both come from Starbucks. Both look authoritative.

So which one should the system trust?

This is where the project became more than a fancy search interface.

The answer was hiding in the metadata.

Dates are boring—until they solve the mystery

Most people do not get excited about fields such as datePublished, dateModified, or ISO timestamps.

Honestly, neither did I.

But those tiny pieces of metadata became the detective of this story.

The Verifier extracts machine-readable dates from every source. It records which metadata field was used, preserves the original value, and normalizes the date to UTC.

Now the system can compare evidence deterministically.

It does not choose a source because it sounds more confident. It can explain that one source represents an older leadership announcement while another contains newer evidence about the company's current leadership.

That difference matters.

The conclusion is not merely:

Brian Niccol is CEO.

It becomes:

The claim is supported by newer public evidence. The conflicting source is legitimate, but outdated.

Suddenly, the contradiction is not something to hide. It is part of the explanation.

I wanted the disagreement to remain visible

A lot of AI tools clean up the messy middle.

You provide a question. Something complicated happens. A neat answer appears.

Magic.

Also slightly terrifying.

I wanted The Verifier to show the messy middle.

The interface keeps the supporting and conflicting evidence in separate lanes. Each source displays its role, URL, relevant statement, and date information.

The user can inspect why the system reached its conclusion instead of being asked to trust a glowing confidence score.

Because “97% confident” sounds impressive, but it does not tell me whether the model checked last year's announcement against today's leadership page.

Evidence does.

The voice feature fought back

I also wanted the experience to feel conversational.

The original idea was simple: click Speak brief, say the claim, and continue asking questions naturally.

The browser had other plans.

At one point, the button barely behaved like a button. Then voice mode required clicking it repeatedly. Even worse, every new interaction felt like the previous conversation had been erased from existence.

The Verifier had the memory of a goldfish with Wi-Fi.

That forced me to rethink the feature.

Voice could not be a one-shot transcription gimmick. It needed to be a continuous conversation where the active claim, collected sources, and date resolution remained available for follow-up questions.

I also added text as a permanent fallback because demos—and browsers—have a wonderful sense of dramatic timing.

The agent can research. It cannot press Save for you.

This became my favourite part of the project.

After completing the investigation, The Verifier does not automatically store the result.

It asks the user for approval.

That is not just a polite message in the interface. The restriction is enforced on the server.

The server creates a one-time approval token and refuses to persist the dossier until explicit approval is received. Export remains locked as well.

If the user chooses to keep investigating, nothing is saved.

Only after server-confirmed approval does the dossier become permanent and downloadable.

The system can investigate, compare, and explain.

The final decision still belongs to a human.

Of course, the build was not a straight line

The first UI used fictional “Maya Chen” and “Northstar AI” evidence while the backend used the real Starbucks case.

Very coherent. Absolutely no notes.

That mismatch had to go.

Then came GitHub authentication, voice bugs, disappearing conversational context, provider configuration, Groq setup, and a Daytona API key that continued rejecting me like it had a personal grudge.

Some parts worked immediately. Several parts worked only after I stopped assuming they worked. A few parts smiled during testing and broke the moment I opened the demo.

That is the real version of building for a hackathon.

It is not one cinematic montage with energetic music. It is a series of tiny mysteries, questionable browser tabs, and commits that begin with the word “fix.”

But each problem improved the project.

The fictional demo became a real public case. The voice button became a conversation. The date field became an explanation. The approval message became a server boundary.

What The Verifier is really about

The Verifier is not trying to make AI sound smarter.

It is trying to make AI easier to question.

The important output is not only the final conclusion. It is the path:

What evidence supported the claim?
What evidence contradicted it?
Which source was newer?
Which metadata field proved that?
Why was the conflict resolved this way?
Did a human approve saving the result?

That path becomes an inspectable dossier that a researcher, journalist, policy team, or compliance reviewer can defend.

The internet changes. Leadership changes. Policies change. Yesterday's correct answer quietly becomes today's misinformation.

The Verifier is my attempt to catch that moment.

Not by asking you to trust another polished AI answer.

By showing you the evidence, explaining the conflict, and waiting for you to decide.

Verify first. Save only when you are ready.

🚀 Live demo: the-verifier.vercel.app

🔗 Project: github.com/Reet24-del/the-verifier

If you build with AI, I would love to know: what part of an answer do you wish AI tools showed more clearly?

Good Boy Amnesia: An AI Detective Game where Memory IS the Gameplay 🐶🧠

Reet Singh — Mon, 17 Aug 2026 07:04:29 +0000

This is a submission for the Weekend Challenge: Dog Days Edition

What I Built 🦴

Good Boy Amnesia is a detective game built for Dog Days where an AI agent's entire long-term memory lifecycle — remember → recall → memify → forget — is the gameplay loop, visualized as a live 3D knowledge graph in Three.js.

The Story:

Your owner Dev left you home alone last night, and you threw a legendary neighborhood puppy party. At 6:00 AM, your memory graph was corrupted. Dev arrives home at noon (12:00 PM), the living room is trashed, and his favorite leather slipper is missing.

You play Buster, a Golden Retriever whose mind is literally a knowledge graph. Reconstruct what happened last night, interrogate the neighborhood animals, purge false rumors, and find Dev's slipper before he walks through the door!

Demo & Screenshots 🎮

Live Game Demo: https://good-boy-amnesia.vercel.app (or your Hugging Face Space URL)
Video Walkthrough: (Optional link to your screen recording)

Gameplay Breakdown:

🔍 Investigate Hotspots: Explore 6 locations (Living Room, Backyard Lawn, Bella's Garden Fence, Dog Park, Lou's Oak Tree Stash, and Rooftop Sandbox).
🗂 File Clues (remember): Committing a fact adds glowing nodes to your live 3D memory graph in real-time.
💬 Interrogate Animals: Chat with Bella (the wise cat), Lou (the shifty raccoon), Rev. Rex (the howling Basset Hound), and Barnaby (the hungover pug). The characters read your live graph and react dynamically to your knowledge.
🧠 Connect the Dots (memify): Consolidate stored memories into derived inferences (e.g. realizing the slipper was locked in the treat safe before the party started).
🗑 Purge False Leads (forget): 5 red herrings are hidden in the story. Delete gossip from your memory log to keep your graph clean and win the case!
🎯 Tell Dev (solve): Reconstruct the timeline before noon to win in a burst of victory confetti!

Code Repository ⭐

GitHub Repository: github.com/your-username/good-boy-amnesia

How I Built It (Tech Stack) 🛠️

From My Father's Agricultural Knowledge to a Voice AI for Farmers

Reet Singh — Sat, 15 Aug 2026 16:12:54 +0000

My father has a master's degree in agriculture. Growing up around someone who had studied the subject deeply made me notice that a farming question is rarely as small as it sounds.

“Which crop should I grow?” can depend on soil, season, water, location, cost, and risk. A mark on a leaf might be harmless, or it might be the first sign of a problem that needs an expert. The useful answer is not the longest answer. It is the answer that understands the situation and helps someone decide what to do next.

A friend of mine made this gap feel real in a different way. He had land, money to invest, and an idea for an agriculture-related business. What he did not have was fluency in the subject. He could search online, but he did not always know which question to ask, which source to trust, or when general advice was no longer enough.

My father had the knowledge. My friend had the intent and the resources. Between them was a problem of access.

That problem is larger than one conversation. The Government of India's Digital Agriculture Mission describes the need for timely, reliable information and customised advisories for crop planning, crop health, pest management, and irrigation. Data may exist in many places, but a person standing in a field still needs a simple way to reach the right information.

I kept returning to one thought: what if asking for farming help could feel less like operating software and more like speaking to someone who listens?

That thought became Kisan Sahayak.

The assistant I wanted to build

Kisan Sahayak is a browser and phone-based voice AI assistant for Indian farmers and people beginning an agricultural venture. A user can speak in English, Hindi, or Hinglish and ask about crops, soil, irrigation, local weather, or an emerging crop problem.

The assistant can fetch live data, remember useful details with permission, place a controlled advisory call, create a human-help request, measure whether a conversation achieved its purpose, and transfer crop symptoms to a separate specialist agent.

It is not meant to replace an agronomist. Its job is to shorten the distance between a spoken question and a safe next step. When it does not have reliable data, it should say so. When a case needs a specialist or a person, it should stop pretending to be enough.

I built it during 10 Days of Voice Agents — VoiceForBharat Edition. Its speech is powered by Murf Falcon. Murf describes Falcon 2 as a real-time speech model with roughly 100 ms time-to-first-audio and the ability to switch languages within a sentence, both of which matter in a conversation that may move naturally between Hindi and English. You can read the technical details in the Falcon 2 documentation.

The source code is available here: github.com/Reet24-del/murf-livekit-starter

What happens when a farmer speaks

A voice assistant sounds like one system, but it is a chain of systems working quickly enough to feel like one conversation.

Deepgram Nova-3 converts speech into text. The project uses multilingual recognition so the caller can speak English, Hindi, or a mixture of both. Deepgram documents its supported models and languages in its model overview.
Google Gemini reads the latest request, conversation context, safety instructions, and available tools. It decides whether to answer, fetch data, ask for consent, or transfer control.
Murf Falcon converts the reply into speech. The main assistant uses the Anisha voice. The crop specialist uses Samar, so the caller can hear that a real handoff has happened.
LiveKit carries the audio and manages the real-time agent session between the browser or phone and the Python backend. Its documentation describes the same sequential STT–LLM–TTS pipeline used in this project.

Farmer speaks
     |
     v
LiveKit room
     |
     v
Deepgram STT ---> latest-turn language detection
     |                         |
     v                         v
Google Gemini <--- memory, tools, consent, safety rules
     |
     +---- routine question ----> Kisan Sahayak
     |
     +---- crop symptoms -------> Crop Problem Specialist
     |
     v
Murf Falcon TTS
     |
     v
The farmer hears the answer

Supporting services:
Open-Meteo -> live district weather
SQLite     -> consented memory, help requests, and call outcomes

This architecture gave me a useful separation of responsibilities. The language model handles conversation. Tools handle facts that can change. SQLite handles information that must survive after a call. The specialist handles a narrower class of problems. The frontend tells the user what the system is doing.

Ten days, one layer at a time

The project did not begin with all of these abilities. Each daily task exposed a weakness in the version from the day before.

Day 1: Giving the idea a voice

The first version had one goal: complete a live voice loop.

I connected Deepgram speech-to-text, Gemini, Murf Falcon text-to-speech, and LiveKit transport. For the first time, I could speak into the browser and hear the assistant answer. During my local tests, the observed time-to-first-audio ranged from 137 ms to 263 ms. Those numbers are local observations, not a universal benchmark, because network, region, model, and device all affect perceived latency.

The early success was exciting, but it also revealed a truth about voice products. A correct answer can still feel wrong if the pause before it is too long. Latency is part of the conversation design.

Day 2: Deciding who the agent should be

A working voice loop is not yet an assistant. On Day 2, I gave Kisan Sahayak a clear role, tone, and boundary.

It would answer only farming and local-weather questions. It would keep spoken replies short. It would never invent current market prices, subsidy details, pesticide doses, or long-range weather. Hindi replies would use Devanagari. English replies would remain English. Hinglish could stay in Roman script.

I also tested hostile and out-of-scope prompts. This was where the project moved from “Can it answer?” to “Can it answer responsibly?” The biggest lesson was that refusal behavior must be designed with as much care as the happy path.

Day 3: Making the invisible conversation visible

Voice interfaces can be confusing when the screen gives no feedback. Is the microphone active? Is the agent thinking? Has the session ended?

I built a browser interface that shows clear states: ready, connecting, listening, thinking, speaking, transferring, and ended. I added a live transcript, a weather panel, saved memory, and controls that avoid ending a call through an accidental tap.

The interface uses a dark field-inspired visual language, but its main purpose is practical. A user should never have to guess whether the assistant heard them.

Day 4: Building memory without taking ownership of the user's data

The assistant could remember a conversation while the session was open, then forget everything when the user returned. Day 4 added persistent memory through SQLite.

Kisan Sahayak can save a caller's name, district, crops, land size, irrigation type, preferred language, and a short summary. It saves new information only after permission. A direct instruction such as “Remember that my district is Lucknow” also counts as clear permission.

This distinction became important:

Conversation context helps during the current call.
Stored memory helps during a future call.

The database stores selected facts, not the full conversation. Python's sqlite3 documentation describes SQLite as a lightweight disk-based database that does not require a separate server, which made it a good fit for a local challenge build. A deployed version would need encryption, authentication, retention rules, and stronger access controls.

Day 5: Teaching the assistant to use real data

The model once gave the wrong current time. That failure made the next design decision obvious: anything described as “current” must come from a current source.

I added a function tool that fetches district weather from Open-Meteo and another that reads the system clock in the Asia/Kolkata timezone. The weather result includes its source time, current conditions, wind, temperature range, and rain probability. Open-Meteo documents the available current and forecast variables in its Weather Forecast API.

The failure path mattered as much as the successful response. The weather request has a timeout. If the service is down or returns incomplete data, the assistant says that live weather is unavailable and refuses to guess.

The tool description also mattered. The model decides whether to call a function from that description, so “use this for current weather, rain chance, temperature, wind, spraying, irrigation, sowing, or harvesting” produced better routing than a vague label such as “weather tool.”

Day 6: Moving from browser conversations to outbound calls

Some useful information should reach a farmer before they open a website. On Day 6, I added controlled outbound rain-advisory calls through LiveKit SIP, with Linphone or Twilio as the call provider.

This feature includes rules that are easy to overlook in a demo:

the recipient must have consented;
the destination must be valid;
calls are limited to 08:00–20:00 IST;
saved opt-outs are honoured;
the weather tool must run before a current advisory is spoken;
failed, unanswered, or declined calls receive a controlled outcome.

The hard part was not writing a dial command. It was connecting the SIP trunk, worker registration, dispatch rule, verified destination, and agent name without mixing credentials between services. Telephony made every configuration mismatch visible immediately.

Day 7: Knowing when to ask a human

An AI assistant should not stretch every problem until it sounds solvable. I selected two situations for human help: serious or rapidly spreading crop damage, and market information that is missing or stale.

The assistant first says what it plans to share: who needs help, what happened, what it checked, urgency, language, and the requested follow-up method. It then asks for a clear yes or no. If the caller declines, no request is created.

After consent, the system stores a short redacted summary and returns a reference ID. It does not store passwords, OTPs, PINs, account numbers, or a full transcript.

This day changed my understanding of escalation. “Contact an expert” is advice. A consented request with a reference ID and visible status is a workflow.

Day 8: Measuring whether a call helped

Before Day 8, I could see calls happen but could not answer a basic product question: did the conversation achieve anything?

I defined success for Kisan Sahayak as one of four outcomes: farming guidance delivered, live weather delivered, an expert request created, or an outbound rain advisory delivered. A call that ends before one of those conditions is recorded as failed even when the software did not crash.

The analytics dashboard reads real browser and SIP session records from SQLite. It shows total, successful, and failed calls, along with filters, trends, channels, languages, durations, and controlled failure categories. It stores no caller identity and no transcript.

This feature forced me to separate technical reliability from user success. A perfectly stable call in which the user leaves before receiving guidance is still a failed product outcome.

Day 9: Handing crop problems to a specialist agent

The main assistant had accumulated weather, memory, time, safety, escalation, and general farming responsibilities. Crop symptom triage needed a narrower role.

I created a separate Crop Problem Specialist. Reports of leaf spots, curling, wilting, pests, disease, nutrient deficiency, or unexplained crop damage trigger the handoff. The main assistant announces the transfer. The website displays “Connecting you to the specialist.” The specialist then introduces itself in a different Murf voice and continues with a copy of the existing conversation, so the farmer does not have to repeat the problem.

The specialist asks one focused question at a time, offers only low-risk first steps, and never claims a certain diagnosis from a voice description. LiveKit's agents and handoffs guide supports this pattern by allowing a tool call to return another agent while preserving conversation context.

The first version did not route correctly. Crop symptoms competed with the older human-escalation tool, so the assistant sometimes offered a human request instead of transferring the call. I fixed that by giving specialist-eligible turns deterministic priority and temporarily removing the escalation tool from that turn.

Day 10: Turning the build into something another person can use

The final day was not another agent feature. It was the work of explaining the system honestly.

I organised the repository, documented setup, checked that secrets and local caller data were excluded, added screenshots, and wrote down the failures that shaped the design. A public project is more useful when a reader can understand its limits, run it, and reproduce the important tests.

The ten-day sequence also made the product progression clear:

Conversation
   -> character and guardrails
   -> visible interface
   -> consented memory
   -> live tools
   -> outbound reach
   -> human help
   -> measurable outcomes
   -> specialist handoff
   -> documented, reproducible project

The bugs that changed the design

The useful lessons came from moments when the assistant behaved confidently but incorrectly.

English questions received Hindi answers

The original prompt described a bilingual assistant, but the bilingual greeting and earlier context sometimes outweighed the caller's newest sentence. An English question could receive a Hindi answer.

I moved language detection to every completed user turn. The latest turn now decides the response mode: English, Devanagari Hindi, or Roman-script Hinglish. Tests cover all three instead of checking only the opening greeting.

The fix taught me that language is not a profile setting. In a multilingual conversation, it is live session state.

The assistant sounded current without having current access

Knowing that a user is in India does not give a language model access to India's current clock. General weather knowledge is not today's weather either.

Time and weather now sit behind tools. Each returned value carries a time or timezone, and each failure has a spoken fallback. This removed the most dangerous kind of voice-agent error: a made-up answer delivered with a natural voice.

The call ended while the user was still trying to speak

Voice activity detection, turn detection, browser audio, silence timeouts, and session lifecycle all interact. In early runs, silence handling could mark the user away too quickly or the browser could disconnect before the final analytics record was written.

I increased the away timeout, avoided automatic disconnect on silence, added controlled re-prompts, and finalised analytics through the session shutdown path. The lesson was practical: real-time state bugs rarely belong to one layer.

The specialist and human-help paths collided

Both features dealt with difficult crop problems, but they served different purposes. The specialist continues the AI conversation. Human escalation creates a request after consent. Without an ownership rule, the model could choose either.

The final routing order is explicit. A crop symptom goes to the specialist first. Serious cases can later move to a human-help request, but only after the specialist path and only with permission.

How to run Kisan Sahayak

You will need Python 3.10–3.14, Node.js 20 or newer, uv, pnpm 9 or newer, a LiveKit Cloud project, and API keys for Murf, Deepgram, and Google AI.

1. Clone and install

git clone https://github.com/Reet24-del/murf-livekit-starter.git
cd murf-livekit-starter

cd backend
uv sync
uv run python src/agent.py download-files

cd ../frontend
pnpm install
cd ..

2. Create private environment files

cp backend/.env.example backend/.env.local
cp frontend/.env.example frontend/.env.local

Add the following values to backend/.env.local:

LIVEKIT_URL=
LIVEKIT_API_KEY=
LIVEKIT_API_SECRET=
MURF_API_KEY=
DEEPGRAM_API_KEY=
GOOGLE_API_KEY=

The frontend needs the same LiveKit project and the explicit agent name:

LIVEKIT_URL=
LIVEKIT_API_KEY=
LIVEKIT_API_SECRET=
AGENT_NAME=kisan-sahayak-primary

Both .env.local files are ignored by Git. Never publish API keys, SIP trunk IDs, phone numbers, caller records, or backend/memory.db.

3. Start the application

chmod +x start_app.sh
./start_app.sh

Open http://localhost:3001, select Start Call, and allow microphone access. The frontend and backend must use the same LiveKit project and agent name.

4. Test the two agent routes

Ask a routine question:

What is today's rain chance in Lucknow?

The main assistant should call the live weather tool and answer in English.

Then begin another call and report a crop symptom:

My tomato leaves have black spots and are curling.

The main assistant should announce a transfer. The interface should display the specialist connection state, and the crop specialist should continue without asking you to repeat the symptom.

End the calls and open http://localhost:3001/call-analytics. The total should increase, and each call should be classified from its real outcome.

What Kisan Sahayak could change, and what comes next

My friend's original difficulty was not a lack of ideas. It was the gap between an idea and informed action. Kisan Sahayak reduces that gap in a few specific ways.

It lets someone begin with the words they already know. It remembers location and crop details after consent, so a returning user does not start from zero. It brings live weather into the same conversation as crop planning. It recognises when a problem belongs to a specialist. It also leaves a visible trail when a human request is created or a call fails to reach its goal.

The current version remains a prototype. Its crop guidance should be strengthened with an agronomist-reviewed knowledge base. District-level mandi prices need a dependable live source and clear timestamps. Photo-assisted crop triage could add evidence that voice alone cannot provide. The local SQLite database should move to encrypted hosted storage with authentication and role-based access before public deployment. Finally, field testing across different accents, devices, and network conditions should shape the next round of changes.

My father’s education reminds me how much context sits behind a reliable agricultural answer. My friend’s plan reminds me how difficult that context can be to reach when someone is starting out. Kisan Sahayak is my attempt to make the first step easier while preserving the point at which software should call a specialist or ask a person for help.

Sources and further reading

Last Light: The Demon Lord Awaits at Dawn

Reet Singh — Fri, 19 Jun 2026 17:32:23 +0000

Last Light is an intense, top-down survival arena shooter inspired by Alice in Borderland. The game is deeply tied to the Solstice theme of Light vs. Darkness and the passage of time.

As a lone samurai, you are trapped in a 12-hour cycle (from 18:00 to 06:00). Your weapon is a "Spirit Slash" that relies entirely on Solar Energy. To survive the encroaching dark and the endless hordes of demons, you must constantly seek out golden "Sanctuaries" to recharge your light.

As the hours tick by, the darkness grows stronger, and the arena itself evolves against you:

21:00 (The Walls Rise): Massive cursed barriers emerge, forcing you into a maze.
00:00 (Midnight): Lethal, rotating lasers ignite across the arena.
03:00 (Spirit Fading): The safe sanctuaries detach and begin moving erratically.
05:00 (The Demon Lord): The final shadow descends. The goal was to create a high-stakes, fast-paced game where the environment is just as deadly as the enemies, perfectly capturing the feeling of fighting through the longest, darkest night of the year to finally see the sun rise.

Video Demo

Code

Reet24-del / last-light

Last Light: A June Solstice Survival Arena

Last Light is an intense, top-down survival arena shooter built for the June Solstice Game Jam. It features dynamic mechanics inspired by Alice in Borderland, where the arena itself evolves to become your greatest enemy as the hours pass.

The Theme: Light, Darkness, and the Solstice

As the June Solstice arrives, the game explores the balance between light and darkness. You must constantly seek the golden "Light Zones" to recharge your solar weapon while fending off creatures of the dark. As the 12-hour cycle progresses, the darkness encroaches, and the arena becomes progressively more hostile.

The Mechanics

Solar Weaponry: Your weapon drains Solar Energy instead of ammo. You must stand in golden light zones to recharge.
Map Evolution: Over the course of 12 hours (waves), the arena evolves
- 09:00: Massive neon walls rise from the ground, creating an impenetrable maze.
- 12:00: Lethal…

View on GitHub

How I Built It
I built the game entirely from scratch using React and HTML5 Canvas, with Vite as the build tool.

Technical Highlights:

Custom Game Engine: Instead of using a heavy game framework like Phaser or Unity, I built a pure requestAnimationFrame loop inside a React useEffect. React handles the state management, HUD, and overlays (like the Turing minigame), while the Canvas API handles rendering thousands of particles, enemies, and complex hitboxes at 60 FPS.
Map Evolution: I implemented dynamic rectCircleCollision and lineCircleCollision algorithms. This allowed me to spawn solid maze walls mid-game that block both player movement and enemy pathing, as well as sweeping lasers that deal precise damage.
Twin-Stick Mobile Support: I wrote native Multi-Touch event listeners (touchstart, touchmove, touchend) to intercept mobile interactions. Dragging on the left half of the screen creates a dynamic virtual joystick for movement, while dragging on the right controls the samurai's slash angle. The canvas scales responsively to any viewport using CSS object-fit.

Prize Categories

I am submitting Last Light for the following bonus categories:

Best Google AI Usage: The hyper-realistic, dark futuristic arena background (the neon-lit floor grid) was generated entirely using Google's Imagen AI models. This gave the game a premium, Alice in Borderland visual aesthetic that perfectly matched the "Darkness" theme.
Best Ode to Alan Turing: In honor of Alan Turing's legendary code-breaking legacy at Bletchley Park, the game features a Spades-style decryption minigame during pivotal hours. Time completely freezes, and a "TURING DECRYPTION REQUIRED" overlay appears. Players must read an 8-bit binary tape and decrypt it into the correct decimal number before the demons consume them. This directly honors his contributions to algorithms and modern computing by making code-breaking a literal survival mechanic!