Versions and changelog

A version is an immutable revision of the pipeline: its steps, rules, outputs and statement of work as they were at one moment. Every build, every change you ask for and every repair creates a new one. Earlier versions are kept. Runs record which version they used, so any row in any dataset can be traced to the exact definition that produced it.

How versions are created

Source badge	Created by	What happened
build	The first build	Jason built the pipeline from your brief and the reviewer accepted it. v1 is always a build.
edit	A change request	You asked for a change with Edit pipeline, in a chat, or by committing comments on the statement of work; Jason made it and the reviewer accepted it. A restore is also an edit.
Auto-heal	Automatic repair	A scheduled or webhook-triggered run failed, Jason repaired the pipeline without being asked, and the reviewer accepted the repair.
Manual heal	A repair you asked for	You pressed Fix with Jason on a failed run (or asked in chat) and Jason recorded the change as a repair.

Whatever the source, the path is the same: Jason produces a candidate, tests it with one or more Test runs (visible in the runs rail, never published), and submits it for independent review. Only a review that passes activates the candidate as the next version. A rejected candidate goes back to Jason; the current version stays active throughout. See Agents, workers and repairs.

The version number only advances when something is activated. A change that Jason decides is not justified, or a repair that cannot be verified, leaves the pipeline where it was and is explained in the chat.

The version chip

The hero shows the active version as a chip: v2 with a history icon. Click it to open the version list.

• One row per version. v2, its source badge, a current pill on the active version, and how long ago it was created.
• Click a row to view that version. The statement of work and the step diagram switch together, and the chip turns amber to show you are not looking at the active version. Click the current row, or Back to current, to return.
• Viewing v1 banner with Restore and Back to current sits at the top of the list while you are on an older version.

A run’s Summary links its version (v1) straight to this view, so you can read the definition that produced that run even after the pipeline has moved on.

Viewing an older version

While viewing an older version, the statement of work shows a sticky amber bar: Viewing v1 · current is v2, with Restore v1 and Back to current. Everything below the bar describes v1: its objective, rules, outputs and steps. Runs, outputs, sources and settings are not affected; they always show the live pipeline.

A rule that changed between versions keeps its id. Compare R3 in v1 and v2 to see what a change actually did to the behaviour you rely on.

Restoring a version

Restoring never rewinds history. It asks Jason to make the current pipeline behave like the older version again, as a new version that goes through review like any other.

1. Open the version chip and click the version you want back.
2. Press Restore (in the chip, or Restore v1 in the amber bar). The Jason sidebar opens and the request is sent: restore the behaviour and configuration of that version as a new current version, validate it with realistic inputs, and require review before activation. The toast reads Jason is restoring version v1.
3. Follow the chat. Jason rebuilds the behaviour, runs its tests and submits for review. If Jason is already busy with this pipeline you are told Jason is already working. Ask to restore this version when the current turn finishes.
4. Check the new version. When the review passes, the chip advances (for example to v3) with an edit badge and a changelog line naming the version it restored.

Restoring v1 after a v2 that dropped a retailer produces v3, which has the retailer back. v2 stays in the list, so the decision to drop and the decision to restore are both on record.

The changelog

How it works › Changelog & Notes › Changelog lists every version with the note Jason wrote when it was created.

Each row shows the version, its source badge, the current pill, how long ago it was created (hover for the exact time), and the changelog text. A version created before changelog notes were recorded reads No changelog recorded. Hover a row for View, which opens that version’s statement of work.

v2 · Auto-heal · 3 days ago — Handle Amazon AggregateOffer price payloads while preserving the existing Offer extraction fallback.

v1 · build · 5 days ago — Built the price and promotion tracker from the brief: three retailers, daily at 06:00 Europe/London.

A changelog line is written by Jason and says what changed and why, in the same terms as the statement of work. It is not a summary of the conversation; if you want the reasoning, open the chat that produced the version from Chat history.

A pipeline with no versions yet shows No versions yet · Versions will appear here as the pipeline is built and edited.

What is not versioned

Some things belong to the pipeline rather than to a version, so changing them never creates one:

• The schedule, cache and Enable Auto Heal settings.
• Notes.
• Value inputs and parameter defaults you set on the Inputs page.
• The pipeline’s name, description and icon.

Runs record the parameter values and dataset revisions they used, so a run remains reproducible even though those values are not part of the version. See Run detail.

What’s next