Skip to main content

Versioning & History

Every Insight LM project can keep its complete history: every saved state of every file, forever, with the ability to read any old version back exactly as it was. You never operate the machinery — you ask the Assistant to save, to keep a version, to show history, to bring back last Tuesday's file — and it happens.

Under the hood this is git — real, standard git, not an imitation of it. That was a deliberate design decision, and a deliberately boring one: no invented version machinery, no proprietary history format, nothing to migrate away from. A project's history is a plain git repository that any standard tool can read and audit.

How it works day to day​

The whole project — all of its workbooks together — is one repository, so one snapshot captures a consistent state of everything. The vocabulary is small on purpose:

  • Save — the Assistant commits the current state with a description of what changed. Files stay normal files; nothing moves or transforms.
  • Keep this one — the Assistant tags the current state with a name. Tags are permanent: they can never be moved or deleted, so a kept version means the same thing years later.
  • Show me — history and old versions read back read-only. Looking at last month's model can never disturb today's work.
  • Bring back — a specific file can be restored to how it was at any saved point. Restore is always scoped to named files — there is no "reset everything" footgun — and in governed sessions it always asks you first.

Two guardrails run underneath: a fail-closed ignore policy keeps tokens and secrets out of the record from the first save, and destructive operations sit behind the same approval gates as every other consequential Assistant action.

What we deliberately did not build​

No branches, no hidden working copies, no commit-message conventions to learn, no parallel "receipt" system. Each of these was considered and rejected: they are the machinery of software teams, and this history serves knowledge work. If a real need appears, git already supports all of it — the point of building on the standard is that nothing is foreclosed.

GitOps: history as an integration surface​

Because the record is plain git, it composes with everything git composes with:

  • Remotes. A project can publish to a git remote (GitHub, GitLab, or self-hosted) for backup, sharing, and pulling updates — configured in Settings, with connection health shown in the status bar. With no remote configured the project is simply local-only, and the app says so honestly.
  • Reproducibility, joined up. When a graph is published (see Graphs & Provenance), the publish workflow lands an exactly-once release commit in the project history — so the immutable graph version and the file state that produced it are recorded together.
  • Audit. "What changed, when, and in what state was everything?" is answered by the repository itself, with standard tooling, independent of Insight LM.

Where this is going (in active build)​

Today, turning history on is an explicit step (Settings → Project repo), and saves happen when you ask or when a governed workflow runs. In build: every new project starts with history on automatically, and capture tightens so that saving is something you stop thinking about entirely. Support for additional enterprise remote types is also in progress.