Why Regulated Software Needs to Remember the Past Differently
A conventional business application is designed around the current state of a record. A calibration interval is 12 months. An instrument is assigned to a location. A procedure is approved. A result has passed. When any of these facts changes, the database row is updated and the application moves on.
That model is efficient, familiar and often entirely appropriate. It becomes inadequate when an organisation must answer a more exacting question: what did the system show, what was approved, and which rules applied when this decision was made?
In regulated and high-consequence work, that is not a historical curiosity. It determines whether a released batch, maintenance decision, calibration status or quality record can be defended. The system must preserve more than the fact that a value changed. It must retain the context in which the earlier state was valid and used.
Current state is not historical truth
A mutable database normally stores one authoritative version of each entity. Updating an asset record may overwrite its manufacturer, acceptance limit, calibration interval or assigned procedure. An updated_at timestamp and updated_by user identifier may show that a change occurred, but they do not necessarily allow an investigator to reconstruct the prior operational reality.
Consider an instrument whose tolerance is revised after a risk assessment. Six months later, a reviewer needs to establish whether a calibration completed before that assessment was acceptable. The relevant question is not simply which tolerance appears on the instrument record now. It is which tolerance was effective when the calibration was performed, which procedure revision the technician followed, which reference standards were available, and whether the result was approved under the controls then in force.
A current-state model can easily apply present knowledge to past events. This creates a form of retrospective distortion. The record may remain technically consistent, while the historical account is wrong.
The same problem appears in software configuration. If a workflow rule changes, a record should not silently acquire the meaning of the new rule. If a specification is superseded, previously assessed results should remain linked to the version actually used. If a user’s authority changes, approval evidence must establish their authority at the time of approval, not only their role today.
An audit trail is necessary, but it is not the whole design
An audit trail commonly records who changed a field, when they changed it, and sometimes a before-and-after value. These controls are important. They support accountability, deter unauthorised alteration and provide evidence that a change took place.
They do not automatically make a system capable of reliable historical reconstruction.
Audit entries can be incomplete, difficult to interpret, or detached from the versioned records needed to understand their meaning. A log may show that an acceptance limit changed from 0.5 to 0.8, yet omit the approved change request, the applicable procedure, the reason for change, and the set of records affected. It may record a status transition without preserving the calculation inputs that produced it.
The engineering requirement is therefore broader than an append-only log. The system needs an intentional historical data model. This typically includes immutable or versioned records for controlled entities, explicit relationships between events and the versions they relied upon, and controls that prevent later amendments from rewriting completed evidence.
Electronic signatures and audit logs may form part of a compliant operating environment where applicable requirements call for them. Their adequacy depends on intended use, validation, procedural controls and the wider system design. Adding either feature to a mutable application does not, by itself, establish data integrity or regulatory suitability.
Two dimensions of time matter
Many systems record when information was entered or changed. This is often called transaction time. Regulated records frequently require a second dimension: when the information was effective in the real-world process.
A calibration procedure may be approved on 10 June but become effective on 1 July. A correction may be entered today for work performed last month. A supplier certificate may state that a reference standard was valid over a defined date range. These are different facts, and collapsing them into one timestamp loses essential meaning.
Bitemporal modelling addresses this by preserving both transaction time and valid time. It allows a system to answer questions such as:
- What did the organisation know on 15 March?
- What calibration interval was applicable to this asset on 15 March?
- When was that interval entered, approved or corrected?
- What would the system have reported had it been queried on that date?
Not every record requires full bitemporal treatment. It adds storage, query and interface complexity, and can make simple operations less simple. The appropriate scope follows from intended use and risk. Controlled specifications, approvals, measurement results, procedural revisions and status determinations often justify stronger treatment than low-risk convenience data.
Provenance must survive calculation and change
Historical reconstruction depends on provenance. For a reported measurement result, defensible provenance may include the raw reading, instrument identity, calibration status at the time of use, reference standard, environmental conditions where material, operator, timestamps, calculation method and software version.
If the system recalculates a result after a formula change, it should not replace the original assessed result without preserving both the original inputs and the method used. A corrected or superseding result can be appropriate, but it must be clearly identified as such, with the reason for correction and approval route retained.
This is particularly important where derived status is shown as a simple label such as compliant, overdue or failed. Labels are operationally useful, but they are conclusions. The underlying evidence, rule version and decision logic must remain available to explain how the conclusion was reached.
Systems such as Obsidian Metra are being designed around this distinction: a calibration record is not merely a current asset status, but a controlled body of evidence that must remain intelligible across later changes to assets, procedures and rules.
Design for investigation, not only operation
A sound test is to assume that an investigator arrives two years after an event. They need to establish the state of knowledge at the time, identify subsequent corrections, distinguish approved changes from unauthorised ones, and reproduce material calculations. If achieving this requires database restoration, manual comparison of exports and interpretation of informal notes, the system has not retained history in a dependable form.
This requirement should influence data architecture from the beginning. Define which entities are versioned, what constitutes a controlled change, how effective dates are represented, which calculations are reproducible, and how superseded records remain accessible without being mistaken for current instructions. Validate these behaviours against realistic scenarios, including correction, backdating, withdrawn approval, partial workflow failure and recovery from interrupted transactions.
Regulated software must do more than preserve a sequence of edits. It must preserve the historical basis on which people acted. That is what permits a record to be examined later without allowing the present to rewrite the past.