Project Deliverables

EE 541: A Computational Introduction to Deep Learning

Deliverables Overview

Deliverable Weight Due Date
Proposal 7% 16 Nov 2025, 23:59
Model Card 3% 05 Dec 2025, 17:00
Final Report 50% 05 Dec 2025, 17:00
Source Code 40% 05 Dec 2025, 17:00
Total 100%

GitHub Repository Access

All project code must be maintained in a private GitHub repository. Grant read access to the GitHub user github-share-uscece no later than 16 November (proposal deadline) and maintain this access through 22 December. The instructor will clone your repository directly for evaluation—you do not submit code archives. Your repository should show regular commits from both team members throughout the project period demonstrating ongoing development and collaboration.

Proposal

See sample template.

The proposal establishes your project direction by documenting your selected problem, initial understanding of the task, and planned approach. This is a required checkpoint that allows the instructor and teaching assistants to identify concerns early and provide guidance.

Content Requirements

Problem Selection and Description
Identify which project topic you have selected. Describe the problem in your own words. What is the task? What makes this problem challenging? What are the key characteristics of the provided dataset?
Mini Literature Survey
Conduct focused exploratory research on your problem domain. This is not an exhaustive literature review but demonstrates you understand the context of your work.

Survey 5-8 relevant sources that inform your approach. These might include:

  • Papers addressing similar problems or datasets
  • Tutorials or blog posts explaining relevant architectures
  • Documentation for techniques you plan to apply
  • Related work that provides baselines or context

For each source, briefly summarize what it contributes to your understanding. Explain how these sources inform your planned approach. Proper citations are required.

Proposed Approach
Outline your initial strategy for addressing the problem.
  • What types of architectures seem appropriate for this problem and why?
  • What data preprocessing or augmentation strategies might be useful?
  • How will you establish baselines?
  • What metrics will you use to evaluate performance?

You are not locked into this approach—it will evolve as you experiment. The goal is demonstrating thoughtful initial planning based on your literature survey and problem understanding.

Timeline and Division of Work
Provide a realistic timeline for completing your work over the remaining weeks. Describe how you and your partner will divide responsibilities.

Evaluation Criteria

Proposals are evaluated on clarity of problem understanding, quality of the mini literature survey, and soundness of the proposed approach.

The literature survey should demonstrate genuine exploratory research—not just listing papers but explaining how they inform your thinking. Your proposed approach should show you’ve thought carefully about the problem based on your research and course knowledge.

Teaching assistants will review proposals quickly and contact teams if there are concerns about scope, approach, or misunderstanding of the problem.

Model Card

The model card documents your best-performing model’s capabilities, limitations, and appropriate use. This reflects standard practice in responsible machine learning development.

Content Requirements

Model Details
Specify model architecture, including layer types, dimensions, and key design choices. Document the training framework and dependencies (PyTorch version, etc.). Include number of parameters and computational requirements.
Training Data
Describe the dataset used for training, validation, and testing. Note dataset size, class distributions, and any preprocessing or augmentation applied. Identify known limitations or biases in the data.
Performance Metrics
Report your model’s performance using metrics appropriate for your task. Include results on training, validation, and test sets. If applicable, report performance across different subgroups or conditions. Explain what these metrics reveal about model capabilities.
Intended Use and Limitations
Describe scenarios where your model performs well and where it does not. What tasks is the model designed for? What input characteristics lead to good performance? What conditions cause degradation? Be specific about both strengths and weaknesses.
Failure Modes
Document known failure modes with examples. What types of inputs confuse the model? What edge cases have you identified? What assumptions might not hold in all contexts?
Fairness and Bias
Discuss potential biases in model predictions. Even for non-social applications, analyze what biases might exist (dataset bias, class imbalance effects). If bias analysis isn’t applicable to your problem, explain why.
Ethical Considerations
Note any ethical considerations relevant to your model. If your model is purely educational with no deployment intent, state this explicitly.

Evaluation Criteria

Model cards are evaluated on completeness, honesty about limitations, and quality of analysis. Strong model cards demonstrate critical thinking about capabilities and appropriate use rather than simply advocating for your work.

Final Report

The final report documents your complete experimental process, results, and analysis. This is your primary deliverable and should comprehensively capture what you did, why you did it, how it worked, and what you learned.

Format

Submit a single PDF file. There is no required length—aim for clarity and completeness. LaTeX is not required but professional presentation is expected. Include figures, tables, and visualizations that support your analysis. Minimize grammatical errors and cite sources appropriately.

Content Requirements

Introduction
Introduce your problem and provide necessary background. What problem are you addressing? Why is this problem interesting or important? What makes it challenging? Briefly summarize your approach and key findings.
Related Work
Expand on your proposal’s literature survey. Describe relevant prior work that informed your approach. Explain how your work relates to existing methods. This should be focused on work directly relevant to your problem, not a comprehensive survey.
Dataset and Preprocessing
Describe your dataset in detail. What are its characteristics (size, dimensions, class distribution)? What preprocessing did you apply and why? How did you split data for training, validation, and testing? What data augmentation strategies did you use? Include exploratory data analysis that motivated your choices.
Methodology
Document your experimental approach systematically.

Architectures: Describe all architectures you explored. For each significant architecture, explain the design rationale and any adaptations you made. Include architecture diagrams for your main models.

Hyperparameters: Document hyperparameter exploration. What hyperparameters did you vary? What ranges did you explore? How did you select final configurations?

Training Procedures: Explain your training methodology. What loss functions, optimizers, and learning rate schedules did you use? How did you monitor training? What techniques did you use to prevent overfitting?

Baseline Models: Describe the baseline models you established for comparison. Why did you choose these baselines?

Results
Present your experimental findings comprehensively.

Performance Summary: Report performance of all significant models using appropriate metrics. Present results in tables that allow clear comparison. Include training curves showing convergence behavior.

Comparative Analysis: Compare different architectural choices and hyperparameter configurations. What worked best and why? Use visualizations to illustrate key comparisons.

Best Model: Present detailed results for your best-performing model. Show performance across different metrics. Include confusion matrices, error analysis, or other task-specific evaluation.

Failure Analysis: Analyze where your models struggle. Show examples of failure cases and explain why they occur. What patterns emerge in misclassifications or poor predictions?

Learned Representations: If applicable, visualize what your models learned. This might include learned features, attention patterns, or activation maps.

Discussion
Analyze and interpret your results.

What Worked and Why: Explain which approaches succeeded and hypothesize why. Connect results to course concepts and theoretical understanding.

What Didn’t Work and Why: Discuss failed experiments and what you learned from them. Why did certain architectures or hyperparameters fail?

Data and Architecture Interactions: Discuss how data characteristics affected modeling choices. How did architectural decisions relate to dataset properties?

Comparison to Baselines: Interpret comparisons with baseline models. What do these comparisons reveal about your problem and methods?

Surprises and Insights: What surprised you during experimentation? What insights about deep learning did you gain?

Limitations: Acknowledge limitations of your work. What constraints affected your results? What could be improved with more time or resources?

Conclusion
Summarize your project and address required reflection questions.

Summary: Briefly recap your problem, approach, and key findings.

Required Reflections: You must explicitly address three questions:

  1. Extensions: Provide at least one substantive extension of your work. This should be a concrete proposal, not vague statements like “try more data” or “make it better.” What specific next steps would build meaningfully on your work?

  2. What question do you feel you answered through this project? What did you learn or understand by completing this work? What question drove your investigation and how did you address it?

  3. What are you still curious about after this project? What questions remain unanswered? What would you investigate with more time or resources? What unexpected directions emerged?

Contributions Statement: Document how work was divided between team members.

Evaluation Criteria

The final report is evaluated across multiple dimensions reflecting the depth of your work.

Experimental Rigor: Systematic methodology, comprehensive exploration of approaches, appropriate baseline comparisons, sound evaluation practices.

Technical Quality: Correct implementation, appropriate architectural choices, sound training practices, proper data handling.

Analysis and Insight: Deep understanding of results, thoughtful interpretation of findings, learning from failures as well as successes, connection to course concepts.

Communication Quality: Clear organization, effective visualizations, professional presentation, thorough documentation of process and decisions.

Critical Reflection: Honest assessment of work, thoughtful responses to required questions, meaningful proposed extensions, demonstration of genuine learning.

The report should demonstrate that you understand deep learning fundamentals through systematic application, not just that you achieved performance on a task.

Source Code

Your source code is the implementation artifact of your project and the most heavily weighted deliverable. Code should be well-organized, documented, and reproducible. This is not a software engineering course, but your code should demonstrate care and understanding.

Repository Access

Your code is evaluated through your GitHub repository. Ensure you have granted read access to github-share-uscece by the initial proposal deadline and maintain access through the required date. The instructor will clone your repository for evaluation.

Do not include trained model files or training datasets in your repository. If the instructor needs access to your trained models for evaluation, this will be arranged separately (likely through S3 upload or SCP transfer).

Documentation Requirements

README File: Include a comprehensive README that describes:

  • The major files and directories in your repository
  • Setup and installation requirements (dependencies, environment setup)
  • How to run your code (training, evaluation, inference)
  • Data format and layout expectations
  • Repository structure and organization
  • Any special technical requirements or dependencies

Your README should enable someone familiar with deep learning to understand and run your code without guessing.

Code Documentation: Include docstrings or comments for non-obvious code sections. You don’t need to comment every line, but complex algorithms, architectural decisions, or non-standard approaches should be explained.

Code Organization

Organize your code logically with clear separation of concerns. Typical organization might include:

  • Model definitions (architecture implementations)
  • Training scripts with clear entry points
  • Evaluation and analysis code
  • Data loading and preprocessing utilities
  • Configuration files for hyperparameters and settings

Your structure should allow someone to understand what you implemented and reproduce your main results.

Reproducibility

Your code should allow reproduction of your main results. This doesn’t mean perfect bit-for-bit reproduction (random seeds, hardware differences, etc. affect this), but someone should be able to train your model and achieve similar performance.

Include or document:

  • Random seeds used for reported results
  • Hyperparameter configurations
  • Training procedures and schedules
  • Data preprocessing steps
  • Any code used to generate figures or results in your report

Evaluation Criteria

Source code is evaluated on correctness, organization, documentation quality, and reproducibility. Code that runs correctly and produces results is expected—evaluation focuses on whether your implementation demonstrates understanding of what you built and whether others could build on your work.

Implementation Correctness:

Does your code correctly implement your approach? Are technical components properly integrated? Does your implementation reflect understanding of the underlying algorithms?

Organization and Clarity: Is your code organized logically? Can someone understand your repository structure? Are file and function names meaningful?

Code Quality: Is your code reasonably clean and maintainable? Does it reflect understanding of deep learning rather than just working implementations?

Documentation: Can someone else run your code based on your documentation? Have you explained non-obvious design decisions? Is your README comprehensive?

Reproducibility: Can main results be reproduced from your code? Are experimental details documented?