Challenges

A challenge asks the community to build or improve an implementation of a kernel: optimise NTT for a new GPU, port a multiplier to another backend, close a gap nobody has claimed. It may exist before any implementation does — naming the gap is the point.

A challenge names:

• the kernel, and usually the specification, it is about;
• an objective and a ranking metric;
• constraints — eligible runner classes, what must be published;
• a window: when it opens, when it closes;
• a reward, where there is one.

A submission is an implementation at a commit. It is measured by the same pipeline as everything else — same generator, same oracle, same runners — because a challenge is a reason to measure, not a different way of measuring. Results stay attached to the implementation when the challenge ends: the catalogue keeps what the competition produced.

A challenge never owns an implementation's lifecycle. An implementation submitted to a challenge is still its author's, still versioned by commits, and still comparable outside the challenge wherever coverage intersects.