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 FRAUD DETECTION MODEL — BEHAVIORAL FINGERPRINTING
A genuine stranded rider and a GPS spoofer sitting at home look fundamentally different across six simultaneous signals. Our XGBoost model fuses all six into a single Fraud Confidence Score.
Signal 1 — GPS Trajectory
A genuine rider shows a delivery route pattern followed by a sudden stop near their dark store. A spoofer shows static coordinates or GPS points that teleport between locations.
Signal 2 — Device Accelerometer
A genuine rider shows high movement prior to the disruption followed by low movement during sheltering. A spoofer shows completely static readings for hours — no micro-vibrations, no movement at all.
Signal 3 — Network Type Switching
This is our most important and counterintuitive signal. A genuine rider outdoors in bad weather will show network degradation — 4G dropping to 2G dropping to no signal as they move through affected zones. A spoofer sitting on home WiFi shows a perfectly stable, single-tower connection throughout.
Network degradation is a positive authenticity signal in our model, not a red flag. Most fraud systems penalize connectivity loss. Ours rewards it as proof of genuine outdoor presence.
Signal 4 — Battery Drain Rate
A rider using their phone actively outdoors drains battery faster than a phone plugged in at home on charge. This is a subtle but statistically significant signal when combined with the others.
Signal 5 — App Session History
Was the rider actively accepting and completing orders on the Blinkit partner app in the 45 minutes before the trigger fired? A spoofer typically shows zero app activity for hours before a claim.
Signal 6 — Platform Contradiction Check
If Blinkit's customer-facing app is still showing delivery ETA of 8 minutes for a zone, but riders in that zone are claiming inability to work — the platform itself is contradicting their claim. This cross-platform validation is unique to the Blinkit persona and is only possible because of the dark store's known delivery ETA data structure.
For coordinated ring detection, we cluster claims by dark store ID. If 8 of 12 riders from the same dark store file claims within a 90-minute window, the entire batch is flagged for zone-level review — not individual rejection. The store's own availability status then cross-validates whether the claims are plausible. This is machine-detectable in milliseconds.
THE PREMIUM MODEL — ACTUARIALLY GROUNDED, NOT JUST AI
Every team at this hackathon will say AI-powered dynamic pricing. Here is what we are actually calculating.
Weekly Premium equals Base Rate multiplied by Zone Risk Multiplier multiplied by Worker Tenure Factor multiplied by Seasonal Index.
The Base Rate sits between 35 and 65 rupees per week, calibrated to hit our sustainability target of a 60 to 70 percent loss ratio — the industry benchmark for viable micro-insurance products.
The Zone Risk Multiplier is trained on five years of IMD historical rainfall frequency data per Bengaluru pincode. A rider operating out of the Bellandur dark store, which sits in a historically flood-prone zone near the Bellandur lake storm water drain overflow area, carries a 1.4 times multiplier versus a rider in Whitefield at 1.0 times. This is actuarially justified pricing, not a number we invented.
The Worker Tenure Factor applies a 1.2 times loading for riders in their first four weeks — standard actuarial practice for unknown risk profiles, identical to how car insurance treats new drivers.
The Seasonal Index applies a 1.5 times multiplier during monsoon months from June through September based on historical disruption frequency data from IMD records.
Why does the loss ratio target matter? A loss ratio below 40 percent means we are overcharging workers — ethically indefensible for a micro-insurance product targeting people earning 700 rupees a day. A loss ratio above 90 percent means the product is financially unviable and cannot sustain claims. The 60 to 70 percent band is where sustainable micro-insurance lives. We are building this as a live, color-coded metric on our insurer dashboard from day one.
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.
WHY WE ARE BUILDING A PWA AND NOT A NATIVE APP
Our target user is a Blinkit rider in Bengaluru earning 700 rupees per day on a 10,000 rupee Android phone with intermittent 3G and 4G connectivity that drops during deliveries.
A native app requiring Play Store installation is an adoption barrier before the product even starts.
We are building a Progressive Web App because it works offline, which is critical for riders in low-connectivity zones. It is installable from the browser with no Play Store download and no 200 megabyte installation. It loads fast on 2G and 3G connections. And the entire onboarding completes in under 90 seconds via mobile number and OTP only — no email required, no Aadhaar upload, no document friction.
The benchmark we are optimizing against is Blinkit's own partner onboarding flow, which currently takes 12 to 18 minutes with document uploads. We are targeting under 2 minutes with zero document friction. The UI will support Kannada and Hindi from Phase 2.
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)