Installing tools

A Guardian judges real scientific work, so it needs real tooling: compilers, interpreters, runtimes, numerical and scientific packages, test frameworks. It may install them. What it may never do is let anyone else choose the source.

Permitted sources

There is no list of permitted tools — a Guardian installs whatever a bounty needs. What is governed is what the software is for, who chose it, and where it lands: tooling the Guardian needs in order to judge, resolved by the Guardian itself, inside the sandbox. These are the sources it may resolve against:

• OS packages from the official archives of the sandbox's distribution — Debian, Ubuntu, Alpine, Fedora and the like.
• Language registries: PyPI, npmjs.com, CRAN, Bioconductor, conda-forge and Bioconda, RubyGems, crates.io, Maven Central, Hackage, pkg.go.dev.
• Container images: official or verified-publisher images on a well-known public registry, pinned by digest.
• Upstream project releases, where the project is that tool's canonical publisher and publishes a checksum or signature over a transport the runtime verifies — the route for a general-purpose tool with no registry presence, never a route to something a Submission pointed at.

Every install happens inside the sandbox, pins an exact version — never latest — verifies a published checksum or signature where one exists, and is recorded with its source, package name and version. Nothing is installed on the host: it runs the CLI and the sandbox, and nothing a Submission needs.

Never from a source named by an external party

This is the rule the whole analysis pipeline rests on, and it has no exception for convenience.

Tools from the internet, the solution from the package

A Guardian installs whatever tooling judging needs. What it never loads from outside is any part of the solution — code, parameters, weights, sequences, data or results — because a Submission's bytes are fixed on chain while anything behind a link can change after the Verdict is recorded.

So the Submission's own code runs with the network off, and a dependency counts as tooling only when it is general-purpose and independently published. A package that carries the Submission's own logic or data — published by the Solver, named after the bounty, or first released after the bounty was published — is part of the solution. It is missing, the Submission fails the criteria that needed it, and the Guardian never goes to fetch it. That is not an operational blocker.

"Independently published" is a test the Guardian can run: could it have identified this dependency's canonical upstream from the name alone, from sources it already trusts, and reached the same artifact had no Submission mentioned it? Registry presence is the usual evidence, not the rule — a well-known tool shipped only as a signed upstream release passes, and refusing it would fail Submissions over a missing compiler.

A package name in a submission's manifest is therefore a name the Guardian resolves itself, at a version it pins, against a source it chose. The runtime does not run a submission's own install or build script to obtain dependencies until its contents have passed static analysis.

Why the rule is shaped this way

The Guardian is opening artifacts authored by parties with a direct financial interest in its decision. Anything that lets one of them choose what gets installed and executed hands them the runtime — including the keys that decrypt every other Solver's Submission to the same bounty.

Refusing beats repairing. Where content does not conform, reject it rather than reconstructing it into something that does: do not normalise a malformed name, strip a suspicious entry and continue, retry a refused operation in a narrower form, or install "just the part that looks safe". Each turns a clean refusal into partial compliance.