All fourteen statements from Apoorv, Priyanshu, Ekta and Rishi, scored against the thing that actually decides SIH — how many teams you are standing next to when the ministry screens ideas in October.
Primary — submit this
SIH26171
On-device Visual Perception for Light-weight Browser Agents
ISRO / Department of Space
The only statement in the shortlist that ships its own scoring rubric with percentage weights. Brutal enough to scare off most of the field, and the hard part is a YOLO model — which is exactly what your ML person already does.
Second slot — you get two
SIH26018
Intelligent Land Record Digitization and Validation System
Ministry of Rural Development / DoLR
Handwritten Devanagari OCR on real Bhulekh scans. Public data by the million, a demo any judge understands in four seconds, and a difficulty wall most teams walk away from.
01 — The algorithm
SIH is not won at the finale. It is won at the October screening.
There are three gates, and they do not weigh the same. Most teams optimise for the last one and die at the second.
Gate 1
Internal hackathon — your own college, PPT only
Judged by your faculty on innovation, feasibility, impact and presentation. Your institute then nominates its top teams to the national portal. Nomination quotas run into the dozens per college, so this gate is soft.
Low kill rate — a good deck clears it
Gate 2
National idea screening — October, judged by the posting ministry
Officials from the organisation that wrote the statement read every idea submitted against it. They are reading dozens to hundreds of near-identical decks. Nothing you build matters yet; only what you wrote and how different it reads from the median submission on that exact statement.
This is where almost everyone dies
Gate 3
Grand Finale — December, 36 hours at a nodal centre
Surviving teams build against the same statement in one room, judged in rounds by domain officials from the posting org. One winner per statement, ₹1 lakh+. Wins go to whoever demoed the hard part working on realistic data — not to the prettiest UI.
Every term matters, but field_size is the only one you control by choosing, and it swings by an order of magnitude across these fourteen. A statement with 30 competing teams and one with 300 pay the same ₹1 lakh.
How to shrink the field
Team count on a statement is driven by how easy it is to imagine a solution, not how easy it is to build one. That gap is the entire opportunity. Reliable repellents, in order of strength:
A genuinely hard technical bar. Anything requiring on-device inference, real handwriting recognition, or actual statistical methodology filters out teams who can only wire an API.
An unglamorous title. No "GPT", no drones, no space, no health. Titles containing "material codes" or "land records" repel students at scale.
Domain obscurity. If a student cannot picture the user, they scroll past. Procurement officers and HSSE auditors are invisible to undergraduates.
Mis-tagged themes. The official theme field in this dataset is badly noisy — SIH26018 is land records filed under MedTech / BioTech / HealthTech, SIH26028 is train ETA under Disaster Management, SIH26046 is a clinical trials dashboard under Space Technology. Teams browsing by theme never find these. That is free field reduction.
Counter-signal
Do not confuse "few teams" with "winnable". A statement nobody picks because the data genuinely does not exist is a trap, not an edge. SIH26192 (flash floods) is low-competition and unbuildable without an IoT deployment — that is the wrong kind of empty.
02 — The scoring matrix
All fourteen, ranked by expected value rather than by how interesting they sound.
Scores are 1–10. Field is inverted — 10 means almost nobody will be competing with you. Weighting reflects the funnel above: Field 30%, Moat 20%, Fit 20%, Demo 15%, Data 15%.
Field expected competition, inverted · Fit match to your five skill sets · Demo what a judge sees in 36 hours · Data can you actually get it · Moat can you do what others cannot
03 — Why 171 wins
They handed you the answer key and then made the exam hard enough that nobody else will sit it.
SIH26171 asks for a browser extension that runs a vision model locally, reads the user's screen, redacts every piece of PII before anything leaves the machine, and sends only the sanitised context to a server VLM that returns UI actions to execute. Four things make it the pick:
1. It ships an explicit numeric rubric
No other statement in your shortlist does this. The judges have already told you exactly how they will score you:
WeightWhat they measureHow you convert it into a number on screen
25%Accuracy of visual context from screenmAP of your UI element detector on a held-out annotated screenshot set
20%Recall & precision of PII detectionP/R/F1 against ground-truth PII boxes, broken out per class
20%Precision of redactionMask IoU, plus a leak test: OCR the outbound payload, assert zero PII strings
20%Client-side resource utilisationLive HUD: peak RAM, GPU ms/frame, CPU %, model size on disk
15%End-to-end task latencyp50 / p95 from capture to executed action, timed in-page
The single highest-leverage move
Build a benchmark harness that computes all five of those numbers and displays a weighted total using their exact weights. Put it on screen during the demo. You will be the only team in the room that hands the judges their own scorecard already filled in — and against a rubric, that reframes the entire evaluation in your favour.
2. The hard part is a YOLO problem
Detecting faces, password fields, Aadhaar/PAN numbers and avatars on a screenshot is bounding-box object detection. That is precisely the small-model work your ML member already does. Everyone else will read "Vision Transformer" and assume they need something exotic; you fine-tune YOLOv8n or RT-DETR on UI screenshots, export to ONNX, quantise to INT8, and ship it. The statement explicitly permits "ViT or equivalent".
3. It splits cleanly across all five of you
No single member is idle and no two are blocked on each other. That is rare and it matters enormously in a 36-hour build.
4. Nobody else will finish it
ISRO's eleven statements include Chandrayaan image correspondence and a satellite-imagery VLM — those absorb the space-obsessed crowd. 171 is filed under Miscellaneous, sounds like a browser extension rather than a space project, and demands WebGPU inference that most teams will fake with a server call. Prestige org, invisible title, high wall. That is the best field profile in your shortlist.
04 — What you actually build
Two processes, one hard privacy boundary, and a receipt proving nothing crossed it.
Client — Chrome MV3 extension, Firefox port
Capture — tabs.captureVisibleTab for pixels, plus a serialised DOM / accessibility tree for structure. Two channels, deliberately.
Detector — fine-tuned YOLO in ONNX Runtime Web on the WebGPU backend, in an offscreen document. Classes: button, input, link, face, avatar, password field, ID number, card number.
Text layer — lightweight OCR via WASM plus regex/NER for Aadhaar, PAN, phone, email, card patterns. Catches PII baked into images that DOM inspection cannot see.
Redaction engine — union of two passes: DOM tags (input[type=password], autocomplete hints, ARIA roles — fast, high precision) and vision boxes (slower, high recall). Masks are burned into the canvas before any network call.
HUD — live latency, memory and GPU counters. This is a demo artefact and a rubric artefact at the same time.
↓ sanitised image + sanitised DOM + redaction manifest ↓
Server — FastAPI or Node
Open-weights VLM — Qwen2.5-VL, InternVL or Llama Vision. The statement allows cloud-hosted versions of open models during SIH, so host it but keep the weights swappable to prove offline deployability.
Redaction-aware prompting — the manifest tells the server what was masked and why, so it reasons around the holes instead of hallucinating into them. The statement asks for exactly this and most teams will skip it.
Action protocol — returns a typed plan: [{action:"click", selector:"#submit"}]. The client executes and loops.
The demo moment
Split screen. Left: the real page — a logged-in profile with a face, a phone number, a card field. Right: the exact bytes leaving the machine, with all of it blacked out. Network inspector open. Then a leak test runs live — OCR over the outbound payload, PII regex, and a hard 0 leaked assertion. Then the agent completes the task anyway. That sequence is worth more than any slide.
05 — The other three worth submitting
SIH26018 — Land Record Digitization use your second slot here
Handwritten, faded, multilingual land records into structured fields with confidence scores and a human-verification queue. Your ML member does layout detection (again a YOLO job — find the table cells and field regions) then fine-tunes TrOCR or a Donut-style model for Devanagari handwriting. Everyone else will call Tesseract, watch it fail on real records, and have no accuracy number to show.
Data is the quiet advantage: state Bhulekh and DILRMP portals expose scanned records publicly, in volume, right now. And because the statement demands confidence scoring and human-in-the-loop review, partial accuracy is a designed feature rather than a failure — you cannot lose the demo on a bad OCR result.
SIH26099 — CPSE Material Code Harmonization highest floor, lowest ceiling
If you want the best raw odds in the list, this is it. "Material master data harmonization for petroleum CPSEs" is about as repellent as a title gets, and the work — sentence embeddings, fuzzy matching, clustering, near-duplicate detection — is comfortably inside your Python member's range. Procurement officers judging it feel this pain daily and have never seen a student address it.
The catch: the promised dataset is "to be provided by participating CPSEs" and may never arrive. Bootstrap from GeM catalogue listings, UNSPSC taxonomy and public tender item lists instead, and say so openly.
SIH26056 — Airfare Price Index dark horse, one condition
Genuinely interesting and MoSPI has only four statements. But note the contradiction buried in it: it demands scraping IndiGo and MakeMyTrip while remaining compliant with robots.txt and terms of service, which for most of those sites forbids exactly what is being asked. Spotting that and designing a compliant-by-construction pipeline is itself a differentiator most teams will miss entirely.
Win condition: the index methodology, not the scraper. Jevons versus Laspeyres, chain-linking, seasonal adjustment, treatment of sold-out flights as missing-not-at-random. MoSPI statisticians care about that and 95% of teams will show them a line chart.
06 — Why the exciting ones lose
Four statements on this list are traps, and they are trapping you with the same mechanism.
SIH26068 WeatherGPT — the name contains "GPT". It will be one of the most-submitted statements in the entire edition, and underneath the branding it is retrieval-augmented chat over IMD APIs. Nothing you build will look different from the other two hundred decks.
SIH26047 MediKiosk — the best-written statement in your shortlist, which is exactly the problem. It is detailed, health-related, obviously high-impact, and easy to imagine, so it will draw a mob. It is also three hard subsystems in a trench coat: Indic ASR, clinical dialogue management, and handwritten prescription OCR, plus ABDM/FHIR compliance. Two teams' worth of work at a tenth of the odds.
SIH26154 NTRO Content Transformation — flashy output, near-zero technical moat. NTRO judges will watch thirty teams demo the same LLM wrapper. Skip.
SIH26107 BIS Assistant — another RAG chatbot, and a corpus problem on top: Indian Standards are sold, not freely published, so your knowledge base will be visibly thin next to what a BIS official expects.
SIH26028 Train ETA — train delay prediction is the single most-attempted student ML project in India, RTIS GPS feeds are not public, and Railways draws a crowd. Fine engineering, terrible odds.
07 — Build sheets
What each one actually is, how it works, and what you would build it with.
One card per statement, in matrix order. In one line is the version you say to someone who has never read the PS. How it works is the pipeline. Highlighted chips are the pieces that carry the project — if you drop those, you no longer have a solution.
SIH26171On-device Visual Perception for Browser AgentsPRIMARY
In one lineA browser extension where a small AI on your own laptop looks at the screen, blacks out anything private, and only then asks a bigger AI on a server what to click next.
Extension screenshots the active tab and reads the page's DOM / accessibility tree — two separate channels, on purpose.
A fine-tuned YOLO detector runs locally in the browser on WebGPU, boxing UI elements and sensitive things: faces, password fields, ID numbers.
The redaction engine burns black boxes into the image and strips PII text from the DOM dump. A "redaction manifest" records what was hidden and where.
Sanitised image + DOM + manifest go to a server vision-language model, which returns an action plan such as click #submit.
The extension executes the action and loops. Nothing identifiable ever left the machine.
SIH26018Intelligent Land Record DigitizationBACKUP
In one lineUpload a faded, handwritten, 50-year-old land record and get back clean structured data — owner, khasra number, area — with a confidence score, where anything the model is unsure about goes to a human.
Scanned PDF or image comes in; preprocessing deskews, denoises and binarises it.
A layout model finds regions — tables, headers, handwritten margin notes — so each gets the right reader.
OCR runs per region: one model for printed Devanagari, a different fine-tuned one for handwriting.
NER plus a rule engine maps raw text into fields: khasra no., khata no., owner, area, village, tehsil.
Validation cross-checks against reference data, flags duplicates, and scores confidence per field.
Low-confidence fields drop into a reviewer UI; every correction becomes training data for the next round.
In one lineTwo government companies both stock the same bolt but call it different things in different spreadsheets. This finds every such match across their catalogues and proposes one national code.
Ingest material master exports from multiple CPSEs — SAP CSV and Excel dumps.
Normalise the descriptions: expand abbreviations, standardise units, parse out technical specs.
Embed each description as a vector, then cluster and fuzzy-match to surface duplicates and near-duplicates.
Classify into a UNSPSC-style taxonomy and generate a candidate common national code.
A reviewer approves or rejects each proposed mapping; the mapping table always retains the original CPSE codes.
Dashboard reports duplicate density per category and estimated procurement savings.
In one lineEvery day, automatically check what flights actually cost on ~20 popular routes, clean the numbers, and turn them into an official-style inflation index — the way the government measures price rises.
A scheduler fires daily collection across routes × booking windows: T+1, T+7, T+15, T+30, T+45.
Headless browsers gather quotes; raw responses are stored untouched so every number stays auditable.
Cleaning splits base fare from taxes, UDF and convenience fees, drops outliers, and treats sold-out flights as missing rather than zero.
The index engine computes a Jevons or Laspeyres index weighted by DGCA passenger traffic, chain-linked across months.
Dashboard and public API publish it; a 30-day backtest against DGCA average fares proves it tracks reality.
SIH26165SIF Precursor Detection in Safety ReportsSLEEPER
In one lineReads thousands of free-text workplace safety reports and flags the small fraction that could have killed someone, tagged to exactly which safety rule was about to be broken.
Ingest free-text unsafe-act, near-miss and incident reports from the HSSE platform.
Clean and normalise heavy domain jargon, then build a labelled set of SIF-potential versus routine.
Fine-tune a classifier for fatal potential; a second head tags the relevant IOGP Life-Saving Rule.
Extract recurring precursor patterns — activity, location, which barrier failed — with NER and topic modelling.
Dashboard ranks sites and activities by SIF-precursor density so HSE intervenes where fatal potential is highest.
NLPDistilBERT / RoBERTa fine-tuneSetFit (few-shot)spaCy NERBERTopic
SIH26191Hazard Red Zones & Carrying CapacityMIDDLING
In one lineA map that colours in the places too dangerous to live in, checks whether the nearby safe places have room for people, and ranks which villages should be moved first.
Ingest hazard layers — landslide susceptibility, flood, coastal erosion — plus population and habitation data.
Weighted multi-criteria overlay produces a composite hazard score per grid cell; the worst cells become red zones.
A carrying-capacity model scores candidate safe sites on land availability, water, road access and slope.
Priority score combines hazard intensity × population vulnerability × disaster history.
Interactive map plus a ranked relocation list, split into immediate, short-term and medium-term.
GeodataBhuvanBhukosh (GSI)NDMA hazard atlasCensus habitationCartosat DEM
SIH26016National Land Acquisition ManagementMIDDLING
In one lineOne national website where every land-acquisition project's paperwork, approvals, compensation payments and progress live together, instead of scattered across state-by-state files.
In one lineLooks at duty rosters, leave patterns and voluntary wellness check-ins to spot personnel who may be burning out — and quietly tells the welfare officer, not the disciplinary chain.
In one linePredicts when your train will actually arrive using how it is running right now plus what usually happens on that stretch of track — instead of just repeating the printed timetable.
Ingest live running status, schedules and historical delay records.
Engineer features: sectional running times, congestion, time of day, weather, delay of the preceding train.
A sequence model predicts delay at each upcoming station rather than one number for the destination.
Forecasts re-run continuously as new position updates arrive.
APIs feed passenger apps, station displays and control-room dashboards.
In one lineBefore you see the doctor, you talk to a screen in your own language about what is wrong and scan your old prescriptions — so the doctor gets a clean, complete history the moment you walk in.
Patient authenticates via ABHA or Aadhaar, picks a language, and gives audio-guided consent.
Voice-and-touch interview: speech recognition transcribes, and a dialogue manager asks SOCRATES-style follow-ups.
A red-flag detector escalates emergency symptoms straight to triage instead of the routine queue.
Document scanning runs OCR over old prescriptions and reports, extracting diagnoses, drugs and lab values into a dated timeline.
A summariser produces the physician-ready structured history, pushed to the hospital system over FHIR and linked to the ABHA record.
SpeechBhashiniIndicWhisperIndicConformerIndic-TTS
Dialogueclinical history ontologyLlama / Qwen fine-tuneguardrails
In one lineAsk about the weather in normal language — in your own language, or by voice — and get IMD's actual forecast back rather than a generic model answer.
A natural-language query is parsed into intent and entities: location, time window, weather parameter.
A router calls live IMD and numerical-model data sources, or pulls from the climate archive for trend questions.
The LLM converts raw numeric forecast grids into a readable advisory in the user's language.
An alert subsystem pushes extreme-weather warnings; voice input and output serve low-literacy users.
LLMfunction callingLlama / QwenLangChain
Weather dataIMD APIsGFS via NOMADSxarray + netCDF4ERA5 reanalysis
DataIMD gridded rainfallGPM / IMERGSMAP soil moistureSRTM DEM
MLXGBoostLSTM (PyTorch)
IoTMQTT / MosquittoESP32 nodes (simulated)
AppFastAPITimescaleDB + PostGISMapLibreCAP alert format
What to notice across all fourteen
The stacks are mostly the same parts — FastAPI, PostgreSQL, React, a HuggingFace model. That is the point: almost none of these are blocked by your tech stack. What separates them is the one highlighted chip in each — the piece nobody else will get working. On 171 that is WebGPU inference; on 18 it is a handwriting model that actually reads Devanagari; on 56 it is real index methodology. Everything around that piece is plumbing you already know how to write.
08 — The four-month plan
De-risk the one thing that can kill you in week one, not week fourteen.
Open-weights VLM serving, redaction-aware prompting, plan generation and validation, fallback behaviour when context is heavily masked.
UI/UX
The privacy story, made visible
Redaction preview panel, the split-screen demo surface, resource HUD, consent flow, and the deck. This role carries the demo.
Now → 20 Sep
Internal hackathon + national submission. Deck only. Idea submission deadline on the portal listing is 20 September 2026 — confirm the exact date with your SPOC.
Build one throwaway proof: any ONNX model running in-browser on WebGPU. One screenshot of that in the deck separates you instantly.
Month 1 · October
De-risk WebGPU first. Get ONNX Runtime Web running a real model in an offscreen document before anything else. This is the only unknown that can end the project.
Extension skeleton, capture pipeline, DOM serialiser.
Start labelling: 800–1000 screenshots with PII bounding boxes, drawn from real Indian government and banking portals.
Month 2 · November
YOLO fine-tune → ONNX → INT8. Target under 100 ms per frame on a mid-range laptop.
DOM-tag redaction pass, then union it with the vision pass.
Build the benchmark harness now, not in December. It shapes every decision after it exists.
Month 3 · December
Server VLM, action protocol, executor loop closed end-to-end.
Redaction manifest format; Firefox port; WASM fallback path for machines without WebGPU.
Rehearse the demo on a locked-down laptop with no internet.
Finale · 36 hours
Bring two laptops, both with WebGPU verified. Server runs on localhost from the second one — assume venue wifi fails.
All model weights pre-downloaded. No first-run downloads on stage, ever.
Three pre-recorded fallback clips of the leak test, in case the live run misbehaves in round three.
09 — The internal-round deck
Six slides. The only job is to look like the team that has already started.
Problem & the gap — agentic AI needs your screen; your screen has your Aadhaar on it. Name the specific failure: today, using a browser agent on a banking page means shipping that page to someone else's server.
Solution & architecture — the two-process diagram with the privacy boundary drawn as a hard line, and the redaction manifest crossing it. One diagram, no clip art.
Technical approach — name the real stack: ONNX Runtime Web, WebGPU, fine-tuned YOLO, INT8 quantisation, Qwen2.5-VL. Naming specific tools reads as competence; "AI/ML" reads as filler.
Feasibility & risks — this is the slide everyone wastes. Put your in-browser inference screenshot here with a measured millisecond number on it, plus the WASM fallback for machines without WebGPU. Showing a measured number in an internal round is unusual enough to end the argument.
Impact — privacy-preserving agents for government portals, banking, healthcare records. Anchor it to DPDP Act 2023 obligations; ISRO's people will connect it to sensitive-data workflows themselves.
Evaluation — reproduce their five rubric rows with your target number in each. Nobody else will put the judges' own rubric on a slide.
Two things to fix before you submit
Team size. You have described five people. SIH requires six, including at least one female member — this is a hard eligibility rule, not a preference. Sort the sixth seat now; a strong generalist or a second frontend dev fits this project best.
Use both slots. A team may submit two ideas. Submitting one is leaving free expected value on the table. Send 171 and 18 — different ministries, different themes, no correlated risk. If the group prefers safety over ceiling, swap 18 for 99.
10 — Second opinion, reconciled
A different analysis picked PS 56. Here is exactly where the two diverge.
Worth reading side by side, because the disagreement is narrow and it turns on one scored value.
QuestionThis briefThe other analysis
Top pickPS 171 — ISRO browser agentrubric is the decisive assetPS 56 — MoSPI airfare indexbest risk-adjusted win
PS 56 data risk6 / 10 — adversarial bot defences, and the statement's own ToS-compliance demand conflicts with the collection it requires10 / 10 — safest in the field, "you are literally the data source"contradicts their own ⚠️ caveat
PS 47 crowding2 / 10 — best-written statement in the list, which is precisely why it draws a mob5 / 10 — ranked #2, "highest ceiling"
PS 171 build riskManageable — ONNX Runtime Web is documented, WASM fallback exists, and the difficulty is the moat4 / 10 — "real chance of a half-working finale"
PS 18#2 — confidence scoring and human review are in the spec, so weak OCR cannot lose the demo#8 — "accuracy gamble"
Scraping IndiGo and MakeMyTrip is not a safe data position. Those fare endpoints run commercial bot management because scrapers cost the airlines money directly, and the statement simultaneously demands robots.txt and terms-of-service compliance — which on those sites disallows the very paths you need. The compliant route and the workable route are not the same route. That single score, marked safest when it is among the most fragile, is what carries PS 56 to the top of the other ranking.
The deeper difference is the objective. Minimising the chance you fail to ship is the right goal for a client project. It is the wrong goal for a tournament with one winner per statement, where reliably producing the median submission is how you lose. What you want to maximise is the probability that you are the best team on that statement — and in a crowded field those two objectives point in opposite directions.
Where the other analysis was right
Its framework is sound and two of its points are better than mine were. Full-roster visibility — judges do ask who built what, so a statement that gives all five members a named module scores better than one where two people carry it. That is a real argument against PS 56, incidentally, since the ML role there is peripheral. And graceful degradation — cached data, recorded fallback runs, offline operation — is exactly right for a venue where the wifi will fail. We also agree completely on ruling out 68, 107 and 154, and on 99 and 165 as genuine dark horses.
When the other pick becomes correct
If the team's honest read is that it will not put in serious weekly hours between October and December, ambition becomes a liability and PS 56 or 99 is the better call. Difficulty only protects you if you actually clear it. If you want to represent both views, 171 + 56 is a defensible pairing — though 18 still beats 56 for the second slot on data position and roster balance.