Frequently asked questions

Can't find your answer? Ask a question.

Who can take part?: The Challenge is open to enrolled students aged 18 or over at the time of registration. Undergraduate, master's and doctoral students are all eligible, from any country and any institution. The organiser may ask advancing teams for evidence of student status or age eligibility.
Can I enter on my own, or do I need a team?: Both work. A team can have between one and six members. If you register on your own you are already a valid team of one, and you can invite more members at any time up to the submission deadline.
How do I form a team and invite members?: Sign in, create a team, then invite members by email address from your team page. Each invited person signs in with that same address and completes their own profile and consents before they count as an active member. Only the team leader can invite or remove members and finalise the entry.
Can a team include members from different universities?: Yes. Cross-institution teams are allowed, and each member records their own institution when they complete their profile.
Can I be a member of more than one team?: No. Each person may be an active member of only one team, and each team submits one entry.
When is the submission deadline?: 24 August 2026 at 23:59 BST. The deadline is enforced by the platform. An entry that has not been finalised by then is not considered submitted — leaving it in draft does not count. Please do not leave finalising to the final minutes.
What exactly do we submit?: A title and abstract on the platform, and three deliverables — all three are mandatory — plus an optional demo video link: • Research document — your method and knowledge-exchange design; system architecture diagram; the Exchange Artefact Table; your chosen Axis A baseline comparison (centralised-cloud or local-only, with the reason for the choice) and the minimum local-only baseline comparison, including the Collaboration-Gain Fairness Disclosure Table; at least one sustainability measurement or estimate; your integration-feasibility statement; disclosure of model initialisation and any pre-existing IP; and references/citations for the key methods you build on (any format). • Presentation — a summary account of the solution; advancing teams build on it for the on-site rounds. • Code — see "What are the requirements for the code deliverable?" below. • Demo video — an unlisted YouTube link. Optional, but it strengthens the reproducibility evidence judges look for. An entry missing any of the three deliverables does not meet the submission requirements — even if the platform lets you finalise with fewer files. When everything is in place, the team leader clicks Finalise.
What file formats and size limits apply?: Research document: PDF, up to 25 MB. Presentation: PDF, PPT or PPTX, up to 100 MB. Code: ZIP, TAR, GZ or TGZ, up to 200 MB. Files upload directly from your browser to secure storage, and every upload is automatically screened for malware.
What are the requirements for the code deliverable?: Executable source code, written mainly in Python (other high-level languages such as JavaScript are acceptable, and performance or hardware components may use C/C++/Rust). Include run instructions — dependency versions, environment requirements, and re-run steps — so judges can reproduce your results. Your program must also be able to actively run at least one scenario-driven demonstration — for example dynamically adding new classes, simulating node disconnection/failure/reconnection, or injecting distribution shift — either triggerable by judges following your instructions, or supported by an automation script or screen recording. Reproducibility is assessed on three evidence tiers: L1 — a smoke test runs the multi-node flow; L2 — the key small-scale results re-run in a general environment; L3 — the main results re-run, or complete hardware-measurement evidence. Hardware-constrained teams that provide reviewable evidence are not penalised for being unable to reach L3, but a team with no evidence at all that the system has actually run will lose substantial marks.
Can we change our entry after finalising it?: Yes. The team leader can unlock the entry, edit it and finalise it again at any point before the deadline. Once the deadline passes, nothing can be changed.
Can new members still join after we have started our submission?: Yes, up to the deadline, as long as the team stays within six members. Every active member must complete their profile and accept the IP licence before the leader can finalise the entry.
Do we need special hardware?: No. Simulation is entirely acceptable — for example several containers on one machine, several laptops on a local network, a mobile app, or low-power boards such as Jetson, Coral or Raspberry Pi if you have them. Entries are judged on the quality of the design and the evidence, not on the hardware you happen to own. Reproducibility uses three evidence tiers (L1 smoke test / L2 key results re-run / L3 full re-run or measured hardware evidence); a hardware-constrained team that corroborates with reviewable evidence is not penalised further for being unable to reach L3.
What must never be exchanged between nodes?: Raw input data; anything from which the main content of raw input could reasonably be reconstructed; and any information that carries raw-data semantics through metadata, prompts, filenames, indices, external links, timestamps, coordinate encodings or other side channels. Any machine-readable exchange that is not disclosed in your Exchange Artefact Table is also a violation. Judging applies a substantive test — what an exchange actually contains, not what it is named. If you are unsure about an artefact, disclose it honestly with a reasoned risk assessment: an artefact marked high risk is not automatically a violation — what matters is whether raw content could reasonably be reconstructed, and whether disclosure was honest. Concealment is treated far more severely than an honest high-risk rating.
What is the Exchange Artifact Table?: A required table in your research document covering every machine-readable exchange between your nodes. Nine fields are mandatory for each artefact: 1. name · 2. purpose · 3. direction (source → target node) · 4. frequency · 5. size per message (bytes) · 6. granularity (per-sample / per-batch / per-class / model-level) · 7. whether it contains metadata (time, coordinates, file names, prompts, IDs, external links) · 8. self-assessed reconstruction risk (low / medium / high) · 9. the reason for that risk assessment — mandatory when you claim low; a low rating without a reason may not be treated as low-risk. Privacy measures (compression, quantisation, noise, clipping, frequency limiting) and notes are optional but welcome. Be aware that sample-level embeddings, per-sample gradients or logits, reversibly compressed features, and summaries containing raw prompts or text fragments are assumed to be at least medium risk unless you show otherwise.
We have no energy-measurement equipment — is that a problem?: No. You may estimate instead — for example hardware TDP multiplied by inference time, or FLOPs/MACs with a hardware energy figure — provided you explain the estimation logic. Communication volume and computing cost are valid sustainability metrics too. What does cost marks is mentioning no sustainability measurement at all.
Do we have to use a particular framework, SDK or platform?: No. The data modality, model architecture, deployment form, communication mechanism and knowledge representation are all yours to choose. The organiser does not provide, or require, any SDK, dataset, container setup or official platform. The one language expectation is that the main implementation should be primarily in Python — see "What are the requirements for the code deliverable?".
Do we need a comparison against a non-collaborative baseline?: Yes — provide a comparison against a local-only baseline, giving the metric name, the final value and a brief explanation. If your scenario genuinely makes that comparison impossible, explain why; a reasoned explanation is accepted.
How are entries scored?: Four axes, each worth 25%: • A — Sustainability Impact: energy-efficient design, computing and communication savings, measurable environmental benefit. • B — Ease of Integration & Feasibility: plug-and-play readiness, portability, dependency clarity, deployment cost. • C — Technical Maturity: stability, completeness of evaluation, measured collaborative gain, reproducibility. • D — Creativity: originality of the knowledge-exchange mechanism, cross-disciplinary imagination, future potential. Each axis is scored from 0 to 25, giving a total out of 100. As rough calibration anchors: 0–8 is low (e.g. no comparison baseline, no execution evidence), 9–17 is medium (clear baseline and evidence, with gaps), and 18–25 is high (rigorous comparison, transparent assumptions, reproducible). Judges score independently, write a review, and may carry out evidence spot checks.
What happens after the deadline?: Judging starts as soon as the deadline passes and runs until mid-September. The eight semi-finalist teams are announced in mid-September and present in person at the University of Cambridge on 28 September; the judges then select three teams to advance to the final, held at Cambridge on 29 September, where the rankings are decided. Teams advancing to the next round may receive brief written feedback.
Who owns the intellectual property in our entry?: You do. Participants retain ownership of their work. Before finalising, each active member accepts a non-exclusive, royalty-free licence that lets the organiser receive, store, review, display to judges and administer the entry for Challenge purposes. Any commercialisation, publication or follow-up collaboration is agreed separately with the team after the competition. If you use existing code, libraries, models or datasets, disclose them and comply with their licences.
What language should we submit in?: English.
I did not receive my sign-in email — what should I do?: Check your spam or junk folder first, as university mail systems sometimes hold external mail briefly. Sign-in links expire 20 minutes after they are requested, so always use the most recent one. There is a limit on how many links can be requested per address per hour; if you reach it, wait a short while and try again. Please do not mark Challenge emails as spam — doing so blocks all future messages to your address, including your sign-in links.
My question is not answered here.: Send it through the Ask a question page — you do not need an account. We reply by email, and publish the questions that come up often on this page.