1. Treat the statement as an executable contract
Before testing code, write down what every legal input means, which inputs are illegal, what the output represents, and which behavior sits at the boundary of the constraints. Samples illustrate the contract; they do not define it.
A useful review asks whether two careful readers could implement different problems while both believing they followed the statement. If so, the package is not ready.
2. Require an independent route to the answer
A reference solution can reproduce the author’s mistaken assumption perfectly. An independently derived solution creates a second interpretation of the specification. Agreement across different reasoning paths is stronger evidence than multiple implementations copied from the same idea.
3. Build a failure catalogue
Wrong solutions are not miscellaneous files. Each one should represent a named misconception: an off-by-one interpretation, a missed structural case, arithmetic overflow, an invalid greedy step, an asymptotically slow approach, or an assumption that holds only on random data.
The release question is not simply whether the accepted solution passes. It is whether every known wrong model of the problem fails for the reason expected.
4. Map tests to risks
Every hand-built case and generator should have a job. Boundary families challenge the specification. Structured adversarial families challenge incorrect reasoning. Large instances challenge complexity. Random instances broaden coverage but cannot substitute for targeted cases.
5. Test the validator as hostile input
A validator needs negative tests: malformed structure, out-of-range values, missing tokens, extra tokens, illegal duplicates, and edge combinations near the stated limits. Rejecting illegal input is part of correctness; silently accepting it weakens every downstream conclusion.
6. Make the package rebuild itself
Continuous integration should regenerate data, validate every input, run accepted solutions, confirm expected outputs, execute the failure catalogue, and report unexpected agreement or disagreement. Rebuilding from source reduces the chance that a stale output or manual edit survives into release.
7. Keep a human release gate
Automation raises the floor, but it cannot establish that a statement is pedagogically fair, that the intended insight matches the data, or that a suspiciously similar solution represents a shared blind spot. A judge who did not author the package should sign off on the specification, evidence, and unresolved risks.
A compact release record
- Contract: statement, constraints, and legal-input model agree.
- Independent evidence: at least one separately derived solution agrees.
- Failure catalogue: known wrong and slow approaches fail as intended.
- Coverage: every named risk maps to a test family.
- Validation: malformed and out-of-range inputs are rejected.
- Rebuild: the package regenerates and verifies automatically.
- Review: an independent judge records the remaining risks and signs off.
The deeper principle
Contest engineering and production reliability share the same discipline: make assumptions explicit, construct failures before users encounter them, automate repeatable checks, and preserve an accountable human decision at the release boundary.