DEV Community: Nehaa V

Scaling the Safety Net: Our Journey into Phase 2 of Guidewire DevTrails 2026

Nehaa V — Sat, 04 Apr 2026 09:17:27 +0000

Welcome back to the AutoLearn development blog. Following our deep-dive into the "Seed Phase" research where we mapped the vulnerabilities of the gig economy, we have officially transitioned into Phase 2: The Scale Phase.

In this stage of the Guidewire DevTrails 2026 Hackathon, the simulation shifts from empathy-mapping to high-stakes execution. We are no longer just building a project; we are running a virtual startup where technical debt and financial "Burn" have real consequences.

1. The Startup Simulation: Navigating "The Burn"

Phase 2 introduced a critical new constraint: The Burn Rate. With a weekly operational cost of DC 12,000 (DevCoins), our team had to adopt a lean-startup methodology.

Every architectural decision from API polling frequency to cloud storage tiers—was evaluated against our survival runway. This phase taught us that scalability isn't just about handling traffic; it’s about resource efficiency. We optimized our backend to ensure ShieldRide could monitor thousands of environmental triggers without bankrupting our virtual treasury.

Key Takeaway: In a scale-up environment, "expensive" code is just as dangerous as "broken" code. Efficiency is the ultimate feature.

2. Technical Architecture: The Parametric Engine

The core of ShieldRide is our AI-Enabled Parametric Trigger Engine. Unlike traditional insurance, which requires manual claims and weeks of verification, ShieldRide uses real-time data to trigger instant relief for delivery partners.

A. Multi-Source Trigger Ingestion

We developed a data pipeline that monitors three specific "External Disruption Triggers":

Hyper-Local Weather: Monitoring for rainfall exceeding 15mm/hr or temperatures above 42°C.
Platform Health: Utilizing synthetic monitoring to detect outages in major delivery apps that prevent workers from logging in.
Environmental Safety: Tracking Air Quality Index (AQI) levels. In high-density urban corridors, an AQI > 250 represents a significant health risk that merits automated hazard protection.

B. Predictive Analytics with Python

We integrated a light-weight machine learning model to predict Earning Loss Probability (ELP). By analyzing historical delivery patterns against real-time disruptions, ShieldRide can quantify exactly how much a worker's income is likely to drop, automating the "payout" trigger.

def evaluate_risk_level(weather_data, platform_status):
    """
    Evaluates if a parametric payout should be triggered
    based on environmental and system telemetry.
    """
    risk_score = 0

    # Check environmental triggers
    if weather_data['rain_mm'] > 15: 
        risk_score += 45
    if weather_data['aqi'] > 250:
        risk_score += 25

    # Check system triggers (Platform Outages)
    if not platform_status['is_up']: 
        risk_score += 60

    # Trigger threshold for micro-payout activation
    return True if risk_score >= 50 else False

3. Product Roadmap: Building the MVP

To survive the simulation's weekly "Sunday Midnight" evaluation, we focused on delivering a high-impact Minimum Viable Product (MVP). We prioritized features that maximized "Investor Confidence" while minimizing operational costs.

Module	Technical Focus	Status	Rationale
Trigger Engine	Real-time API integration (Weather/Traffic)	Production-Ready	Core functionality for parametric insurance.
Worker Dashboard	Low-latency, offline-first UI for field use	Beta Testing	Essential for workers with spotty connectivity.
Claims Ledger	Transparent, immutable record of micro-payouts	Completed	Necessary for financial audit and trust.
Predictive ML	Random Forest model for risk assessment	Optimizing	Balancing accuracy vs. computational "Burn."

4. Pivots and Lessons Learned

In the middle of the Scale Phase, we hit a significant roadblock: our initial data-scraping module was consuming too much "Burn" (virtual DC) due to high-frequency polling.

The Pivot: We refactored our architecture from a "Pull" model (constantly checking APIs) to a "Push" model using Webhooks and Event-Driven Architecture. This reduced our operational overhead by nearly 22%, ensuring our startup remains solvent as we head into the final phase.

This taught us a vital lesson: Architect for the budget you have, not just the performance you want.

5. The Path to "Soar" (Phase 3)

As we wrap up Phase 2, our focus is shifting toward Phase 3: Soar. Our goal is to demonstrate how ShieldRide can be integrated into existing insurance ecosystems using Guidewire’s principles of digital transformation.

What’s next on the horizon:

Finalizing our investor pitch and financial sustainability report.
Stress-testing the platform for extreme "Flash Event" scenarios (e.g., city-wide floods).
Refining the user experience to ensure delivery partners can access support in under three clicks.

Team: AutoLearn

Project: ShieldRide

Phase: 2 (Scale) - Successfully Navigated Mission: Protecting the backbone of the gig economy through automated, AI-driven resilience.

Building ShieldRide: Why We Chose Blinkit's Dark Store for Parametric Insurance Platform for Guidewire DevTrails Hackathon

Nehaa V — Wed, 18 Mar 2026 18:09:37 +0000

Team AutoLearn | Guidewire DEVTrails 2026 — Seed Phase
Amrita Vishwa Vidyapeetham, Bengaluru | March 2026

THE 10:47 PM MOMENT THAT DEFINED OUR IDEA

On December 31, 2025, while the rest of India was counting down to the new year, over 2,00,000 delivery workers across Zomato, Blinkit, Swiggy, and Amazon went on a nationwide flash strike.

They weren't asking for a salary hike. They were asking for something far more basic — a safety net for the days they simply cannot work. Not because they chose not to, but because it rained too hard, the air became unbreathable, or the platform they depend on went dark.

That strike became the seed of our idea. This is the story of Phase 1.

WHY THIS PROBLEM IS BIGGER THAN IT LOOKS
India's gig workforce stands at 12 million workers today and is projected to cross 24 million by the end of this decade. The Q-Commerce segment alone — Blinkit, Zepto, Swiggy Instamart — is expanding at 40 percent year-on-year, with Blinkit alone targeting 3,000 dark stores by March 2027.

Yet despite Zomato and Blinkit spending over 100 crore rupees on insurance coverage for delivery partners in 2025, that coverage addresses health, life, and accidents — not income loss. Not the 600 to 900 rupees a Blinkit rider loses on a day when rainfall shuts down their entire service zone.

The Sabka Bima, Sabki Raksha Bill 2025 explicitly calls out gig workers and informal sector participants as underinsured and promotes parametric insurance as a priority solution. The regulatory window is open. The market is ready. The product does not exist yet.

That is the gap we are building for.

We spent Day 1 of Phase 1 in a genuine debate — Zomato, Swiggy, Amazon, or Blinkit. The answer became obvious the moment we drew the risk map.

Blinkit operates on a dark store model. Each rider is physically anchored to a single store with a fixed GPS coordinate, a known 1.5 to 2.5 kilometer service radius, and a documented set of serviceable pincodes. Blinkit currently operates 300 plus dark stores in Bengaluru alone as part of their aggressive national expansion toward 3,000 stores by 2027.

This hyperlocal architecture creates something no other delivery persona has — a verifiable, machine-readable anchor point for every single parametric trigger.

When IMD reports rainfall above 20mm per hour in Koramangala, we do not have to guess which riders are affected. We cross-reference the exact pincodes served by dark store BLK-BLR-047. The trigger is surgical, not approximate.

For Zomato riders scattered across 30 plus restaurants in a city, that precision does not exist. For Amazon riders operating city-wide, even less so.

Blinkit's dark store model is the only persona where parametric insurance is mathematically defensible at the street level. That is why we chose it.

WHAT WE ARE BUILDING — SHIELDRIDE
An AI-powered, zero-touch parametric income protection platform for Blinkit delivery partners.

The core promise is simple. When a disruption hits your zone, your compensation is already processing before you even check your phone.

No claim forms. No documentation. No waiting. The event itself is the claim.

WHY TRIGGER DESIGN IS WHERE MOST PARAMETRIC PRODUCTS FAIL
Before listing our triggers, we need to talk about something most teams will completely skip — and it is the most important design decision in any parametric insurance product.

The Nagaland state government's parametric insurance pilot with Tata AIG failed to pay out a single claim despite real disasters occurring on the ground. The reason was that trigger thresholds were calibrated using satellite data that did not match ground reality, and IMD data was never consulted as the primary source. The state paid 70 lakh rupees annually in premiums for coverage that never activated.

That failure taught us the three non-negotiable criteria for every trigger we designed. First, it must be independently monitorable — verified by a credible third-party data source, not self-reported by the worker. Second, it must be fortuitous — entirely outside the worker's control. Third, it must be causally direct — a clear, unambiguous line between the trigger event and the income loss.

Every single one of our five triggers is designed against these three criteria.

OUR FIVE PARAMETRIC TRIGGERS

Trigger 1 — Rainfall Intensity
Threshold: Above 20mm per hour sustained for one hour
Data Source: IMD API and OpenWeatherMap
Why it works for Blinkit: A rider operating in a 2km radius simply cannot complete deliveries in this intensity of rain. The causal chain from trigger to income loss is immediate and total.

Trigger 2 — Extreme Heat Index
Threshold: Above 44 degrees Celsius for two or more consecutive hours
Data Source: IMD API
Why it works for Blinkit: Q-commerce riders are on bikes for 8 to 10 hours a day with no shade. At this heat index, physical delivery becomes genuinely dangerous, not just uncomfortable. We are covering income loss, not health — but the heat itself is what stops the income.

Trigger 3 — Severe AQI
Threshold: Above 400 on the AQI scale for four consecutive hours
Data Source: CPCB India — the Central Pollution Control Board's free government API
Why we chose CPCB over any other source: CPCB is the Indian government's own air quality monitoring system. In an Indian regulatory context, citing CPCB data is the difference between a legally defensible trigger and one that could be challenged. Almost no other team in this hackathon will know this API exists.

Trigger 4 — Platform Hub Downtime
Threshold: Blinkit dark store showing Closed or Inactive status for more than 60 minutes during peak hours between 10am and 10pm
Data Source: Mock Blinkit Store Status API built to mirror real Blinkit data schema
Why it matters: If the dark store itself is down, every single rider assigned to it has zero ability to earn — regardless of weather. This is a pure platform-operational trigger that no weather API can detect.

Trigger 5 — Hyper-local Internet Shutdown
Threshold: Mobile data suspension in the hub radius for more than three hours
Data Source: IODA — Internet Outage Detection and Analysis, which tracks real-time telecom disruptions across India
Why almost nobody will think of this: India recorded 84 internet shutdowns in 2024 alone, many of them government-imposed in specific districts. When mobile data goes down in a delivery zone, riders cannot accept orders, navigate, or confirm deliveries. IODA provides real-time tracking of these events at the district level. This is a first-party data oracle for parametric claims that we have not seen used in any InsurTech hackathon project before.

THE ARCHITECTURE DECISION THAT DEFINES EVERYTHING — ZERO-TOUCH CLAIMS

Most teams will build a button that says File Claim. We are not building that button.

A Blinkit rider earning 700 rupees per day should not need to understand insurance to receive insurance. The entire philosophy of parametric insurance is that the event itself triggers the payout — the worker is a beneficiary, not a participant in the claims process.

Here is our zero-touch claim pipeline in plain language.

Step 1 — The IMD API detects rainfall above 20mm per hour in pincode 560034, Koramangala.

Step 2 — Our system identifies all Blinkit dark stores serving pincode 560034. Store BLK-BLR-047 is confirmed within the affected zone.

Step 3 — The system identifies all active riders assigned to BLK-BLR-047 and runs two cross-checks. Was the rider's GPS within 200 meters of the store 30 minutes before the trigger? Was the rider's Blinkit app session active in that window?

Step 4 — A Fraud Confidence Score is calculated across six behavioral signals. If the score is below 40, the claim is auto-approved and UPI credit is initiated immediately. If the score is between 40 and 75, the claim goes into a soft hold with a 2-hour review SLA. If the score is above 75, it enters a human review queue with a 4-hour SLA. Crucially, no claim is ever auto-rejected — only auto-approved or queued for review.

Step 5 — The worker receives a WhatsApp message that reads: Heavy rain detected in Koramangala. Your income protection of 180 rupees has been credited to your UPI. No action needed. Stay safe — ShieldRide.

The worker did absolutely nothing. That is the entire claim experience. That is what zero-touch means.

THE INSURER DASHBOARD — FORWARD-LOOKING, NOT JUST BACKWARD

Most teams will build an analytics dashboard that shows historical data — past claims, past payouts, past fraud cases. That is a reporting tool, not an insurer tool.

Real insurers need forward-looking intelligence. Our insurer dashboard includes a predictive reserve panel that reads as follows.

Based on IMD 7-day forecast and historical claim patterns, Zone 4 Koramangala has a 73 percent probability of triggering three or more claims next week. Recommended cash reserve: 12,400 rupees.

This is reserve modeling — and it is what Guidewire's own enterprise products are built to support. A team that shows forward-looking risk forecasting on their insurer dashboard is building in the same mental model as Guidewire's actual product suite. Judges who are insurance engineers will immediately recognize this.

REGULATORY FRAMING — WHY IRDAI MATTERS

Our product sits within three active regulatory frameworks that make it not just viable but timely.

The IRDAI Sandbox Framework from 2019 explicitly permits parametric insurance experimentation without prior product approval. We qualify, and we are building within that sandbox.

IRDAI Micro-Insurance Regulations classify any product with a premium under 200 rupees per week as micro-insurance. Our entire premium range of 35 to 65 rupees per week fits comfortably within this bracket, meaning simplified compliance requirements and significantly lower distribution costs.

The Sabka Bima, Sabki Raksha Bill 2025 — India's most significant insurance reform legislation in decades — explicitly promotes parametric and micro-insurance for informal workers as a national priority. We are not building against the regulatory grain. We are building exactly what the government has legislated for.

This matters because Guidewire's entire enterprise product suite is built around making insurance compliant, scalable, and real. A team that ignores regulatory context is building a demo. A team that embeds it is building a product.

OUR TECH STACK

Backend — FastAPI with Python for async-ready real-time trigger processing
Mock Platform API — FastAPI with JSON fixtures mirroring the real Blinkit store schema including store ID, delivery ETA, serviceable pincodes, and availability status
Weather and AQI — OpenWeatherMap combined with the CPCB India government API for real Indian air quality data
Internet shutdown detection — IODA API for real-time India telecom disruption tracking
Fraud detection ML — XGBoost trained on a six-signal behavioral feature vector, chosen for being