Deployment

Where a run writes its artifacts, how to resume and reproduce, how predictions reach the leaderboard, and how this documentation portal is published.

1. Execution environments

2. Output layout

A run is identified by its approach and experiment, and every artifact it produces lands under that pair:

outputs/
└── <approach>/
    └── <experiment>/
        ├── results/     checkpoints written during training
        ├── wandb/       local tracking logs for the run
        └── hydra/       the resolved configuration actually used

The hydra/ directory is the most valuable of the three when reproducing a result: it contains the fully resolved configuration, after the shared base and the experiment file have been composed. Two runs can be compared by diffing those two files alone, without reconstructing which overrides were passed on the command line.

Prediction artifacts are written wherever the inference run is pointed, conventionally outside the repository on the same fast storage:

<inference_output>/
├── probabilities/<case_id>.npy     foreground probability per case
├── distance_preds/<case_id>.npy    predicted distance field per case
└── metadata                        ties each prediction back to its source case

3. Checkpoints and resume

Checkpoints are written periodically during training rather than only at the end, at a cadence controlled by the experiment configuration. Two consequences shape day-to-day practice:

• Intermediate models are usable. A checkpoint from partway through a run can be loaded for inference directly, which is how the effect of training duration is assessed without waiting for a full run to finish.
• A long run is recoverable. If a job is interrupted, the most recent checkpoint is a valid starting point rather than a total loss.

Because each experiment writes into its own directory, changing the experiment name is the safe way to start a new run alongside an existing one; runs cannot overwrite each other’s checkpoints.

4. Experiment tracking

Training reports to Weights & Biases. What is reported falls into three groups:

Tracking mode is a configuration setting: it can run online, buffer locally and sync later, or be disabled entirely. Offline mode is the pragmatic choice when training on a machine without outbound network access, or when sweeping many short runs that would otherwise clutter the project.

Training metrics are progress indicators, not the competition score The metrics reported during training are computed from validation tensors, so they run on every validation round without waiting for prediction volumes to be written. The authoritative competition score is produced separately, from stored predictions, through the scoring path described in Evaluation & Metrics. Use the first to steer a run; use the second to make a claim.

5. Kaggle packaging and submission

Submission-time inference runs in Kaggle’s notebook environment, which has no access to this repository. The necessary slice of the code is therefore published as a Kaggle dataset, and the competition notebook consumes it.

exploration/scoring/
 ├── nnunet_inference/            partitioned multi-GPU predictor
 ├── post_processing_probs.py     post-processing dispatch
 ├── postprocess_ribbons.py       ribbon / continuity strategies
 └── analyze_prediction_*.py      prediction analysis helpers
        │
        │  Makefile target: package-nnunet-dataset
        ↓
kaggle_datasets/inference/          published package
        │
        │  kaggle datasets version
        ↓
Kaggle dataset  →  competition notebook  →  submission

The package is a copy, so it can drift Because the packaged files are copies of files under exploration/scoring/, the two can diverge if the source is edited without republishing. Treat the Makefile target as the only supported way to update the package, and republish immediately after changing any of the source modules it copies. Diffing the two locations is a quick way to confirm they agree.

6. Reproducibility

7. Publishing this documentation

This portal is plain static HTML with no build step, which makes publication trivial: the contents of docs/repo-overview/ are the site. A GitHub Actions workflow publishes that directory as the Pages artifact on every push to the default branch.

docs/repo-overview/
├── index.html                    front door
├── .nojekyll                     tells Pages to serve files as-is
├── assets/
│   ├── css/style.css             shared stylesheet
│   ├── js/site.js                navigation, theme, table of contents, copy buttons
│   └── diagrams/                 diagram sources
├── architecture/                 ┐
├── ai/                           │ one directory per section
├── development/                  │ each with its own index.html
└── operations/                   ┘

Three properties are worth preserving when editing the site:

• No build step. Pages are authored directly, so what you commit is what is served. The cost is that the navigation block is repeated in every page — a change to the section list has to be applied everywhere.
• No external requests. Styles, scripts and diagrams are all local, so the site works offline, renders identically in restricted networks, and prints cleanly.
• .nojekyll is required. Without it, Pages runs the content through Jekyll, which can silently drop files whose names begin with an underscore.

8. Moving to a new machine

When relocating the pipeline, these are the settings to review, roughly in the order they will bite: