Skip to main content

Analytical work, with its history intact.

Publish a notebook or a report as a release that never changes. Link it to the code it came from, collect feedback on it, and keep every revision in one history.

PM2.5 seasonal trends

Select a release

Release 8

Published

A correction becomes Release 9. Release 8 stays exactly as it was reviewed.

Notebook
pm25-seasonal-trends.ipynb sha256:306c…9f1e
Code
3f81a92 linked commit on GitHub
Parent
Release 7, with release notes
Feedback
2 threads on this release
Published by
Priya Raman Sep 30, 2026, 9:36 AM UTC
Illustrative. A release records its notebook, its linked code and its parent.

What a release records

  • The notebook or report, with a checksum for every file, exactly as published.
  • The commits and pull requests it is linked to on GitHub.
  • The parent release and the notes that explain what changed.
  • Who published it, and when.

From output to evidence trail

Each layer adds context without changing the result that was reviewed.

  1. Step 1

    Private projects

    Invite members by email, and share a published HTML or PDF release through an expiring, password-protected link.

  2. Step 2

    Immutable releases

    Publish a Jupyter notebook, or an HTML or PDF report, as a release with a checksum for every file. A correction creates a successor release.

  3. Step 3

    One history

    The publication graph shows every draft and release in order, so you can see what changed and when.

Feedback that keeps its place

Comments live on the release they were made on, so the record stays intact while the work moves forward.

Select a pin in the report.

Seasonal variation

The adjusted model includes the baseline measurement.

Winter means declined across the study period.

Two monitors were relocated during the period.

Methods · Release 8

Thread 1 · needs discussion

Priya Raman

Could we make the baseline adjustment explicit in the methods?

Alex Chen

I’ll clarify the wording in the next release.

Illustrative report and discussion. Feedback stays attached to the release reviewed.
  • Comment in context

    Pin a comment to a passage, a figure or a table cell of a notebook or HTML report, or to a region of a PDF page. Guests with a share link can comment on HTML and PDF reports.

  • Assign and follow up

    Assign a thread to a member, and see what is still open across the project.

  • Review alongside a meeting

    Members follow the presenter's place in an HTML or PDF report, or browse on their own, while the record stays intact.

Works where the analysis happens

  • Python

    Publish from your analysis environment with dataship.publish_notebook or dataship.publish_report, using a project token scoped to exactly what the task needs.

  • VS Code

    Preview a notebook as a release, publish it, and read its feedback threads without leaving the editor.

  • Coding agents

    Give an agent approved project context through the MCP server. Agent permissions are scoped capabilities, narrower than yours by default.

  • GitHub, linked not mirrored

    Link a repository so a release records its commits. Dataship stores stable identifiers and the minimum metadata needed for lineage.

Private by default, recorded by design

Every resource belongs to a project
Access is decided on the server, at the project boundary, for every request.
Published means published
A published release cannot be edited. A correction is a new release with a parent.
An audit trail you can export
Consequential changes are recorded as activity events with the actor, the subject and the time, in UTC.

Start with one project.

enes