Version History

What a version is

A version is a single saved state of a note. You do not create versions by hand and there is no "commit" button to remember. You save explicitly by clicking Save checkpoint in the editor (see Saving in the editor), and every one of those saves appends one row to an append-only history file that lives next to the note on disk, at users/<owner>/_history/notes/<id>.jsonl. The row records what changed since the previous save, the timestamp, and the editor who made it.

Because the file is append-only and stores deltas, the history never rewrites the live note. The note you are editing is always the ground truth. The history is a side-channel that the save path writes after the note is safely on disk, and a failure to write history can never block or corrupt a save.

This is a different kind of safety net than the Trash. Trash recovers a note you deleted, while version history recovers a note you edited. A paragraph you overwrote three saves ago is not in the trash, because the note itself was never deleted, but it is sitting in the version history, exactly as you last left it.

Where you find it

Open any note and look for the clock-arrow history control on the note popup. Click it and a version history sidebar slides in on the right while the note body stays on the left. The sidebar is the timeline, and the body column becomes the place where each version is shown.

Each row in the sidebar is one version. It shows the editor's avatar, a one-line summary of what that save changed (for example, "edited 2 paragraphs"), and a relative timestamp like "3 hours ago." Hover the timestamp for the full date and time. The newest state sits at the top, tagged Current version. Scroll down to walk backward in time.

Grouped by day, then by session

A working note can accumulate dozens of saves in an afternoon. A flat list of every save would be overwhelming, so the sidebar groups them the way you actually remember your work, by day first, then by editing session within the day.

• Day headers ("Today," "Yesterday," then dated) split the timeline into the days you worked on the note.
• Sessions bundle a run of consecutive saves by the same editor into one collapsible group. A burst of ten small saves while you tightened up a protocol collapses to a single "Mira, 10 versions" row you can expand when you need the detail and leave folded when you do not.

The in-place diff

Select any version and the note body column does not just show that old snapshot. It shows a diff, the note as it stands, with the selected version's changes marked inline. Added lines render in green, removed lines in red with a strike-through, and unchanged prose renders normally so you keep your bearings. The change is shown in the full context of the note, not as a stripped-down patch.

On a note that more than one person edits, the diff goes a step further and tints each change by editor. Every changed run of lines carries a left border in that editor's personal color, with their avatar at the start of the run, so you can see at a glance that Mira rewrote the lysis step while Alex corrected the buffer table. It is the same per-collaborator coloring you know from shared documents elsewhere.

Compare against previous or current

By default, a version is diffed against the one immediately before it, so you see exactly what that single save changed. A toggle at the top of the sidebar switches the comparison base to the current version instead. That answers a different question, "what is different between this old state and the note as it stands right now?" Use Previous to audit one edit, or Current to see everything that has happened since.

Who sees it, local and private

Version history is part of your data folder, not a cloud service. The history file sits inside the note owner's folder on disk, right beside the note, and it travels with the rest of your data through whatever sync you already use (OneDrive, Google Drive, Dropbox, and the others covered under Shared Lab Accounts). Nothing about the history is uploaded to a ResearchOS server.

Visibility follows the same rules as the note itself. A note that is private to you keeps its history private to you. If you share the note with the lab, a labmate who can read the note can read its history too. The history does not widen access, and it does not leak past edits to anyone who could not already read the note. See Sharing and permissions for the full read/write model.

Restoring a version

Selecting any earlier version reveals a Restore this version button in a sticky footer at the bottom of the sidebar (the current version has nothing to restore to, so it never shows the button). Clicking it asks for an inline confirmation rather than popping a browser dialog, in keeping with the rest of the app.

Restoring does not erase anything. The note's current state is kept as a version in the history before the older state becomes the live note, so a restore is just one more forward edit on the timeline. You can always see what the note looked like before you restored it.

The 24-hour undo

A restore is reversible. For 24 hours after you restore a version, an Undo restore affordance lets you put the note back the way it was before the restore, in one click. After the window closes the restore simply stands as a normal edit in the history, which you can still walk back through manually like any other version.

Why it matters for compliance

A per-entry edit history with the ability to revert is one of the things funders and reviewers look for in a research record. It is what makes the record provenanced, a tamper-evident trail of who changed what and when. ResearchOS records that trail automatically and keeps it in your own data folder in an open, plain-text format you can read without the app. For how this fits the NIH Data Management and Sharing expectations, and how it compares to other electronic lab notebooks, see the NIH Data Management and Sharing and ResearchOS vs LabArchives pages.