Architecture
How the project is put together: the external context, the two segmentations pipelines, the component responsibilities, and the data and label contract that everything else is built on.
System Design
External context, the two-pipeline decomposition, component responsibilities and the
configuration layer that drives experiments.
Data Flow
Raw CT volumes to training tensors to prediction artifacts — the label semantics and
the exact transform chain that produces each output key.
Dependencies
The runtime stack, how it is pinned with
uv, the externally supplied metrics
package, hardware assumptions and the module import graph.
1. Why architecture deserves its own section
On the surface this is “a segmentation repo”. In practice three independent structures are layered on top of one another, and untangling them is the main cost of onboarding:
| Layer | What it decides | Where it lives |
|---|---|---|
| Data contract | What a training sample is: which labels are valid, how sparse foreground is handled, and which keys a batch exposes to the model and loss. | src/approach/unetbasic/data/dataset.py |
| Modelling | The network, the auxiliary prediction heads, and the loss composition that trades off voxel accuracy against topological correctness. | models/, utils/losses.py |
| Experiment configuration | Which of the above is active, with what weights, patch size, augmentation set and schedule. | configs/ + src/approach/*/configs/experiments/ |
The pages in this section walk each layer in turn. The single most useful thing to understand
first is the data and label flow: almost every naming decision
elsewhere in the codebase — label_fg_bin, label_valid,
distance_unsigned — is explained by the transform chain documented there.