Make your work reproducible

Workflow

1. Choose a project and read its objective, interfaces, examples, checks, and deliverables.
2. Download the package, install its dependencies, and run the unchanged baseline before implementation.
3. Implement your solution, verify correctness, and conduct controlled experiments. Preserve raw data and distinguish simulations, estimates, and physical-device measurements.
4. Upload a code ZIP and a separate PDF or Markdown report, with contributor and tool-use information.
5. Save the receipt. Use its submission ID and lookup key to retrieve the stored status. Resubmissions create new records.

Project requirements

Every final project needs a reproducible baseline, a complete technical design, an executable implementation, an end-to-end demonstration with correctness checks, and quantitative evidence. A CPU setup exercise or successful upload alone does not complete a research project.

For projects with supplied documentation and tests, the distributed implementation defines executable behavior. The statements retain its signatures, data layouts, dtypes, precision checks, command-line options, and timing behavior; public input instances differ from instructor evaluation. Where the runner lacks a check, that limitation is stated explicitly; a new threshold is not presented as an existing requirement.

Project 1 and Project 2 include optional CPU setup exercises. Project 3 uses the full RankMixer benchmark; Project 4 uses the All-to-All/FFN benchmark; Project 5 uses the KDA contract and public sample checks. Project 6 is provided by SLAI: self-provided data, both SFT and RL on Qwen3.5-0.8B, and MCQ/QA assessment across the full 14-week curriculum. Submission deadlines, late-work policy, team-size rules, and grading details follow course announcements.

Files and stages

Upload a ZIP of at most 25 MiB, with at most 2000 entries and at most 100 MiB total expanded size. Use relative paths and ordinary files/directories; encrypted archives, symbolic links, and parent-path traversal are rejected. Upload a separate nonempty PDF or UTF-8 Markdown report of at most 4 MiB.

Exclude virtual environments, model weights, caches, and large generated artifacts. Provide reproducible retrieval instructions and checksums for necessary large assets. Recommended organization:

submission.zip
  README.md             # Clean-environment setup and execution commands
  src/                  # Implementation, kernels, or generator
  requirements.txt      # Locked dependencies; also record drivers/devices
  configs/              # Workload, shapes, seeds, and experiment budgets
  results/              # Correctness, baseline, raw timings, and ablations
  CONTRIBUTIONS.md      # Contributors, responsibilities, and tool use

Proposal: objective, design, interface understanding, baseline, experiment plan, and risks. Milestone: current implementation, passing/failing checks, comparisons, and remaining work. Final: complete implementation, quantitative evidence, report, and reproducible demo. All stages require a code package and separate report. Archive structure is a recommendation; the upload service does not grade its technical contents.

Report checklist

• Project number, title, stage, team members, and contributions.
• Objective, hypotheses, architecture or subgraph DAG, interfaces, and algorithms.
• Baseline, input generation, hardware, drivers, dependencies, seeds, budgets, and timing boundaries.
• Correctness coverage, numerical thresholds, failure cases, and controlled baseline/candidate comparisons.
• Ablations, raw repeated measurements, cost analysis, limitations, and unsuccessful approaches.
• Complete installation, execution, validation, and reproduction commands.
• Disclosure of reused code and material AI-tool use, including how generated artifacts were verified.

Receipt and evaluation status

Received · Pending review means the files have been saved by the local server. The receipt includes file sizes, SHA-256 checksums, timestamp, and submission ID. It does not indicate an Accepted verdict or a grade. This service does not execute uploaded code or provide a GPU/NPU judge queue.

Run each project's checker in your development environment and include the reports and logs. Technical evaluation uses these artifacts and the demonstration. Keep the lookup key: it is returned when the submission is created. Download the JSON receipt as a backup.

This browser saves receipts, not contact-form drafts or uploaded files. On a shared computer, use “Clear local receipts” after saving your copy. Clearing browser storage does not delete server files. Uploaded materials are not available through the public static-file routes.

Public checks and instructor evaluation

Each download contains starter/reference code and a small public evaluation. Complete matrices, regression suites and additional generated inputs remain outside the web directory. Public sample success is not an Accepted verdict. Instructor evaluation uses the same interfaces, mathematical definitions and numerical gates, with different seeds and input instances within the published domain. Full-project review also examines implementation, hardware evidence and experimental rigor.

Environment verification

Every package includes ENVIRONMENT.md and preflight.py. Run the preflight after extraction; its JSON records the executed commands, exit codes and output. CPU and CUDA dependencies have separate pinned requirements. Dependency pins make the verified CPU environment reproducible.

The development environment is Linux, Python 3.12, CPU PyTorch 2.6.0, NumPy 1.26.4, einops 0.8.2 and pytest 9.1.1. No NVIDIA/Ascend device tools or EasyASC installation are available here. A dependency/import check does not prove accelerator execution. The downloadable preflight returns a nonzero status for blocked or dependencies-only paths. Full hardware environments must be validated before course-wide use.