Inspected the ve2e root training dataset/data module and the standalone data/ vxData pipeline without changing the ve2e repository.
Traced patient resource identifiers through vxData queries, patient filtering, study and modality selection, mask generation, training-table construction, artifact materialization, VxprosDataset, preprocessing, preload modes, and DataLoader batching.
Identified that no current public function accepts patient IDs and returns an inference loader. The standalone pipeline has a debug-only patient filter, while the root data module resolves only artifact IDs or local CSVs.
Recommended a narrow build_inference_dataloader-style boundary which uses the checkpoint data config, returns resolution diagnostics, creates neutral inference rows, and instantiates the production clinical dataset directly.
Lessons Learned: Pitfalls
The knowledge page vxdata-sdk-and-schema-model.md documents SDK 2.1.0, while ve2e now pins SDK 3.0.0. It was useful conceptually but cannot be treated as an exact current API reference.
The standalone data/ pixi environment is Linux-only, so its installed SDK signatures could not be introspected on the macOS inspection host. Repository call sites and lockfiles were used instead.
debug_patient_ids sounds like the desired selection input, but filtering occurs only after the full source-wide query and after 4D DWI preparation, so it is not an efficient production patient resolver.
Lessons Learned: Improvements
Add a durable inverse-workstream guide that distinguishes the standalone vxData selection pipeline from root ve2e.data, and documents the current gap between artifact creation and disk/RAM preloading.
Refresh the infrastructure SDK guide for vxdata-sdk 3.x, including exact query and materialization signatures.
Document the inference-table minimum schema and the dataset batch contract: (inputs, label, metadata), with inputs shaped (B, C, D, H, W) for volume mode.
