Regulation
How HACKB evaluates your submissions: scoring per mode, submission statuses, judge sandbox details, and ranking rules. Please skim before joining a contest.
Judge process
How a submission moves from upload to judged result, and the statuses it can land in along the way.
1. Submit
Upload submission.py and requirements.txt to enqueue the submission for judging. It starts in the WJ (waiting-judge) state.
2. Build
The judge server picks up the submission, resolves dependencies, and runs a static check on the code. Anything that fails here terminates as IS (InvalidSubmission) and skips the rest of the pipeline. On success the submission transitions to RJ (Running).
3. Judge
The judge server executes the submitted code. A clean run becomes AC (Accepted); otherwise the status reflects the failure mode — WA, RTE, TLE, MLE, or IE. Only AC produces a valid score that feeds into rankings.
Judge status transitions
A submission walks the three phases — Submit, Build, Judge — and ends in one of the terminal statuses.
Submission statuses
Every submission ends up in one of the statuses below. Queued / Running are intermediate; the rest are terminal. Among terminal statuses, only Accepted produces a valid score.
| Code | Description |
|---|---|
| WJ | Waiting Judge: queued; the worker will pick it up as soon as a slot is free. |
| RJ | Running Judge: a worker is currently evaluating the submission. |
| AC | Accepted: the run finished successfully and produced a valid score. |
| WA | Wrong Answer: the output didn't meet the format requirements (e.g. out-of-range values or shape). |
| RTE | Runtime Error: the submission threw an exception during execution. Check stderr. |
| TLE | Time Limit Exceeded: the run did not complete within the allotted time. |
| MLE | Memory Limit Exceeded: the run exceeded the memory budget. |
| IS | Invalid Submission: the uploaded files or entrypoint were malformed, so judging never started. |
| IE | Internal Error: a judge-side failure occurred. Resubmit or contact the operators. |