Project rubric
The course project contributes 25% of the course grade, split across four milestones:
- Topic check-in (5%)
- Proposal (5%)
- Poster / demo (5%)
- Final report (10%)
For milestone logistics and expectations, see project milestone guide.
1. Topic check-in (5 points)
| Criteria |
Points |
Description |
| Relevance |
2 |
The idea clearly fits the course and identifies a concrete privacy question. |
| Feasibility |
2 |
The scope is realistic for one semester and the available tools. |
| Planning |
1 |
The memo or talk identifies an initial path, not just a broad topic area. |
2. Proposal (5 points)
| Criteria |
Points |
Description |
| Problem framing |
2 |
Clear motivation, setting, and threat model. |
| Method and baselines |
2 |
Specific plan for what will be implemented, compared, or measured. |
| Scope control |
1 |
Realistic milestones, risks, and fallback plan. |
3. Poster / demo (5 points)
| Criteria |
Points |
Description |
| Technical content |
2 |
The core question, method, and evidence are understandable and technically sound. |
| Break and repair |
1 |
The team shows a reproducible challenge, root cause, and repair or a justified clean/insufficient finding. |
| Results and honesty |
1 |
The team shows actual results, limitations, and residual risk without overclaiming. |
| Communication and contributions |
1 |
The presentation is clear and team member roles are visible. |
4. Final report (10 points)
| Criteria |
Points |
Description |
| Technical correctness |
3 |
Methods match the stated threat model; privacy claims, DP claims, and metrics are technically justified. |
| Evidence, failure, and repair |
3 |
Results include concrete scale and baselines plus a reproducible challenge, root-cause analysis, repair, and regression evidence. |
| Transfer and limitations |
2 |
The changed setting tests generalization, and the report states what transferred, what did not, and the residual risks. |
| Writing and artifacts |
2 |
The report is organized, properly cited, and supported by clear figures, tables, configs, tests, and contribution notes. |
Additional notes
- Novelty is not required
- This is an undergraduate course project, not a conference submission.
- Strong reproduction, benchmarking, or application projects can earn top marks.
- Claims should match evidence
- A narrow but carefully tested claim is stronger than a broad claim with thin evidence.
- Be precise with differential privacy, RAG privacy, side-channel generalization, and LLM-judge results.
- Auditability matters
- Reports should include enough detail to check the result: counts, splits, seeds, prompts, configs, examples, or logs as appropriate.
- If code or artifacts are shared, they should support the report without exposing private or sensitive data.
- Visuals count as communication
- Figures and tables should be readable and should make the main comparison or failure case easy to see.
- Visual polish cannot replace weak evidence, but unclear visuals can make strong work hard to evaluate.
- Individual vs. group
- Individuals may submit narrower projects.
- Teams of 2 should show either broader experiments, stronger comparisons, or a more polished system.
- Contribution statements
- Every project submission should include a short contribution note for each member.
- If there is a serious contribution imbalance, grades may be adjusted.