Versioning

Every application has its own version history. As you draft, Nodes-IP keeps a running record of where the application has been, so you can always reach back to a previous state, and so a filed version is preserved exactly as you filed it, no matter how the matter evolves afterwards.

Applications and versions

An application is a single filing under a matter: a US application, an EP application, a PCT application. A matter can hold any number of applications, and each one is independent: it has its own claims, sections, title, docket, bibliography, and version history.

A version is a saved checkpoint of an application's content. Each version preserves:

The claims and application sections (Background, Summary, Detailed Description, etc.) as they read at that moment.
The title and docket / reference for the filing.
The inventors and applicants named on the filing, captured as they were at that moment, including their names, nationalities, and addresses.
The figures and reference-sign elements referenced from the content, captured with their state at that moment.

Versions are immutable. Once a version is frozen, nothing about it changes: not the claims, not the inventors, not the figures it points at. It is a faithful record of the application as it stood when you saved it.

Current draft and frozen versions

At any time, exactly one version of each application is the working draft, the editable draft you're typing into. Every other version is frozen.

When you save, Nodes-IP freezes your working draft (under a name, if you give it one), then creates a new working draft on top of it. You keep editing in the new draft; the frozen version stays put as a permanent record.

You don't manage this by hand. There is no "switch to edit mode": if you can type into it, it's the working draft. If you can read it but not type, it's frozen.

The Versions page

Open Versions in the sidebar (under Application) to see and manage an application's version history. The page shows one application at a time, following the matter and application you have in scope.

The history reads as a timeline, newest at the top:

The working draft card sits pinned at the top. It shows when the content last changed, which version the draft continues from (or branched or forked from), and what has changed since. The Save version button lives here.
Below it, the draft's ancestry runs down the spine. Named versions stand out with solid dots and bold names; unnamed checkpoints are smaller and quieter. Each entry shows what changed against its parent ("2 claims amended · Summary updated"), computed when the version was frozen.
Runs of automatic checkpoints collapse into a single expandable "N autosaves" entry so the spine reads as your milestones.
Versions that are no longer on the draft's line of descent (for example, the state you left behind when you reopened an older version) appear as dimmed side branches under the point where they forked off.
The timeline ends where the application began: a "Forked from ..." marker linking to the source application, or an "Application created" marker for an application started from scratch.
As you scroll, the timeline slides underneath the draft card and a small counter on the spine tallies the versions scrolled past; click it to jump back to the top.

Each version's ... menu offers Continue from this version, Rename, and Delete.

Saving a version

Save from the Versions page (Save version on the working draft card) or press Ctrl+S while editing claims or sections. A name is optional. Naming a version is how you find it again later, so it's worth naming the ones that matter, like "as filed at the USPTO", "first office action response", or "ready for client review".

There is no save button in the editors: your content is saved continuously as you type. Saving a version is a different act, freezing a milestone you can return to.

You cannot save while there are unresolved pending changes from the assistant on the working draft. Accept or reject them first, then save.

Previewing a version

Click a version on the timeline to pin the Preview panel to it. The entry stays highlighted while pinned; click it again (or click the working draft card) to unpin and return the preview to the live draft. The preview highlights its version crumb and outlines the document while it displays a frozen version.

You can also switch versions from the version selector in the Preview panel header itself.

This gives you a simple compare workflow: keep the working draft open in the editor on the left, pin any frozen version in the preview on the right.

Opening an old version

Continue from this version (from a version's ... menu on the Versions page) makes a frozen version your editing target again. Your current working draft is checkpointed automatically first, so nothing is lost, and a fresh draft is created with the old version's content. The state you left behind stays reachable on the timeline as a side branch.

Renaming a version

Rename a frozen version at any time from its ... menu. Names are unique within an application.

The live registry vs frozen versions

Inventors, applicants, figures, and reference-sign elements live in a matter-wide registry. Editing them updates the registry, and the change is reflected in the working draft of every application.

Frozen versions are immune. Renaming an inventor or updating an address changes how the registry reads going forward, but it does not change what's on any version you've already frozen. A filed version always shows the inventor exactly as named at filing time.

This is why a save freezes the bibliography too, so the record of who was named on which filing is preserved, even years later when the registry has moved on.

Forking from another application

A new application can start either empty or as a fork from a frozen version of another application in the same matter. This is the natural workflow for follow-on filings, for example an EP application that starts from the US version 2 filing, or a continuation that starts from the parent's grant.

When you fork, the new application is created with a working draft whose content is copied from the source version (claims, sections, title, docket, bibliography, figures). It is its own application after that, and edits there don't affect the source. The new application's timeline starts with a "Forked from ..." marker that links back to the source application.

Forking is matter-scoped: you can only fork from versions in the same matter. The element and figure registries are shared per-matter, and crossing matters would break those references.

Deleting versions

Delete a saved version from its ... menu on the Versions page. Deleting a version does not break the chain: any later versions that branched from it are re-parented to its parent, so the history stays connected. If the deleted version has cross-application descendants (an EP application that forked from it, for example), the confirmation dialog warns you before re-parenting them. A root version (the very first version of an application) can't be deleted, since there's no parent to stitch its children onto, and the live working draft can't be deleted either.

Coming soon

Automatic checkpoints. Background autosaved versions between your named saves, so an unnamed safety-net copy is always available. The timeline already groups these; until they ship, save the states that matter: a version only exists once you save it.