AI-Driven Hyper-Local Early Warning System for Severe Weather Nowcasting

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   The sponsor has written the solution, not the problem — innovation scope is effectively nil and every responsive submission will have the same architecture, so execution and data handling are all that separate teams

2. It gets worse

   No curated catalogue of Indian cloudburst and flash flood events exists, so you must assemble labels by hand from incident reports, and label quality will bound your results far more tightly than model choice

3. Still reading?

   Cloudbursts are extremely rare in a grid-and-time sense, so a model optimised on accuracy learns to predict nothing and scores beautifully — use categorical scores that penalise misses and report them by hazard

4. And the finisher

   Aligning reanalysis, multi-channel satellite and elevation data onto one grid is where most of the time goes, and teams consistently budget for the model instead

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  3/5

  Buildable. Not comfortably. There is a week in here you have not planned for yet.

  The statement names its data sources and they are genuinely obtainable — reanalysis, satellite water vapour and infrared channels, precipitation estimates and elevation models are all available with registration — but there is no curated catalogue of Indian cloudburst and flash flood events with locations and times, so the labels for two of the three output heads have to be assembled by hand from incident reports.

• Innovation scope

  1/5

  Nothing here is new. Your only edge is execution — and execution is also everyone else's only edge.

  The statement is written as a proposed solution rather than a problem — it specifies the multi-task architecture, the shared backbone with branching heads, the cross-attention mechanism, the precursor variables and the datasets, leaving essentially nothing for you to design.

• Clarity

  5/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  Exhaustively detailed across seven thousand characters, naming every predictor variable and the physical reason for it, every dataset and where it comes from, the architecture, the lead time window and all four deliverable components.

• Acceptance potential

  3/5

  Middle of the pack. This statement will not win the room for you — you will have to.

  The physics is sound, the data is named and real, and hindcasting a documented event is honest validation — but the sponsor has written the architecture down to the attention mechanism so there is nothing to invent, and cloudbursts are rare enough that the class imbalance will dominate your results more than the model does.

• Effort

  Massive

  A semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.

  Aligning reanalysis, multi-channel satellite and elevation data onto a common grid is a project on its own, and on top of it sit derived thermodynamic index computation, a multi-task spatiotemporal network, three output heads, an explainability module, a dashboard and an alerting API.

• Demo-ability

  Medium

  Demoable, if you rehearse it. Nobody rehearses it.

  A hindcast of a real cloudburst with probability rising over the correct valley is genuinely persuasive, but probability maps require interpretation and the result depends entirely on having found a well-documented event with usable timing.

• Data

  None supplied

  No dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.

  Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.

The demo they will have already seen 🪞

Somewhere around 140–330 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• The statement names every dataset and every predictor variable with the physical reasoning behind it, so you are not guessing at either the science or the sources — this is a specification a meteorologist wrote
• Cloud top temperature drop rate and integrated water vapour accumulation are genuinely strong, physically motivated precursors that can be computed directly from free satellite channels
• Multi-task learning across three related hazards is the right architecture here because they share precursors, and the sponsor having specified it means you can spend your time on the data rather than defending the design