Validation

Validation

Use this skill for the narrow slice that sits beyond the normal dev loop:

• debugging runtime behavior
• inspecting logs after source, artifact, or daemon changes
• validating whether a claim is benchmark-grade or still provisional
• triaging whether a behavior is a platform truth, a family quirk, or a likely bug

Do not use this skill for the common implementation path. The default loop still lives in AGENTS.md, MEMORY.md, and docs/dev-harness.md.

For real LTX-2.3 fidelity bring-up and stage-local smoke debugging, use the dedicated ltx-fidelity-debugging skill instead of stretching this generic validation overlay.

Default workflow

1. Run the repo harness first:
   • uv run python scripts/dev.py verify
   • uv run python scripts/dev.py logs --tail 120
2. Inspect the relevant platform docs before interpreting results.
3. When a promoted clip or showcase result depends on semantic correctness, run scripts/gemini_describe_video.py as an automated semantic cross-check and keep the parsed XML review with the receipt.
4. Distinguish between:
   • implementation bug
   • missing benchmark evidence
   • stale docs
   • still-open architecture question
5. If the result is still uncertain, downgrade the claim instead of over-stating it.

What to load

• For benchmark strength and freeze criteria:
  • docs/benchmark-matrix.md
  • docs/research/09-open-questions-and-validation-plan.md
• For runtime and scheduler interpretation:
  • docs/technical-design.md
  • docs/research/05-optimization-playbook.md
• For LTX-specific runtime pressure:
  • docs/research/07-ltx-integration-seams.md

Validation rules

• Prefer measured local evidence over inferred explanations.
• Separate model behavior, output-path behavior, and harness behavior.
• Treat logs as evidence, not decoration.
• Do not promote a result to a stable claim if it still depends on one machine, one family, or one narrow path.