Builder Guide

Get set up. Build something useful. Make your submission count.

Submission & judging

Turn your work into a submission judges can review.

Prepare your project

Add your project name, description, repository link, and the technologies you used.
Check your team roster and complete the required fields in the project form.
Save your project, then record and save a video demo in the project form.
Submit for judging and check that your project shows as submitted.

Saving a draft does not submit it. After submitting, you can keep saving updates; judges see your latest saved version.

Event-specific instructions

Submission & Judging

Start submitting by 3:30 PM and aim to finish by 4:00 PM. Your submission must be fully uploaded and processed before the deadline.

This is what a great submission looks like.

Video Submission by 4:00 PM

Submissions close November 2 at 4:30 PM Pacific.

What to submit

Project overview: Your task, intended user, approach, and why the result matters.
Public open-source repository: Include setup instructions and the code or notebook used to run your evaluation.
Before-and-after results: Identify your baseline model, evaluation dataset, metric, and method. Show what improved and disclose tradeoffs.
Demo video under 120 seconds: Explain the problem, demonstrate your approach, and show the measured result. Aim for under 60 seconds if you can cover everything clearly.

A clickable app is optional. A clear notebook or API demonstration can earn full marks. Fine-tuning is optional.

Submit here: Fireworks Deploy HackerSquad Submission Link

How projects are scored

Criterion	Weight	What judges look for
Benchmark evaluation	40%	A meaningful, reliable advantage over a frontier-model baseline, supported by evidence.
Business value	25%	A clear user, valuable problem, and compelling reason to adopt your solution.
Technical execution	20%	Thoughtful engineering, working implementation, and meaningful experimentation.
Presentation & demonstration	10%	A clear explanation and convincing demonstration of your results.
Documentation	5%	Instructions that help another builder understand and reproduce your work.

Make your evidence count

Compare both systems on the same held-out test cases. Aim for 100+ varied examples where feasible; support your claims with uncertainty estimates or appropriate statistical testing.

For cost or latency improvements, demonstrate that quality remains useful. Explain limitations honestly.

Before submitting: Test your repository and video links, check access permissions, and confirm your upload has finished.

How your work is judged

Round 2

A detailed rubric isn’t published for this judging stage. Check the event instructions or ask the organizers what judges will focus on.

Main Round

Published criteria

Fireworks: Deploy Rubric

Review the demo, repository, and evaluation results. Score each criterion independently from 0-10 using the rubric anchors. Score what the team demonstrates. Reflect unresolved evidence gaps in the relevant criterion. A strong pitch or ambitious method cannot substitute for benchmark evidence. Fine-tuning and a clickable app are optional; a notebook or API can earn full marks. Originality is not a separate criterion.

Benchmark evaluation
Look for a meaningful, reliable improvement over a named frontier-model baseline on the same task and test cases. Consider whether the test set is representative, held out from training and tuning, and measured with a relevant metric under fair comparison conditions. Check uncertainty and quality, cost, and latency tradeoffs; efficiency gains must retain useful quality. The 100+ example target supports stronger evidence, but sample count alone does not prove a result.
40%
Business value
Consider who would use this, why the problem matters, and whether the improvement would change their workflow. Look for a credible, quantified benefit such as time saved, lower cost, or better outcomes, with assumptions made clear. Weigh practical adoption barriers alongside the proposed benefit.
25%
Technical execution
Consider whether the approach works, fits the task, and reflects thoughtful engineering. Look for experiments that explain which choices contributed to the result, plus awareness of failure cases and limitations. Reward well-executed decisions; added complexity should have a clear purpose.
20%
Presentation & demonstrations
Consider how clearly the team explains the problem, approach, and result within the video limit. Look for a convincing demonstration that makes the claimed improvement easy to understand and inspect. A focused notebook or API demonstration can be as strong as a polished app.
10%
Documentation
Consider whether another builder could understand the public repository, set up the project, and reproduce the evaluation. Look for clear dependencies, model and configuration details, test data or access instructions, and reported outputs. Note missing steps or unclear assumptions that would prevent reproduction.
5%

Final Round