Horizon · The rules
Entering
You submit a Hugging Face repository of weights at a commit — no code — and a token that proves the repository is yours.
4 min read
You fine-tune Zero-WAM and submit the weights. Your code is not run: every model in an epoch is served by the same runtime, so evaluation time is predictable and two models differ only by what they learned.
What you submit
A Hugging Face repository at a commit, holding weights only.
The repository
transformer/*.safetensors the same architecture as the base model
norm_stats/*.json your action statistics
zerowam.yaml inference settings, within the published boundsCheck it before you send it
horizon-runtime-zerowam check reads file headers only, so it takes seconds and needs no GPU. The
organiser runs the same command on the copy they fetch, so what it says on your box is what
decides your entry.
Check your weights
pip install horizon-runtime-zerowam
horizon-runtime-zerowam check --weights /path/to/your/repoWhat it refuses, and why:
| Refusal | Reason |
|---|---|
| "the weights are not this model's architecture" | A tensor is missing, extra, or the wrong shape. Fine-tune the base model; do not change its shape |
| "the repository is N GB" | Over the published limit |
"zerowam.yaml sets X, which is not a knob" | Only the published knobs exist |
| "X is N, outside [a, b]" | The knob is outside its bounds |
What you may tune without touching code
zerowam.yaml carries the inference settings, and only the published knobs exist. Fewer steps is
faster and usually worse; that trade is yours to make. action_guidance_scale is not offered,
because with a video prompt the action branch runs a single pass and the setting would do nothing.
The knobs, their ranges and their defaults are published with the runtime, not in an epoch record,
so this site does not quote them: horizon-runtime-zerowam check is what holds your file to them, and it
names the bound it refused you on.
How you submit
Push your repository, then enter the commit through the organiser's intake. Ask the organiser for its address and its token; for the pilot it is on a private network, so you reach it over the SSH tunnel or the network they give you.
The shape of it — fill in what only you have
export HORIZON_INTAKE_TOKEN=<the organiser's intake token>
export HF_TOKEN=<a fine-grained Hugging Face token, scoped to this repository, with content write>
horizon-competition submit --intake <the intake's URL> --participant <your name> \
--repo <owner/name> --revision $(git -C /path/to/your/repo rev-parse HEAD)
horizon-competition status --intake <the intake's URL> --repo <owner/name> --revision <the commit>That block is an example, not a command this site built for you: the intake's address, its token and your repository are yours, and nothing in the store carries them. Every command this site offers to run as printed is built from a record and is on the page of the epoch it belongs to.
submit does not return until the organiser has decided, because deciding means fetching your
repository and checking it, which takes as long as the download does. What comes back is your
entry and its submitted_at, or the reason it was refused.
Three things are worth knowing about that.
Your token proves the repository is yours. The Hub is asked who the token belongs to and
whether it can write to the repository you named; if it cannot, the submission is refused. This is
what stops somebody else entering your repository under their name. The token fetches the
repository and is then gone: it is not stored, not logged, and not published. Your account name is
recorded, and that is all. Make it a fine-grained token scoped to the one repository with
repo.content.write: it is sent over the intake's plain HTTP, and a token like that can write
nothing else of yours. A classic write token is accepted, but can write every repository your
account can.
The organiser fetches and checks, not you. repo@revision is downloaded and
horizon-runtime-zerowam check is run on the copy that arrived. Nothing you send is taken on trust —
including the hash of your weights, which is computed there, from the bytes fetched. That copy is
the only thing served under your key.
submitted_at is the organiser's clock, and it is signed. Your entry is an ed25519-signed
record in the same store as the epochs, so the stamp that breaks a tie is not a line in a file
somebody could edit.
Practical notes
- Enter a commit, not a branch. A branch can move under an epoch, and it is refused.
- Enter the same commit twice and you get the same entry, with the time it first arrived.
- Entries accepted before an epoch opens are the ones it takes; later ones wait for the next week. The epoch publishes that list, signed, when it opens: you can see whether you are in this week's.
- Identical weights are one entry, whoever sends them; the earlier one keeps the place.
- Screening runs one episode per task first. Only the shortlist gets a full evaluation, so a model that fails everything costs you a week rather than a place.
After the week closes
The epoch's secret is revealed and everything is published: the units, the demonstrations, every
result, and the scoring, signed. You can re-derive the units yourself and rebuild the same
demonstrations, and check the numbers you were given — and that needs nothing installed but the
competition's own package: no simulator, no fork, no GPU. epoch derive refuses a secret that
does not hash to the commitment the epoch published when it opened, before it saw your entry.
Verification says what each check is worth, and why the organiser's key has to come from somewhere other than the store you are checking.
