Feature proposal: explicit input preflight validation mode

Proposal

Add a small explicit preflight mode to run_alphafold.py, for example --validate_input_only, that loads and validates AlphaFold 3 input JSON and exits before the data pipeline or model inference starts.

The goal is to let users catch input problems before allocating expensive accelerator time or launching a long data-pipeline job.

A first version could remain deliberately narrow:

• parse the same --json_path / --input_dir inputs used by normal runs;
• run the existing folding_input validation and inexpensive consistency checks that do not require model weights or database searches;
• resolve and validate user-supplied chemical-component / CCD references where this can be done locally;
• validate obvious MSA/template field consistency without executing the searches themselves;
• report every input file as valid or return the existing actionable validation error;
• perform no inference and create no normal prediction output directory.

For example:

python run_alphafold.py \
  --json_path=my_job.json \
  --validate_input_only

could print a compact summary such as the job name, entity/chain counts, seeds, custom CCD usage, whether MSAs/templates are supplied versus require the data pipeline, and a final validation result.

Motivation

run_alphafold.py already exposes separate --run_data_pipeline and --run_inference flags, so users can technically disable both stages. However, that combination is an implementation-oriented way to reach a partial input-loading path: it still goes through the normal output workflow and does not communicate which checks are intended to be useful as a preflight contract.

An explicit validation mode would make the supported workflow discoverable and give scripts/cluster submission systems a stable way to validate batches of JSON jobs before scheduling expensive work.

This seems particularly useful for complex AlphaFold 3 inputs containing multiple entity types, custom CCD components, user-provided MSAs/templates, modifications, or bonds, where an input mistake may otherwise only surface after the job has entered the normal execution path.

Scope

This is intentionally not a new schema or a second validation implementation. The mode should reuse existing parsing and validation code and remain a small CLI/usability addition, consistent with this repository's preference for small changes.

I searched current issues for validate-only, dry-run, preflight, and input-validation modes and did not find an equivalent proposal.

If this fits the repository's scope, I would be happy to implement the small CLI path, focused tests, and documentation.