Versions and undo

Versions

A version is a saved copy of the whole project, and it never changes. Every project has one from the start, Initial version. Save another with Create Version, beside Undo at the top of a project, or in the More project actions menu on a tablet. A version keeps the Spec score of its moment, and cannot be deleted.

Reading and comparing versions

• Versions, in the project panel, lists them, newest first. View changes shows what changed since the version before.
• Open a version to read it as it was. It is read-only.
• Compare sets any two versions side by side, or a version against the current draft.

A comparison matches items by their id, such as Req-004, and marks each one added, removed or modified. For a modified one it shows each field that changed, before and after: the statement, the acceptance criteria, the priority, the subsystem. A tab for each kind of item, stories, requirements, stakeholders and subsystems, counts its changes, and Hide unchanged leaves out the rest.

What a comparison is for

A spec changes as the product does. A comparison turns those changes into something to act on: what is new, what was reworded, what was dropped.

• For a coding agent, the change is the work. The agent saves a version with create_project_snapshot when it builds from the spec. Later, projects_diff gives it what changed since: the stories, requirements and interface contracts added, removed or modified, field by field. It builds that, rather than reading the whole spec again and working out for itself what is new, which costs its context and misses things. Then it saves a new version to compare against next time.
• For a reviewer, the change is what there is to agree to. Before a release, or before handing the spec on, compare it with the version last agreed, and read what was added, reworded or dropped, not the whole spec again.
• For a process that has to show its changes, the versions are the record. Each one is what the spec was at a moment, with its date and its Spec score, and cannot be changed or deleted. Comparing two of them shows what changed in between.

Restoring a version

Restore makes a version the working draft again, in place of what is there. The draft it replaces goes into the undo history first, so a restore can be undone.

Undo and redo

Undo, at the top of a project, steps back one change at a time, up to 49 changes; Redo steps forward again, until a new change is made. A change is anything saved: an edit or a deletion, an accepted proposal (as one step), a finished AI run or chat reply, a restore.

• The history is the project's, not yours: undo takes back the latest change, whoever made it.
• It survives a reload.
• It leaves the versions, the Spec score and a shared link as they are.

For experts: baselines and change control

In configuration management, a version agreed as the base for further work is a baseline: a "formally approved version of a configuration item … formally designated and fixed at a specific time" (ISO/IEC/IEEE 15288:2023, 3.8; the same in ISO/IEC/IEEE 29148:2018, 3.1.3). What changes between two baselines goes through change control. A version in Entalpa is fixed in the same way, and comparing two versions shows what a change control has to look at.

Why the change, and not the whole spec. For a language model, more context is not free: models use information in the middle of a long context markedly worse than at its start or its end (Liu et al., 2024). A diff puts what changed in front of the agent instead of somewhere inside the whole spec. For people, code review research found understanding the change to be the reviewer's main challenge (Bacchelli and Bird, 2013); a comparison field by field, before and after, gives them that.

Where Entalpa departs from these sources, it says so:

• No approvals yet. A baseline is formally agreed. A version is saved by anyone who can edit the project, with no sign-off. Until then, record the approval where your process keeps it, naming the version.
• No history per item yet. A comparison shows what changed, not who changed it or why. The undo history keeps the last 49 changes, and is not an audit trail.
• Not everything is compared yet. The app compares stories, requirements, stakeholders and subsystems; projects_diff, stories, requirements and interface contracts. A requirement's status, the open questions and the project's settings are left out.

Approvals, a history of each item with who changed it, and a comparison of everything are coming soon. If you need one of them now, write to contact@entalpa.com: it may be available on request.

References

• ISO/IEC/IEEE 15288:2023. Systems and software engineering: System life cycle processes.
• ISO/IEC/IEEE 29148:2018. Systems and software engineering: Life cycle processes, Requirements engineering.
• ISO 10007:2017. Quality management: Guidelines for configuration management.
• ISO 13485:2016. Medical devices: Quality management systems, Requirements for regulatory purposes.
• U.S. Food and Drug Administration. Quality Management System Regulation, 21 CFR Part 820, effective 2 February 2026.
• IEC 62304:2006+AMD1:2015. Medical device software: Software life cycle processes.
• ISO 26262-8:2018. Road vehicles: Functional safety, Part 8: Supporting processes.
• VDA QMC (2026). Automotive SPICE Process Assessment Model, version 4.1.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F. and Liang, P. (2024). Lost in the middle: how language models use long contexts. Transactions of the Association for Computational Linguistics 12, 157–173.
• Bacchelli, A. and Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. Proceedings of the 35th International Conference on Software Engineering (ICSE 2013), 712–721.