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

Created by	What happened
The first build	Jason built the pipeline from your brief and the reviewer accepted it. v1 is always a build.
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.
Automatic repair	A live run failed, Jason repaired the pipeline without being asked, and the reviewer accepted the repair. See Verification and repair.
A repair you asked for	You pressed Fix with Jason on a failed run (or asked in chat) and Jason made the repair.
A restore	You restored an earlier version from the changelog. It republishes that version exactly, without Jason or a new review. See Restoring a version.

Each version’s changelog line says which of these it was and what changed.

Apart from a restore, 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.

Viewing a version

Open How it works › Changelog, click the version’s row, and press View v2 in the details window. The version opens in its own window headed v2, with current on the active version, its date and its changelog line, and two tabs:

• Statement of Work. What that version was for, its rules and its scope.
• Pipeline. Its step diagram, with the reading panel for each block. A version without one reads No diagram is available for this version.

Close returns to the changelog. Runs, outputs, sources and settings are not affected; they always show the live pipeline. A run’s Summary links its version (v1) straight to this window, so you can read the definition that produced that run even after the pipeline has moved on.

Restoring a version

Restoring never rewinds history. It publishes the older version again as a new current version.

1. Open the version. In the changelog, click the row of the version you want back, then View v1.
2. Press Restore v1. The button is in the window’s footer and is not shown on the current version. The toast reads Restored v1 as v3, and the changelog gains a Version 3 row marked Current version, with the line Restored v1.

The restored version is the exact definition that was reviewed and ran before, so it becomes current straight away, without a new review. Your current input values and parameter defaults stay as they are. If the pipeline changed while you were looking (for example Jason activated a new version), the restore is refused: close the window, check the changelog and try again.

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 is the pipeline’s history: Versions, automatic repair attempts, and human decisions. The Last updated on date on the statement of work opens it too, and so does Learn more on a degraded pipeline’s banner or card.

The heal status card

The first thing on the page is a card with the pipeline’s heal status.

Card	When	What it offers
Ready	The latest live run did not fail.	Nothing to do.
Degraded, with This pipeline is degraded and needs healing to resume. and the heal status	The latest live run failed. The status is one of Automatic healing will retry in 3h 20min., Automatic healing is in progress., Automatic healing is turned off. or Automatic healing is paused.	Autoheal now, when Enable Auto Heal is on, the pipeline is not marked permanently broken and no repair is running.
Autohealing	Jason is working on a repair.	Nothing; the card updates when the attempt ends. If the pipeline has just been marked permanently broken, Future attempts suppressed; the current task is still running.

Autoheal now asks Jason to repair the pipeline straight away, without waiting for the 24-hour cooldown between attempts. It reads Starting… while the request goes in; if Jason cannot start (another chat is working on the pipeline, or a run is active) the toast reads Could not start autoheal. See Verification and repair.

The history table

Below the card is a table, newest first, with 50 rows per page and Previous and Next under it when there is more.

Column	What it shows
Event	Version <n> (a version was activated), Autoheal (an automatic repair attempt) or Human decision (a person allowed or stopped automatic repair).
Outcome	A coloured pill; the values are listed below.
Summary	For a version, its changelog line, or No changelog recorded. for a version made before notes were recorded. For a repair attempt, Automatic healing was attempted. or Production recovery confirmed. For a decision, the reason given.
When	The date and time.

Outcome	Event	Meaning
Current version	Version	The active version.
Version published	Version	An earlier version.
Queued	Autoheal	The attempt is waiting to start.
Jason working	Autoheal	Jason is working on the repair.
Recovery confirmed	Autoheal	A live run after the repair succeeded, so the pipeline is healthy again.
Awaiting recovery	Autoheal	Jason activated a repaired version; the next live run has not confirmed it yet.
Temporarily blocked	Autoheal	The cause was outside the pipeline and looked temporary (the site was down or blocking). Nothing was changed.
No change justified	Autoheal	Jason found nothing in the pipeline to change.
Could not repair	Autoheal	Jason tried and could not produce a repair that passed review.
No verified repair	Autoheal	The attempt finished without an activated version.
Attempt failed / Interrupted	Autoheal	The attempt stopped before it finished.
Permanently broken	Human decision	The Jsonify team stopped automatic repair for this pipeline, usually because the source is gone.
Autoheal allowed	Human decision	Automatic repair was allowed again.

Click any row for its details window, headed with the event and the outcome (Autoheal · Recovery confirmed). It shows the outcome pill, the exact time and who made a decision, the full summary, Production recovery confirmed with its time when that happened, and the links that apply:

• Triggering failure. The failed run that started a repair attempt.
• Repair conversation. The chat in which Jason worked on the repair.
• View v<n>. Opens that version in its own window, where it can be restored.

Close details (or Escape) returns to the table.

Version 3 · Current version — Handle Amazon AggregateOffer price payloads while preserving the existing Offer extraction fallback.

Autoheal · Recovery confirmed — Production recovery confirmed.

Version 1 · Version published — Built the price and promotion tracker from the brief: three retailers, daily at 06:00 Europe/London.

A changelog line is written by Jason when it submits the version and says what changed for you, in the same terms as the statement of work. It is not a summary of the conversation; for the reasoning, open the chat that produced the version (Repair conversation on a repair, or the chat from Conversations).

A pipeline with no history yet shows No pipeline history yet. The page refreshes itself every 15 seconds; if it loses contact it says History may be out of date. Reconnecting…

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