mlcommons / mlcommons/mlcube

Proposal: optional audit manifest for reproducible MLCube runs

Open
#367 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
160
Forks
31
PR merge metrics
No merged PRs in 30d

Description

Proposal

Would MLCube be open to an optional run audit manifest for MLCube executions?

MLCube already focuses on portability and reproducibility. A small sidecar manifest could make benchmark runs easier to review, compare, cite, and publish safely without changing the core MLCube task interface.

Suggested manifest shape

{
  "schema_version": "mlcube.run_audit.v1",
  "mlcube_task": "run",
  "runner": "docker",
  "image": "...",
  "mlcube_config_hash": "...",
  "benchmark": "...",
  "dataset_refs": [
    {
      "source_id": "...",
      "kind": "dataset",
      "provenance": "...",
      "redaction_status": "safe_for_public_log"
    }
  ],
  "result_paths": ["..."],
  "provenance": {
    "repo": "...",
    "commit": "...",
    "created_at": "..."
  },
  "claim_status": "diagnostic",
  "redaction_status": "safe_for_public_log"
}

Why this may help

  • makes it clearer which MLCube/config/image produced a benchmark result
  • preserves provenance such as runner, image, config hash, repo commit, dataset refs, and result paths
  • separates diagnostic/internal runs from results intended for public reports or model cards
  • gives downstream benchmark users a standard place for audit-safe metadata
  • avoids storing raw secrets, private paths, tokens, or full sensitive arguments in public logs

Scope I would keep small

If maintainers think this is useful, I can prepare a follow-up PR that:

  • documents an optional manifest schema
  • adds a minimal example manifest under docs/examples or docs/getting-started
  • keeps the manifest opt-in and backward compatible
  • does not change existing runner behavior by default
  • does not add external service dependencies

This is motivated by work in the AANA project around audit-safe AI evaluation artifacts, but the contribution would be generic to MLCube and would not require AANA as a dependency.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing docs/examples and docs/getting-started structure, then check how MLCube currently documents runs, configuration, and reproducibility. Confirm the optional manifest scope with maintainers; done means an agreed schema and minimal example are documented without changing default runner behavior or adding dependencies.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.