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.
Start a fresh conversation. Replace the highlighted placeholders.
Use tao-run-dinov3-ssl-deft for one grit-score DINOv3 SSL DEFT round over [immutable unlabeled target/source pools], [original checkpoint], [fixed-encoder embeddings/contracts], [sampling budget] and [durable run directory] on [selected platform]. Verify the resolved release Data Services image contains reviewed modules and passes packaged validation, including post-rc-90/#59 fixes. Use its native allocation/launch lifecycle; prepare the packaged recipe, validate, GPU-preflight and plan inside that runtime. Present all six approval-contract items from observed evidence, including benchmark isolation if declared; ask for launch approval only when complete. Run the DS-owned controller after approval, never edit locks/state, monitor to terminal status and return checkpoint/metrics/report/stop reason. Every candidate starts from the immutable original checkpoint.
Required inputs
[immutable unlabeled target/source pools]
[original checkpoint]
[fixed-encoder embeddings/contracts]
[sampling budget]
[durable run directory]
[selected platform]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: tao-run-dinov3-ssl-deftdescription: 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.0compatibility: 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 Writetags: - 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
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:
DS ships no multi-task scorer, and validate rejects the recipe's
placeholder. Read architecture.md for the
scientific meaning, task weighting, and stopping policy.
Read 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.
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:
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 when declaring a
held-out benchmark (isolation),
or configuring custom scoring/evaluation, indexed retrieval, or resource policies.
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.
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).
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.
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>
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.