Earth, Not as a line chart. Not as a dashboard. As a living, breathing 120,000-cell map where every pixel is a differential equation

shivam kumar — Mon, 20 Apr 2026 06:57:44 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

I built TERRA-STATE: VOX ATLAS, a real-time ecological simulation that runs on a 200×600 world grid with 120,000 active cells.

The project turns ecological and economic feedback into a live, playable planet. Forests generate water, agriculture drains soil, cities expand, and a DESERTIFICATION CASCADE can collapse the world if the balance breaks.

Demo

Run the app locally:

git clone https://github.com/shivamKumarG11/Dev-to-Weekend-challenge-Earthday-edition-submission.git
cd Dev-to-Weekend-challenge-Earthday-edition-submission
python run.py

Then open:

http://localhost:8000

Video demo: https://youtu.be/wpWgt12ABmo

Code

shivamKumarG11 / Dev-to-Weekend-challenge-Earthday-edition-submission

Dev-to-Weekend-challenge-Earthday-edition-submission

View on GitHub

The codebase is structured with a clean separation between simulation, external services, and frontend rendering.

terra-state/app.py — FastAPI entrypoint, routes, and integration wiring
terra-state/core/engine.py — world state machine, tick loop, and grid operations
terra-state/core/simulation.py — pure differential-equation physics for biomes
terra-state/core/models.py — Pydantic v2 schemas for state and API contracts
terra-state/services/auth0_guard.py — JWT validation for authenticated agent actions
terra-state/services/gemini_oracle.py — Google Gemini advisory prompt builder
terra-state/services/snowflake_log.py — async telemetry sink for every tick
terra-state/services/backboard.py — live climate multiplier fetcher
terra-state/static/ — frontend shell, Canvas renderer, app controller, styles

How I Built It

I built the app with a focus on making the system feel immediate and scientifically grounded.

Isolated the physics engine in terra-state/core/simulation.py so the world logic is testable and independent from HTTP or UI
Used FastAPI to expose a tick endpoint, world state hydration, Oracle sector reports, authenticated agent actions, and integration endpoints
Added a POST /tick route that advances the simulation and fires an async Snowflake logger without blocking the response
Implemented Auth0 JWT verification in terra-state/services/auth0_guard.py, with a local dev-token bypass for development
Wired Google Gemini to generate a concise advisory bulletin from the live world state
Added Backboard remote config to influence drought severity and market demand every tick
Built the frontend as a zero-framework HTML5 Canvas SPA with pan/zoom controls and a live metrics strip

Prize Categories

Best Use of Backboard — live climate overrides influence drought and market demand in real time
Best Use of Auth0 for Agents — authenticated spatial agent actions with audit logging
Best Use of Google Gemini — AI bulletins from the current planetary state
Best Use of Snowflake — non-blocking telemetry logging for every simulation tick

Launching DSTAIR: 3 Insights from Building a High-End Analytical Platform

shivam kumar — Sat, 18 Apr 2026 19:10:46 +0000

Hey DEV Community! 👋 For my very first post here, I wanted to share a major project I recently launched. I’m an engineering student at IIT Madras, and I led the technical development and UI/UX redesign for DSTAIR | Institutional Reform Analysis.

Spearheaded by my professor, it's a web-based diagnostic tool designed to evaluate a country's institutional health and recommend targeted anti-corruption policies. Bringing his methodology to life as a production-ready platform meant merging complex data processing with a premium web experience.

Here are three architectural and design insights I gained during the build.

Insight 1: Streamlining Database Logic

To maintain a strict and clean architecture, I completely removed the traditional repository layer. Instead, I tied all database interactions directly into the data models themselves.

The Result: HTTP routes remain incredibly thin—handling only basic parsing and session logic—while the business logic remains centralized. Keeping the models "fat" and the routes "thin" made the complex mathematical scoring logic much easier to scale and maintain.

Insight 2: The "Economist meets OpenAI" Aesthetic

Most data-heavy institutional tools are clunky and visually dated. We wanted an authoritative, intellectual, and clean aesthetic.

The Execution: To present dense institutional diagnostics without overwhelming the user, I relied heavily on a Bento Grid layout. It forces design restraint, organizes complex data into highly digestible cards, and makes translating intricate data dashboards to mobile devices significantly easier.

Insight 3: Bridging Server Context with Frontend Reactivity

The core analysis workspace is a highly dynamic interface that needs heavy context from the backend to compute legitimacy scores on the fly in the browser.

The Solution: Instead of relying on a messy external JavaScript architecture that struggles to securely access backend variables, I embedded the core workspace logic directly inside the server-rendered templates. This allowed instant, secure access to backend context and routing URLs, while using a lightweight, declarative frontend framework to handle simple UI states natively.

Explore the Live Platform

You can check out my professor's methodology and the live tool we built here: DSTAIR | Institutional Reform Analysis

I’d love to hear from other developers building data-heavy apps:

Have you experimented with tying database logic directly to your models in Python frameworks?
How do you prefer to handle the bridge between server-side context and frontend engines?

Let me know in the comments. Excited to finally join and share with the DEV community!

Forem: shivam kumar