Version History & Provenance

Every change to a mindmap is recorded. You can browse past states, inspect where any node came from, and revert when needed. This is the audit trail — and it's the reason refinement is safe.

The audit trail surfaces in two places:

  • Provenance per node — for any single node, what produced it, when, and from which sources.
  • Version history per mindmap — the full sequence of mindmap states, each one snapshotted automatically.

You'll use provenance when reviewing claims; version history when something went wrong and you want to step back.

Provenance: what's recorded per node

Open any node and look at its provenance panel. You'll see:

  • Author — which model generated the node (e.g., claude-sonnet-4-6, gpt-5), or manual if you wrote it yourself.
  • Source workflow — the conversation turn that produced the node, with the original instruction you sent.
  • Citations — every document and passage attached to the claim.
  • Confidence score — the 0–100 score the Researcher assigned. See Confidence, Gaps & Iteration Limits.
  • Edit history — every modification to the node, who/what did it, when.
  • Timestamp — when each event happened.

This is enough to reconstruct why any node says what it says. If you're writing a methods section, it's also enough to defensibly describe how a claim was produced.

Version history: snapshots of the whole map

The system snapshots the mindmap state at workflow boundaries — automatically, not on demand. Browsing version history shows you:

  • A list of versions in reverse chronological order, each tagged with the workflow that produced it and a short summary.
  • A diff view for any two versions: nodes added, removed, moved, modified.
  • A point-in-time preview of the whole map at any version.

Restoring a version

Restoring is non-destructive: the current state isn't deleted, it's just superseded by the restored one. You can re-restore the original later. Common reasons to restore:

  • A restructure went sideways and the old structure was better.
  • A workflow produced output you don't want to keep, and the conversation got too far ahead to refine your way out cleanly.
  • You want to A/B compare two directions you tried.

Reverting is the right move when refinement keeps making things worse. There's no shame in stepping back.

Audit trail for AI-generated content

Because every claim has full provenance, you can answer questions like:

  • Which papers actually support this claim? — Citations on the node.
  • Was this written by the agent or by me? — Author field.
  • When was this added, and what instruction produced it? — Source workflow and timestamp.
  • Has anyone (or anything) edited this since? — Edit history.

In practice, this matters for:

  • Method transparency — being able to describe how a research artifact was produced.
  • Co-author review — a collaborator can audit your work without rerunning anything.
  • Reproducibility — re-running an old instruction against an updated KB to see what changes.

Inspecting why a claim exists

A useful debugging move when a claim looks wrong: open its provenance, follow the citations into the PDFs themselves, and read the passages the agent drew from. The system will jump you directly to the cited location in the PDF reader.

Common findings:

  • The passage genuinely supports the claim — the issue is your skepticism, which is fine, but the claim stays.
  • The passage partially supports the claim — soften the claim or add a qualifier.
  • The passage doesn't support the claim — this is rare but it happens, especially with low-confidence nodes. Flag, delete, or revert.

Provenance under restructure

When the Editor moves or merges nodes, provenance follows them. Restructuring doesn't erase history — the moved node still carries its original author, citations, and confidence score, plus a new edit-history entry recording the move.

When two nodes are merged, the resulting node inherits provenance from both. The edit history shows the merge as an explicit event.

What's not in the audit trail

  • Conversation messages outside this project. Each project has its own history.
  • External edits that bypass the system (there aren't any, but worth stating — there's no out-of-band edit path).
  • KB-side changes. If a document was updated or removed from a KB after a claim was made, the citation still points to the original passage as it was at the time. You'll see this surfaced when the underlying document has changed.

Tips

  • Snapshot before big restructures. They're automatic, but glancing at the version list before a major change makes the "restore" option obvious if needed.
  • Use restore liberally. It's cheap and non-destructive.
  • Read provenance on the claims that matter most. For the 5–10 nodes that will carry your argument, the two-minute provenance audit pays off.

What's next