A web platform that calculates a human thermal stress index from weather and demographic data, providing ward-level heatwave alerts and automated warnings for municipal authorities.
Ministry of Earth Sciences (MoES) · National Centre for Medium Range Weather Forecasting (NCMRWF) · Software
Signing in saves it for your whole team — everyone on your invite link sees the same two entries. Anything you shortlisted while signed out comes with you.
Decomposed from what the description asks for. Nothing added.
Thermal Stress Engine
Algorithms that compute advanced metrics like WBGT, UTCI, or Heat Index using temperature, humidity, wind, and radiation data.
Mortality Risk Predictor
A predictive model that uses historical health, demographic, and weather data to forecast hospitalization and mortality spikes three to five days in advance.
GIS Mapped Dashboard
A dynamic, color-coded map interface displaying hyper-local alerts at the zone and ward level alongside public health advisories.
Automated Alert API
An application programming interface that pushes regional SMS or WhatsApp alerts and triggers city administration action plans.
Both columns are read off the brief's own wording. Nothing here is inferred from the ministry's name.
The jury will check if your algorithms correctly compute advanced heat stress metrics rather than relying on simple temperature, and if your platform successfully integrates weather data with demographic and public health factors to generate ward-level forecasts three to five days in advance.
A jury can still ask about these. Decide them deliberately rather than by accident.
Generated from the brief's own wording and the competition's published rules — never from a guess about what this ministry prefers.
Specific weather data sources or APIs to use?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Historical public health and mortality datasets to train the model?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Exact demographic data for elderly and outdoor worker density?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
SMS or WhatsApp gateway provider requirements?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Each one is quoted from a gap in the brief, not a guess about your team.
Needs data you may not get
The prompt requires integrating historical public health, demographic, and localized weather data which are not provided by the organisers.
What the organisers attached, and what the brief assumes you can get.
Same organisation, same year. Reading two of theirs tells you more about what they care about than reading one.
Pick what you are about to do and copy the prompt. It carries the organisers' own wording, the constraints they never spell out, and an instruction not to invent requirements they never set.
Who has this problem, what already exists, and what you would have to find out.
Has any part of this been shown at a previous event, hackathon or college project?
The guidelines are explicit: your solution must not have appeared in any previous event or programme, of any sort. A recycled project is what a team under time pressure reaches for.
The brief asks for thermal stress engine. How would you build that?
Decoded from SIH26083 itself — Algorithms that compute advanced metrics like WBGT, UTCI, or Heat Index using temperature, humidity, wind, and radiation data. The brief asks for it by name.
The brief asks for mortality risk predictor. How would you build that?
Decoded from SIH26083 itself — A predictive model that uses historical health, demographic, and weather data to forecast hospitalization and mortality spikes three to five days in advance. The brief asks for it by name.
The brief asks for gis mapped dashboard. How would you build that?
Decoded from SIH26083 itself — A dynamic, color-coded map interface displaying hyper-local alerts at the zone and ward level alongside public health advisories. The brief asks for it by name.
The brief asks for automated alert api. How would you build that?
Decoded from SIH26083 itself — An application programming interface that pushes regional SMS or WhatsApp alerts and triggers city administration action plans. The brief asks for it by name.
Where does your data come from — a published source, one you collect, or one you generate?
No dataset is attached to this problem statement, so sourcing it is part of the work and nobody told you that.
Why not use what already exists? Name the closest thing to this that is already running.
A team that has not named the alternative themselves is answering this for the first time in the room.
Which single thing will you demonstrate end to end, start to finish, with nothing skipped?
Ours, not a rule: a narrow thing that fully works survives questioning better than a broad thing that half works. If nobody on the team can name it, that is the finding.
Show me this working: the jury will check if your algorithms correctly compute advanced heat stress metrics rather than relying on simple temperature, and if your platform successfully integrates weather data with demographic and public health factors to generate ward-level forecasts three to five days in advance.
This is the evaluator read for your problem statement, decoded from the brief's own wording.