Judging Rubric
Defines a 100-point scoring rubric for an AI-for-social-good hackathon, covering five criteria with detailed score bands and tie-breaking rules.
What this file does
Defines a 100-point scoring rubric for an AI-for-social-good hackathon, covering five criteria with detailed score bands and tie-breaking rules.
When to use it
- Organising a hackathon that needs a transparent judging framework
- Creating a rubric for projects that must integrate a specific AI platform
- Standardising evaluation across multiple judges with independent scoring
- Providing teams with clear expectations before submission
Judging Rubric
AI for Social Good Hackathon – SUST 2026
Scoring Overview
Projects are evaluated by a panel of judges across five criteria, totalling 100 points.
| Criterion | Weight | Description |
|---|---|---|
| Social Impact & Relevance | 25 pts | Real-world problem, clear target beneficiary |
| Z.ai Integration Quality | 25 pts | Meaningful, non-superficial use of Z.ai |
| Technical Execution | 20 pts | Working demo, code quality, reliability |
| User Experience & Clarity | 15 pts | Usability, simplicity, clarity for non-technical users |
| Demo & Communication | 15 pts | Team presentation, explanation, confidence |
Maximum total: 100 points
Detailed Criteria
1. Social Impact & Relevance (25 pts)
| Score Range | Description |
|---|---|
| 21–25 | Problem is clearly defined, meaningful, and directly impacts a real community. Target users and expected benefit are compelling. |
| 16–20 | Good problem choice with adequate justification. Impact is plausible but not fully articulated. |
| 11–15 | Problem is generic or lacks specificity. Social impact is vague. |
| 6–10 | Weak problem framing. Limited relevance to social good. |
| 0–5 | No clear social purpose or the use case is trivial/irrelevant. |
2. Z.ai Integration Quality (25 pts)
| Score Range | Description |
|---|---|
| 21–25 | Z.ai is central to the solution. Integration is non-trivial, contextually appropriate, and clearly enhances the user experience. |
| 16–20 | Z.ai is used meaningfully and contributes to the solution, though not central. |
| 11–15 | Z.ai is included but the integration feels superficial or bolted on. |
| 6–10 | Minimal or unclear Z.ai usage. Documentation of usage is lacking. |
| 0–5 | Z.ai is absent or the integration is non-functional. |
3. Technical Execution (20 pts)
| Score Range | Description |
|---|---|
| 17–20 | Project runs reliably. Code is organized and well-documented. Architecture suits the problem and 1-day scope. |
| 12–16 | Project mostly works. Minor bugs or incomplete features, but core functionality is demonstrated. |
| 7–11 | Some functionality present but significant issues or missing features. |
| 3–6 | Barely functional. Major gaps in implementation. |
| 0–2 | Non-functional or empty repository. |
4. User Experience & Clarity (15 pts)
| Score Range | Description |
|---|---|
| 13–15 | Intuitive, clean interface or workflow. A non-technical user could understand and use the product. |
| 9–12 | Usable with minor rough edges. User flow is mostly clear. |
| 5–8 | Functional but confusing or difficult to navigate. |
| 1–4 | Poor UX; requires significant explanation to operate. |
| 0 | No user-facing interface or experience considered. |
5. Demo & Communication (15 pts)
| Score Range | Description |
|---|---|
| 13–15 | Clear, concise, and confident presentation. Demo shows real functionality. Team answers questions well. |
| 9–12 | Good presentation with minor clarity issues. Demo covers the core features. |
| 5–8 | Partial demo or unclear explanation. Some key features not demonstrated. |
| 1–4 | Weak or disorganized presentation. Demo does not prove functionality. |
| 0 | No presentation or demo. |
Tie-Break Policy
If two or more teams have equal total scores:
- Higher Technical Execution score wins.
- If still tied, higher Social Impact & Relevance score wins.
- If still tied, the judges panel holds a brief discussion and majority decision.
Judge Conduct
- Judges score independently before any group discussion.
- Judges must declare conflicts of interest with any team before scoring.
- Judges should provide at least one line of written feedback per team.
- Scores are final once submitted to the scoring sheet.
- Judges must not share individual scores with participants before the official announcement.
Scoring Template
See judging/judge-evaluation-sheet.md for the per-team scoring form judges will use.
What's inside
5 criteria with score ranges, tie-break policy, judge conduct rules, and a reference to a separate scoring template.
Change this for your project
- Replace
Z.aiwith the actual AI platform name used in your hackathon - Replace
SUST 2026with your event name and year - Replace
../judging/judge-evaluation-sheet.mdwith the correct path to your scoring template
Where it goes
Keep it in your repository where the agent or team that needs it will read it.
Worth borrowing
- Score bands with explicit descriptions for each range reduce ambiguity
- Tie-break hierarchy prevents deadlock without requiring full re-evaluation
- Judge conduct rules ensure fairness and confidentiality
Related Documents
AICA PRD Quality Rubric
Defines a 10-dimension scoring rubric (0-5 each) to evaluate and create PRDs, with a target score of 36+ for agent-driven implementation.
Liscribe v2 — Rubric of Success
Defines the complete UI specification, success criteria, and non-negotiable principles for a macOS transcription app with three independent workflows.
QualRubric
Defines a qualitative rubric for PhD qualifying exam presentations, focusing on context, organization, and knowledge demonstration rather than numerical scoring.