Project rubric
The course project contributes 30% of the course grade, split across four milestones:
- Topic check-in (5%)
- Proposal (5%)
- Poster / demo (10%)
- 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 (10 points)
| Criteria |
Points |
Description |
| Technical content |
4 |
The core question, method, and evidence are understandable and technically sound. |
| Communication |
3 |
Visuals, structure, and spoken explanation are clear. |
| Results and honesty |
2 |
The team shows actual results and does not overclaim. |
| Contribution clarity |
1 |
Team member roles and contributions 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 and analysis |
3 |
Results include concrete scale, baselines, uncertainty or exact counts, representative examples, and limitations or failure cases. |
| Writing quality |
2 |
The report is organized, readable, properly cited, and uses clear figures, tables, and captions. |
| Reflection and next steps |
2 |
The team explains what was learned, what remains unresolved, and what artifacts support the result. |
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.