Track Compute runs in MLflow or Weights & Biases

What this connects

Your own experiment tracker, in one direction, and your own client does the writing. You read a finished result bundle and publish a bounded summary of it into a tracking session you already own.

The file exchange is import_compatible, with a published conformance matrix. There is no wire, SDK or endpoint compatibility with either tracking service, and Lithi never signs in to one.

Bind an exact input

Publish only from a bundle that is complete. result-manifest.json is written last and is the only complete-bundle marker; part files alone never mean the job finished.

Record the identity of what you are summarizing, so the tracking run points at one exact bundle:

"snapshot": {
  "version_id": "<the result bundle identity>",
  "content_sha256": "<the digest of those exact bytes>"
}

A tracking run whose metrics cannot be traced to a digest is a note, not a record.

Credentials

Your tracking credentials stay in your tooling. Lithi has no field for a tracking token, an API key or a workspace URL, and never receives one.

Going the other way, do not publish a Lithi credential reference, a signed download authority or anything resembling a secret into a tracking run. Those runs are usually visible to a wider group than the person who created them.

Formats and limits

Publish the bounded artifacts, not the data. Two files carry nearly everything a tracker needs:

Log the counts from failures/, abstentions/ and disagreements/ as first-class metrics. A run that reports only accepted rows reads better than it is, and hides the outcome that most needs attention.

Keep row-level logging out of the tracker. If you need a handful of examples, publish item identifiers and let the reader fetch the bundle under its own access controls.

Commit the output

Treat the tracker as a mirror, never as the record. Publish once, after the bundle is complete, and tag the run with the workflow id, the quality preset and the bundle digest.

Rubric and result authority stay with Lithi. The rubric is versioned on the Lithi side, and verification.json in the bundle is the evidence of what was checked. A metric copied into a tracker and later edited there does not change what the run proved. See what verification evidence contains.

Quality presets bound the claim you can make. Standard proves schema and deterministic validation. Verified adds independent sample verification. High assurance raises the verification rate or the number of independent checks. Custom evaluation applies your own rubric or reference set. None of them is a correctness guarantee, so label the preset beside the metric.

What is not supported

Lithi does not write to a tracking service on your behalf, and claims no compatibility with either one.

Outside the adapter:

• Automatic run creation, autologging, or a callback that publishes as your job progresses.
• Reading a rubric or a metric definition back out of a tracker to change how work is graded.
• Publishing full result rows, evidence excerpts or anything carrying customer content.
• Treating a tracker's stored number as the authority when it disagrees with the bundle.

If the bundle and your tracking run disagree, the bundle is correct. Re-read result-manifest.json, republish the summary, and mark the earlier run superseded rather than editing it.