Hackathon rules: code, AI, assistance and disputes
What to define in hackathon rules before work starts: pre-existing code, AI use, mentor assistance, deadlines, judging and dispute handling.
·5 min read·
What you’ll learn
Decisions to document about existing code, AI and mentor assistance.
A process for recording rule versions, deadlines and project submissions.
Questions for disputed scores and conflicts of interest.
Hackathon rules should let a team understand in advance what is allowed, what must be disclosed and how a dispute will be decided. Publish them before competition work begins and save the version. A spoken explanation at the opening can supplement the document but does not replace it.
Below are the organizational decisions to cover in the rules. Participation conditions, rights to materials, data processing and contractual obligations need to be agreed for the specific event and jurisdiction. A general article cannot replace that document.
Define participation and team composition
State the participant requirements, permitted team size and whether solo participation is allowed. If there are special categories, explain who qualifies and how this is checked. Calling a category "for beginners" without defining it can create different expectations.
Describe how members can be invited, replaced or leave a team. Set the point after which the roster cannot change and identify who confirms a change. Separately, decide whether organizers, volunteers and mentors can enter the competition for judging.
For an online event, clarify which stages require attendance. If a team must join a checkpoint or final demo, it needs to know this when registering. Missing an optional lecture should not suddenly become a violation.
Set the boundaries of competition work
State when development starts and ends. Explain which preparation is allowed: reading documentation, setting up the environment, finding a team or developing an idea. Do not leave "preparation" undefined if it affects eligibility.
Decide separately how to treat pre-existing code. A library, a general application template and a previously built product contain different amounts of work done by others or before the event. The rules need to explain which options are permitted and how they must be disclosed.
Ask teams to identify what existed before the event and what changed during it if your format allows work on an existing starting point. If this is not permitted, say so explicitly. Commit history can help a review, but it does not describe the entire process of creating a project on its own.
Describe AI use
Distinguish assistance during the work from a model used inside the product. Code generation, editing a presentation, creating images and calling a model in an application may need different conditions. State permitted uses, data restrictions and disclosure requirements.
Do not stop at the word "honestly." Give an example of the required record: which tool was used, for which part, what the team checked and which limitations remain. If a prompt log or another form of evidence is required, specify its format in advance.
The MLH guidance on rules also highlights disclosure of pre-existing components and AI use. Its conditions apply to its own format; organizers need to adopt and publish rules for their particular competition.
Set limits on outside assistance
A mentor can explain an approach, help find a bug or discuss a solution. The rules determine how much involvement in implementation is allowed. Participants need to understand when advice becomes doing the competition work for the team.
Decide how to account for help from people outside the official team. If outside consultations are allowed, explain what must be disclosed. If they are prohibited, define the boundary so that ordinary documentation reading does not fall into an unclear area.
Assign a channel for questions about the rules. Publish any answer that affects competition conditions for everyone. Private correspondence with one participant must not create a hidden advantage or exception.
Define the submission pack and deadline
List the required fields, files, links and access level. State the video length if it is limited, along with any requirements for a live demo. Give the deadline's exact time zone and the submission state that counts as a successful entry.
Explain whether materials can be edited after submission but before the deadline, and what is allowed afterward. Correcting a typo, restoring access and improving a feature need different decisions. If there is an exceptions procedure, assign an owner to it.
Agree on how to record a technical failure. Participants need a contact channel and a list of evidence they can safely provide. Making a request does not guarantee an extension unless the rules establish that condition.
The Stavleak hackathon rules template can help collect these decisions in one document. Replace its fields with your event's conditions and resolve disputed points before publication.
Prepare a procedure for disputed cases
Define who receives a report, who reviews the facts and who approves the decision. Preserve the issue raised, materials, the team's explanation and the basis for the outcome. Do not discuss unverified accusations in the shared chat as if they were established facts.
Give the team a chance to explain the circumstances within the agreed process. An unusually polished demo alone is not enough to conclude that a project was built in advance. A review needs to rely on a specific rule and available evidence.
State the possible consequences and notification procedure. Distinguish a technical error, incomplete disclosure and a confirmed violation. Apply decisions consistently to comparable cases rather than according to how well known the team is.
Test the rules against borderline examples
Before publication, work through several scenarios:
A participant uses their own template created before the event.
AI wrote a function that the team modified and checked.
A mentor sent a small code fragment during a consultation.
A video uploaded on time, but processing finished later.
A judge advised a project and was then assigned to assess it.
The submission service is unavailable shortly before the deadline.
If the answer depends on a particular organizer's spoken opinion, clarify the document. Then connect the rules to the judging criteria and submission form. Participants should see a consistent process from registration to the result.
