DEV Community: Ishant gupta

Everything Was Green. The AI Was Still Wrong. Building Veritas: a SigNoz-powered risk engine for AI agents

Ishant gupta — Sat, 18 Jul 2026 13:30:22 +0000

Everything Was Green. The AI Was Still Wrong.

Three days before I wanted to call this done, I was staring at the SigNoz Logs Explorer trying to figure out why my OTLP logs weren't showing up. Traces had landed fine from the first run. Logs? Nothing. Not even an error, which honestly is worse than an error — at least an error gives you something to grep for.

That's kind of the whole point of this post, actually. The agent can be dead wrong and none of your dashboards will notice, because they were never built to notice.

The gap I kept running into

Standard observability tells you three things: is it up, is it fast, did it throw a 500. That's it. An AI agent can pass all three checks and still hallucinate a fact, retrieve zero relevant documents and answer anyway, or execute a plan that was broken from the first step. None of that shows up as an error. It shows up as a decision — and decisions don't come with status codes attached.

I kept coming back to one rule while building Veritas: it can't just be a black box scoring another black box. If it flags a run and I can't explain why in plain English, that's not accountability, that's just a second opinion nobody can argue with. So everything the score is based on has to already exist on the trace, and every point has to be something a human could look at and say "yeah, that's fair" or "no, that's wrong."

That's also why nothing in the risk engine is machine-learned. Not because ML is bad, just — for this specific job, I wanted something I could point at and explain, not something I'd have to trust.

What it actually does

Veritas reads OpenTelemetry data out of a self-hosted SigNoz instance and turns it into a Semantic Risk score from 0–100 for each agent run. Then it builds a Replay Timeline so you can jump straight to the step where things fell apart instead of scrolling through logs like you're doing archaeology. It doesn't store any telemetry itself — SigNoz stays the source of truth, Veritas just reads off it.

My FastAPI agent has five stages: planner, retriever, tool, memory, response. Each one is its own OTel span nested under a root agent.run span, and each carries attributes like tool.success, retrieval_score, response.confidence. Six heuristics turn those attributes into the score, with weights that live in one file:

RETRIEVAL_ZERO_DOCS = 25
TOOL_FAILURE = 30
PLANNER_ZERO_TASKS = 25
CONFIDENCE_VERY_LOW_PENALTY = 30
LATENCY_HIGH_PENALTY = 10

I ran it against five scenarios through the actual engine (not typed in by hand):

Scenario	Score	Level
Healthy	5	LOW
Retriever issue	35	MODERATE
Tool timeout	65	HIGH
Planner failure	75	HIGH
Multiple failures	100	CRITICAL

Small thing, but every weight is a multiple of 5, so the engine can only ever spit out multiples of 5. I'd written an early planning doc with "illustrative" scores like 48 and 84 in it, and when I noticed that months later I realized the engine literally cannot produce those numbers. I left the real output alone instead of fudging it to match the doc — a demo that's quietly tuned to look verified is exactly the thing this whole project is supposed to catch, so it would've been a bit much to do that here.

Here's the Replay Timeline on a real tool-timeout run, score 75, HIGH. Retriever comes back with one document instead of several, the policy lookup times out at 330ms, confidence drops to 0.41 — each of those shows up as its own line instead of getting buried somewhere in a log file.

Click into a flagged run and you get a full incident report: root cause, what was expected vs. what happened, a plain-English chain of why, and the business impact. All of it comes straight out of the same risk breakdown — no extra model call, no second AI judging the first one.

Why SigNoz

Before any of the risk-scoring stuff, I had a much more boring problem: I needed somewhere to actually put the telemetry. I'd built agent pipelines before without any real observability layer — just print statements and a prayer — and this time I wanted to do it properly, which meant OpenTelemetry, which meant picking a backend to send it to.

My first instinct was the usual stack everyone reaches for: Prometheus for metrics, Loki for logs, Tempo for traces, Grafana to glue it all together and pretend it's one tool. I got about an hour into setting that up before I realized I was going to spend the whole weekend wiring four services together and configuring their scrape intervals and label schemas, and none of that time would go toward the actual idea, which was scoring agent runs, not learning YAML. So I went looking for something that treated traces, logs, and metrics as one thing instead of three things you correlate by hand, and SigNoz kept coming up. Self-hosted, OTLP-native, one docker-compose to get a working instance, and — this is the part that mattered most — logs and traces share the same trace_id in the same UI, so you can pivot from a span straight to the log lines that happened during it without switching tools or copy-pasting an ID between two different dashboards.

That single decision is basically the reason Veritas works the way it does. The Replay Timeline only exists because I could pull a trace and its logs together as one query instead of stitching two systems' outputs together after the fact. If I'd gone with the four-tool stack, I think I would've spent the entire build just writing glue code to keep Tempo's trace IDs and Loki's log labels in sync, and the actual risk engine — the part I actually cared about — would've been the last 10% of the weekend instead of the first 80%. SigNoz didn't give me the scoring logic, that's still just Python and a handful of if statements, but it gave me a place to point that logic at where everything I needed was already sitting next to everything else.

Here's the raw Logs Explorer mid-debug, with risk_score and risk_level sitting right there as structured fields on the log line, not something I had to reconstruct from a separate metrics panel:

The stuff that actually broke

Logs that went nowhere. Traces worked from run one. Logs didn't. I wired up the OTLP log handler, hit the endpoint, checked the explorer — nothing. No error, no warning. My first guess was propagate = False somewhere blocking records before they hit the root logger's handler, so I grepped the whole logging setup for the word propagate. Zero hits. Theory dead, and no error message to chase down instead. What ended up working was attaching the handler directly to each veritas.agent.* logger by name instead of the root logger. Logs started flowing immediately. Downside: lines duplicate now, since both handlers fire on the same record.

I went back and checked this against the actual OpenTelemetry Python docs afterward, rather than just trusting my memory of why the fix worked, and it turns out the documented setup is the opposite of what I did — you're supposed to attach the handler once, to the root logger, and named child loggers should reach it automatically through Python's default propagate=True. The OTel docs also mention a much more common cause for this exact symptom: if logging.basicConfig() gets called anywhere before the OTel logging integration is set up, the integration's formatting silently never takes effect. So if you hit this same wall — logs go nowhere, nothing in the console — check your init order first. That's the documented issue. Mine might have just been working around the same root cause from a different angle, honestly not 100% sure. Leaving the account here as it happened rather than rewriting it to sound like I knew what I was doing at the time.

A route that didn't exist. The Replay Timeline kept throwing 404s and every instinct said "broken import somewhere." It wasn't that — app/trace/[id]/page.tsx genuinely hadn't been created yet. Components were built, the route just wasn't wired up.

Once that got fixed, I found the trace lookup only recognized two hardcoded keys — high-risk and low-risk. Five other demo fixtures were sitting fully generated on disk and completely invisible to the UI.

SigNoz's percentile gap. A P50/P90 latency panel threw Function with name 'histogramQuantile' does not exist. Turned out to be a real version mismatch in the specific SigNoz/ClickHouse build I'd self-hosted — nothing wrong with my config. I ended up rebuilding every percentile panel as a simple sum-divided-by-count average instead.

Zooming out to the fleet view

Past a single run, there's a fleet-level dashboard: risk distribution, latency by stage, which agents are failing most, and some rule-based recommendations keyed off whatever's breaking most often right now.

Worth being upfront about: the numbers on that page are simulated 24-hour traffic across three agents, and it says so right on the page. Only the Refund Agent card links to a real, clickable trace — Research and Support Agent don't yet. Didn't want someone to click around and find that out on their own without me having said it first.

What I'd tell myself three weeks ago

"No errors" is not the same as "working." I know that now, but at the time it just felt like relief — like, okay, good, nothing's on fire. Took me embarrassingly long to realize that silence is its own red flag, and arguably a worse one than an actual error, because at least an error gives you a line number.

The planning doc thing I found almost by accident — I had it open in another tab while writing this up, not even looking for anything, and just noticed 48 and 84 sitting in there. Had this small "wait, my engine literally can't make that number" moment. Every weight's a multiple of 5. It can't output 48. Those were just numbers I'd typed in early on because they sounded roughly right, from before any of this was actually running. Nobody would have noticed if I'd just quietly loosened the engine to allow numbers like that instead.

One line

I don't think AI agents need less autonomy. I think they need the same kind of accountability every other system had to earn before anyone trusted it with production traffic.

Veritas is open source: https://github.com/ishantgupta30/veritas-flight-recorder

Every Sports App Resets Your Streak Eventually. Mine Can't. 🔒⚡

Ishant gupta — Sat, 11 Jul 2026 16:43:04 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Loyalty Ledger — a fan loyalty tracker where your check-in streak, badges, and history live on Solana instead of some app's database.

Live app: https://loyalty-ledger-blond.vercel.app

Here's the problem I kept coming back to. Every sports app wants you to check in, engage, "prove your loyalty" — collect points, build a streak, unlock a badge. Cool. Except every single one of them throws that history away the second you stop opening the app. Switch apps and your streak resets to zero. Get banned, or the app shuts down, or they just quietly decide to wipe inactive accounts one day — and your history is just... gone. Because it was never actually yours. It was a number sitting in someone else's database, and they could reset it, inflate it, or delete it whenever they felt like it. You had zero say in it.

And that bugged me way more than it probably should have. Like — we figured out how to make ownership portable for money, for domain names, for digital art. But "I've supported Argentina since 2019" 🇦🇷 still lives and dies inside one company's backend, and nobody's really questioned that.

So I kept the weekend scope deliberately small: prove one fan's loyalty to one team, for real, end to end — instead of sketching ten features that are all half-fake. You connect a wallet, pick a sport and team, and check in. FIFA World Cup is the fully working path here ⚽ — that check-in sends an actual transaction that creates or updates a program-owned account, not a row in my database somewhere. Your streak count, your badge tier, the actual badge tokens — none of it exists anywhere I control. Which honestly felt a little weird to build, in a good way.

Once that core loop worked, I built the rest of the identity around it: a Fan Passport that shows your streak, a derived "Fan Score," your tier (Rookie → Devoted → Veteran → Legend 🏆), a progress bar toward the next tier, an achievements grid with locked/unlocked states, a recent-activity feed pulled from real on-chain history, and a leaderboard ranking actual fans by actual streaks. There's also a "Demo Preview" toggle that fills the passport with sample numbers, clearly labeled as sample data — because a screen full of zeros just doesn't demo well, and I'd rather be upfront about that than pretend it's real.

NBA and "Other International Sport" are in the app too, same UI and flow, but honestly? They're stubbed. Sample fixtures, no chain writes, and the app says so directly instead of hiding it. I'd rather ship one path that's completely real than three that are all a little bit fake.

Demo

Live app: https://loyalty-ledger-blond.vercel.app
GitHub: https://github.com/ishantgupta30/Loyalty-Ledger

To actually try it:

Install Phantom if you don't have it, and switch it to Devnet — Settings → Developer Settings → Change Network → Devnet. This is the step almost everyone misses first, myself included the first time 🙃
Grab free devnet SOL from the faucet to cover transaction fees, which run a fraction of a cent per check-in. No real money touches this project anywhere.
Open the app and click Connect Wallet, top right.
Pick FIFA World Cup and a team.
Hit check-in and approve the transaction Phantom pops up.
Watch the streak and Fan Score update, confetti fires 🎉, and if you crossed a threshold, a badge-unlocked toast shows up.
Scroll down and the full Fan Passport fills in — tier, progress bar, achievements, recent activity, your actual rank on that team's leaderboard.
Once you've crossed tier 1 (3 check-ins), hit Claim Badge — it mints a real SPL token straight to your wallet. Go check Phantom's token list after, it's just sitting there. Permanently. Not a UI element pretending to be a thing 👀

Code

GitHub Repository:
https://github.com/ishantgupta30/Loyalty-Ledger

How I Built It

The account design

The core piece is a small Anchor program. Every fan gets a PDA — a Program Derived Address, an account owned by the program itself, not by me — keyed to (wallet, sport, team):

pub struct FandomRecord {
    pub wallet: Pubkey,
    pub streak_count: u32,
    pub last_checkin_ts: i64,
    pub bump: u8,
    pub highest_tier_claimed: u8,
    #[max_len(32)]
    pub sport: String,
    #[max_len(32)]
    pub team: String,
}

Check-in doesn't touch a database at all. It fires a check_in instruction that either creates this account (first check-in) or updates it — extends the streak, or resets it if too much time passed between check-ins. That's basically the whole point of this project in one sentence: the streak isn't something my frontend can fake, inflate, or quietly reset, because it was never my frontend's data to begin with. Anyone — not just this app — can read the account directly and verify exactly what it says. No trust required.

The leaderboard problem (this one got me)

This took way longer than it had any right to. My first cut of the account only stored wallet, streak_count, and last_checkin_ts — sport and team lived purely in the PDA seeds. Which is fine if you already know a wallet and want to look up their record. But it's a total dead end if you want to ask "who are the top Argentina fans," because seeds only let you derive one specific account when you already know the inputs. You can't run that backwards to enumerate every account matching a team. Learned that one the hard way mid-build.

So I ended up adding sport and team as actual fields on the account data, not just seed inputs. Which meant a full account-struct change, a rebuild, and a redeploy — genuinely annoying mid-weekend — but it's what makes a real getProgramAccounts call (filtered client-side by sport/team) actually able to answer "rank every Argentina fan by streak" using real chain state instead of a cached guess or a fake list.

Why Solana, specifically

I wanted this to be a project where pulling out the blockchain would actually break something — not just remove a buzzword from the pitch. Check-ins are frequent and individually pretty worthless — potentially one per match, per fan, across a lot of fans over a tournament. That only works as a real product (not a novelty) if each check-in is near-free and confirms fast enough to feel like a UI action instead of a bank transfer. Solana's one of the few chains where both of those are true at once. A check-in here confirms in about a second and costs a fraction of a cent — which is the actual, boring, practical reason "check in every match, forever" is something you could really build, instead of something that only works in a demo video.

There's a side effect of the PDA design I honestly didn't fully plan for going in: because the fan record is owned by the program and not by my database, any other app that knows the program id can read it directly. No API key. No integration meeting with me. No trusting my numbers. A ticketing platform could check the same record to offer a loyalty discount. A streaming service could unlock a perk off the same tier. None of that needs my permission or my infrastructure staying online. That's a meaningfully different thing from "an app that happens to use Solana" — and it kind of just fell out of choosing PDAs over a normal database, rather than being the original plan.

What actually broke along the way

Being honest here instead of pretending this all went smoothly: I burned a genuinely embarrassing amount of time on devnet SOL. The official faucet rate-limits per IP, and I hit that wall hard while iterating on deploys — every account-struct change meant a full redeploy, and every redeploy needed enough SOL to cover rent for a fresh program buffer. I ended up bouncing between the CLI faucet, a couple of backup faucets, and eventually just asking around, before I could get back to actually building.

Prize Categories

Best Use of Solana — the PDA-per-fan account design and the on-chain leaderboard aren't decorative. Pull Solana out of this project and the core claim — that a fan's streak can't be faked, inflated, or reset by the app itself — just stops being true. That was the whole point of building it this way instead of with a normal backend.

Git-regret 💀 — I Finally Finished the CLI That Reads Your Shame

Ishant gupta — Tue, 02 Jun 2026 08:31:21 +0000

This is an official submission for the GitHub Finish-Up-A-Thon Challenge.

Try It Yourself: https://ishantgupta30.github.io/git-regret/

🕒 Introduction: The Ghost in the `.git` Directory

Every developer has a digital graveyard.

It is a hidden directory, usually tucked away in a generic /Developer/Projects folder, filled with half-baked ideas, abandoned repositories, and code that was written at 3:00 AM under the influence of intense caffeine and false confidence.

For 18 months, my personal digital graveyard contained a repository called git-audit-tool.

If you opened that repository and ran git log, you would find a brief, tragic story told in three commits:

initial commit - hackathon night
wip add secret detection - crashes on big repos
giving up for tonight, too tired - will finish later

That last commit sat there untouched for a year and a half.

The code inside was embarrassing.

It was a single Python file that hardcoded execution limits, contained broken placeholders, and regularly threw unhandled exceptions if you pointed it at a repository with a mature history.

But the core problem never went away:

Nobody actually checks their git history until something goes terribly wrong.

We push API keys.

We squash terrible commit messages into production branches.

We leave panic-driven fix: layout again commits scattered across our history.

When the GitHub Finish-Up-A-Thon was announced, I realized it was time to stop closing the tab.

It was time to take this broken, abandoned script and turn it into a production-ready CLI.

This is the story of how I completely rewrote that technical mess into git-regret—a tool that scans repository history for mistakes, calculates project "regret metrics," and generates GitHub Copilot remediation plans automatically.

🛑 The Before: One Function, Zero Architecture, Infinite Shame

Before discussing the rebuild, we need to look at the starting line.

The original script was a masterclass in anti-patterns.

One file
Zero tests
Fragile parsing
Hardcoded limits
Empty TODOs everywhere

import subprocess
import sys

# wip - trying to add secret detection
# TODO: this crashes on big repos lol

def run_audit(path="."):
    result = subprocess.run(
        ["git", "log", "--oneline", "-20"],
        cwd=path,
        capture_output=True,
        text=True
    )

    if result.returncode != 0:
        print("not a git repo")
        return

    commits = result.stdout.strip().splitlines()
    print(f"checking {len(commits)} commits...")

    for line in commits:
        sha = line.split()[0]
        msg = " ".join(line.split()[1:])

        if "wip" in msg.lower():
            print(f"bad commit: {sha} — {msg}")

if __name__ == "__main__":
    path = sys.argv[1] if len(sys.argv) > 1 else "."
    run_audit(path)

🔍 Anatomy of a Broken Script

The Magic Number Limitation

["git", "log", "--oneline", "-20"]

The tool literally refused to inspect more than 20 commits.

Fragile String Parsing

sha = line.split()[0]

The parser assumed every log line would always have the same structure.

Not exactly resilient engineering.

The Phantom Feature

The tool claimed to perform secret detection.

The implementation?

# TODO secret detection here

The README

# git-audit-tool

TODO: write this.

## Status
Gave up. Crashes on any repo > 10 commits. Will fix later.

- [ ] fix the crash
- [ ] add secret detection
- [ ] make it actually useful

Every time I looked at the repository, the technical debt felt bigger than the project itself.

💡 Designing git-regret

To build a utility people would actually use, I had to stop thinking like a script writer and start thinking like a systems engineer.

The vision centered around three pillars:

1️⃣ Multi-Dimensional Analysis

[Repository Scan Engine]
       │
       ├── HIGH SEVERITY 🚨
       │      ├── Secret Leaks
       │      └── Fix Chains
       │
       └── MEDIUM SEVERITY ⚠️
              ├── WIP Commits
              ├── Regret Keywords
              └── Giant Commits

2️⃣ Decoupled Architecture

Analysis and presentation should never depend on one another.

3️⃣ AI-Powered Remediation

Finding mistakes is useful.

Generating the exact fix plan is even better.

This became the foundation of the --copilot feature.

🤖 Pairing with GitHub Copilot

A surprising amount of CLI development is boilerplate:

Regex creation
Test fixtures
Argument parsing
State tracking

GitHub Copilot helped accelerate all of it.

🧠 Challenge #1: Secret Detection

I needed a reliable set of patterns for identifying leaked credentials.

Prompt

I am building a high-performance Python static analysis tool for git history. Generate compiled regex patterns for AWS keys, Stripe live keys, GitHub tokens, private SSH keys, database URLs, and common API secret assignments.

Result

import re

SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"AKIA[A-Z0-9]{16}", re.IGNORECASE),
    "stripe_live_key": re.compile(r"sk_live_[0-9a-zA-Z]{24}"),
    "github_pat": re.compile(r"ghp_[0-9a-zA-Z]{36}"),
    "pem_private_key": re.compile(r"-----BEGIN[A-Z ]+PRIVATE KEY-----"),
    "database_url": re.compile(
        r"(mongodb|postgresql|postgres)://[^:]+:[^@]+@[^/]+"
    ),
}

This became the foundation of the scanning engine.

⛓️ Challenge #2: Detecting Fix Chains

One common signal of rushed development is a series of consecutive patch commits:

fix: layout bug
fix: layout bug try 2
fix: forgot import
bugfix: typo

These should usually be squashed into a single commit.

I asked Copilot to generate a state machine capable of identifying runs of three or more consecutive fix commits.

The resulting implementation correctly handled edge cases and trailing chains without introducing off-by-one errors.

🧪 Challenge #3: Automated Testing

Testing Git tooling is difficult because you cannot safely mutate a real repository during unit tests.

I used Copilot to generate a Pytest fixture that:

Creates a temporary repository.
Configures dummy Git identities.
Generates synthetic commit histories.
Runs assertions against isolated repositories.

The result was a reproducible testing environment covering:

Secret detection
Empty histories
Pagination
Fix chains
WIP detection

By release day, the project had:

35 assertions
10 test scenarios
Full isolated execution

🏗️ Architecture

The rewrite introduced strict separation between components.

┌────────────────────────────┐
│ cli.py                     │
│ Flag parsing               │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ analyzer.py                │
│ Repository analysis        │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ ui.py                      │
│ Rich rendering + prompts   │
└────────────────────────────┘

This architecture makes the analysis engine reusable in:

GitHub Actions
CI systems
Future integrations

without modification.

🚀 The Result: git-regret

Installation:

pip install git-regret

Run:

git-regret

Sample output:

╭──────────────────────────────╮
│ git-regret 💀                │
│ Unbreak your past commits.   │
╰──────────────────────────────╯

Scanned 142 commits

Found:
🚨 1 HIGH
⚠️ 2 MEDIUM

[HIGH] Secret Leak Detected

Commit: a3f910d

Message:
hotfix: override api connection auth

Detail:
Leaked Stripe key detected

Suggested Fix:
Rotate credential and purge history.

🛠️ The Killer Feature: `--copilot`

git-regret --copilot

The tool generates a GitHub Copilot prompt tailored to the repository findings.

Example:

You are an elite principal engineer auditing my repository.

Detected:
- secret_leak
- trailing_fix_chain

Affected commits:
- a3f910d
- 84b2c11

Please:

1. Provide an interactive rebase plan.
2. Show git filter-repo commands.
3. Draft replacement commit messages.

Instead of searching Stack Overflow for hours, developers get an immediate remediation workflow.

📊 Before vs After

Metric	Old Script	git-regret
Codebase	87 Lines	520+ Lines
Architecture	Single File	Modular
Testing	None	35 Assertions
Analysis Rules	1	5
UI	print()	Rich
Error Handling	Minimal	Robust
AI Integration	None	Copilot Prompts

🔮 Roadmap

Planned features include:

`git-regret install-hook`

Automatically install pre-commit protections.

`git-regret --ci`

Generate GitHub Actions workflows automatically.

`.gitregret.json`

Custom organizational rules and policies.

🏁 Conclusion

Finishing an abandoned project taught me something important:

An old idea is not necessarily a bad idea. Sometimes it is simply waiting for a better implementation.

The original project failed because it lacked structure.

By introducing:

Decoupled architecture
Automated testing
GitHub Copilot assistance
Clear design boundaries

I transformed a forgotten hackathon script into a production-ready developer tool.

If you have an abandoned repository sitting in your projects folder, this challenge is your sign to revisit it.

You might discover that the hardest part was simply finishing.

⚡ Audit Your Repository Today

# Install
pip install git-regret

# Generate a report and Copilot remediation plan
git-regret --copilot

🔗 Links

🌐 Documentation & Website: https://ishantgupta30.github.io/git-regret/
📦 GitHub Repository: https://github.com/ishantgupta30/git-regret

⚡ Get Started

pip install git-regret
git-regret --copilot

If git-regret helps you uncover a secret, clean up a fix chain, or finally understand what happened in your repository six months ago, consider giving the project a ⭐.

I Built a Space App That Gives You Real-Time Planetary Data — Powered by Gemma 4, No Backend

Ishant gupta — Mon, 11 May 2026 18:36:34 +0000

I Built a Retro Space Mission Control Powered by Gemma 4 — and It Talks Like a NASA Commander 🚀

What happens when you give an open-source AI model the keys to the solar system?

I've been obsessed with space since I was a kid. But every space app I found was either too boring (just static facts) or too complex (needs a PhD to use).

So I built Cosmos Explorer — a retro, terminal-aesthetic space mission control center that runs entirely in the browser, powered by Gemma 4.

🔗 Live Demo → cosmos-explorer-ishant.netlify.app
🔗 Github

No downloads. No installs. Just open it and feel like you're at NASA.

The Idea: What if space exploration felt alive?

Static facts are boring. I wanted something that reacted — that felt intelligent, cinematic, and immersive.

That's where Gemma 4 came in.

Instead of hardcoding descriptions, I let Gemma 4 generate real-time mission briefings, reveal hidden planetary secrets, narrate the night sky like a planetarium, and compare worlds with the insight of an actual scientist.

Gemma 4 isn't just a feature in this app. It's the soul of it.

What is Cosmos Explorer?

It's a 7-in-one space dashboard built as a single HTML file:

Module	What it does
🌍 Solar System	Animated real-physics orbits, click any planet
🤖 Mission Briefings	Gemma 4 generates NASA-style planet briefings
💡 Discovery Mode	Gemma 4 reveals obscure scientific secrets
🛰️ Satellites	Live mission data for Hubble, JWST, Voyager 1 & more
📡 ISS Tracker	Real orbital physics, updates every second
🔭 Sky CAM	Point your camera at the sky — Gemma 4 narrates it
⚖️ Planet Compare	Gemma 4 analyzes any two worlds side by side

Let me walk you through each one.

Feature 1: The Solar System — Click a Planet, Get a Mission Briefing

The moment you click a planet, Gemma 4 kicks in. No loading spinner for 5 seconds. Just instant, cinematic text that typewriters across the screen like a real mission computer.

Gemma's output for Saturn:

TARGET ACQUIRED: SATURN. Ring system spans 282,000 km yet only 10-100 
meters thick. Density lower than water — it would float. Enceladus moon 
sprays water geysers at 1,400 km/h. Titan has liquid methane lakes. 
145 moons confirmed.

This isn't hardcoded. Gemma 4 writes this fresh every time. I just gave it a persona:

callGemma(
  'You are a NASA mission commander. Cite specific instruments and missions 
   by exact name. Begin with TARGET ACQUIRED:. Be cinematic. 2-3 sentences maximum.',
  `Generate a mission briefing for ${planetName}`
)

That system prompt is doing a LOT of work. The model picks up on tone, format, and scientific precision instantly. That's the power of a 27B instruction-tuned model.

Feature 2: Discovery Mode — Secrets Gemma Reveals

Every planet has a Discovery Mode button. Press it, and Gemma 4 digs up something genuinely obscure — not the usual "Saturn has rings" stuff.

Real output for Saturn:

DISCOVERY: Saturn's rings are geologically young — only 10 to 100 million years old, formed when dinosaurs walked on Earth. Cassini measured ring mass and dust accumulation rates, shocking scientists who expected billion-year-old rings. The rings may disappear in 100 million years as Saturn's gravity pulls them inward.

I prompted it as a planetary scientist with access to mission data:

'You are a planetary scientist revealing a genuinely obscure fact. 
 Choose something highly specific. Cite missions, instruments, or datasets. 
 2-3 sentences. Begin with "DISCOVERY: "'

What I love here: Gemma 4 doesn't just recite Wikipedia. It connects facts. The dinosaur comparison? That's Gemma making an analogy on its own.

Feature 3: Sky CAM — Your Camera Becomes a Planetarium

This is the feature I'm most proud of.

Point your device camera at the sky (or just use the direction/tilt sliders), and Sky CAM overlays constellation lines in real time. But the real magic? Hit "GEMMA AI ANALYSIS" and watch this happen:

"Turn your gaze southward, where Orion strides across the winter sky — Betelgeuse blazing with the light of a star 700 times larger than our own Sun, a red supergiant in its final cosmic act. In 2019, Betelgeuse dimmed so dramatically that astronomers worldwide predicted imminent supernova — a reminder that even celestial constants can surprise us. The ancient Egyptians saw Orion as Osiris, god of death and resurrection, his belt stars aligned with the three pyramids of Giza."

I gave Gemma 4 a very specific persona here:

'You are a live planetarium narrator with deep astronomy expertise. 
 Be vivid, poetic, scientifically precise, and cinematic.'

The prompt also feeds in the current compass direction, tilt angle, and which constellations are visible. Gemma uses all of that context to write something specific to what you're actually looking at.

This is where the 128K context window of Gemma 4 shines — I can pass rich contextual data and get nuanced, location-aware responses.

Feature 4: Planet Comparison — Gemma as Data Analyst

Pick any two planets, hit ANALYZE, and Gemma 4 breaks down the comparison like a scientist explaining it to a curious friend.

Mercury vs Mars:

SIZE CONTRAST: Mars is 1.4× wider than Mercury. DISTANCE: Mercury orbits at 57.9M KM from the Sun, while Mars orbits at 227.9M KM — a vast difference in solar energy received. TEMPERATURE: Mercury surface reads -180→430°C vs Mars's -125→20°C — Mercury and Mars represent extreme thermal environments.

The structured breakdown format comes entirely from the prompt. I didn't template the output — Gemma 4 just... organizes it that way when you ask it to.

Feature 5: The Space Q&A Chat

At the bottom of the Solar System view, there's a chat bar. Ask anything about space.

The system prompt is simple but effective:

'You are an expert space scientist. Answer questions about planets, moons, 
 satellites, black holes, and galaxies enthusiastically. Keep answers 2-4 
 sentences with specific numbers and surprising facts.'

The "specific numbers" instruction is key — it stops Gemma from giving vague answers and forces it to ground responses in real data.

Why Gemma 4? The Model Selection Decision

This was a deliberate choice, not a default.

I needed a model that could:

Switch personas instantly — NASA commander, planetarium narrator, planetary scientist, data analyst. All in the same app.
Produce short, precise outputs — The UI doesn't have space for essays. 2-3 sentences max.
Work reliably via API — The whole app runs client-side, so I needed a stable, fast endpoint.
Handle creative + factual tasks — Mission briefings need drama. Discovery Mode needs accuracy. Both at once is hard.

I went with gemma-4-27b-it (the 27B dense model via Google AI Studio's Gemini API).

Why 27B and not 2B or 4B?

The smaller models are amazing for edge/mobile deployment — but they struggled with the tonal range this app demands. A 4B model would give me a decent mission briefing or a poetic sky narration, but not both reliably. The 27B model handles persona-switching cleanly.

Why not the 26B MoE?

The MoE is built for high-throughput reasoning. My use case is lots of short creative + factual bursts, not long-chain reasoning. The dense 27B was the better fit here.

The killer feature: instruction following

Every Gemma 4 call in this app has a very specific system prompt. The model follows them precisely — it doesn't ramble, doesn't break character, doesn't exceed the sentence limit I set. That level of instruction-following made the entire UI feel polished.

Architecture (The Short Version)

The entire app is one HTML file. No frameworks, no build step, no server.

Cosmos Explorer
├── Canvas-based solar system (vanilla JS + requestAnimationFrame)
├── Real orbital mechanics (Kepler's equations)
├── ISS tracker (simulated TLE physics)
├── NASA images via JPL/APOD APIs
├── Space news via curated data
└── Gemma 4 via Gemini API (gemma-4-27b-it)
    ├── Mission briefings (on planet click)
    ├── Discovery Mode (on button press)
    ├── Sky CAM narration (on analyze)
    ├── Planet comparison (on analyze)
    └── Space Q&A (persistent chat)

The Gemma integration is surprisingly clean — one callGemma() function that every AI feature uses:

async function callGemma(systemText, userText, maxTokens = 350) {
  const url = `https://generativelanguage.googleapis.com/v1beta/models/gemma-4-27b-it:generateContent?key=${API_KEY}`;
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      system_instruction: { parts: [{ text: systemText }] },
      contents: [{ role: 'user', parts: [{ text: userText }] }],
      generationConfig: { temperature: 0.85, maxOutputTokens: maxTokens }
    })
  });
  const data = await res.json();
  return data.candidates[0].content.parts[0].text.trim();
}

That's it. Every Gemma feature in the entire app flows through that one function. Clean, simple, powerful.

The Moment That Made Me Go "Whoa"

During testing, I clicked on Earth and asked Gemma to generate a mission briefing.

It said:

"TARGET ACQUIRED: EARTH. The only confirmed biosphere in the known universe. Magnetic field generated by liquid iron outer core deflects solar wind at 400 km/s. 71% surface liquid water. 8.1 billion crew members aboard. Protect at all costs."

"8.1 billion crew members aboard. Protect at all costs."

I didn't prompt that. The model extrapolated from the NASA commander persona and added something genuinely moving. That's the difference between a language model and a creative language model.

That line stayed in the app.

What's Next

Exoplanet Explorer — Gemma 4 generating habitability reports for Kepler catalog planets
Mission Planner — Ask Gemma to plan a hypothetical mission to any planet
Night Sky Events — Gemma narrating upcoming eclipses, conjunctions, meteor showers
Offline mode — Gemma 4 2B/4B running locally via WebGPU (no API key needed)

The offline idea excites me most. The 4B model is small enough to run in the browser — imagine a space education tool that works with zero internet, perfect for schools and rural areas.

Try It Yourself

🚀 Live Demo: cosmos-explorer-ishant.netlify.app

Open it, click Saturn, hit Discovery Mode, then go to Sky CAM and press Gemma AI Analysis. That sequence will show you everything Gemma 4 can do in about 60 seconds.

Final Thought

People talk about AI like it's a search engine replacement. But Gemma 4 did something different here — it became a narrator. It gave this app a voice, a personality, a sense of drama.

Space is the most dramatic story humanity has ever told. I just needed an AI good enough to tell it.

Gemma 4 was that AI. 🌌

Built with vanilla JS, Canvas API, and Gemma 4 via Google AI Studio.

No frameworks were harmed in the making of this app.

Thanks for reading!!

Tags: #gemma4 #googleai #javascript #space #webdev #ai #opensource

I Tried to Run Google's Most Enterprise Database on My MacBook. Here's What Actually Happened.

Ishant gupta — Wed, 29 Apr 2026 13:57:01 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

At Google Cloud NEXT '26, buried inside announcement #68 of 260 total announcements, was a single sentence that stopped me cold:

"Run it anywhere — across multiple clouds, on-premises, or on your laptop."

"It" is Google Spanner — the database that powers Gmail, Google Ads, Google Pay, and YouTube. The system Walmart, Goldman Sachs, and Shopify depend on for their most critical workloads.

They said I could run it on my laptop. So I tried. Here's the honest account of what happened — including the part where Google locked me out before I even started.

Spoiler: Spanner Omni itself requires whitelisting. But what I could run locally surprised me more than I expected.

What Spanner Omni Actually Is

Spanner Omni is Google's answer to a question nobody thought they'd ask: what if you could take the database that runs Google's entire ad business and make it deployable anywhere — on AWS, on-premises, in an air-gapped data center, or on a developer's MacBook?

The hard engineering problem wasn't the database itself. It was TrueTime.

Original Spanner's legendary consistency guarantees depend on atomic clocks and GPS hardware physically embedded inside Google's data centers. That hardware is what lets Spanner know, with mathematical certainty, the order in which transactions happened across data centers on opposite sides of the planet.

You cannot ship GPS satellites in a Docker image.

So Google built a software-defined TrueTime alternative — a reimplementation that provides error-bounded time synchronization without specialized hardware, relying on the insight that Spanner can tolerate weaker uncertainty bounds because it overlaps time-uncertainty waits with other database work.

That is not a minor detail. That's a fundamental reimagining of one of distributed systems' most famous components, shipped quietly alongside 259 other announcements.

The Part Google Didn't Advertise: It's Not Public Yet

The blog post says "available today in preview." What it doesn't prominently say: the Docker image requires Google to whitelist your account before you can pull it.

I found this out the hard way:

docker pull us-docker.pkg.dev/cloud-spanner-omni-preview/release/spanner-omni:2026.r1-beta

Even after configuring gcloud auth, the pull failed with the same authorization error: permission denied on the registry. The preview is real, but access is controlled. If you want in, you need to contact Google directly.

This is worth knowing before you block off an evening.

What You Can Do Right Now: The Spanner Emulator

While Spanner Omni stays behind Google's velvet rope, there's a fully functional local Spanner environment that IS publicly available right now: the Cloud Spanner Emulator.

docker pull gcr.io/cloud-spanner-emulator/emulator

docker run -d -p 9010:9010 -p 9020:9020 \
  --name spanner-emulator \
  gcr.io/cloud-spanner-emulator/emulator

It pulled cleanly and started in under 2 seconds:

Configure gcloud to point to your local emulator:

gcloud config set auth/disable_credentials true
gcloud config set project test-project
gcloud config set api_endpoint_overrides/spanner http://localhost:9020/

Then run a real query:

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT 'Spanner is running on my MacBook' AS message"

That line printing in my terminal felt genuinely surreal. This is the same database engine that handles Google's global ad auction, running entirely offline on a MacBook Air.

Benchmark: How Fast Is It Locally?

I didn't just want to run a hello-world query. I wanted real numbers.

I inserted 1,000 rows using a shell loop:

for i in $(seq 1 1000); do
  gcloud spanner rows insert \
    --instance=test-instance \
    --database=test-db \
    --table=Users \
    --data="UserId=$i,Name=User$i,Email=user$i@test.com"
done

Then timed a COUNT query across all 1,000 rows:

time gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT COUNT(*) FROM Users"

And a LIMIT 100 fetch:

time gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT * FROM Users LIMIT 100"

Result: 100 rows fetched in 0.37 seconds on a MacBook Air. COUNT across 1,000 rows returned near-instantly. For a database engine designed for planet-scale distributed workloads, that's more than responsive enough for real local development.

ACID Transactions Working Locally

This is Spanner's actual superpower — strong consistency across distributed nodes. I wanted to verify it works locally too.

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="UPDATE Users SET Name = 'Ishant Gupta' WHERE UserId = 1" \
  --enable-partitioned-dml

Immediately queried it back:

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT * FROM Users WHERE UserId = 1"

The change was there instantly. Then I ran aggregations across all 1,000 rows:

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT COUNT(*) as TotalUsers, 
        MAX(UserId) as MaxId, MIN(UserId) as MinId 
        FROM Users"

COUNT, MAX, MIN — all correct, all returned in under a second. This isn't a mock. It's real Spanner consistency semantics running entirely offline.

Vector Search: The AI Angle

One of the biggest NEXT '26 announcements was Spanner's support for vector search — making it viable as an AI retrieval database with no ETL pipeline needed.

I created the schema locally to see if the emulator would accept it:

CREATE TABLE Documents (
  DocId INT64 NOT NULL,
  Content STRING(MAX),
  Embedding ARRAY<FLOAT32>
) PRIMARY KEY (DocId)

It accepted the schema instantly. Note: actual vector similarity search queries require cloud Spanner — but designing and validating your AI data model locally before touching production is exactly the workflow Google is targeting with these announcements.

The Real Story: Solving the Parity Problem

Here's what I think is genuinely underreported about both the emulator and Spanner Omni:

Before this, building on Spanner meant one of three painful options:

Mocking the database (fast but inaccurate)
Substituting SQLite (wrong SQL dialect, wrong behavior)
Pushing every change to a cloud dev environment and waiting

With a local Spanner running, the queries that work in your terminal work in production. The schema you design locally is the schema you deploy. The ACID semantics you rely on locally are the semantics you get in prod.

For AI applications specifically, this matters even more. Spanner now supports vector search, Spanner Graph for relationship queries, and full-text search — all in one database. You can prototype an entire AI retrieval stack locally, for free, before spending a rupee on cloud credits.

My Honest Take

Spanner Omni as announced is not what you can run today unless Google whitelists you. That gap between the blog post and actual access is worth calling out — not as a criticism, but as something every developer should know before they try.

But the emulator is real, it works, and the numbers speak for themselves: 1,000 rows, 0.37 second fetches, real ACID transactions, and vector-ready schema — all running on a MacBook Air that was also playing Spotify.

The 2012 Spanner paper felt like reading about infrastructure from another planet. Running SELECT * FROM Users locally in 2026 means that planet is now your dev environment.

If you're building anything data-intensive — especially with AI retrieval — run these two Docker commands this weekend and see how it fits your stack. I'm waiting on Spanner Omni access; when it lands, I'll write the follow-up this article deserves.

References: