A web dashboard that uses AI to compare current weather forecasts with past errors, producing a confidence map and bust probability for meteorologists.
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.
Forecast Confidence Map
Displays region-wise confidence scores for Day 1 to Day 10 forecasts.
Forecast Bust Probability
Calculates and shows the probability of large forecast errors over different regions.
Error-Prone Area Detection
Identifies specific areas where the model forecast is likely to be unreliable.
Explainable Output
Provides key meteorological reasons for why confidence is low in certain areas.
Prototype Dashboard or API
Provides a simple interface for operational use by forecasters.
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 system compares current weather patterns with historical forecast errors, produces regional confidence maps for Day 1 to Day 10, and explains the meteorological reasons for low confidence. They will also look for a working dashboard or API for operational use.
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.
Historical weather data and model forecast datasets needed to train or test the AI?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Specific numerical accuracy or error threshold that counts as a forecast bust?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
The exact file formats or data pipelines the operational dashboard must ingest?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
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.
Each one is quoted from a gap in the brief, not a guess about your team.
Needs data you may not get
The challenge requires comparing current numerical weather prediction forecasts with historical forecast error behaviour, but no dataset is provided by the organisers.
No measurable target
The description asks to identify high uncertainty or large errors without specifying a numerical accuracy target or percentage threshold for what constitutes a bust.
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.
The brief asks for forecast confidence map. How would you build that?
Decoded from SIH26079 itself — Displays region-wise confidence scores for Day 1 to Day 10 forecasts. The brief asks for it by name.
The brief asks for forecast bust probability. How would you build that?
Decoded from SIH26079 itself — Calculates and shows the probability of large forecast errors over different regions. The brief asks for it by name.
The brief asks for error-prone area detection. How would you build that?
Decoded from SIH26079 itself — Identifies specific areas where the model forecast is likely to be unreliable. The brief asks for it by name.
The brief asks for explainable output. How would you build that?
Decoded from SIH26079 itself — Provides key meteorological reasons for why confidence is low in certain areas. The brief asks for it by name.
The brief asks for prototype dashboard or api. How would you build that?
Decoded from SIH26079 itself — Provides a simple interface for operational use by forecasters. 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 system compares current weather patterns with historical forecast errors, produces regional confidence maps for Day 1 to Day 10, and explains the meteorological reasons for low confidence.
This is the evaluator read for your problem statement, decoded from the brief's own wording.
Show me this working: they will also look for a working dashboard or API for operational use.
This is the evaluator read for your problem statement, decoded from the brief's own wording.