Paidf Augmentation

PAIDF Augmentation Pipeline Skill

Remote-API pipeline for captioning, generating, and evaluating augmented camera data. Models are configured as HTTP endpoints; no local model weights are included.

Purpose

Use it to select a supported generation mode, author and validate PipelineConfig YAML, configure captioning/evaluators, and run the paidf-augmentation:1.2.0 container. It covers Cosmos Transfer/Predict, Cosmos3 WSM controls, image editing, image-to-video, BYOM endpoints, and quality gates.

Do not use this skill for training or fine-tuning models, deploying clusters or NIM endpoints, or unrelated application/database development.

Prerequisites

Inputs

Resolve each value in this precedence order: state file → explicit prompt arguments → agent context → user prompt. Ask the user only for what remains unresolved.

BYOM model: endpoints, adapters, roles

Each endpoints: list entry declares role, url, wire model, and optional id, adapter, api_key_env, and timeout. Roles are vlm, llm, image_edit, video_transfer, video_predict, image2video, and evaluator. augmentation.model.name resolves by endpoint id, then role, then the known model-name mapping. Adapter contracts and full fields are in configuration-schema.md.

Supported Models

When the user hasn't specified a model, choose from their input type and goal:

Key rule: use Cosmos Transfer for video scene changes, Cosmos Predict for new/continued video, image edit for still edits, and image-to-video to animate a frame. For Cosmos3 WSM, set data[].inputs.controls.wsm. Config selection details are in config-decision-tree.md.

All models run via remote HTTP through one BaseExecutor; there is no local torchrun and no executor_type field.

Canonical Workflow

Follow this ordered decision tree; open the linked references only for the selected mode's details.

Config Correction Budget

config_attempts counts YAML versions, not validation or preflight calls. Keep it across the whole workflow and never reset it.

1. Set it to 1 after initial authoring.
2. On a correctable error, if it is already 3, STOP and report the error. Otherwise increment it once and make one correction pass containing all currently reported YAML fixes.
3. Validate and preflight that edited version without another increment. Repeat rule 2 only if a later check finds another correctable YAML error.

STEP 0 — Mandatory Entry Gate

Execute this gate before every other step:

• Scope gate: if the request asks for training, fine-tuning, cluster/NIM deployment, or unrelated development, decline it and STOP.
• Input gate: resolve values using Inputs. If required values remain unresolved, request only those values and STOP until they are supplied.
• Proceed only when both gates pass and the input type and augmentation goal are known.

1. Select the model from Supported Models using that input type and goal.
2. Author the YAML in this order: data, endpoints, captioning, augmentation, evaluators, pipeline, then data_processing. Omit optional sections rather than creating placeholders. Set config_attempts = 1 (config attempt 1 of 3).
3. Branch on the requested outcome:
   • Configuration only or “do not execute”: do not build, launch, run preflight, or infer. A trusted runtime is an already-running container whose recorded immutable image ID/digest, checkout commit, and config mounts satisfy step 4. If validation was explicitly requested and such a runtime exists, run only the validation command and apply step 5's failure rules. Return the config (mark it unvalidated if validation was not run) and STOP.
   • Inference/run requested: proceed to step 4.
4. Prepare the runtime in these verifiable sub-steps: a. Obtain EXPECTED_RELEASE_REF from the user as a release-owner-approved full commit or retrieve it from the verified release manifest. b. Verify the Git working tree is clean. c. Verify HEAD matches EXPECTED_RELEASE_REF. If a release tag selected the revision, verify the tag first, then compare its resolved full commit. d. Build the image and capture its immutable sha256: image ID, or obtain a verified registry digest. e. Create the paidf Docker bridge if needed and attach local services. f. Launch the container using the recorded image ID, the paidf network, required volume mounts, --entrypoint /bin/bash, and only the endpoint key variables named by api_key_env plus the scoped storage credential variables required for the configured remote media. If any sub-step fails, STOP and report the exact failure and relevant remediation: clean a dirty tree, supply the approved revision, resolve a revision mismatch, check the Docker daemon/build, fix network setup, or fix the container launch. Do not continue with a partial runtime.
5. Inside the container, run the validation-only command in Usage Step 2 and classify its result while preserving config_attempts (current config attempt N of 3):
   • Success: if no external Cosmos evaluator is enabled, proceed directly to step 7. If one is enabled, proceed to step 6.
   • Editable YAML/schema error: when required endpoint URL/model details are known, apply the Config Correction Budget rule, then rerun validation on that YAML version.
   • Infrastructure/unknown input: for missing endpoint details, credentials, DNS, connectivity, or unhealthy services, do not edit speculatively. STOP and report the error or ask for the missing endpoint details.
6. With external Cosmos evaluation enabled, preserve config_attempts (current config attempt N of 3) and run its hard preflight gate before captioning/generation by querying /health, /checkers, and /dependency-graph:
   • Pass: require /health.status == "healthy"; require every configured checks[].name to exactly equal one string in the top-level checkers array returned by /checkers and one key in the top-level checkers object returned by /dependency-graph. Do not use substring, alias, or nested-field matching. Then proceed to step 7.
   • Config error: only a 4xx response from /checkers or /dependency-graph whose body explicitly identifies a configured checker name or invalid config field qualifies. Apply the Config Correction Budget rule, then return to step 5; revalidation does not increment the counter.
   • Infrastructure failure: any timeout, network/DNS error, 5xx response, /health failure, unhealthy service, or missing deployed checker stops the workflow before generation. Create no candidate and report the root cause.
7. Enter inference only after step 5 succeeds and, when external evaluation is enabled, step 6 passes. Run a candidate loop bounded to pipeline.retry + 1 candidates (retry defaults to 1, so the default maximum is 2). Resolve the base seed once before the first candidate as defined in Inputs; retry n uses base_seed + n:
   • Generate a candidate and run its configured evaluators.
   • On pass, accept it and exit the loop.
   • On quality failure with attempts remaining, set the next seed to base_seed + next_retry_number. If regenerate_caption_on_retry: true, regenerate the caption next; then generate the replacement. If false, generate the replacement immediately.
   • On exhausted quality retries, fail evaluation and exit the loop.
   • On a service/contract failure, stop on the current candidate without generating another. For external Cosmos evaluation, this means a submission, polling, or discovery failure; a failed execution; a missing or skipped result; or an invalid gating contract without a literal top-level boolean passed. With pipeline.evaluation.strict: true (the default), apply retain_failures: its default true retains video, caption, metadata, and evaluation outputs for inspection; explicit false deletes them. With strict: false, retain the files and report the evaluator failure without failing the sample.
     • If provider metadata contains error_code: ambiguous_post, preserve the retained candidate, do not resubmit automatically, STOP, and defer to operator recovery. Follow the ambiguous-POST recovery flow.