Skip to content
SIH Buddyby Ganeev Singh
Dev

πŸ”₯ Roast My Pick Β· SIH26006

Development of an Intelligent Freight Forecasting Model for Optimized Vessel Chartering and Bulk Cargo Procurement from overseas to East Coast of India

Ministry of Steel

Mild33/100

Reasonable choice. The scoreboard liked it. The scoreboard is not the one asking questions on the day.

Worth considering. A rare low-competition statement with a sponsor who genuinely wants the answer, but the freight rate series is licensed, so decide on day one what public proxy you are forecasting and be honest about that substitution instead of letting a judge find it. Roughly 250–500 teams are expected to go here.

The receipts

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

  1. Exhibit A

    Route-specific dry bulk rates are commercial Baltic Exchange data β€” you cannot get them, and forecasting the headline BDI instead is a materially different and much easier problem that a domain judge will spot

  2. It gets worse

    Freight markets are close to a random walk over short horizons, so an honest model may barely beat a naive persistence baseline and you must show that comparison rather than hide it

  3. Still reading?

    Real-time port congestion needs an AIS feed whose useful tiers are paid, and free AIS coverage of Indian anchorages is patchy

  4. And the finisher

    Four separate recommendation types are asked for and idle-scenario management in particular requires fleet data you have no route to, so scope down explicitly rather than faking that module

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.

    Port draft and berth limits are published and macro indicators are free, but route-level dry bulk freight rates are a licensed Baltic Exchange product, so the target variable your model is supposed to predict is the one input you cannot legally obtain and you will end up forecasting a public index as a proxy.

  • Innovation scope

    4/5

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

    The description specifies four output categories but says nothing about method beyond suggesting time series and regression, so the modelling approach, the feature set and how the port constraint layer interacts with the forecast are all genuinely yours to design.

  • Clarity

    4/5

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

    Unusually concrete for an SIH statement β€” it names the discharge ports, the origin countries, the vessel classes and the specific constraint variables, and the four recommendation types are laid out separately, though it never states what forecast horizon or accuracy would count as success.

  • Acceptance potential

    3/5

    Middle of the pack. This statement will not win the room for you β€” you will have to.

    The domain is unglamorous enough to thin the field considerably and the sponsor has a real operational need, but the licensed-data problem is structural rather than solvable by effort, and a proxy-index forecast is a much weaker answer than the statement is asking for.

  • Effort

    Heavy

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

    Assembling a defensible rate series, building and validating a forecast, encoding a port constraints database accurately, writing the vessel matching logic and wrapping it in a usable dashboard is four substantial workstreams with the data assembly quietly the largest.

  • Demo-ability

    Medium

    Demoable, if you rehearse it. Nobody rehearses it.

    A backtest overlay showing your recommendation would have beaten the spot approach is genuinely persuasive to a logistics judge, but it is charts and tables with no physical or interactive moment, so the presentation has to carry it.

  • 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 250–500 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 description names seven specific East Coast ports and their constraint variables, so the hardest requirement-gathering work has been done for you and your port database is verifiable against published port handbooks
  • Shipping economics is a domain almost no student team will touch, so the competition for this statement will be a fraction of what an AI-health or agri PS attracts
  • The vessel-class matching logic is deterministic and demonstrably correct, giving you a component that works reliably even if the forecast underperforms

Nothing here is fatal. It is just the list of places this statement pushes back, and you now get to push there first.

The framing is a joke. The findings are not β€” they are the same analysis on the statement page, and every line above is attached to a score or a fact in the record. It is one opinion with its reasoning attached, so argue with it before you trust it.