---
name: wandb-reporting
description: "Use W&B runs, reports, and artifacts consistently for experiments, benchmarks, and task results with dense numeric output."
---

# Skill: W&B Reporting

Use W&B when scalar series, plots, large comparison tables, or raw artifacts are
too dense for issue comments or logbooks. Keep GitHub as the narrative layer and
W&B as the data/report layer.

## Project Policy

- Choose project scope by the type signature of the work.
- Default to the `marin` project for pretraining runs.
- Use a new project for materially different work, such as kernel development
  or a new RL variant.
- Runs requiring explicit run-to-run comparison must share a W&B project.
- Decide scope early; you cannot reliably move or copy runs across projects
  later.

## Run Naming and Metadata

- Use the same experiment/task ID in W&B run names, logbook entries, and issue
  comments.
- Group related sweeps with a stable group name.
- Prefer artifacts for raw CSV/JSON outputs that feed published tables.

## Reporting

- Link W&B runs/reports from the coordinating issue and logbook.
- Summarize only the decision-relevant numbers in GitHub; link W&B for dense
  tables and plots.
- Before publishing a claim, verify expected row counts, key uniqueness, and any
  de-duplication or aggregation logic.
- Keep report titles and sections aligned with the issue/logbook labels.
- Keep artifacts small (<10MB). Larger artifacts should be stored in the experiment dir and linked.

## Completion Checklist

- Relevant runs are in the intended project.
- Run names map back to issue/logbook experiment IDs.
- Primary comparison table or chart is linked from the issue.
- Raw artifacts needed to reproduce the table are uploaded or linked.
- Claims in GitHub match the final W&B values.
