/cdf-video-data-augmentation

name: cdf-video-data-augmentation
description: Run the CDF Video Data Augmentation Airflow workflow on Kubernetes or OSMO to create Cosmos video-to-video variants and auto-label both source and generated videos. Use for VDA payload authoring, preflight, execution, monitoring, output verification, or result retrieval. OSMO requires external endpoints. Standalone augmentation or auto-labeling configuration belongs to the respective component skill. Not for retrieval-driven CDF pipelines or image-to-video event generation.
license: CC-BY-4.0 AND Apache-2.0
metadata:
  owner: NVIDIA
  service: cosmos-data-factory
  version: "1.0.0"

Run CDF Video Data Augmentation

Run the existing Video Data Augmentation workflow end to end. Read the [getting-started guide](../../docs/video-data-augmentation/getting-started.md) and [payload guide](../../docs/video-data-augmentation/payload-guide.md) before authoring a payload. Treat the checked-in DAG, payload model, and platform manifest as the source of truth if the docs and implementation differ.

Use the bundled references progressively:

• Read [setup-and-preflight.md](references/setup-and-preflight.md) when preparing input or checking

a controller/compute environment.

• Read [payload-contract.md](references/payload-contract.md) before rendering or changing a

payload.

• Read [airflow-direct-api.md](references/airflow-direct-api.md) before triggering or monitoring a

run through the API.

• Read [outputs.md](references/outputs.md) before downloading or interpreting artifacts.
• Read [troubleshooting.md](references/troubleshooting.md) when a check or run fails, or when the

user asks to stop a run.

The workflow prepares source videos, runs the full auto-labeling and training-export chain on the source branch, generates Cosmos Transfer variants, runs the same chain on passing generated videos, validates storage outputs, and shuts down run-owned services. It does not produce one combined final dataset manifest.

Component details

Distinguish the configuration layers before authoring a payload:

| Requested work | Route to | |---|---| | Augmentation container input/config YAML, model parameters, distributions, or evaluator settings | `cdf-augmentation` | | Auto-labeling container input/config, stage options, prompts, or question banks | `cdf-auto-labeling` | | Existing VDA DagRun `conf.payload`, mapping supported component options into it, triggering, monitoring, or results | This skill and its workflow references | | Kubernetes/Airflow controller setup, environment audit, connections, or deployment readiness | `cdf-orchestration-setup` | | A requested new Kubernetes DAG with added, removed, or reordered stages that no existing DAG covers; or DAG parity review against a specification | `cdf-orchestration-write-dag` |

Consult the component skill before authoring or changing its container configuration, even when that configuration is used inside a full VDA run. Component YAML and the Airflow trigger payload are different contracts; do not put an entire container config directly into `conf.payload`. Changing supported payload values alone does not require a new DAG. Route structural changes to the DAG-authoring skill only when requested; setup/deployment remains separately authorized.

When the request needs component configuration or diagnosis, consult that component's documentation, and do not invent keys or values. The links below are pinned to the latest `main` commit of each component repository as of 2026-10-20; a component skill installed separately may describe a different version.

| Component | Covers | Documentation at that commit | |---|---|---| | `cdf-augmentation` | Cosmos configuration, distributions, captioning, evaluator setup, and component errors | [`cdf-augmentation` skill][augmentation-skill] | | `cdf-auto-labeling` | Stage configuration, prompts/question banks, stage outputs, and component errors | [`cdf-auto-labeling` skill][auto-labeling-skill] |

[augmentation-skill]: https://github.com/NVIDIA/cdf-augmentation/tree/73c861c43a4952b6060c87265bf39f4abc48199a/skills/cdf-augmentation [auto-labeling-skill]: https://github.com/NVIDIA/cdf-auto-labeling/tree/6c75c76c52a6c76c3866a38d30885e11123b0981/skills/cdf-auto-labeling

Use only documentation at these commits; do not substitute a moving branch or another version. If the documentation is inaccessible, report the exact reference and continue only work supported by the local workflow guidance; do not invent component settings.

The orchestration routes are sibling skills in this repository: [`cdf-orchestration-setup`](../cdf-orchestration-setup/SKILL.md) for environment preparation and Airflow controller setup, and [`cdf-orchestration-write-dag`](../cdf-orchestration-write-dag/SKILL.md) for custom DAG composition and specification parity review.

The pinned component skills own container schemas, model options, prompt authoring, and evaluator internals; use their referenced documentation rather than maintaining local copies. This skill owns the VDA trigger contract and the constraints imposed by its checked-in DAG. Preserve those overrides in [payload-contract.md](references/payload-contract.md); component capabilities do not automatically become supported DAG options. Keep execution through Airflow for a workflow request. If a pinned component contract differs from the deployed image or DAG integration, report the version mismatch before proposing settings; do not silently update an image or bypass an override. Routine payload rendering, status checks, and GPU sizing do not require loading both components.

Select the execution target

| Target | DAG ID | Service modes | |---|---|---| | Kubernetes | `video_data_augmentation_dag_k8s` | Internal or external inference services | | OSMO | `video_data_augmentation_dag_osmo` | External inference and evaluator endpoints only |

List the DAGs Airflow actually loaded and check import errors before selecting a DAG. A platform D