> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Track Compute runs in MLflow or Weights & Biases
description: >-
  Publish bounded metrics and manifest digests into your own tracking session,
  not every result row. Rubric and result authority stay with Lithi's
  verification evidence.
route: /docs/compute/integrations/mlflow-wandb
page_id: docs-compute-integrations-mlflow-wandb
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: ML engineers recording Compute evaluation runs in their own tracker
voice: D
reader_question: How do I record a Compute run in my experiment tracker without copying the data?
primary_action: Publish the metrics and digests to your tracking run
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-mlflow-wandb-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## 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:

```json
"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:

| File | What to publish from it |
| --- | --- |
| `metrics.json` | Aggregate and slice metrics, as scalars in your run |
| `verification.json` | Rubric identity, grader evidence and the independent check count |
| `provenance.json` | Input, workflow, model, schema and envelope digests |
| `result-manifest.json` | Accepted, failure and abstention counts, and the bundle digest |

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](/docs/compute/workflows/verification-evidence).

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.