Run ID (Experiment ID)

A Run ID is a globally unique identifier (UUID) assigned to a single execution of a training or evaluation script. This uniqueness is fundamental, ensuring every experiment—even with identical parameters—can be distinguished, retrieved, and compared.

• Primary Key Function: Acts as the immutable reference for all associated data in a tracking system.
• Format: Often a string hash (e.g., run_abc123def456) or a sequential number, but must be unique within the project scope.
• Prevents Ambiguity: Critical for collaborative environments where multiple engineers may run similar experiments concurrently.

The Run ID serves as an immutable anchor point to which all experiment metadata is permanently attached. Once created, the ID itself does not change, even if the run's associated data (like final metrics) is updated.

• Centralized Reference: All logged data—hyperparameters, metrics, artifacts (model files, visualizations), and code state—is indexed by this ID.
• Audit Trail: Enables precise historical querying (e.g., "show me all data for run xyz789").
• Lineage Foundation: The first step in establishing full data provenance and model lineage, tracing from raw data to final prediction.

A Run ID aggregates diverse, time-series, and static metadata into a single, queryable entity. This consolidation is what transforms a script execution into an analyzable experiment.

Core Metadata Categories:

• Parameters: Hyperparameters, configuration flags, and environment variables.
• Metrics: Evaluation scores (accuracy, loss, F1) logged at each epoch or step.
• System Metrics: GPU/CPU utilization, memory usage, and runtime duration.
• Artifact References: Pointers to saved model checkpoints, dataset versions, and logs.
• Contextual Data: Git commit hash, user, timestamp, and custom tags.

The primary engineering value of a Run ID is enabling experimental reproducibility. By linking code, data, and environment state, it allows any team member to precisely recreate the conditions of a past run.

• Snapshot Reference: The ID points to a complete snapshot, including the environment (library versions), data version (e.g., dataset hash), and code version (Git commit).
• Facilitates Debugging: Engineers can re-run a failed or interesting experiment (run_id=abc123) with exact parameters to diagnose issues.
• Audit Compliance: Provides a verifiable record for regulatory or internal governance requirements, proving how a model was built.

In experiment tracking systems, the Run ID is the fundamental unit for comparative analysis. Tools use IDs to fetch and contrast runs, powering dashboards and visualizations that guide model selection.

• Run Comparison: Analysts select multiple Run IDs to compare their metrics and parameters side-by-side in a table or parallel coordinates plot.
• Hyperparameter Tuning: Each trial in a hyperparameter sweep (e.g., using Optuna or Ray Tune) generates a unique Run ID, allowing the optimization algorithm to track performance across the search space.
• Model Selection: The best-performing Run ID, as determined by an objective function like validation accuracy, is typically promoted to a model registry.

A Run ID is not isolated; it integrates into broader MLOps pipelines and lifecycle stages, acting as a handoff token between development and production systems.

• Pipeline Runs: In a multi-step pipeline run, each step may have its own sub-run ID, all linked to a parent execution ID for full lineage.
• Model Registry Promotion: A Run ID associated with a trained model file can be registered, versioned, and transitioned through stages (Staging → Production).
• Deployment & Monitoring: The ID can tag a model in production, linking its predictions back to the exact experiment that created it for drift detection and performance monitoring.

MLflow generates a Universally Unique Identifier (UUID) for each run. This ID is immutable and serves as the primary key for all logged data. Key characteristics include:

• Hierarchical Organization: Runs are grouped under parent Experiment IDs, allowing logical categorization (e.g., "bert-sentiment-2025").
• Artifact URI: The Run ID is part of the path for storing model checkpoints, plots, and other artifacts (e.g., s3://mlflow-bucket/123/abcdef/artifacts/model.pkl).
• REST API Core: All operations—logging metrics, fetching parameters, or registering a model—require the Run ID as a primary argument in the Tracking Server's API.

Weights & Biases (W&B) assigns an alphanumeric Run ID (e.g., 3q7h1xzj) that is intrinsically linked to its cloud-native platform.

• Centralized Context: The ID points to a dedicated cloud page containing all run metadata, system metrics, logged console output, and visualizations.
• Project & Entity Scope: The full run path includes the entity (user/team) and project name (e.g., my-team/sentiment-model/3q7h1xzj), enabling granular access control and organization.
• Resumable Runs: The Run ID allows scripts to resume interrupted training sessions by re-initializing the run with the same ID, ensuring continuity in metric logging.

In the TensorFlow ecosystem, Run IDs are often managed via callbacks that integrate with external trackers.

• TensorBoard: The tf.keras.callbacks.TensorBoard callback automatically organizes logs under a timestamped directory (e.g., logs/fit/20250115-102030), which acts as a de facto Run ID for visualization.
• Custom Loggers: Frameworks like tf.summary.create_file_writer() use log directory paths as unique identifiers. For full experiment tracking, these paths are typically registered with a separate system (like MLflow) to generate a formal Run ID.
• Distributed Training: In multi-worker setups, a single logical Run ID must be propagated and used consistently across all workers to aggregate events correctly.

High-level frameworks automate Run ID creation and lifecycle management.

• PyTorch Lightning: Integrates directly with trackers like MLflow, W&B, and Neptune. The Trainer class automatically generates and manages a Run ID, passing it to the logger. The ID is accessible via trainer.logger.experiment.
• ClearML: Upon script execution, the ClearML agent automatically captures the environment and creates a Task with a unique ID. This Task ID functions as the Run ID, linking code, stdout, and results without requiring manual initialization in the training script.

Teams building in-house tracking often generate deterministic Run IDs to guarantee reproducibility.

• Common Strategy: Create a hash (e.g., SHA-256) of a concatenated string containing the git commit hash, dataset version, and the hyperparameter configuration (sorted).
• Benefits: This method ensures that re-running the exact same code and data produces the identical Run ID, preventing duplicate entries in the tracking database.
• Example: run_id = sha256(f"{git_sha}:{data_hash}:{json.dumps(sorted(params))}")[:12]. This ID can then be passed to a logging client or used as a directory name for artifacts.

In orchestrated workflows, Run IDs exist at multiple levels of granularity.

• Pipeline Run ID: Identifies a single execution of the entire multi-step DAG.
• Component Run ID: Each step (e.g., data preprocessing, training, evaluation) within the pipeline has its own unique execution ID, often a child of the pipeline Run ID.
• Lineage: The hierarchy (Pipeline Run ID → Component Run ID) is critical for lineage tracking, enabling engineers to trace a final model artifact back through the specific data and code versions used in each step of its creation.

The overarching discipline of systematically logging, versioning, and comparing machine learning training runs. A Run ID is the primary key within this system, linking all logged elements for a single execution.

• Core Components: Hyperparameters, metrics, code snapshots, data versions, and output artifacts.
• Primary Goal: To ensure reproducibility and facilitate iterative model development by allowing precise comparison between runs.

The persistent, versioned storage system for large, immutable outputs generated during a run, referenced by the Run ID.

• Examples: Trained model files (.pt, .h5), dataset snapshots, evaluation reports, and visualization plots.
• Function: Provides durable storage separate from metric logging, ensuring that the full output of any run identified by its Run ID can be retrieved later for deployment or analysis.

The ancillary information logged alongside core metrics and parameters for a run, all associated with its unique Run ID.

• Common Fields:
  • User: The executor of the run.
  • Timestamps: Start time, end time, and duration.
  • Version Info: Git commit hash, code snapshot.
  • System Context: Environment snapshot (Python version, library dependencies).
  • Custom Tags: User-defined labels for filtering and organization (e.g., baseline, test-ablation).

A single execution instance of a multi-step machine learning workflow (e.g., data preprocessing → training → evaluation). A pipeline run typically generates a parent Run ID that may encapsulate or link to child Run IDs for each constituent step.

• Importance: Enables lineage tracking across complex workflows, answering questions like "Which training run used which version of the processed dataset?"
• Tools: Implemented in frameworks like Kubeflow Pipelines, Apache Airflow, or Metaflow.

A centralized repository for managing the lifecycle of trained models. A model entry in a registry is fundamentally linked to the Run ID that produced it.

• Key Functions:
  • Versioning: Track different model iterations.
  • Stage Management: Move models through staging, production, and archived stages.
  • Lineage: Clicking a model version reveals the exact Run ID, allowing engineers to trace back to all its parameters, metrics, and training code.

The analytical process of contrasting two or more experiment runs, facilitated by their unique Run IDs. This is the primary action that gives experiment tracking its value.

• Compared Elements:
  • Hyperparameters: What changed between runs?
  • Metrics: How did performance differ (e.g., accuracy, loss, inference latency)?
  • Artifacts: Compare validation confusion matrices or training loss curves.
• Visualization: Often done via dashboards using parallel coordinates plots to visualize high-dimensional relationships.