1
SIH ONE2026 EDITION
SIH 2026 TACTICAL PLAYBOOK

Grand Finale Survival & Jury Defense Guide

The complete roadmap from College SPOC & Internal Hackathons (Jun–Aug) to National Screening (Sep–Oct) and Grand Finale Victory (Dec 2026).

OFFICIAL AICTE / MIC ROADMAP

Smart India Hackathon 2026 Season Journey

Complete 11-stage process lifecycle from Internal College Selection to the Grand Finale

Stage 1 of 11
Interactive Process Flow (Click any stage to view requirements):
College LevelJun – Aug 2026

Stage 1: Registration of College SPOCs

Colleges and Universities appoint and register their Single Point of Contact (SPOC) on the official SIH portal.

Required Team Actions & Deliverables:
  • College SPOC verifies institutional AISHE/AICTE registration code.
  • SPOC sets up college internal evaluation committee and jury panel.
Critical Evaluation Rule: Only teams nominated by an officially registered College SPOC can submit proposals on the portal.

36-Hour Hackathon War-Room Roadmap

Phase-by-phase execution cadence for peak team productivity

Hour 0 – 4

Foundation & Contract Freezing

Phase 1 of 6

Objective: Zero ambiguity on API contracts, database schema, and Git workflows.

  • Initialize monorepo or Git branches (main, dev, feature/*). Enforce zero direct pushes to main.
  • Finalize database schema (PostgreSQL / SQLite) and OpenAPI/Swagger mock contracts.
  • Spin up local Docker containers and verify package installation before venue Wi-Fi saturates.
War-Room Rule: Do NOT write frontend UI yet. Get mock API endpoints responding on localhost first.
Hour 4 – 14

The Core MVP Sprint

Phase 2 of 6

Objective: End-to-end happy path functional workflow operating seamlessly.

  • Backend: Implement core CRUD and core algorithms (ML inference, GIS data parsing, or RTOS packet handling).
  • Frontend: Build high-contrast, responsive UI with realistic dummy data binding.
  • Conduct First Local Smoke Test: Verify that user click triggers real backend action with database state change.
War-Room Rule: Stay away from edge-case polishing or themes. Focus strictly on the primary problem statement loop.
Hour 14 – 20

Mentoring Evaluation Round 1

Phase 3 of 6

Objective: Prove technical feasibility and record mentor feedback without defensiveness.

  • Demonstrate the working core workflow on localhost. Do not show slides; show running code.
  • Ask mentors: "Which feature would make this solution production-ready for your ministry?"
  • Incorporate 1-2 key mentor suggestions immediately into your Phase 4 roadmap.
War-Room Rule: Mentors love teams that listen and execute on their advice before Round 2.
Hour 20 – 28

Winning Edge & Wow Factor Integration

Phase 4 of 6

Objective: Implement the high-value differentiator that separates top 1% from average teams.

  • Implement Winning Edge features: Offline sync, audit PDF exports, role-based dashboards, or anomaly alerts.
  • Add graceful degradation: If external API or sensor disconnects, show clear fallback UI rather than crashing.
  • Seed high-density realistic data so tables, charts, and maps look filled and dynamic.
War-Room Rule: Empty tables and blank charts kill judge enthusiasm. Populate demo state with 50+ rich records.
Hour 28 – 33

Mentoring Round 2 & Code Freeze

Phase 5 of 6

Objective: Showcase mentor-requested additions and freeze feature commits.

  • Show mentors how their exact Round 1 feedback was incorporated into the live system.
  • Perform strict CODE FREEZE at Hour 32. Zero new features allowed after this point.
  • Fix critical UI glitches, responsive alignment, and unhandled null exceptions.
War-Room Rule: Any team writing new code 2 hours before the final pitch risks crashing their live demo.
Hour 33 – 36

Grand Finale Staging & Rehearsal

Phase 6 of 6

Objective: Flawless 3-minute pitch delivery and foolproof offline backup readiness.

  • Run 5 full dry-run pitch rehearsals with strict 3-minute stopwatch timing.
  • Record a 1080p 60fps screen walkthrough of the entire demo and store on 2 separate USB drives.
  • Test projector display resolution (1080p vs 720p) and verify high font contrast.
War-Room Rule: Assign designated speakers for specific questions: Dev 1 for AI/Backend, Dev 2 for Architecture/Security.

Wi-Fi Crash & Venue Network Survival Protocol

How to build 100% resilient offline demos that never fail on stage

1. Dual Database Strategy (Cloud + Local Fallback)

Never depend solely on cloud databases (Supabase / MongoDB Atlas / RDS). Configure an environment flag (USE_LOCAL_DB=true) that instantly switches the ORM/client to local PostgreSQL or SQLite if internet drops.

// db.ts - Deterministic failover const dbUrl = process.env.USE_LOCAL_DB === 'true' ? 'postgresql://postgres:postgres@localhost:5432/sih_db' : process.env.CLOUD_DATABASE_URL;

2. Mock API Gateway for External Services

If your solution relies on external APIs (ISRO Bhuvan, OpenAI, Weather APIs, SMS Gateways), write mock response handlers pre-seeded with real JSON payloads. If the external API times out after 2000ms, fall back to the mock generator automatically.

// apiFallback.ts export async function fetchSatelliteData(region: string) { try { return await fetchWithTimeout(`https://api.bhuvan...`, 2000); } catch (err) { console.warn('Network failed. Loading deterministic local cache.'); return LOCAL_MOCK_SATELLITE_DATA[region] || DEFAULT_GEOJSON; } }

3. Pre-Download All Packages & Model Weights (T-24h)

Never run "npm install", "pip install", or "huggingface.from_pretrained()" on venue Wi-Fi during the hackathon. Pre-cache all npm packages, pip wheels, and quantized model weights (.gguf / .onnx) directly on local disk or USB drives.

# Download HuggingFace weights locally before traveling python -c "from transformers import AutoModel; AutoModel.from_pretrained('model_name', cache_dir='./local_weights')"

4. The 60FPS Full-Demo Backup Video

At Hour 32, record a high-definition 1080p 60fps continuous screen recording showing every feature working smoothly. If the projector or laptop crashes on stage, seamlessly open the video and narrate over it without pausing.

// Golden Rule: // Judges value seeing the working feature regardless of projector glitch. // A smooth video narration beats a broken live crash 100% of the time.
Golden Rule of Offline Hackathons:

Assume venue Wi-Fi will disconnect 30 seconds before your final jury pitch. If your application can run completely on http://localhost:3000 with zero active internet connection, you are already ahead of 80% of competing teams.

Mentor vs. Grand Finale Jury Psychology

Understanding what evaluators look for during intermediate rounds vs final stage judging

Mentoring Rounds (Hours 14 & 28)

Technical Evaluators

Mentors are experienced software architects or domain specialists sent to test your code depth.

What they want: Clean code, real logic (not just UI Figma mocks), and team receptiveness to feedback.
Winning Move: Take notes in front of them, ask for specific constraints, and show that exact change in Round 2.
Fatal Mistake: Arguing with mentors or pretending a broken feature works.

Grand Finale Jury (Hour 36)

Decision Makers

Grand Finale judges are Ministry Directors, PSUs Heads, and Senior Industry Executives.

What they want: Business ROI, national deployment viability, data privacy, and a crisp 3-minute pitch.
Winning Move: Quantify impact (e.g. "Reduces manual dispatch lag by 72% at 1/10th the commercial software cost").
Fatal Mistake: Spending 2 minutes on generic introductory slides instead of live product demonstration.

Official SIH Evaluation Scoring Weightage

30%Pillar 1

Technical Execution & Architecture

Real working codebase, scalable architecture, sensible database design, non-mocked core logic.

25%Pillar 2

Ministry Feasibility & Impact

Direct alignment with ministry pain points, operational cost reduction, regulatory compliance.

20%Pillar 3

Innovation & Novel Approach

Distinct competitive edge over existing off-the-shelf software or standard academic projects.

15%Pillar 4

Live Demonstration Quality

Smooth zero-crash user workflow, authentic dummy data, responsive UI/UX polish.

10%Pillar 5

Q&A Defense & Team Dynamics

Crisp, confident answers with multi-member participation rather than a single solo presenter.

The 3-Minute Zero-Fail Live Demo Script

Exact timestamp breakdown to maximize judge score within strict hackathon time limits

0:00 – 0:30

The 30-Second Hook & Ministry Context

Segment 1
Verbatim Script Template:

"Judges, Indian Railways faces 4,000+ track fracture alerts yearly, resulting in manual inspection delays of over 4 hours. Our solution, RailVision AI, reduces alert verification from 4 hours to 30 seconds."

Screen Action: Show 1 crisp slide stating problem, quantified cost/delay, and your core value proposition.
0:30 – 2:00

The Live Happy-Path User Workflow

Segment 2
Verbatim Script Template:

"Let's simulate a live track anomaly detection. When acoustic telemetry arrives, our engine automatically geolocates the kilometer mark, runs our edge model, and triggers an instant dispatch dispatch ticket."

Screen Action: Click the "Trigger Simulation / Run Test" button in your UI. Show database state update and live UI change.
2:00 – 2:30

The Winning Edge & Wow Factor Differentiator

Segment 3
Verbatim Script Template:

"What makes us unique is our offline synchronization protocol and automated tamper-proof PDF audit trail. Even in zero-cellular tunnels, ground workers can verify repairs offline."

Screen Action: Toggle offline mode or click "Export Ministry Audit Sheet" to display rich PDF/CSV generation.
2:30 – 3:00

Architecture Blueprint & Handover to Q&A

Segment 4
Verbatim Script Template:

"Our stack runs FastAPI, PostgreSQL with PostGIS, and a quantized ONNX model for sub-50ms inference on low-cost hardware. We are now open for technical defense questions."

Screen Action: Display the single architecture diagram slide and step back for judge questions.
Dual-Laptop Staging Setup

Connect Laptop 1 to the projector running the clean frontend. Keep Laptop 2 next to the presenter running Docker logs and database metrics so technical mentors can inspect real query execution if questioned.

Zero Live Typing Rule

Never type long inputs or email addresses live on stage during the 3-minute pitch. Pre-fill forms with 1-click "Load Sample Data" buttons to avoid typos and awkward silences under pressure.

Top 8 Fatal Rejection Traps & Disqualifications

Common evaluation pitfalls that cost teams the championship and how to prevent them

1. Hardcoded UI with Zero Real Backend Execution

The Risk: Mentors ask you to create a new record live, and the dashboard fails to reflect the update.

The Winning Fix: Always connect real API routes to a local PostgreSQL / SQLite database with actual write and read operations.

2. Ignoring Ministry-Mandated Data Standards

The Risk: Using generic Google Maps when ISRO Bhuvan was explicitly requested, or using AWS cloud when on-premise NIC servers were mandated.

The Winning Fix: Carefully check the Ministry name in the problem statement. Quote their specific regulatory guidelines in your opening slide.

3. Solo Pitching (The One-Person Show Trap)

The Risk: Judges immediately deduct marks for team dynamics if 1 student talks for 3 minutes while 5 teammates stand motionless.

The Winning Fix: Assign explicit speaking segments: Lead gives 30s Hook, Dev 1 demos Frontend/UI, Dev 2 explains Architecture & AI model, Lead closes with Impact.

4. Empty Tables and Blank Charts on Stage

The Risk: Empty dashboards look like an incomplete school project and fail to demonstrate visualization capabilities.

The Winning Fix: Seed your database with 50+ rich historical records before stepping on stage so maps, sparklines, and tables look dense and production-ready.

5. Single Massive Git Commit at Hour 35

The Risk: Mentors inspect GitHub commit logs to verify that code was written during the 36-hour hackathon and not copy-pasted from an existing repo.

The Winning Fix: Make frequent atomic commits every 1–2 hours across distinct feature branches with descriptive commit messages.

6. Using Paid Proprietary APIs without Free/Open-Source Alternatives

The Risk: Judges ask: "How will the government pay millions in OpenAI/Google API credits if deployed nationally?"

The Winning Fix: Show how your system can run on open-weight models (Llama 3 / Mistral / Quantized ONNX) locally at zero API runtime cost.

7. Unhandled Null Pointers During Judge Live Testing

The Risk: A judge asks to enter an unusual phone number or invalid PIN code, and your React app shows a blank white screen of death.

The Winning Fix: Wrap critical UI components in React Error Boundaries and validate all user inputs with defensive fallbacks.

8. Unreadable Font Sizes on Projector Displays

The Risk: Text readable on a 14-inch laptop screen becomes completely illegible on a distant 1080p auditorium projector.

The Winning Fix: Use high font contrast (e.g. pure dark mode or crisp off-white) and ensure minimum body font size is 14px+ on slides and demo dashboards.