Pipelines, training, and results

Run a pipeline safely#

1. Create the task query

   Select the verified dataset and provide a precise instruction describing the target, task type, important metric, and constraints.

2. Track the pinned backend

   Choose an ML backend explicitly only at pipeline creation. Clones, fine-tunes, reruns, and later model versions inherit the applicable source profile; read each model version’s ml_backend_profile instead of assuming the current user default.

3. Review the generated resources

   Confirm architecture, transforms, optimizer, loss, metrics, and training configuration before execution.

4. Start one run

   Use the task-run endpoint once. A queued response is accepted work, not a failure that should be resubmitted.

5. Follow durable state

   Poll task progress and results until a terminal state. WebSocket events are optional live notifications and are not replayed after disconnect.

6. Recover deliberately

   Use checkpoint or evaluation-only recovery when available. For the narrow failed-first-version case where checkpoint lookup confirms no checkpoint, a REST rerun or MCP run_again may restart the same v1 from scratch; require fresh_retry.reason=first_version_missing_checkpoint and resume=null before presenting that outcome.

7. Review the operating point

   For binary results, the compact configured-metric panel uses the default 0.5 threshold. Validation-selected and test-sample-optimal values remain in detailed Result Analysis, while threshold-independent metrics must be interpreted separately.

Discover and verify segmentation architectures#

• EoMT DINOv2 Small 640, Base 640, and Large 640 target panoptic segmentation.
• RF-DETR Segmentation Nano, Small, Medium, and Large target instance segmentation.
• RTMDet-Ins Tiny, Small, Medium, and Large target instance segmentation.

1. Prefer automatic selection

   Describe whether the workflow needs semantic, instance, or panoptic segmentation and omit an explicit architecture unless the integration has a verified reason to pin one.

2. List catalog entries

   Use the REST architecture knowledgebase or the equivalent MCP list tool to discover model keys and capability metadata. New catalog families include EoMT DINOv2, RF-DETR Segmentation, and RTMDet-Ins variants.

3. Inspect task-scoped alternatives

   After planning, query the task-scoped architecture knowledgebase with the generated architecture resource id. Treat its related models as the relevant replacement set for that pipeline.

4. Verify the selected runtime

   Check the catalog capability, task fit, planned runtime contract, validation warnings, and support on the selected ML backend. Catalog discovery alone does not prove that every backend can execute the model.

5. Pin or swap before execution

   Use an exact catalog model_key only after those checks. Architecture swaps are for a not-started pipeline; clone a pipeline that has already run before changing its architecture.

When a run cannot proceed#

• Inspect dataset readiness and required splits.
• Check queue state before submitting another run.
• For a typed GPU-memory failure, apply a positive recommended batch size before retrying. A value of zero means batch size one is still too large, so reduce model or input size; optional diagnostic fields may be absent.
• Read failure details and clone diagnostics before changing the architecture or input size.

Pipeline contracts and recipes#