Identify what stops work
Start with the external event that could prevent work, then identify a suitable independent data source.
← All projectsProduct investigation / 01
Product concept · Parametric insurance
Resilio.
When the weather stops work, what happens next?
Concept developed
Resilio is a student project exploring a simple question: could weather data help delivery partners receive income support when severe weather stops them working?
Read the storyIllustrative concept · A crossed threshold starts a coverage check, not an automatic payout.
01 / Why I worked on this
A missed day of work is not a small problem.
Bad weather can stop a delivery partner from working. An insurance claim may take longer than they can afford to wait.
I explored whether an agreed weather threshold could start a payment process without asking every delivery partner to prove the same weather event. The concept still needs a separate check that the worker is covered.
My contribution
I mapped how weather data could lead to a payment, who would qualify, and what could go wrong.
01 · Event
Does the signal meet the agreed threshold?
Use weather data from an independent source.
Yes ↓ ContinueNo → No event based payout
02 · Coverage
Is this worker covered in the affected location?
Check eligibility separately from the weather event.
Yes ↓ Initiate agreed payoutNo → Explain the coverage decision
One problem to test: someone loses income, but the weather reading never crosses the threshold.
Illustrative concept logic. The mismatch between the trigger and a person’s loss is called basis risk; it remains a pilot question.
02 / Developing the idea
Two checks. Different questions.
01
Weather
Did the agreed event happen?
02
Coverage
Is this person covered?
03
Decision
Apply the agreed rule.
Illustrative concept. An event alone does not guarantee a payment.
Explain when the cover applies
Connect independent weather data to a predefined threshold so users understand what activates the cover.
Check each step towards payment
Look at the weather check, the coverage check, and the payment separately to see where mistakes or fraud could happen.
03 / My reasoning
What I chose, and why.
01Use an independent weather reading
The same independent weather reading could establish the event for workers in the affected area.
02Agree on the rule upfront
Make the trigger visible up front so the user can understand what will and will not lead to a payout.
03Test the assumptions
The price, payment amount, seasonal limit, and risk of the trigger missing a real loss all need testing.
04 / Where it stands
A concept, with real questions left to test.
I put together a model covering the weather trigger, coverage checks, payments, and questions for a pilot. It is still a concept. I would need to test the pricing, local weather data, fraud checks, and cases where the trigger does not match a worker’s loss.
Progress so far. The concept sets out a weather threshold, a check on who is covered, and a decision about payment.
What I’m taking into the next version
- People need to understand which weather reading is used and when it leads to a payment.
- Checking the weather and checking the worker’s cover are two different jobs.
- The explanation needs to include the situations where someone would not receive a payment.