Judging Rubric

# 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:

1. Higher **Technical Execution** score wins.
2. If still tied, higher **Social Impact & Relevance** score wins.
3. 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`](../judging/judge-evaluation-sheet.md) for the per-team scoring form judges will use.