tao-run-dinov3-ssl-deft v0.1.0A

Immutable. This exact content never changes and is served at /api/v1/blob/ad4647326e7a2e14.

---
name: tao-run-dinov3-ssl-deft
description: Run iterative DINOv3 SSL DEFT data selection and retraining from an unlabeled pool, using GRIT or multi-task weakness and fixed-encoder retrieval. Use for active-learning-style DINOv3 mining, not plain pretraining/fine-tuning (tao-train-dinov3) or AOI/PAS DEFT.
license: Apache-2.0
compatibility: Requires the selected platform's native launcher and a TAO Data Services image containing the DINOv3 SSL DEFT modules; no host TAO or Python data-stack installation.
metadata:
  author: NVIDIA Corporation
  version: "0.1.0"
allowed-tools: Read Bash Write
tags:
- application
- workflow
- deft
- dinov3
- ssl
---


# DINOv3 SSL DEFT

The DS-packaged Python controller owns the loop and durable state. This skill
prepares and approves its inputs; it does not implement orchestration.

## Instructions

1. Resolve the DINOv3 model using the model resolver. Choose `grit-score`
   for unlabeled target ranking; its scorer is built in. Offer
   `multi-task-round-robin` only when the user already has a score adapter
   that meets the [task scoring contract](references/adapter-contracts.md#task-scoring):
   DS ships no multi-task scorer, and `validate` rejects the recipe's
   placeholder. Read [architecture.md](references/architecture.md) for the
   scientific meaning, task weighting, and stopping policy.
2. Read [tao-container-integration.md](references/tao-container-integration.md).
   Check release readiness before offering a launch: the resolved
   `images.tao_toolkit.data_services` image must be a release build whose
   installed packages contain the reviewed DEFT modules and pass packaged
   validation. An older DS build is not sufficient. The placeholder rejection
   (step 1), the cohort checks and the canceled-run exit code 143 need a DS
   build that contains tao-data-services#59: the first DS 7.3.0 RC after
   rc-90. DS rc-90 and older accept the placeholder at `validate`, fail in
   round 1 with `Missing configured inputs: [... 'score_implementation_0']`,
   and exit 0 after a cancel. The `release/7.3.0` cherry-pick of this skill
   must bump `images.tao_toolkit.data_services` in `versions.yaml` to that RC.
   The executable profile is
   one allocated DS container; no external runner ships with this application.
   For release QA, the repository script `scripts/deft_container_handoff.py`
   runs each repository's regression tests (`--suite source`) and the shipped
   package checks (`--suite packaged`) inside the approved images; the
   packaged suite also rejects a DS image that predates #59. Run it from
   clean checkouts of the release SHAs; the default `--base-ref origin/main`
   diffs each release from its merge base. It is a QA tool, not a launcher.
3. Follow the selected platform's launch gate. For Docker, use the concrete
   allocation, preflight, and `docker exec` lifecycle in the integration
   reference. Inside that runtime, follow the preparation sequence in
   [adapter-contracts.md](references/adapter-contracts.md#prepare-fixed-mining-embeddings):
   produce source/target embeddings with the same fixed encoder, register the
   source store with its payload contract, and write the target contract.
   No additional host/model package installation is needed. Generate a packaged recipe with `init`,
   fill paths/resources, then run `validate <config>`, `preflight <config> --gpu`
   in the launch runtime, and `plan <config>`.
   Read [adapter-contracts.md](references/adapter-contracts.md) when declaring a
   held-out benchmark ([isolation](references/adapter-contracts.md#held-out-benchmark-isolation)),
   or configuring custom scoring/evaluation, indexed retrieval, or resource policies.
4. Inspect the plan and present the approval contract below. Read
   `references/skill_info.yaml:path_contract` as the input-mount checklist:
   every applicable path must be visible in the allocated container, and
   `output.run_dir` must match the platform's durable results directory.
   Skill Bank resolves image keys on the host; DS accepts explicit image
   references only and never reads this repository at runtime.
5. After approval, execute `run <config>` inside the allocated container.
   Monitor to a terminal result using the commands below. Do not modify
   controller state or locks manually.

## Approval contract

Populate these six items from preflight and the plan, not from assumptions:

- Loop: chosen strategy, maximum rounds, stops, evaluation scope and patience.
  For `multi-task-round-robin`, the user's score adapter command and its
  `implementation_files`.
- Data: immutable target/source versions, verified row/shard counts, parent
  history, storage capacity and mount locations. For any held-out benchmark,
  the identity sidecar and its declared columns, even with evaluation disabled,
  and preflight's `contracts.benchmark_isolation` (at least 1; otherwise stop)
  ([held-out benchmark isolation](references/adapter-contracts.md#held-out-benchmark-isolation)).
- Sampling: fixed target budget, resolved integer task quotas, neighbors,
  radius/floor and duplicate thresholds; index, audit, probes/depth for ANN.
- Training: passes, resolution, resources/update floor and immutable original
  checkpoint. Every candidate starts from that checkpoint, never its predecessor.
  Check the per-round update budget against LR warm-up and last-layer freeze;
  follow [short-round schedule sizing](references/adapter-contracts.md#short-round-schedule-sizing).
- Cache/output: read-only images/embeddings, any platform cache, node-local
  `TAO_LOCAL_SCRATCH`, cumulative
  locator manifests, checkpoint retention, and durable results directory.
- Monitoring: cadence, stage/round updates, retry/failure handling and final reason.

Do not request launch approval while any of these items is unknown.

## Lifecycle and monitoring

All commands below follow `python -m nvidia_tao_ds.mining.dinov3.workflow`
inside the same allocated DS runtime:

- `preflight [<config>] [--gpu]` (with the config, also checks the allocation)
- `init --recipe grit-score --output run.yaml` (or `multi-task-round-robin`,
  which needs the user's score adapter; see step 1)
- `validate <config>`, `plan <config>`, `run <config>`, `resume <config>`
- `status <run_dir> [--config <config>]`
- `logs <run_dir> <client_job_id> [--cursor <cursor>] [--config <config>]`
- `cancel <run_dir> [--config <config>]`
- `report <run_dir> [--config <config>]`
- `adopt-training <continuation_config>` only for an explicitly approved
  continuation into a new run directory.

Read the job ID from status before requesting logs. Resume takes the config
path, not the run directory. Cancellation is terminal for that run: `run` and
`resume` then exit with code 143, not 0. Use an explicit new-run continuation
when appropriate.

Keep monitoring attached until the workflow is terminal. Use the user's
cadence, otherwise about five minutes for short stages and 20–30 minutes for
long search/training stages. Report stage/round transitions, mining yield,
metrics, retries, failures, and the final stop reason. Submission is not success.
If the container has exited, use the integration reference's read-only
inspection recipe rather than attempting `docker exec` against it.

## Related Skills

- `tao-train-dinov3`: ordinary DINOv3 training without a mining loop.
- `tao-launch-workflow`, `tao-run-on-docker`, `tao-data-io`: launch and storage.
- `tao-run-deft-aoi`, `tao-run-deft-pas`: different supervised DEFT workflows.