Self-Configuration as an Engineering Principle

Configuration is part of the model

When two segmentation systems are compared, the architecture name is only one part of the procedure. Spacing, resampling, intensity handling, patch size, sampling strategy, augmentation, training budget, post-processing, ensembling, and the split can all affect the result. A more elaborate network can appear to win because it received a better configuration, while a simple network can appear weak because its input scale or training schedule did not match the dataset.

Self-configuration addresses this engineering bottleneck. Rather than asking each user to choose every preprocessing and training setting by hand, a self-configuring system can inspect declared properties of a dataset and derive a reproducible recipe. Voxel spacing, image dimensions, class balance, and available memory may influence choices about representation, patching, network configuration, and optimisation. This is not a claim that every possible choice can be automated or that one recipe is optimal for every task. It is a principle: make configuration explicit, systematic, and tied to the data instead of allowing undocumented hand-tuning to become a hidden source of performance.

nnU-Net is a dated illustration of the principle

The 2021 nnU-Net paper (PMID 33288961) is a useful dated illustration of this strategy. Its importance for this chapter is not a permanent claim that one implementation wins every future benchmark. It is the example of a conventional U-Net family being embedded in a broader procedure that configures preprocessing, spatial representation, training, and post-processing from the dataset rather than treating architecture as the only research variable.

The lesson to carry forward is methodological. Before attributing an observed margin to a new architecture, establish that the comparison used compatible input geometry, preprocessing, data splits, training budgets, post-processing, and evaluation definitions. If an implementation has optional ensembling or other modes, those modes are part of the system being compared. A small margin that does not survive matched procedures, repeated fits, or an appropriate test setting is weak evidence for architectural superiority. The comparison should therefore evaluate frozen configured procedures: before examining the evaluation cases, freeze preprocessing, input geometry, training procedure and budget, model or recipe selection state, ensembling, post-processing, and any applicable thresholding. A margin can support an architecture attribution only when it is interpreted at a matched test setting, with its uncertainty reported and against a prespecified practically relevant margin for the stated task. This does not establish a universal architecture-versus-configuration ranking, and there is no universal cutoff that makes a margin small.

Tool names are dated examples, not the engineering rule

An automatic segmentation tool can provide many anatomical masks, making region generation a reusable input to later measurements. This is an illustration of the infrastructure lesson, not a claim that any particular tool’s structure count, supported modalities, release, or performance will persist. Named tools, release facts, and scoped results belong in the dated companion Web, where they can be reverified rather than carrying the stable argument.

The infrastructure consequence remains even when the tool changes. Automatic masks still need an input contract, a geometry check, a reference or task-aware evaluation, and a decision about which errors are acceptable downstream. Cheap mask production can increase the number of measurements exposed to a boundary error; it does not turn a model output into ground truth.

Compare complete procedures before crediting architecture

An implementation framework can provide resources for constructing medical-imaging pipelines, but a framework name is not an evaluation result. Whether a pipeline is built from a framework, a self-configuring system, or custom code, the comparison should identify the data contract and every fitted or selected step. The practical question is whether the proposed change adds information or improves a controlled procedure, not whether it adds a more impressive model label. Current framework names and feature rosters belong in the companion Web rather than in this stable claim.

This also keeps current tools in their proper place. A model or framework can be valuable in a dated experiment and still be replaced, reconfigured, or outperformed under a different task, modality, or split. The durable engineering habit is to make configuration auditable and to test the whole procedure under the conditions represented by the claim. The next section applies the same discipline one stage earlier, to the reconstruction that creates the image on which the model operates.