Can I share a Comet experiment without adding someone to the workspace?

Comet supports public projects, which is all-or-nothing and rarely acceptable for internal work. For a specific stakeholder, export the figures and the metrics table into a page and share that URL instead.

Aren't Comet Reports already for this?

They are, for people inside the workspace. The audience that stalls is the one outside it — a product lead, a clinical collaborator, a customer — and for them a report behind a seat is no report at all.

What should the exported page contain?

The claim first, then the evidence: the metric that decides the question, the comparison against the incumbent model, the figures that support it, and the hyperparameters as an appendix.

Does this replace experiment tracking?

No. Comet keeps logging every run. The page is one curated argument drawn from a few of them — the thing you would present, not the thing you would query.

Can the model owner answer questions inline?

Yes. Comments anchor to the figure or the number, so 'why is recall down on the held-out set?' is asked and answered next to the chart.

Share a Comet ML experiment

You ran forty variants. Comet logged all of them, and the panel comparing the top five is genuinely good — the loss curves, the confusion matrices, the parameter sweep.

The person who decides whether this model ships is a product director without a Comet seat, and the comparison they need is between two of those forty runs.

Tracking and communicating are different jobs

Comet is built for the first: log everything, query it later, never lose a run. That is the right design for an experiment tracker and the wrong shape for a decision document.

A stakeholder does not want a workspace. They want one page that says we should ship variant 31, here is why, here is what it costs, with the figures underneath. Forty runs in a comparison table is an invitation to ask about run 17, which nobody needs to discuss.

Export the argument

Pull the figures and metrics from the experiment and assemble one page:

exp = comet_ml.API().get_experiment("ws", "churn", exp_key)
metrics = {m["metricName"]: m["metricValue"] for m in exp.get_metrics_summary()}
# fetch logged figures, then render one HTML document and publish it

Structure it as an argument rather than a dump:

The recommendation, in one sentence.
The comparison — candidate against the model in production, on the metric that matters and the one you are worried about.
The figures — the two or three that carry the claim.
The appendix — hyperparameters, data version, run ids in Comet for anyone who wants to dig.

The Comet run links in the appendix are what keep this honest: an interested reader can go from the claim to the raw run in one click, if they have a seat.

Public projects are not the answer

Comet's public-project setting makes the whole project world-readable. For published research that is fine; for a churn model trained on customer data it is a disclosure decision that should not be made to solve a sharing problem.

A restricted report shows the people who need it exactly what they need — see security.

Questions land on the figure

The reply you want is not "looks good". It is "why does recall drop on the held-out set?", asked on the chart that shows recall dropping — see commenting on HTML. That question, answered in place, becomes the record of why the model shipped, which is the artifact you will want when someone asks in six months.

Worth knowing

Publish from the training job. At the end of a run, build the page and update the same report id, so the link in the ticket always shows the current best candidate.
Static figures, not embedded dashboards. A page that tries to embed live Comet panels is a page that will ask your reader to log in.
5 MB per report body. Downscale plots; nobody needs a 4000px loss curve.

Try it

Free — unlimited reports, commenters and revisions.

Read the API reference →