I built HawaGuard for the Code for a Billion hackathon (Climate & Sustainability track) around one idea:

honesty labels as a feature.

I’m Rozeena, an independent full-stack developer from Pakistan, building in public, and this is how I tried to make that idea concrete.

Three agents, three jobs

HawaGuard splits the work across three agents, so each stage is easy to inspect.

DataAgent fetches real PM2.5 measurements. The data behind the project is a real dataset of 315,632 hourly PM2.5 rows from 12 Beijing monitoring stations, plus a live WAQI demo feed.

AnalysisAgent classifies air quality into US EPA AQI categories, computes the recent trend, and produces a 24-hour forecast.

ActionAgent raises alerts and gives health guidance in either English or Roman Urdu, because guidance is only useful if people can read it comfortably.

Keeping the stages separate means that when something looks off, you know which agent to look at.

The forecast is a baseline, and the app says so

The 24-hour forecast is not machine learning. It’s a naive baseline: persistence plus a linear trend. In other words, it assumes things continue roughly as they are, nudged by the recent direction.

It would have been easy to dress that up with a fancy label. Instead, the app calls it what it is. A simple baseline is useful, and it’s also a fair yardstick. If someone later builds a smarter model, there’s an honest reference point to beat. If I had passed off a baseline as AI, nobody could tell whether any improvement was real.

Recommendations are rules, and they’re labeled that way

The health guidance is rule-based. It follows standard EPA-style categories: once the AQI crosses a threshold, a given kind of advice applies. I don’t make medical claims beyond that, and I’m not trying to replace a doctor or official public-health advice. The app marks these recommendations as rule-based so nobody mistakes them for personalised medical judgement.

Why the labels matter

Here’s how I see each layer, and how it’s presented:

• Measured: real PM2.5 readings from the dataset and the live WAQI demo feed
• Computed: AQI category and trend, both derived transparently from those readings
• Baseline: the 24-hour forecast
• Rules: the alerts and health guidance

When a tool blurs these together, you can’t tell what to trust. When it separates them, you can weigh each piece accordingly: lean on the measurement, treat the forecast as a rough guide, and read the advice as general guidance. That’s especially important when the output touches health.

I’m also not claiming usage or impact numbers. HawaGuard is a hackathon build, and I don’t have figures to show, so I won’t invent any.

What I’d do next

The obvious next step is to test a real forecasting model against the baseline, which now exists to compare it with. I’d also keep the labeling approach for any new feature, so the app keeps being clear about what each part is.

Try it

The live demo is at hawaguard.vercel.app, and the code is on GitHub at rossycoder/hawaguard.

I’d really value your feedback, especially on whether the labels are clear enough, and which other parts of a tool like this should be labeled.

I didn’t build that, because I didn’t trust it. A small shop doesn’t need a confident paragraph. It needs a number it can check. If a language model tells you to reorder 40 units, you should be able to ask why 40 — and get an answer that doesn’t change when you ask twice.

So I made one rule for the whole project: the math decides, the AI explains.

I’m Rozeena, an independent full-stack developer from Pakistan, building in public. I’m not a retailer, and StockSentry is a software project, not a report from a shop floor. I’m saying that up front because the rest of this post is about being clear on what’s real.

Step one: a deterministic engine

You upload an inventory CSV. Before any AI is involved, a deterministic analytics engine works out four things for every SKU:

• Days of stock, meaning how long what’s on the shelf will last
• Reorder point, meaning when it’s time to act
• Risk score from 0 to 100, meaning how likely you are to stock out
• Suggested reorder quantity

The same CSV always gives the same results. You can open the code and trace any number back to its inputs. The output is a ranked reorder list plus a KPI dashboard, so the most urgent SKUs sit at the top and the shop owner isn’t scrolling through hundreds of rows.

Step two: the AI as narrator

Once the numbers exist, the AI layer has a job it’s good at: turning a table into language. It writes a plain-language briefing, along the lines of “here’s what needs attention this week and why”, and answers natural-language questions about the analysis.

Because the AI reads finished results instead of inventing them, it has far less room to make things up. It explains what the engine found and can’t quietly change a reorder point.

Being honest about what’s under the hood

This part matters to me, so here it is plainly:

• The demo data is synthetic. The app badges it “DEMO DATA” so nobody mistakes it for a real shop’s inventory.
• The briefing has two modes. With an InfiniSynapse API key configured, the briefing comes from that API. Without one, it falls back to an offline heuristic narrator, and the app labels it clearly so you know which one you’re reading.
• The Q&A is rule-based. Questions are answered over the real analysis, not by free-form generation.

I’m not publishing user counts, accuracy percentages or sales claims, because I don’t have any. This is a hackathon project, and I’d rather show you exactly what it does than dress it up.

What I learned

The hackathon framing made it tempting to lead with the AI. But the more I built, the more the deterministic layer felt like the actual product. The AI makes the output friendlier. The math makes it trustworthy. If I had to remove one of them, I’d keep the math.

Try it

You can click through the live demo here: stocksentry-bice.vercel.app. The full source is on GitHub at rossycoder/stocksentry.

If you’ve worked on inventory or replenishment tooling, I’d love your feedback. What would you want the risk score to take into account that mine doesn’t?

So TerraDetective AI answers differently: your city in 2050 will feel like a city that exists today. Karachi's 2050 climate twin? Riyadh, now. That lands differently — because you've seen Riyadh's heat. You can picture living in it.

I built TerraDetective for the NASA Space Apps Challenge on 40 years of real NASA POWER data. No projections invented by a language model — measured data, analyzed live.

The feature to try first: Future Twin City. Pick your city; the tool analyzes its temperature trajectory and finds its 2050 climate twin among real cities today.

Also inside:

• Was This Normal? — pick any month in history, get a z-score verdict: normal, unusual, or off the charts
• Danger Days — count of days per year above heat thresholds, trended over decades
• Real statistics — every trend ships with a 95% confidence interval and a p-value. If the trend isn't significant, the tool says so.

That last point is the whole philosophy: a climate tool that overstates its case is just propaganda with better charts. Every number carries its uncertainty.

Run your city through it: 👉 https://terradetective-ai.vercel.app Code: https://github.com/rossycoder/terradetective-ai

Built for NASA Space Apps. Tell me your city's 2050 twin in the comments — the surprising ones are the best argument for building tools like this.

This isn't a sales problem — it's a memory problem. Salespeople forget. CRMs don't remind. So I built Dealership Brain for the FalkorDB Graph Hacks hackathon: an AI operations brain that stores every customer, every promise, and every conversation in a knowledge graph — and escalates before a broken promise costs a sale.

🔴 The feature that matters most: Callback SLA Escalation. Every callback promise gets a timer. Miss it, and the case automatically escalates to the manager. No customer silently falls through the cracks again.

Also inside:

• Promise Tracker — every commitment made to a customer, tracked to done
• Smart Match — a new car arrives, the brain finds buyers who wanted exactly that, and drafts the WhatsApp message
• Follow-Up Agent — surfaces who to contact today and why
• Trade-In Valuation — trade-in value + remaining loan → net equity
• Test Drive Booking — double-booking is rejected outright
• Neighborhood Graph — customers visualized as a connected network
• Roman Urdu chat — because that's how many customers actually write
• Staff Leaderboard + service reminders

How it works: a FastAPI backend over a graph store. Every interaction becomes nodes and edges, so the system reasons about relationships, not rows. Ask "which customers were promised a callback this week and never got one?" — a graph answers that natively. A traditional CRM makes you dig.

Try it — simulate a missed callback and watch the escalation fire: 👉 https://dealership-brain.vercel.app Code: https://github.com/rossycoder/dealership-brain

Built for FalkorDB Graph Hacks. Feedback welcome — especially from anyone who's worked a dealership floor: what's the promise your team breaks most?

#buildinpublic #ai #hackathon #python #webdev