hackathon-brief-design

Hackathon Brief Design

You write the document a hackathon hands its teams: what to build, under which rules, who may enter, what to submit, and what "good" will be called. It is the only artifact every participant reads, and every dispute at the ceremony traces back to a sentence it did or did not contain.

What "track" means here

A challenge track is a thematic category a team enters its project into: an AI track, a sponsor's API track, a beginners track. It is a content and prize construct.

samber/dev-event-organizer-skills@event-format-selection uses "track" for parallel session streams, single-track versus multi-track programming. Same word, different concept.

Write challenge track wherever a reader could take the other meaning. A session-track decision settles nothing here.

What you own, and what is already decided

You own the written brief:

• problem statements
• challenge-track content
• rules and eligibility text
• the submission checklist
• sponsor-challenge framing
• the names of the evaluation categories

Three things arrive already decided. Publish them rather than re-open them.

• The demo/judging structure (expo table, stage pitch, video-only, or the two-stage hybrid) belongs to samber/dev-event-organizer-skills@event-format-selection. Translate it into the submission checklist and the deadline rather than pick it: a video-only event makes the video the deliverable, an expo event makes it optional. Deliverable format is downstream of that choice, never an independent one you make here.
• Criteria weights, the scale, judge allocation, tie-breaks and disputes belong to samber/dev-event-organizer-skills@hackathon-judging. That skill states the boundary from its own side: the evaluation categories named in the published brief are yours, and it weights them and builds the mechanics on top. Name the categories, and never print a weight, a scale or a points total.
• Prize amounts, cash-versus-in-kind and payout handling belong to samber/dev-event-organizer-skills@hackathon-cash-prize. Write "each challenge track awards a prize"; never write the figure.

Every ranking below is a default, not a law. Re-rank each menu after the interview against what you already know about this event:

• last edition's published rules
• a signed sponsorship agreement
• an organizer who has run this API before
• a beginner-heavy audience

Interview

Ask one question at a time, multiple-choice where possible. Questions 3-5 and 8-9 decide which rung each menu defaults to; the defaults cannot be picked without those answers.

1. How long is the hacking window in hours, and is the event in person or fully digital?
2. Which demo/judging structure is already chosen? (Fixed input - do not re-decide it.)
3. Do participants bring their own problems to work on, or does the organizer supply the problem statements? Both is a real answer.
4. How many sponsors fund a prize, and does any signed agreement already promise a named challenge track?
5. Does any sponsor's API, dataset or hardware need keys or accounts - and has anyone on the organizing team actually built something small against it end to end? What happens to those teams if it goes down mid-event?
6. Who may enter and who is barred: students only, an age minimum, geography or employment exclusions, organizers and volunteers? And what team-size rule has samber/dev-event-organizer-skills@hackathon-team-formation already decided - a maximum, a minimum, solo entries allowed or not? (Fixed input you publish, not one you set. The pass threshold below counts it, so get the number before drafting.)
7. Is a demographic or skill-level carve-out required - a beginners track, a first-timers quota, a student-only category?
8. Do prizes carry cash value, are minors expected to attend, and is any personal data collected through the submission? (Decides whether the cheapest rules rung survives at all.)
9. What is the publication timeline and event cadence?
   • When must the brief be published?
   • Is this a one-off, or a recurring edition whose rules should still hold next year?
   • What is the effort ceiling: organizer hours before publication, and whether counsel is available at all?

Q9's three answers each move a named rung. Say which as you re-rank:

• A near publication date promotes the adopted standard rule set over anything drafted, and demotes the fully specified challenge, whose starter repo and acceptance tests are the longest lead time on any menu here.
• A recurring edition promotes the rungs written once and reused, the adopted set with its carve-outs and the per-track prompt skeleton, because their cost amortises across editions where a one-off pays it in full.
• An effort ceiling with no counsel behind it does not demote full legal-grade, it removes the route to it. Say so rather than substituting self-written legal-sounding text.

Workflow

1. Run the interview. Read last edition's published rules first if one exists.
2. Fix the rules and eligibility text before the problem statements. It deletes rungs from the other menus and it carries the real exposure. Load references/rules-and-eligibility-source-text.md.
3. Decide the challenge-track structure, then write one problem statement per track. Load references/problem-statement-patterns.md.
4. Convert each sponsor commitment into a track prompt or a bonus-prize criterion, and write the fallback sentence for a sponsor platform that fails.
5. Name the evaluation categories. Say plainly in the brief who weights them and when the weights get published, then hand the categories to samber/dev-event-organizer-skills@hackathon-judging.
6. Build the submission checklist from the chosen demo structure, never from a generic template. Load references/submission-checklist-and-categories.md.
7. Run the ambiguity pass: for every rule, ask what a team arguing the opposite reading would point at.
8. Publish before registration closes, then freeze. A rule added after teams start building applies to a competition nobody entered.

Present the brief section by section for validation, never as one block:

• rules
• eligibility
• tracks
• problem statements
• submission checklist
• categories

Get explicit approval before publishing; publication is the point of no return.

If your harness has persistent memory, record:

• the published rule set and which fields were edited
• the specificity rung chosen per track
• the sponsor fallback sentences
• every question a participant actually asked during the event, the most useful of the four, since each one names a sentence the next brief needs

Problem-statement specificity

Four rungs, from a bare theme to a fully specified challenge with a starter repo and acceptance tests.

Size the ambition to the time box. One practitioner rule of thumb circulates: "Most projects will accomplish about 25% of what they think they can accomplish in the limited time they have." Read the figure against the right denominator: it is 25% of a team's own pre-hack estimate of its own scope, not of the organizer's prompt, not of any absolute measure, and not a completion rate. It is one organizer's observation, not a measured rate.

The design consequence runs through every rung below: write each prompt so that the quarter a team actually reaches is itself demoable, by naming a minimum viable submission rather than leaving teams to discover one at hour forty.

• value (a team can self-assess whether it is in scope; judges can compare submissions to each other): fully specified > structured statement > domain-scoped prompt > open theme
• effort (organizer writing time before publication, plus keeping every prompt consistent with the rules): fully specified > structured statement > domain-scoped prompt > open theme
• efficiency: structured statement > domain-scoped prompt > open theme > fully specified

Dominance check, re-derived: clean only by construction, and by-construction is never a pass. Both axes run in the same order, so no pair exists where one rung has value greater than or equal to another's and effort less than or equal to it. Zero dominance relations exist, the check can catch no misordering here, and the efficiency line therefore rests entirely on the arguments below rather than on any verification.

• Structured statement - the default, in five parts: context, the challenge as a question, the constraints, the resources provided, and a stated minimum viable submission. It is the cheapest rung at which a team can answer "are we in scope" without asking an organizer, and the rung the submission checklist and the evaluation categories both derive from without further writing.

  Its project-quality template asks that projects have "a clear question or problem they are trying to solve plus a reasonably specific proposed solution". That template assumes participants pitching their own projects, so when the organizer writes the prompt instead, the burden moves to the organizer.

• Domain-scoped prompt - one sentence naming a domain and nothing else. Real segmentation value for near-zero cost, but it leaves the in-scope question open, and that question generates the clarification traffic an organizer answers all weekend.

• Open theme - near-zero cost, and genuinely correct at events where participants bring the problems. Promotion condition, keyed to Q3: participants arrive with their own projects and pitch them, in which case the brief's job is to publish the pitch mechanic rather than the problem.

  Delete it, from this menu and from the axis lines above, as soon as any sponsor funds a prize (Q4). A sponsor prize needs a stated criterion to attach to, and parking the open theme at the bottom quietly leaves that prize with nothing to award against.

  Where the pitch mechanic is chosen, publish one refinement alongside it: require the pitch to state a problem, not a solution. A team pitching "we want to build X" commits to an approach before anyone has tested whether the problem is real; a team pitching "this target group has this problem, here is the evidence" leaves the approach open to whoever joins. Publish two things with it - a short evidence requirement (interviews, numbers, a lived account - whatever counts as evidence here) and a stated minimum before a team may move to building - and hand both to samber/dev-event-organizer-skills@hackathon-team-formation as content the pitch mechanic runs.

• Fully specified challenge - the starved option: top of value, top of effort, so efficiency never picks it. Building a starter repo, a dataset and acceptance tests is organizer engineering work measured in days.

  Promotion condition, keyed to Q1 and Q5: a time box of a week or longer, or a sponsor whose own integration tests already exist and can be handed over as-is. Below roughly a weekend it also changes what the event is, turning a build into a graded exercise.

  No source publishes a formula converting a specificity rung to an hour count. A second, independent source agrees on the direction and nothing more: guidance for writing AI/ML challenge prompts tiers them by complexity, and states plainly that its hardest tier - real-world systems, unpredictable data, enterprise-grade reliability - "often exceed[s] the standard 24-72 hour window and may be better suited to extended formats," while its lower tiers fit inside it. Never read it as a second data point for the same quantity as the 25% figure above; they measure different things.

Challenge-track structure

Four rungs: one unified challenge, general plus one sponsor track, general plus several sponsor tracks, fully partitioned (every sponsor, every demographic, plus an open track).

Adding a challenge track does not split the field. A team submits one project, and that one project may enter several challenge tracks; the standard rule set publishes both halves as adjacent text, "You may not submit multiple projects" and "You may submit to multiple challenges". Every team stays eligible for the general prize while entering the sponsor track too, so the marginal cost of a track is rules-consistency work, not lost submission density. This lever is routinely missed, and it is what makes every rung below affordable.

• value (sponsor satisfaction, audience segmentation, prize flexibility, a beginner's chance of placing): fully partitioned > general plus several sponsor tracks > general plus one sponsor track > one unified challenge
• effort (writing each prompt, keeping eligibility carve-outs consistent, and the cross-track submission rule): fully partitioned > general plus several sponsor tracks > general plus one sponsor track > one unified challenge
• efficiency: general plus one sponsor track > general plus several sponsor tracks > one unified challenge > fully partitioned

Dominance check, re-derived: clean only by construction, and by-construction is never a pass. Value and effort run in the same order across all four rungs, so no strict-dominance pair exists and nothing here was verified by the check. The argument above is the whole basis for the ordering.

• General plus one sponsor track - the default. The first sponsor track costs one prompt and one prize line, and it converts a sponsor from a logo into a challenge owner. It is also where the cross-track rule gets written once, which is the real cost.
• General plus several sponsor tracks - marginal effort per additional track falls, because the second track copies a pattern the first one paid for, while value keeps rising. Total effort still rises, which is why it sits below the default; the falling margin is why it sits above one unified challenge.
• One unified challenge - cheapest, and it leaves prize flexibility and sponsor value on the table. Delete it, from this menu and from the axis lines above, as soon as any sponsor funds a prize (Q4): with no named track the sponsor's prize has no published criterion, and awarding it becomes an improvisation at the ceremony.
• Fully partitioned - the starved option, top of both axes. Promotion condition, keyed to Q4 and Q7: enough sponsors that each funds its own prize and a demographic carve-out is already required, so the per-track eligibility wording has to be written anyway. Absent both, partitioning buys empty tracks and a prize nobody competed for.

No published ratio scales track count to participant headcount. The one sourced ceiling scales it to judging capacity instead: MLH's own guide says to aim for 3 tracks absent sponsor tracks and without an overall 1st/2nd/3rd placement, never 20 or more, and to raise the count only as far as the judges running deliberations can absorb without the panel turning chaotic. Treat sponsor and judge headcount, not particip

...