DEV Community: Yash Gurav

I gave NPCs a graph database. Now the whole village knows I stole an apple.

Yash Gurav — Sat, 17 Oct 2026 11:41:38 +0000

description: Hearsay is a memory-and-gossip engine for game characters built on FalkorDB. Villagers remember what they see, spread rumours along trust, exaggerate them, and can explain exactly who told whom.
cover_image:

I stole an apple in a video game. Only the merchant saw it.

By evening, the innkeeper had heard I robbed his stall. By night, the town guard had heard I robbed the market. Next morning, the guard, who never saw a thing, blocked the town gate.

So I asked her why. She told me: "I heard it from Bertha; Bertha heard it from Old Tomas; Old Tomas saw it first-hand."

That's Hearsay, the project I built for Graph Hacks: Context for AI Agents (WeMakeDevs × FalkorDB). It's a small 3D game, but the real thing is the engine underneath: game characters whose memories, beliefs and relationships live in a graph.

▶ Play it: https://hearsay-six.vercel.app
📦 Code: https://github.com/Yashgurav002/hearsay

The problem: NPCs are amnesiacs

Game characters forget everything. The shopkeeper greets you warmly five seconds after you robbed them. And when games do remember, it's usually a single number, a "reputation" or "honour" meter, that every character somehow knows instantly. Nobody heard it from anyone, nobody misremembers it, and nobody can tell you where it came from.

Real reputation doesn't work like that. It travels person to person, only between people who trust each other, it changes in the retelling, and it takes time to reach the next town.

Underneath, this is an agent-memory problem, not a game problem. Agents that share a world need:

memory that persists;
knowledge that moves between agents only through realistic channels;
a record of where each belief came from;
decisions you can trace.

That's a graph.

The idea: memories, beliefs and trust as a graph

Here's the whole model for one rumour chain:

(Tomas)-[:WITNESSED]->(Event: theft at the market)
(Tomas) -[:HOLDS {confidence: 1.00}]-> (Rumour sev 1: "took an apple")      ─┐
(Pip)   -[:HOLDS {confidence: 0.45}]-> (Rumour sev 2: "stole a basket")      │ each one
(Bertha)-[:HOLDS {confidence: 0.75}]-> (Rumour sev 3: "robbed the stall")    │ -[:ORIGIN]->
(Ilsa)  -[:HOLDS {confidence: 0.51}]-> (Rumour sev 4: "robbed the market")   │ the real Event
                                                                            ─┘
 Pip's version   -[:HEARD_FROM]-> Tomas's version
 Bertha's version -[:HEARD_FROM]-> Pip's version  AND  -[:HEARD_FROM]-> Tomas's version
 Ilsa's version  -[:HEARD_FROM]-> Bertha's version

 (Ilsa)-[:TRUSTS {weight: 0.75}]->(Bertha)-[:TRUSTS {weight: 0.8}]->(Tomas)

An Event is what actually happened.
A Rumour is one villager's version of it. Every retelling creates a new Rumour node for the listener, with its own wording, severity and confidence.
HOLDS carries how sure they are. HEARD_FROM is the provenance chain. ORIGIN always points back to the truth, however distorted the story got.
TRUSTS is directed: "Ilsa trusts Bertha" means Bertha can tell Ilsa things.

Each player gets their own graph (hearsay_<playerId>), created with GRAPH.COPY from a read-only template village. That gives per-player memory isolation from the database itself, not from WHERE player = ... filters I might forget.

Three queries that do the real work

1. Who can gossip right now?

Every in-game hour, villagers move to their scheduled places. Then one pattern match finds every possible conversation:

MATCH (a:Villager)-[:AT]->(pl:Place)<-[:AT]-(b:Villager)
MATCH (b)-[t:TRUSTS]->(a)
RETURN a.id AS teller, b.id AS listener, t.weight AS trust, pl.id AS place

Read it as: A and B are in the same place, and B trusts A, so A can tell B things. That one line is why gossip in Hearsay feels social. The guard never hears anything from the kid, because she doesn't trust the kid.

When A tells B a story, B gets their own version:

CREATE (b)-[:HOLDS {confidence: $conf, since: $tick, last_reinforced: $tick}]->
       (r:Rumour {id: $id, text: $text, severity: $severity, hops: $hops})
CREATE (r)-[:HEARD_FROM {tick: $tick, place: $place}]->(src)
CREATE (r)-[:ORIGIN]->(e)

The maths is kept simple on purpose:

Confidence drops every hop: teller's confidence × trust × 0.9.
Severity can climb one step on a fixed ladder ("took an apple" → "stole a basket" → "robbed the stall" → "robbed the market" → "is part of a gang of thieves") with the teller's exaggeration chance. Pip, the village kid, exaggerates 80% of the time.
If B already knows the story from someone else, no new node is made. B gets a second HEARD_FROM arrow and corroboration raises their confidence: 1 − (1 − old) × (1 − new). Two people telling you the same thing makes you more sure.

2. "Why do you think that?"

This is the query I'm proudest of, because it's the one that would be painful anywhere but a graph:

MATCH (v:Villager {id: $villager})-[h:HOLDS]->(r:Rumour)-[:ABOUT]->(:Player {id: $player})
WITH r, h ORDER BY h.confidence DESC LIMIT 1
MATCH path = (r)-[:HEARD_FROM*0..6]->(o:Rumour)-[:ORIGIN]->(e:Event)
WHERE o.hops = 0
WITH path, e ORDER BY length(path) ASC LIMIT 1
RETURN [n IN nodes(path) WHERE n:Rumour | n.id] AS rumour_ids, e.base_text AS what_happened

Take the villager's strongest belief and follow HEARD_FROM arrows, zero to six of them, back to someone who saw it first-hand (hops = 0). The *0..6 covers "I saw it myself" for free. In SQL this is a recursive self-join; here it's one pattern, and it runs in about 2 ms.

The game turns the result into a comic strip, so you can watch the story get worse hop by hop:

3. Whose word spreads furthest?

CALL algo.pageRank('Villager', 'TRUSTS') YIELD node, score
RETURN node.name AS villager, score ORDER BY score DESC

TRUSTS points from a listener to the person they believe, so PageRank flows toward the most-believed villagers. Bertha the innkeeper comes out on top. Add algo.WCC over strong trust for cliques ("the inn crowd", "the chapel pair"), algo.betweenness for brokers, and shortestPath for the fastest route to get a story to someone, and you have a spymaster that helps the player plan:

"Captain Ilsa trusts Bertha most (0.75). Bertha will be at the inn from 10:00: do a good deed where she can see it, or whisper it to Pip, who reaches her in 1 hop."

Graph algorithms as tools for an agent, and the player's way out of the mess.

The design choices that made it believable

A distortion ladder, not free-form AI exaggeration. The engine decides the severity (1–5). The language model only rephrases it in the teller's voice ("Oh my stars, the traveller just snatched Tomas's stuff!"). The distortion is real, deterministic and testable, because it's in the graph.
The echo-chamber guard. A story is never told back to the person it came from. Otherwise two friends would keep "confirming" each other's rumour until they were 100% sure. In Cypher that's a variable-length pattern predicate: NOT (r)-[:HEARD_FROM*1..6]->(mine).
The sceptic. Mira the blacksmith ignores any rumour with fewer than two different tellers.
Forgetting. Every in-game midnight, beliefs nobody reinforced in 24 hours fade (confidence × 0.97).
Procedural memory. Behaviour lives in Rule nodes, like "guard: block the gate below opinion −0.3" or "guard: treat a gift as a bribe if she already distrusts you". The code evaluates the rules; the model never decides anything.
Two coordination channels. Gossip is informal. When the guard gets really angry, she posts a wanted notice at the gate, and anyone who walks past reads it. That's shared state between agents.

Why the AI doesn't hold the memory

It's tempting to throw everything into an LLM's context and call it memory. But a chat history:

grows until it doesn't fit;
vanishes between sessions;
can't be shared selectively between characters;
can't tell you where a belief came from.

The graph does all four.

So the villager agent loop is perceive (graph queries) → decide (code, from Rule nodes) → speak (AI, with only the facts the graph returned) → remember (graph write). I tested it over 50 scripted conversations with Gemma 3 4B running locally: 0 / 50 replies mentioned a villager outside the speaker's graph context. If the model is off or slow, template lines built from the same facts take over, and the game never breaks.

The numbers

Measured on a laptop with FalkorDB in Docker:

What	Result
Belief + opinion reads, 500 player worlds alive in one FalkorDB	~1 ms p50, 2.3 ms p95, flat from 10 to 500 worlds
A full hour of village gossip (~20 queries)	~15 ms
"Why?" end to end	7.7 ms
Theft reaching the guard, over 50 seeds	50/50 times, median 9 hours, arriving at mean severity 2.5

What broke (and how I fixed it)

The honest part. These are the things that cost me real time:

Duplicated rows from an OPTIONAL MATCH. My first echo-chamber guard was OPTIONAL MATCH echo = (r)-[:HEARD_FROM*1..6]->(mine) when mine could be null. FalkorDB expanded it to every path and duplicated the rows, while echo still read as null. The guard told Ilsa the same rumour twice in one hour. Moving the check into a WHERE pattern predicate fixed it.
GRAPH.COPY under load. The load test died with could not fork: copies fork the server, and two at once fail. I serialised copies behind a lock with a short retry.
ORDER BY length(path) after RETURN errored because path wasn't projected. Ordering in a WITH first fixed it.
A thinking model in a game loop. Gemma 4 on AI Studio always emits a <thought> block before answering, sometimes runs out of tokens mid-thought, and took 14–34 s per call. I strip the thought block and retry server errors. Retellings are written instantly with template text and reworded in the background, so ticks never wait on the model. The hosted demo uses templates; local play uses Gemma 3 4B on Ollama (~1–4 s).
A Promise that crashed React. Chrome's scrollIntoView() now returns a Promise. An arrow-body useEffect returned it, React tried to call it as a cleanup function, and the whole page unmounted. Effects get block bodies now.
Vercel guessed wrong. It saw fastapi in requirements.txt, picked the FastAPI preset, and sent every request, even /, to Python. Pinning "framework": "vite" made the frontend static and kept Python for /api.

Beyond one village

The village is a demo. The reusable part is a small contract: events go in ("theft happened here, these characters are here"), and beliefs, opinions and explanations come out ("the guard believes you robbed the market, at 0.51 confidence, because Bertha told her").

Picture that in an open world:

A shop clerk sees a robbery and tells a cousin in a gang, and the gang prices you differently.
A bard carries "slew a griffin bare-handed" to the next town.
A sceptical alderman won't believe it until two people say so.
Tracing a rumour to its source becomes the detective mechanic.

A GTA-sized world would need gossip "level of detail" (full simulation only near the player), region graphs and batched ticks. But the model and the queries stay the same, and at ~1 ms per lookup, per-character graph reasoning is affordable.

Try it

▶ Play: https://hearsay-six.vercel.app. Steal an apple, skip to the evening, then ask the guard "Why?". The 🔭 Spyglass shows the live graph, PageRank and every Cypher query as it runs.
📦 Code, graph model and all 45 Cypher queries: https://github.com/Yashgurav002/hearsay
🛠️ Stack: FalkorDB, FastAPI, React + Three.js, Gemma.

Yashgurav002 / hearsay

NPCs that remember what you did, and gossip about it. A 3D game + NPC memory engine on a FalkorDB graph (Graph Hacks 2026).

Hearsay: Everyone's talking about you.

A memory engine that lets game characters remember what you did, gossip about it, and explain exactly who told whom, built on a FalkorDB graph. It's playable here as a small 3D village. The same engine is a baseline for NPC memory in any open-world or story game.

▶ Play it live: https://hearsay-six.vercel.app · Repo: https://github.com/Yashgurav002/hearsay

Hackathon: Graph Hacks: Context for AI Agents (WeMakeDevs × FalkorDB) Tracks: Track 02 — Agent Memory and Coordination (primary) · Track 01 — Agents That Act on Connected Data

Docs: How to play · Reading the graph (every chart in the UI explained) · Architecture · Measured results · Decisions

Why this is a baseline for NPC memory in any game

The village is a demo. The reusable part is the engine underneath: a graph that stores what every character saw, what they've heard, from whom, and how sure…

View on GitHub

Built for Graph Hacks: Context for AI Agents (WeMakeDevs × FalkorDB). AI disclosure: I built this with an AI coding assistant (Claude Code) for much of the code and this write-up, and reviewed it myself; in-game voices use Gemma. All villagers, places and events are fictional.

My dad's PF clients wait weeks for their own money over one wrong

Yash Gurav — Sat, 17 Oct 2026 11:28:43 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

My dad is a Provident Fund (PF) consultant in Vasai, near Mumbai. He handles PF for dozens of small companies: monthly filings, and the claims workers file when they leave a job and want their savings back.

The part that hurts is rejections. A worker's father's name is "Kannen Krishnadas Bhat" in the EPFO records and "Kannen Bhat" at the bank. Nobody notices. The claim goes in, and three weeks later EPFO rejects it with a remark like:

F/H NAME NOT MATCHING WITH BANK A/C. PL SUBMIT CORRECTED CHQ

The worker waits even longer for their own money. My dad gets the calls: "PF kab aayega?" ("When will my PF come?"). This isn't rare. EPFO's 2024-25 annual report puts it at roughly 1 in 5 claims rejected (Business Today), and for final settlements it was about 1 in 3 in 2022-23 (The Ken).

PF Desk is a back office for PF consultants. It does the experienced colleague's job:

Pre-check before filing. It compares names, father's name, date of birth, bank, KYC, Aadhaar link and exit date across records, and says exactly what to fix and which rule says so.
Rejection risk and settlement date. TabPFN, trained on past claims, says "High, 59%" and "likely by 29 October".
Rejection Decoder. Paste EPFO's cryptic remark and get the real reason, the fix steps, and a message for the worker in Hindi, Marathi and English. This is a model I fine-tuned with Tinker.
WhatsApp drafts to the worker in their language, ready to copy.
A private help link for workers. "Mera PF kab aayega?" gets answered from their own claim's facts. Anything off-script, like a loan question, goes to the consultant as a task.
The monthly cycle per client company, as durable Temporal workflows: ask for the salary sheet, validate contributions, chase, remind before the due date.
A Rule Book where every rule cites its source, editable by the consultant.

Who pays: independent PF consultants like my dad. They charge small employers about ₹1,000–2,400 a month per client for PF compliance (listings on IndiaMART). At ₹499–999 a month, PF Desk costs less than one client brings in. It pays for itself if it saves one rejected claim's worth of re-filing and phone calls.

Demo

Live demo (synthetic data only): https://pfdesk.buildwithyash.tech · passcode demo

The free hosting sleeps when idle, so the first visit can take about a minute, and AI answers on the free Gemma API take 15–40 seconds. On the laptop, which is how a consultant actually runs it, they take a few seconds. The video is recorded locally.

Code

Yashgurav002 / pf-desk

PF Desk

Private back office for Provident Fund consultants: pre-checks claims before EPFO rejects them, decodes rejection remarks, estimates settlement dates, and answers employees in Hindi / Marathi / English. Open models only (Gemma via Ollama); real data stays on the consultant's machine.

PF Desk helps consultants prepare and check. It does not file with EPFO, and it is not legal or financial advice. Rules change: always verify with the latest EPFO circulars.

Live demo (synthetic data): https://pfdesk.buildwithyash.tech · Spec: PFDESK_PRD.md · Progress: TASKS.md · License: MIT

Run locally

Needs Node 24+, pnpm, and Ollama with gemma3:4b and nomic-embed-text.

ollama pull gemma3:4b && ollama pull nomic-embed-text
pnpm install
pnpm --filter tabpfn setup  # Python venv for TabPFN (CPU torch); optional — API falls back to baselines
cp .env.example .env      # DEMO_MODE=true loads synthetic data
pnpm dev                  # web http://localhost:3000 (passcode: demo), API :8787, TabPFN :8790
pnpm seed                 # wipe

…

View on GitHub

MIT licensed. TypeScript (Hono API + Next.js), Python for the ML pieces, Postgres + pgvector.

How I Built It

The rule I set on day one: an AI never decides anything a rule can decide, and never sees an identifier.

1. Deterministic checks first. Pre-check is plain code driven by Rule Book parameters. Name matching understands Indian name variants: initials ("R. K. Patil"), transliteration (Sunita/Suneeta), and bank-style CAPS. On 800 planted errors it catches all 800, with 0 false alarms on 1,000 clean claims. That's synthetic, so it only proves the rules fire as designed.

2. TabPFN for risk and settlement time. The open TabPFN v2 runs locally on CPU as a small service. Pre-check calls it through two functions, predictRisk and predictEta, with de-identified columns only: form type, service months, match flags, office. No names, no IDs. On a time-ordered split it beat every baseline at ranking risky claims:

Model	ROC-AUC	Brier
Rejection rate per form	0.549	0.240
Gradient boosting	0.751	0.202
Logistic regression	0.817	0.166
TabPFN	0.834	0.163

Settlement-time error dropped from 3.67 to 2.92 days. The history is synthetic for now; every claim PF Desk sees settled or rejected becomes a new training row automatically.

3. Tinker for the Rejection Decoder. EPFO remarks are terse and inconsistent. I fine-tuned Qwen3-8B with a LoRA on Tinker to turn a remark into strict JSON: {category, fields_involved, fix_step_ids}. Gemma then writes the human messages from that JSON.

The interesting part was the evaluation. My first test set was synthetic, and the model scored 94%, which proved nothing. So I collected 148 real remarks that members had posted publicly, and kept them out of training. On those, 43% fit none of my 15 categories. They were pension (EPS) membership problems, contribution gaps, pending transfers and TDS. I added five categories, wrote new training templates in my own words, and retrained twice. Total training cost on Tinker was about $1.65.

On 148 real remarks	Accuracy
Gemma 3 4B, few-shot	53%
Qwen3-8B, no fine-tune	58%
Qwen3-8B + PF Desk LoRA	72% (100% valid JSON)
Same LoRA on my laptop (Q4, llama-server)	72%, about 6 s per remark

Honesty note: the last two rounds were guided by this set's error categories (never its text), so treat 72% as optimistic. The real test is my dad's own remarks; there's a labelling tool built in for that.

4. Gemma does the language. Explanations, WhatsApp drafts and helpline answers come from Gemma: gemma3:4b on the laptop through Ollama, and Gemma 4 on Google AI Studio for the public demo. It's context-first: code gathers the facts, ETA and matching rules, and Gemma only writes. A rejected claim never gets a model-written date; it gets a fixed "your consultant will call" reply.

5. Privacy layer. Every prompt passes through a tokenizer that swaps names, UAN, Aadhaar, PAN, bank account and phone for [NAME_1], [UAN_1], and so on. It's tested against 200 red-team strings with 0 leaks. While recording the demo, I caught a real bug. Gemma echoed the [UAN_1] example from its own instructions, and my un-tokenizer helpfully swapped in the worker's real UAN. Now only placeholders that were actually sent can be restored, and identifiers always come back masked (XXXXXXXX6259). A test covers exactly that case.

6. Temporal for the monthly cycle. Each client's month is a workflow: request the sheet, wait for it, chase, validate, remind on the due date, mark paid. I killed the worker at random moments 20 times. The first run scored 17/20, and the failures exposed a real bug: a salary sheet arriving after the chase window was never validated. After fixing it: 20/20 resumed, 0 duplicate tasks.

7. Rules, researched. I couldn't sit my dad down this week, so I checked every Rule Book entry against official sources instead. That's how I found that the EPF Scheme, 2026 took effect on 1 July: a full PF withdrawal now needs 12 months out of work, not 2. Also, the wage ceiling rose to ₹25,000 in September. Pre-check now knows this and suggests the 75% partial withdrawal instead.

Stack: Hono + Next.js on Node 24; PGlite (embedded Postgres + pgvector) on the laptop and Tiger Data Postgres for the demo; hybrid keyword + vector Rule Book search, which finds the right rule in the top 5 for 29 of 30 test questions; deployed on Render, at a .tech domain.

Why Does Open Innovation Matter?

Look at what a PF consultant handles: Aadhaar numbers, bank accounts, salaries, family names for hundreds of workers. That's exactly the data that should never be pasted into a closed AI service.

Open models make the only acceptable version of this product possible:

It runs on the consultant's own laptop. Gemma through Ollama, TabPFN on CPU, and my fine-tuned decoder as a 185 MB LoRA on llama-server. Real client data never leaves the machine. The public demo uses only synthetic people.
A small open model beats a general one at the narrow job. EPFO remark-speak ("F/H", "DOE", "PL SUBMIT CORRECTED CHQ") is its own dialect. A $1.65 fine-tune of an 8B model beat Gemma few-shot by 19 points on real remarks, and runs offline.
The cost per claim is basically zero. That's what makes ₹499 a month viable for a one-person business. No per-token bill scales with my dad's client list.
No lock-in. If a model gets better or cheaper, swap it. The rules, data and fine-tune are his.

My First User

My dad, the PF consultant this was built for. I showed him PF Desk, and he said yes: he's approved it, and he'll use it on his clients' claims. That's the whole point. This started as "build my dad's practice a back office", not as a hackathon idea.

For real work it runs in local mode on his laptop, so his clients' Aadhaar, bank and salary data never touches the cloud. The demo site only has synthetic people. His first job for it: label his own past rejection remarks in the built-in labelling tool, so the next decoder is trained on the remarks his regional office actually writes.

Prize Categories

Best Use of Gemma: all explanations, WhatsApp drafts and helpline answers; local through Ollama, Gemma 4 on AI Studio for the demo.
Best Use of TabPFN: rejection risk (classification) and settlement ETA (regression) inside every Pre-check and the worker helpline, beating logistic regression and gradient boosting on a time-ordered split.
Best Use of Tinker: LoRA fine-tune of Qwen3-8B for EPFO remark decoding. 72% vs 58% base on held-out real remarks, about $1.65 to train, runs offline on a laptop.
Best Use of Render: hosts the public demo (web app + API) at pfdesk.buildwithyash.tech.
Best Use of Temporal: monthly compliance cycle and claim follow-up workflows, with 20/20 resumes after forced worker kills.
Best Use of Tiger Data: Postgres + pgvector for the Rule Book's hybrid keyword + vector search on the live demo.
Best Use of a .tech Domain: https://pfdesk.buildwithyash.tech

PF Desk helps consultants prepare and check. It doesn't file with EPFO, and it isn't legal or financial advice. Rules change, so always verify with the latest EPFO circulars.

I built this with an AI coding agent (Claude Code) as my pair programmer. The idea, the product decisions and the problem are my family's. All demo data is synthetic.

Sitspot — my places, calling me back outside

Yash Gurav — Sat, 10 Oct 2026 13:20:21 +0000

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

What I Built

I live in Vasai, near Mumbai. Within 20 minutes of my desk there's a park, a lake edge and three beaches. Last month I went to none of them. Not because I didn't want to, but because in an Indian city in October timing is everything: afternoons feel like 38°C, air quality swings by the hour, and the coast is only nice near low tide and before dark. Nobody checks five apps to find the good 40 minutes.

Sitspot watches a few real places you choose and calls you back outside only when one of them opens a genuinely good window.

You add 3–5 spots once (a park, a beach, your terrace) — that's most of the screen time you'll ever spend.
Every hour it pulls weather, air quality, tide timing, sun position and recent eBird sightings for each spot, and forecasts how good birding will be with TabPFN.
A plain, tested decision function (code, not a model) scores every spot × hour — and five hard safety rules can veto anything: no coast after sunset − 30 min, none near high tide, nothing at ≥ 38°C feels-like or US AQI ≥ 200, quiet hours are absolute.
When a window clears the bar, Gemma writes a short, grounded invitation ("…Leave by 6:40, it stays good until 8:00. The air is poor (US AQI 150), so keep it short and easy. Want to go?"), and your phone buzzes.
Tap it and Sitspot talks to you (ElevenLabs voice, with Gemma as the brain). Ask "how far is it?", say "yes, let's go".
At the spot, tap I'm here and put the phone in your pocket: BirdNET runs on the phone and names what it hears, always with an honest confidence word. Audio never leaves the phone.
In the evening it writes a short field note, and every night it learns from what you accepted.

The screen is the shortest part of it: ~3 minutes of setup, then a buzz, a tap, and you're out.

Demo

Live app: https://sitspot.vercel.app
Video (phone screen recording): https://www.youtube.com/shorts/BJddW_OH_ZY

Honest note on the video. Vasai's air was hazardous for my whole build week — US AQI 200–299 most evenings, 35–39°C feels-like. Sitspot did exactly what it should and refused to invite me anywhere; even its "send a TEST invitation" button refuses when no window passes the safety rules. So the recording uses a TEST invitation (the real pipeline — Gemma script, push, voice, visit, field note — with only the score threshold skipped, never safety) for a clean-air test spot, recorded at home. You can see my real Vasai spots on the home screen marked AQI 229 · very unhealthy. In pocket mode it heard a House Crow (they're everywhere here) and a Barn Owl — "possibly" at 2:50 pm indoors, which is almost certainly a false detection. That "possibly" is the point: the app is designed to say how sure it is and never to invent a bird.

The forecast says the air improves this weekend; the first real dawn invitation is queued for my park.

Code

Yashgurav002 / sitspot

Your places, calling you. Watches a few real places near you with open data and calls you when one opens a genuinely good window. Open models: Gemma, BirdNET (on-device), TabPFN. Hacktoberfest 2026 Touch Grass.

Sitspot

Your places, calling you.

You add the 3–5 real places you could actually go: a creek, a fort, a beach, a terrace. Sitspot watches them every hour using open data (weather, air quality, tide, sun, recent eBird sightings). When one of them opens a genuinely good window, your phone buzzes, and tapping it opens a voice conversation with Sitspot in the browser (ElevenLabs voice, Gemma brain). The call gives you the place, the reasons with real numbers, and when to leave. If you go, you tap "I'm here", put the phone in your pocket, and walk. In the evening it writes a short field note from what actually happened, and it learns from what you accepted and declined.

Live: https://sitspot.vercel.app · Write-up: docs/devto-post.md

Phone calls: the ElevenLabs + Twilio path is implemented (apps/api/src/delivery/call.ts), but new Twilio trial accounts block streaming call audio to an AI agent…

View on GitHub

A pnpm monorepo: Next.js 16 PWA (apps/web), Hono API (apps/api), Temporal workflows (workflows/), and small packages for the policy, agent, LLM client, data pullers and DB. ~300 tests across TypeScript and Python; CI runs typecheck + tests on every push.

How I Built It

Open models, each doing the one thing it's best at:

Job	Open model	Where it runs
Invitation scripts + evening notes	Gemma 4 31B	Google AI Studio (free tier)
Live voice replies	Gemma 3 1B	My laptop, via Ollama (p50 time-to-first-token 379 ms)
Bird ID	BirdNET (TF.js build)	Inside the phone's browser, in a Web Worker (~120–340 ms per 3-second window)
"Will birding be good here at 7 am?"	TabPFN	Python job, hourly, on my laptop
Note search embeddings	nomic-embed-text	Ollama

Context-first, not tool-calling. The server gathers every fact (weather, tide timing, sightings, your preferences) into a small context block; the model only writes. Then validators check every output: every number must appear in the facts, no bird may be named that wasn't detected or reported, coastal scripts must say "stay on firm ground", nothing may encourage the coast after dark, confidence words must match the detection score. A failure gets one retry with the problems fed back, then a deterministic template. On my 40-turn adversarial eval (Gemma 3 1B), the raw model named a bird that wasn't there in 5% of turns; 0% reached the user. Unsafe advice reaching the user went from 12.5% → 2.5% after I enforced the coast-after-dark rule inside the agent itself — the eval caught that before any real person did.

Temporal makes it durable. One workflow per day evaluates hourly; each invitation is its own workflow (sleep until send time → re-check conditions → write script → deliver → wait for answer → wait for arrival → wait for the visit to end → write the note). I killed the worker 20 times at every waiting point: 20/20 resumed, 0 duplicate notifications.

TabPFN, honestly. I trained on 19,588 real eBird checklists (2022–2026, Palghar/Thane/Mumbai) joined with Open-Meteo history. On the held-out 2026 season TabPFN tied the simple hotspot × hour baseline on ROC-AUC (0.649 vs 0.650) — it did not hit my target of +0.05. But it had the best precision at the invite threshold (0.627 vs 0.549) while flagging far fewer hours, which is exactly what an app that should rarely interrupt you needs. The main limit: eBird's rate limits pushed me to the daily feed, so 96% of rows lack checklist duration and the label is noisy. Results file: evaluation/tabpfn_results.md.

Memory. Say "the creek is too far on weekdays" and that becomes a rule — weekday creek windows are held back, and the reason quotes your own words. Every preference must store the user's actual sentence. Overnight it nudges your threshold and learns which hours you say yes to.

Hosting for ₹0. The web app is on Vercel; the API, Temporal worker and Ollama run on my laptop behind a free ngrok domain, with Vercel proxying /api so it's one origin. Postgres is PGlite (embedded, with pgvector) — swap in any Postgres via DATABASE_URL.

What didn't work (and what I did instead). I wanted a real phone call. ElevenLabs + Twilio is wired and tested up to Twilio — but new Twilio trial accounts block streaming call audio to an AI agent, so the "call" happens in the browser instead: the push opens the call page and Sitspot speaks through ElevenLabs. The Twilio-direct code is in the repo and works on a paid account.

Why Does Open Innovation Matter?

Privacy you can verify. Bird ID runs on the phone. Your microphone audio never leaves your pocket; only "House Crow, 0.71, 07:31" is sent. A closed audio API would mean streaming your walk to someone's server.
It works where the signal doesn't. Mangroves and beaches have bad coverage. The model runs in the browser; detections queue in IndexedDB and sync later.
Swappable brains. Every LLM call goes through one OpenAI-compatible client. I moved scripts from local Gemma 3 4B to Gemma 4 31B on AI Studio, and kept voice on local Gemma 3 1B for latency, by changing environment variables. When Gemma 4 turned out to "think" before answering (and that can't be switched off), I stripped it in one place.
Open data in, honest numbers out. eBird checklists from thousands of birders, Open-Meteo forecasts and history, OpenStreetMap tiles, and an open tabular model I could actually evaluate — including publishing that it tied the baseline.
It costs nothing to run. Free tiers, a laptop, and open weights. An always-on agent that checks five places every hour would be a real monthly bill on closed APIs.

My Agent Session

Built with Claude Code as my coding agent: it wrote the PRD, split it into 20 tasks, ran sub-agents in parallel per package, and every task had to pass its tests before commit.

Prize Categories

Best Use of Gemma — Gemma 4 31B writes every invitation and note; Gemma 3 1B runs locally as the voice agent's brain; both behind validators.
Best Use of TabPFN — hourly "good birding" forecast trained on 19.6k real eBird checklists, benchmarked against three baselines with the honest result above.
Best Use of ElevenLabs — the Sitspot voice: an ElevenLabs agent whose LLM is my own open-model endpoint (Gemma), so the voice is grounded in the same facts and safety rules.
Best Use of Temporal — durable invitation workflows with signals, re-checks and retries; 20/20 resumes after forced worker kills, zero duplicates.

Credits: TabPFN by Prior Labs; BirdNET (Kahl et al., 2021, CC BY-NC-SA 4.0); eBird / Cornell Lab of Ornithology; Open-Meteo (CC BY 4.0); © OpenStreetMap contributors.