Docs / Hand-off & history

Version history

Every version of a feature keeps its own analysis document and its own set of canvases. You can switch between versions on the feature page to see exactly what was planned and approved at each point, and nothing earlier is ever overwritten.

Each time you create a new version, REEZN freezes the previous one and starts the next from a copy of its definition. The earlier version’s analysis, canvases, and approvals stay exactly as they were, stored under their own version, so the record grows rather than getting replaced. (Creating versions is covered on its own page; this one is about reading the history that results.)

Artifacts are kept per version

Artifacts are stored against the version they belong to, not the feature as a whole. Opening version 1 shows version 1’s analysis and version 1’s canvases, the documents as they stood then, not whatever the latest version produced. A multi-version feature therefore carries several full sets of plans side by side, each tied to the version that generated it.

Definition: The author’s input for that version: goal, scope, acceptance criteria, and the rest. Each version has its own, since a new version starts from a copy and is then edited.
Analysis document: The analysis generated and approved for that version. An older version keeps the one it was reviewed with, untouched by anything that came after.
Canvases: The REASONS canvas per service for that version, with their own approvals. Switching versions swaps in that version’s canvases, not today’s.

Switching between versions

On the feature page, a “Definition versions” list in the sidebar shows every version the feature has had, newest first, with the latest marked “current.” Each entry shows the reason it was created. Click any version to view it:

Open the feature and find the Definition versions list in the left sidebar. It has one entry per version (v1, v2, and so on), with the latest tagged “current” and each showing the reason it was created.
Click an older version. The page switches to show that version’s definition, analysis, and canvases in place of the current ones.
Click the current version again to return to today’s plan, where editing, reviewing, and approving happen.

When you’re viewing an older version, it is clearly marked read-only and the artifacts are shown for reference only: you can read every section, but you can’t edit, comment on, or approve it. Approved artifacts and superseded versions are locked; the only live, editable plan is the current version’s.

Why a version exists

A new version is only ever created for a real change in requirements, and REEZN requires a short reason at the moment you create one. That reason is saved alongside the version, so versioning is always a deliberate decision rather than a silent overwrite, and the history records why each version came about. Each version is numbered, so the record reads as an ordered sequence of intent: v1 was the original ask, v2 followed a specific change, and so on.

The preview always reflects the current version

However many versions a feature has, the generation preview always exports the current version’s approved plan, never an older one. Each version keeps its own canvases, and the filename on a downloaded canvas carries the version (for example canvas-billing-api-v2.md), so what you hand to engineers is always the latest agreed blueprint, clearly labelled. Older versions stay viewable for reference, but they are history, not the thing you build from.

Archiving a feature doesn’t erase any of this, and neither does rejecting one. An archived or rejected feature is retired from active work, but its full history, every version, artifact, and approval, stays intact and viewable.

Why this exists

The answer to “why was it built this way?” should always be one click away. Keeping each version’s analysis, canvases, and approvals intact, rather than overwriting them when requirements change, means the record reads as a story of decisions: what was planned, what changed and why, and who signed off on each. That history stays useful long after the work has shipped, when the original context has otherwise evaporated.