Submit and discuss your work

Submit only after the provided build, correctness test, and benchmark complete in your working copy.

Before you push

• Confirm that only src/submission.hpp contains your changes.
• Confirm that the code is your own work.
• Remove temporary diagnostics, generated files, and local benchmark artifacts from the proposed change.
• Run the preset build and correctness test one final time.
• Review the change so you can explain every design decision.

Automated evaluation

Push your changes to the repository supplied for your onboarding task. The template’s GitHub Action runs on every branch, sends the repository and commit to the UWHPC evaluator, polls for up to twelve minutes, and reports the result as a commit check. The full result JSON is written to the run’s step summary.

The check passes only when the evaluator returns completed. The other terminal states it reports are failed_build, failed_tests, failed_benchmark, timed_out, and internal_error — the first three point at your submission, the last two do not.

The public participant instructions do not require you to configure evaluator credentials or modify the workflow. If the evaluation check is absent or fails for infrastructure reasons, do not alter the harness to bypass it.

TODO — official submission procedure

Missing from the repositories: whether candidates receive a repository inside the UWHPC organization or fork to their own account, and if the latter, how the workflow is expected to reach its self-hosted uwhpc runner and the UWHPC_EVALUATOR_URL and UWHPC_EVALUATOR_TOKEN settings, which a personal fork will not have. Also missing: whether a specific branch or commit is required, submission deadlines, and the official support contact.

Evaluation criteria

The review considers:

• Whether the implementation is correct
• The quality and clarity of the implementation
• The reasoning behind design decisions
• Performance on the team benchmark machine

Correctness is required but is not the only consideration. The problem statement says applications are reviewed holistically and are not advanced on benchmark score alone.

Design discussion

After submission, candidates may be invited to a short virtual chat about their work. Prepare to explain:

• How you interpreted the requirements
• The design choices you made
• How you verified correctness
• How you evaluated the result
• What tradeoffs you considered

This is a discussion of your own reasoning, not a request for a particular implementation.

Use of AI

The problem statement permits using AI to learn and explore ideas, but the submitted implementation must remain your own work. Do not paste generated or third-party solution code into the submission. You should be able to explain and defend everything you submit during the discussion.

Source of truth

The submission flow comes from the template README and its evaluation workflow. The review dimensions, design discussion, and AI guidance come from the problem statement on this site.