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
Top comments (0)