Change notes & history

Version history tells you what changed. A change note tells you why — so the next person reading the history does not have to guess, and neither do you in six months.

Versions

Open any research item or experience entity and use Versions to see its history. Each version lists its changes the way a review would: fields that were rewritten, and connections that were added or removed, named rather than shown as ids.

Links are part of that history. When a piece of evidence is attached to a page, or a source is unlinked from an assumption, the version records it — so a change note can explain the connection itself, not just the wording around it.

Add a change note

On any version, choose Add change note and fill in four things:

The linked source is a real reference, not a label: history shows it by title, and the artefact stays one click away. Clearing the reason clears the rest, so nothing is left dangling.

Status changes explain themselves

Frame lines — questions, assumptions, evidence, and gaps — carry an understanding status that moves as research lands: open, validated, refuted, clarified, answered, closed, or superseded. Moving the status asks for the same four fields, so the trail is recorded at the moment the decision is made rather than reconstructed afterwards. Those versions are annotated from the status control instead of the change-note dialog.

Why it matters

• Ask can cite the reasoning, not just the current wording.
• Restoring is a judgement, not a gamble — you can see what a version was for before you roll back to it.
• Handovers survive. A page whose description changed three times reads as a decision trail rather than an unexplained diff.

Next

• Reviewing AI output
• The research graph
• The experience graph