Using AI/ML and Space Technology to Identify Manganese Reserves and Overcome Production Shortfalls.

The receipts 🧾

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

1. Exhibit A

   The description asks you to find sub-surface reserves using rainfall, soil moisture, vegetation index and land temperature, and none of those indicate manganese — following the statement literally produces a model that is scientifically indefensible

2. It gets worse

   MOIL's geological drill logs, production records and equipment downtime data are all internal, and no dataset link is provided, so both halves start with a data source you have to invent

3. Still reading?

   Two unrelated problems in one statement means a team either splits its effort and does both badly or answers half the PS

4. And the finisher

   There is no way to validate a reserve prediction without drilling, so your headline claim is permanently unverifiable and a domain judge knows that better than you do

The damage report 📉

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

• Feasibility

  2/5

  You have picked a fight with physics, procurement, or both. One of them always wins.

  Sub-surface manganese reserves cannot be identified from the satellite inputs the description names — rainfall, soil moisture, NDVI and land surface temperature are not mineralisation indicators — and the data that would work, ASTER spectral or airborne geophysics plus MOIL's own drill logs, is either unavailable or internal, while the production and equipment downtime records the second half needs are proprietary and will not be released to a student team.

• Innovation scope

  4/5

  There is something genuinely new here. Do not bury it under another dashboard.

  Only a dashboard is prescribed and the description is short enough that the modelling approach, the choice of indicators and the entire structure of the recommendation engine are left to you.

• Clarity

  2/5

  Nobody is sure what is being asked, quite possibly including the people who asked it.

  At barely 1,300 characters it fuses two unrelated problems — geological prospecting and operations scheduling — into one statement, and the satellite inputs it names have no established causal link to the reserve estimation it is asking for, so the premise itself is confused rather than merely thin.

• Acceptance potential

  2/5

  The numbers do not like you. Bring something the numbers cannot see.

  The reserve identification half is built on a hollow premise that a geologist judge will dismantle immediately, and the shortfall half depends entirely on internal operational data you have no route to, which leaves a well-built dashboard sitting on top of nothing verifiable.

• Effort

  Heavy

  Heavy. Somebody on this team is not sleeping in week three. Pick who, on purpose.

  Two independent modelling problems in different disciplines, each needing its own data pipeline and validation story, plus a unified dashboard — the code is not deep but the ground you have to cover is wide and the two halves share nothing.

• Demo-ability

  Hard

  Near impossible to show working in five minutes, which is roughly five minutes more than you get.

  There is no ground truth in the room for either half — you cannot show a predicted reserve is real without drilling it, and you cannot show a production forecast is right without MOIL's actual subsequent output.

• 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 120–270 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.

• Innovation scope is wide open because the description prescribes almost nothing beyond a dashboard, so you can define the problem in a way you can actually deliver
• Mineral exploration is an unusual domain for a hackathon and the field for this statement will be very thin
• The production forecasting half is a legitimate, well-understood time-series problem that works on synthetic operational data if you frame it as a planning tool rather than a prediction of MOIL's real output