CI Validation

tmorph validate runs the same diagnostics that populate the Problems panel interactively - see Error Messages - as a single headless command suitable for a CI pipeline gate.

Basic usage

tmorph validate checkpoints/candidate.safetensors
echo $?   # non-zero if any Error-severity diagnostic was found

A non-zero exit code always corresponds to one or more Error-severity diagnostics you can reproduce by opening the same checkpoint locally and looking at the Problems panel - CI failure and interactive investigation always agree on what's wrong, since they run the same underlying checks.

What gets checked

By default, this covers the same categories described in Error Messages: import/parse errors, adapter warnings, NaN/Inf and statistical data-quality flags, and backend/compute errors. A custom ruleset (--rules) can add project-specific checks - for example, a performance baseline regression threshold, or a required-reviewer check on a morph proposal - expressed the same way any other check is, as a pass/fail gate with a reproducible reason.

A typical pipeline step

- name: Validate candidate checkpoint
  run: tmorph validate candidate.safetensors --rules ci-rules.toml

Pairing this with Model Diff-based checks - comparing a candidate against a known-good baseline rather than validating it in isolation - is usually more informative than a standalone validation pass, since some pathologies (a values-shifted-but-still-finite regression) don't trip a pure diagnostics check but do show up clearly in a diff against a baseline.

Related resources

• Error Messages - the diagnostic categories this command checks.
• Performance Baselines - using a pinned baseline as part of a CI check.
• Batch Inspection - running validation across many checkpoints, not just one.