Versions & history

Controlled records change over time, and TraceUnified keeps the full story: what a requirement said at each point, who changed it, and why. Versioning and history are what let you trust — and prove — the current state.

Version history

When versioning is enabled for a project, each requirement carries a version history. Routine edits are tracked, and significant changes are captured as distinct versions, so you can always see how a requirement evolved rather than only its latest form.

Creating a version

Creating a new version is an explicit, authenticated act. Because a version marks a controlled change, you’re asked to re-authenticate and to record details about the change before it’s committed. This ties the new version to an identified person under your electronic-signature controls — the same Part 11 expectations that run through the rest of the platform.

Field-level history

Beyond whole versions, you can see the history of an individual field — its previous values and when they changed — directly from the record. This makes it easy to answer a precise question (“when did this acceptance criterion change, and to what?”) without reading an entire version diff.

Comparing versions

You can compare records to see exactly what differs between two points — which fields changed and how. Comparison turns “something changed” into a clear, reviewable account of the change, which is invaluable during reviews and investigations.

Relationship to the audit trail

Versions and field history are the record-level view of change; the audit trail is the system-wide, tamper-evident log behind it. Together they mean every change to a requirement is attributable and reconstructable — the foundation the Compliance section builds on.