ML Run Provenance for Openclaw

ML Run Provenance creates and validates self-describing machine learning run metadata at initialization so every execution has traceable intent, inputs, code identity, and lineage.

antreasantoniou
v1.0.0
Sep 6, 2026
0
264
0

Install & Download

1. ClawHub CLI

The fastest way to install a skill directly from the registry.

npx clawhub@latest install ml-run-provenance

2. Manual Installation

Copy the skill folder to one of these locations

Global
~/.openclaw/skills/
Workspace
<project>/skills/

Priority: Workspace > Local > Bundled

3. Prompt Installation

Copy this prompt to OpenClaw to install it automatically.

Help me install ml-run-provenance using Clawhub. If Clawhub is not installed, install it first (npm i -g clawhub).

Prefer to download?

Get the raw skill files in a ZIP archive.

What is ML Run Provenance?

ML Run Provenance is a protocol and local JSON validator for recording the context behind machine learning experiments. It captures run identity, campaign intent, dataset and configuration identity, repository state, execution attempts, resume lineage, and the limits of available evidence alongside checkpoints and metrics.

The skill is designed for Openclaw Skills workflows that need trustworthy experiment metadata without pretending to provide reproducibility automatically. It does not replace a trainer, tracker adapter, backfill service, or provider integration; instead, it defines the contract and validation practices project-specific integrations should implement and test.

ML Run Provenance Use Cases

  • Establish a consistent naming and metadata contract for a new ML training project.
  • Attach approved run context before the first logged training step.
  • Audit existing campaigns for missing intent, code, data, configuration, or seed information.
  • Distinguish original run birth facts from metadata reconstructed during a later backfill.
  • Track resume attempts with current code, configuration, and checkpoint identities while preserving original provenance.
  • Investigate why a run exists, which proposal authorized it, and what evidence supports its recorded metadata.
  • Validate JSON metadata locally before expensive training campaigns or tracker uploads.
  • Design progress and observability records that separate liveness, output growth, failures, and completion.

How ML Run Provenance Works

  1. Define the metadata contract with stable identity fields, campaign intent, code and data identity, execution inputs, evidence limits, and privacy boundaries.
  2. Implement a project-local run_context.py as the source of truth for approved run-name patterns and curated metadata.
  3. Run a pure classify(run_name) function that returns structured context; unknown names produce explicit unknown values and diagnostics instead of guessed classifications.
  4. Use an idempotent attach_run_context(logger, context, resolved_config) adapter to merge only owned fields and tags while preserving unrelated user notes.
  5. Classify the run and attach metadata during logger initialization, before the first training step, while capturing code and configuration identity once per execution attempt.
  6. For resumed runs, read tracker state, preserve original birth facts, and append a new attempt containing current code, configuration, and checkpoint identities.
  7. If backfill is authorized, preview an exact diff, label reconstructed fields and their sources, and apply only approved changes to exact run IDs.
  8. Validate the local record, then verify actual artifacts, tracker readback, timestamps, hashes, permissions, and attachment behavior because schema validation alone cannot prove reproducibility.
  9. Report implemented components, checks performed, verified fields, unresolved gaps, and exact artifact paths at handoff.

ML Run Provenance Setup

  1. Read the metadata contract at references/metadata-contract.md and decide which fields are safe to expose across the project and tracker boundary.
  2. Agree on run naming, metadata ownership, privacy rules, and the distinction between human-readable names and unique execution IDs.
  3. Implement the project-local classifier and logger adapter only where integration is requested; keep classification pure and attachment idempotent.
  4. Create a metadata JSON record and validate its shape locally with the installed skill path:
python3 <installed-skill>/scripts/validate_metadata.py <record.json>
  1. Use strict validation when core provenance fields must be non-null:
python3 <installed-skill>/scripts/validate_metadata.py --strict <record.json>
  1. Add table-driven classifier tests, preview authorized run names, test unknown-name diagnostics, and run an authorized short training job before a larger campaign.
  2. Read back local and remote fields at initialization and resume to confirm provider-specific behavior; do not assume initialization metadata is reapplied automatically on resume.
  3. No package installation, paid run, provider upload, tracker write, deletion, or global migration is implied by invoking this Openclaw Skills workflow.

ML Run Provenance Data Schema & Taxonomy

The record is organized around five metadata groups:

Group Representative fields Purpose
Identity run_id, created_at, phase, variant, modality, seed Identifies the execution and its campaign context.
Intent dataset, reason, notes Explains what the run is for and links proposals, configurations, prior results, and parent campaigns.
Code repo_url, branch, commit, dirty, commit_url, code_snapshot Records the source identity and whether uncommitted work was present.
Execution inputs config, data, preprocessing and tokenizer details Captures resolved configuration, data identity, and transformation inputs.
Evidence metadata_origin, recorded_at, missing, tags Distinguishes birth metadata from backfill and documents uncertainty and classification labels.

Additional organization rules:

  • Use a stable unique run_id; phase, variant, and seed naming alone do not distinguish retries.
  • Represent unknown facts as null and list them in missing; never invent historical values.
  • Hashes should identify immutable artifacts and specify their algorithms, not merely record filenames.
  • Resume lineage preserves original birth facts and adds attempt-level code, configuration, and checkpoint identities.
  • Backfilled fields must identify that they were reconstructed and cite their evidence source.
  • Keep private repository URLs, internal paths, dataset samples, secrets, and resolved secret configuration behind an appropriate disclosure boundary; use local identifiers or nulls where necessary.
  • Generated or maintained project artifacts may include run_context.py, classifier tests, metadata JSON records, validation output, backfill diff previews, and progress or handoff reports.
  • Local validation confirms shape and consistency only; it does not prove tracker attachment, artifact accessibility, timestamp accuracy, permissions, or that a recorded commit generated the result.

ML Run Provenance Advanced Features

  • Pure, table-driven run-name classification with explicit diagnostics for unknown patterns.
  • Idempotent metadata attachment that merges owned fields and tags without overwriting unrelated notes.
  • Resume-aware lineage that separates original run birth metadata from later execution attempts.
  • Preview-first backfill workflows with exact run IDs, authorized fields, reconstruction labels, and source tracking.
  • Strict local validation for required provenance fields and ordinary validation for shape and consistency checks.
  • Privacy-aware provenance using local identifiers, null values, redaction, and artifact hashes at the disclosure boundary.
  • Progress observability that records stage, current and total work, rate, ETA, elapsed time, last successful operation, outputs, checkpoints, failures, and completion separately.
  • Evidence-aware handoff reporting that clearly distinguishes the protocol, classifier, adapter, backfill tooling, performed checks, and unresolved gaps.
  • Openclaw Skills compatibility for disciplined ML metadata workflows without requiring a private repository, trainer integration, or observability stack.

SKILL.md


Loading

Related Openclaw Skills

METADATA

Github Stars: 0
forks: 0

Featured*