Builder Guide

Fireworks: Deploy — Hackathon Rules

November 2, 2026 · TERRA · 511 Harrison St, San Francisco Build period: 10:30 AM–4:30 PM Pacific

These rules apply to all participating teams and prize categories, alongside any published sponsor-specific requirements.

1. Registration and in-person participation

• Every participant must have an approved event registration.
• All team members must check in and participate in person at TERRA in San Francisco on November 2 to be eligible for prizes.
• Remote submissions and remote team members are not eligible for prizes.
• Finalist teams must present in person when called.
• At least one team member must remain present for the awards.

2. Teams and submissions

• Teams must have 2–5 members. Single-person teams cannot compete.
• Each participant may belong to only one team.
• Each team may submit one project.
• List every contributing team member in your submission.
• Teams may enter multiple prize categories if they satisfy each category’s requirements.

3. The challenge

Build an open-model system for a meaningful task and demonstrate a measurable improvement against a frontier-model baseline.

Your improvement may be in quality, cost, or latency. Cost and latency improvements must retain useful task performance, and all material tradeoffs must be disclosed.

• Frontier-model baseline required: Identify the baseline model and compare both systems on the same evaluation cases.
• Fireworks infrastructure is optional: You may use other infrastructure. Check individual sponsor-prize criteria for additional requirements.
• Fine-tuning is optional: You may specialize a model, build a harness, route across open models, or combine approaches.
• No deployed app or website required: Notebooks and API demonstrations are sufficient. Judges will assess your implementation, evidence, and explanation.

Your submission must explain:

• Who benefits from your project.
• What task your system performs.
• How you evaluate success.
• What improved against the frontier baseline.
• What tradeoffs and limitations remain.

4. Existing work, tools, and AI assistance

• Existing models, libraries, frameworks, datasets, and development tools are allowed, subject to their licenses.
• Disclose any pre-existing project code, trained models, or other substantial work your team brings.
• Clearly identify what your team built or changed during the event. Judges will assess that contribution.
• AI coding assistants and other AI tools are allowed. Disclose material use and be prepared to explain your implementation.
• Advice from mentors is allowed. Your team must remain responsible for its project and reported results.
• Credit third-party work. Do not present another person’s work as your own.

5. Development and submission deadline

Development ends and submissions close at 4:30 PM Pacific.

• Stop developing when the build period ends.
• Submit the Git commit hash identifying the version to be judged.
• Your submission, including required uploads and processing, must be complete by the deadline.
• Starting an upload before 4:30 PM does not count as a completed submission.
• Do not add features, replace evaluation results, or change the submitted code after the deadline. Judges evaluate the submitted version.

Start submitting by 3:30 PM and aim to finish by 4:00 PM.

6. Required submission materials

Every submission must include:

• Project overview: The task, intended user, approach, and business value.
• Public open-source GitHub repository: Project code, setup instructions, and evaluation instructions.
• Evaluation evidence: Baseline and model details, dataset source and size, metrics, method, before-and-after results, and limitations.
• Demo video under 120 seconds: Explain the problem, demonstrate your work, and show the measured result.
• Team information: All participating team members.
• Sponsor-track information: Identify any sponsor awards you are entering and explain the relevant technology use.

Submission link: HackerSquad Submission Page

7. GitHub repositories MUST be accessible

Your submitted GitHub repository must be public and accessible to judges without requesting permission.

If judges cannot access your repository and review your code, your submission cannot be given a score and cannot receive a prize.

• Private, deleted, empty, or inaccessible repositories prevent review.
• Broken links or links pointing to the wrong repository prevent review.
• A working application, presentation, or demo video does not replace access to your code.
• Keep the repository and submitted commit accessible throughout judging and prize verification.
• Test your repository link in a signed-out or incognito browser before submitting.

An inaccessible submission remains unscored. It does not receive a zero that can be averaged with scores in other categories.

8. Honest and reproducible evaluation

• Compare your frontier-model baseline and submitted system on the same test cases using a consistent scoring method.
• Keep evaluation cases separate from data used to train or tune your system.
• Identify the models, configurations, dataset sources, and measurement conditions.
• Disclose quality, cost, and latency tradeoffs relevant to your claim.
• Efficiency improvements must retain useful task performance.
• Distinguish measured results from estimates or expectations.
• Do not fabricate results, hide material failures, deliberately weaken the baseline, or cherry-pick test cases to create a misleading comparison.
• Include enough instructions and saved evidence for judges to inspect how you reached your conclusions.

Aim for 100+ varied held-out examples where feasible. This is an evidence target, not a minimum entry requirement.

9. Judging criteria

Eligible, reviewable submissions will be assessed using:

A strong presentation or complex implementation cannot substitute for benchmark evidence.

Judges must disclose relationships or involvement that could compromise impartiality and recuse themselves from affected submissions.

10. Finals and tie-breaks

• Preliminary judging will identify six teams for live finals.
• Finalists must present in person when called and follow the announced presentation and Q&A time limits.
• Finalists who do not present cannot receive an overall placement prize.
• All judges will score each finalist against the published rubric, using the same criteria and weights.
• Final placements will be determined by the judges’ scores from the finals.
• If teams are tied, the judging team will discuss their submissions, evidence, and rubric scores to determine the final placement.

11. Prizes and sponsor awards

• Teams may win both an overall placement prize and one or more sponsor prizes, based on their performance and eligibility for each award.
• Advertised cash prizes are per winning team, not per individual.
• Teams are responsible for agreeing how to divide their award.
• Sponsor awards may have additional technology-use or eligibility requirements.
• Entering a sponsor category does not guarantee a prize. Judges must be able to verify the relevant technology use and assess the submission against that award’s criteria.
• Teams must satisfy registration, attendance, submission, and repository-access requirements to receive prizes.

12. Responsible use and conduct

• Use only code, models, and data you have permission to use and share.
• Do not publish API keys, credentials, personal information, or confidential data in your repository.
• Follow the event’s code of conduct and treat other participants, staff, and judges respectfully.
• Harassment, plagiarism, fabricated evidence, interference with other teams, and attempts to manipulate judging may result in disqualification.

Code of conduct: [TODO: Add link]

13. Questions and rule enforcement

Raise submission problems or eligibility questions with event staff as early as possible.

Organizers will apply the published rules consistently and may withhold scoring or disqualify submissions that violate them. Suspected violations will be reviewed by the event lead.

Report a factual scoring or eligibility concern promptly so organizers can investigate before awards are finalized. Final eligibility and award decisions rest with the organizers and judging panel.

Builder support: [TODO: Add support channel or help-desk location]