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

Versioning is always on. 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 act. Depending on the record’s workflow, New Version may ask you to provide an electronic signature and a comment about the change before it’s committed. When it does, that 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. Where the workflow doesn’t call for them, neither is requested.

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.