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's content is preserved 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 jurisdiction the application was drafted under, which drives the section set and the jurisdiction's document-format preset.
  • The drawings: which sheet each FIG. n points to, its artwork, and its number, as they were at that moment.
  • The reference-sign numbers (e.g. (101)) assigned to each element at that moment.
  • The bookmarked prior-art citations referenced in the text at that moment.

Versions are immutable. Once a version is frozen, none of the above changes — it is a faithful record of the application as it stood when you saved it.

One thing a version does not pin down: document formatting. Paragraph numbering style, typeface, and heading alignment are a live, per-application setting rather than part of any one version, so they can still change after a version is frozen — see the Formatting section of Preview.

Versions frozen before drawing/reference-sign/citation capture shipped are the exception. Older frozen versions didn't record figures, reference-sign numbers, or citations at save time, so those three keep showing the registry's current state on such a version — the same approximate behavior as always. Anything frozen since shows exactly what was true at freeze time.

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, reference-sign elements, and bookmarked prior art all 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 to registry changes. Renaming an inventor, renumbering or deleting a reference sign, reordering, deleting, or re-uploading a figure, or removing a bookmark all change how the registry reads going forward, but none of it changes what a version you've already frozen shows. A save captures the bibliography, the drawings, the reference-sign numbers, and the citations together, so the record of what a filing named, numbered, and cited is preserved even years later, after the registry has moved on.

Deleting an element or a figure from the registry doesn't remove it from a frozen version either: the version still shows and numbers it, using what was true at freeze time.

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). 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. Figures and reference-sign elements aren't copied because they're already shared across every application in the matter.

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.