An agent-native platform for ML experiment tracking and lineage/knowledge.
Every existing tracker is human-dashboard-first: great at scalars-over-time, silent about why a run exists and how it relates to the others. ml-party treats a run's abstract, typed relationships, and reproducibility contract as first-class data — a durable, queryable lab notebook that agents write (over MCP) and query, and that humans read live (CLI + web viewer). It is also a full local tracker: metrics, artifacts, checkpoints, all stored locally; mirroring to W&B/MLflow is a future optional adapter, not the product.
Core ideas:
- The write contract is the product.
run_startpre-registers intent (title, purpose, hypothesis, full parameters) and auto-captures the repro tuple (source snapshot, env lock, invocation, hardware, outer-git provenance).run_finalizerefuses without method + result/verdict + reproduce — refusals are machine-readable{missing, invalid}. Failures are knowledge (run_fail); silent deaths becomeabandoned. - Internal git per experiment. Every run snapshots the actually-running
source (allowlisted, size-capped, secrets denied) as a commit in a bare
internal repo. A run references a commit — a launch-arg sweep is many
runs on one commit, distinguished by mandatory
parameters. Declaredderives_fromlineage becomes the commit's parent; every run gets its own ref (no races). - A knowledge graph over it. Typed nodes (
project / experiment / run / note), a controlled edge vocabulary (derives-from,supersedes,refutes, …), hybrid BM25(+optional embeddings)+graph retrieval that downranks superseded/refuted beliefs. Knowledge is append-only; correction is an edge. - Boards: agents author whole views. An agent logs a self-contained HTML page as an artifact and the UI renders it sandboxed — comparison dashboards, demo galleries, live reports that fetch current data from the read-only API at view time (boards guide).
- Run control through registered templates. Users register shell
templates with typed placeholders — the allowlist; agents invoke them
with validated, shell-quoted values (never commands), and every
invocation is recorded in the graph, edged to the run it controlled.
Restart is never a mutation: a new run,
derives-fromthe old (run-control guide). - Local-first, remote-ready. Writers always write a local spool store;
spool-and-flush sync ships runs to a served store over three idempotent
streams (remote-tracking guide). Multi-user auth (roles,
per-user tokens, UI login) activates with the first
mlp user add(deployment guide).
Quickstart
Requirements: Linux or macOS (Windows via WSL — the store relies on POSIX file locking) and Python ≥ 3.11. The web UI ships prebuilt in the wheel; nothing to compile.
pip install mlparty
mlp init --root .mlparty # create a store (+ MCP registration)
python -m mlparty.demo & # a real run: contract + live metrics
mlp ui # → http://127.0.0.1:7327
Open the browser: the demo run is streaming its loss curve live. It went through the full lifecycle a real training does — pre-registered with purpose/hypothesis/parameters, source snapshotted, metrics streamed, then finalized with a verdict. Click into it: Overview | Metrics | Artifacts | Code.
Let an agent drive it
mlp init registered the MCP server in ./.mcp.json, so agents started in
this project (Claude Code and compatible clients) pick it up automatically —
approve it once when asked. The server is self-teaching: the full
tracking workflow rides in its MCP instructions, so "use ml-party for this
run" is all an agent needs to hear. Other setups: mlp connect registers
an existing store into another project; mlp mcp-config prints the snippet
for other MCP clients.
Instrument a training script
The agent brackets the run over MCP and launches your script with
ML_PARTY_STORE/ML_PARTY_RUN set; the script attaches as the second
writer:
import mlparty
h = mlparty.attach() # env-var handshake (inert without ML_PARTY_RUN)
h.log_metric("loss", loss, step=step) # streams to the live view
h.log_artifact("ckpt/best.pt")
h.finalize(method=..., result={"summary": ..., "verdict": "confirmed",
"metrics": {"wer": 0.048}},
reproduce="python train.py --lr 1e-3")
# unhandled exceptions auto-fail the run with the traceback
CLI mirror: mlp status / runs / show <ref> / tail <run> / query "…" / diff <a> <b> / janitor / rebuild-index.
Web viewer
mlp ui serves a read-only SPA: experiments → runs → tabbed run pages with
live SSE metric dashboards, a finder-style artifact browser (image/audio/
video viewers, an .npy/.npz tensor slicer), agent-authored boards, the
lineage graph, search, and diff. Remote box → tunnel like TensorBoard:
ssh -L 7327:localhost:7327 <box>. For a shared server with logins and
sync ingest, see the deployment guide
and the remote-tracking guide.
From source
For development, or to run an unreleased revision — needs Node ≥ 20, since the UI bundle is built rather than downloaded:
git clone https://github.com/paul-krug/ml-party && cd ml-party
python -m venv .venv && .venv/bin/pip install -e .
(cd ui && npm install && npm run build) # web UI bundle, once
.venv/bin/python -m pytest tests/ -q
Contributions: CONTRIBUTING.md for the flow and the maintainer-only paths, AGENTS.md for conventions, SECURITY.md for the trust model.
Design
- User guide (rendered from docs/): tracking runs, the web UI, boards, run control, MCP setup & tools, remote tracking, deployment & auth.
- DESIGN.md — the living design document (ontology, contract, internal-git model, storage, surfaces, remote mode, forward design).
- AGENTS.md — conventions for agents/contributors working in this repo (incl. the doc-sync rule). Planning lives in the repo's GitHub Project, not in tracked files.
Layering: pydantic ontology → journal-first store (journal.jsonl is the
source of truth; SQLite/FTS5 is a rebuildable index) → dulwich internal-git
engine → MlParty core API → thin frontends (MCP server, mlp CLI,
in-process client, read-only HTTP+SSE for the viewer).
Status
Beta (0.x): APIs may still move between minor versions; the store format is journal-first and rebuildable, and every release migrates it forward. Licensed Apache-2.0.
Tests: .venv/bin/python -m pytest tests/ -q
Metadata
Release files for mlparty 0.2.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| mlparty-0.2.2.tar.gz | 296.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| mlparty-0.2.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 577.4 kB
Release files / mlparty-0.2.2.tar.gz
| Download URL | mlparty-0.2.2.tar.gz |
|---|---|
| Size | 296.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3f405385653a2383ae4e6d603b8f04f9d8100e2680115824d050d12d0e4b6d02
|
|
BLAKE2b-256 checksum How to use checksums |
3504b716105ae8eb0224e08e4620ef032bd851a82c30c5aaff42595abc1cd860
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 16, 2026.
Transparency logRelease files / mlparty-0.2.2-py3-none-any.whl
| Download URL | mlparty-0.2.2-py3-none-any.whl |
|---|---|
| Size | 281.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
173f1d5dd7a3623b9a21ccb1d72f274433c8b9ae3398c41c047b22a9ded394a4
|
|
BLAKE2b-256 checksum How to use checksums |
bd3f4c58e7a548eb2ab1a0d56139be199522e4c05ae5efbcdee4e0bf22d20498
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 16, 2026.
Transparency log