> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# Versions overview

> Treat agent configurations as code. Frozen, auditable, instantly rollback-able.

Every published Flow is a **version**. Versions are immutable — once shipped, they're frozen. Nora manages the pointer from "production" to whichever version is currently live.

Versions make risk manageable. You can publish confidently because rollback is instant. You can audit clearly because every deployment has a fixed identity. You can compare precisely because two versions are two things you can diff.

## What's in a version

A version captures:

* **Every block** in the Flow.
* **Every wire** between them.
* **Every setting** (limits, approvals, retention).
* **Every attached preset** (retrieval, memory, causal graph).
* **Every attached data source** — pinned to specific collection versions.
* **The release note** you provided at publish.

Nothing about a version can change after publish. Rollback shifts the "current" pointer; it doesn't edit the version itself.

## Where versions matter

<CardGroup cols={2}>
  <Card title="Publish a version" icon="rocket" href="/reliable/versions/publish">
    Ship the Draft as a new version.
  </Card>

  <Card title="Rollback" icon="rotate-left" href="/reliable/versions/rollback">
    Point production to a prior version.
  </Card>

  <Card title="Version diff" icon="code-compare" href="/reliable/versions/diff">
    See exactly what changed.
  </Card>

  <Card title="Drafts" icon="pen" href="/reliable/versions/drafts">
    Edit safely without touching production.
  </Card>

  <Card title="Audit trail" icon="clipboard-list" href="/reliable/versions/audit">
    Every publish, rollback, and restore.
  </Card>
</CardGroup>

## The version numbering

Versions are numbered per Flow, starting at v1. Numbers are monotonically increasing — the number tells you the order things were shipped, not necessarily the one that's live.

Also visible: the version's **content hash** — a short ID derived from the version's contents. Two versions with the same content share a hash (rare but possible after a rollback + reroll).

## Version lifecycle

```
Draft → Publish → Version (immutable)
                       ↓
                    Live? (via version pointer)
                       ↓
                Superseded by later publish
                       ↓
                Reachable via version ID for grace period
                       ↓
                Archived (queryable but not runnable) after N months
```

Configurable retention: how long a version stays runnable after being superseded. Default: indefinite for the most recent 10 versions, 1 year for older, then archive.

## The published pointer

Every Flow has one **published pointer** at any time. It points to the version that gets production traffic. Publish moves the pointer forward. Rollback moves it back.

The pointer is what runs — the versions themselves are storage.

## Multiple pointers (canary)

For canary rollouts, you can have two pointers active at once:

* **Primary** — the version handling the majority of traffic.
* **Canary** — the version handling a % of traffic.

Both are pinned versions. Traffic split is defined at the Flow level.