Rules
The following rules are designed to support a fair, inclusive, technically meaningful, and practical hackathon experience across both the online and in-person stages.
- Track selection. Each submission must identify one primary challenge track. If participants feel their idea can be cross-track. please select the primary track that is best fit.
- Original work and attribution. The submitted solution should represents original work by the participant or team. Existing open-source software, APIs, models, datasets, libraries, templates, or prior components may be used when permitted by their open source licenses, but they must be clearly disclosed and attributed.
- Responsible use of AI. Teams using generative AI, AI coding assistants, or autonomous/agentic tools must disclose the major tools used. Teams maintain full responsibility for the correctness, safety, security, and originality of the final submission.
- Data privacy and confidentiality. Do not submit confidential employer information, proprietary source code, restricted datasets, personal data without appropriate authorization, credentials, secrets, or other information that participants do not have the right to use.
- Intellectual property. Participants are responsible for ensuring that their project does not knowingly infringe third-party copyrights, patents, trademarks, licenses, or other rights.
- Safety, trust, and ethics. Projects should consider relevant risks such as privacy, security, bias, misuse, hallucination, accessibility, environmental impact, or unsafe automation. Strong submissions will explain both benefits and limitations.
- Submission deadline. Only projects submitted through the official Devpost event page by the published deadline will be considered for online judging, unless organizers announce an extension.
- Finalist participation. Teams selected as finalists must be available for the in-person presentation round or notify organizers promptly if they cannot participate. The policy for substitutions or remote exceptions, if any, will be announced by organizers.
- Verification. Judges or organizers may request reasonable clarification, a live demonstration, source-code evidence, architecture details, or other materials needed to verify claims made in a submission.
- Professional conduct. Participants must interact respectfully with other teams, volunteers, judges, mentors, and attendees. Harassment, discrimination, deliberate disruption, or misrepresentation may result in removal from the event.
- Judging decisions. Judging decisions are based on the published criteria and are final, subject to organizer review for eligibility, conflicts of interest, or rule violations. The team with more members will have an advantage.
Dates
The event is intentionally structured in two stages: an online submission/judging phase and an in-person finalist round in the following week.
| Milestone | Date | Notes |
| Registration / Devpost page opens |
11th October 2026 |
Participants may form teams and begin/continue project work according to the published rules. |
| Online submission deadline | 19th October 2026 | All required Devpost materials must be submitted by this deadline 11:59 PM EDT |
| Online judging period | 20th-22nd October 2026 | Judges review eligible submissions independently using the published rubric. |
| Finalists announced | 22nd October 2026 | Selected teams receive presentation instructions and logistical details. |
| In-person finalist presentations | 24th October 2026 | Finalists present and demonstrate their projects before the on-site judging panel. The event will take place from 9 am to 5 pm. |
| Winner announcement | 24th October 2026 | Final awards and recognition presented. |
Eligibility
- Eligible participant groups: Students / Professionals
- Participation may be individual or team based. Maximum team size: 5.
- Each participant should register through the official event/Devpost process and be listed on the project submission.
- A participant may not be listed on competing finalist teams unless the organizers explicitly allow it.
- Organizers, individuals directly administering the judging process, and judges should not compete in categories they oversee.
- Participants must have the right to use all data, code, media, models, APIs, and other materials included in their submission.
- Finalists must comply with venue, safety, and presentation requirements for the in-person round.
Project and Submission Requirements
See the Submission Requirements section of this page for the full list of required Devpost content and what strong submissions should demonstrate.
Prizes
- 1st Prize – IEEE recognition and winner's certificate.
- 2nd Prize – People's choice award.
*** More Prizes are being considered and yet to be announced ***
Judging Criteria and Winner Selection
Judging will occur in two stages. The same core 100-point framework is used to emphasize impact, innovation, feasibility, risk awareness, scalability, and adoption across all five Hack for Humanity tracks.
| Criterion | Points | What Judges Consider |
| Human / Societal Impact & Problem Relevance | 25 |
|
| Innovation & Creativity | 20 |
|
| Technical Feasibility & Solution Quality | 20 |
|
| Trust, Ethics, Risks & Constraints | 15 |
Awareness of following constraints:
|
| Scalability & Extensibility | 10 |
|
| Ease of Implementation & Adoption | 10 |
|
Stage 1 - Online Devpost Judging
- Only eligible submissions that meet the published submission requirements proceed to judging.
- Judges review assigned Devpost entries independently and score each project using the 100-point rubric.
- Judges evaluate the evidence actually submitted online. Teams should not assume that judges will infer missing architecture, results, risk controls, or implementation details.
- Scores from multiple judges are aggregated (average score after conflict-of-interest checks).
- The highest-ranked projects, subject to organizer review for eligibility and track balance, are invited to in-person final.
- All participants submitting online should be prepared to travel and make presentation in in-person venue for the finals. Participants are responsible for their own travel expenses and travel accomodations for the event.
- Participants are required to submit online video walkthrough of their application which will be reviewed by judges.
Stage 2 - In-Person Finalist Presentation
The in-person final is intended to validate the project, let judges interact directly with finalists, and evaluate how well the solution stands up to questions about impact, technology, risk, and implementation.
- Presentation format: Approximately 10 minutes for presentation/demo plus 5 minutes for judge Q&A.
- Finalists should demonstrate the project wherever practical rather than relying only on slides.
- The presentation should cover the problem, solution, current versus proposed experience, architecture/technology, impact, trade-offs/risks, scalability, and recommended next steps.
- Judges apply the same 100-point rubric. Live demonstration and answers to questions provide additional evidence within the existing criteria; presentation polish should not outweigh technical merit and impact.
- Final-round scores are calculated independently from Stage 1: Stage 1 is used to select finalists and Stage 2 is used to determine winners.
- Judges review the video submissions of participants for selection of in-person finalists
Tie-Breaking and Conflict-of-Interest Guidance
- Judges should disclose actual or perceived conflicts of interest and recuse themselves where appropriate.
- If final scores are tied, organizers will use
- higher score in Human / Societal Impact & Problem Relevance, followed by Innovation & Creativity, followed by Technical Feasibility & Solution Quality.
- higher member teams will have an advantage over lower-member team
