Designing Software for Evidence, Not Just Data
A record that says a calibration result was accepted, a batch was released, or an alarm was acknowledged is not necessarily evidence that the action was properly performed. In a regulated or high-consequence environment, the important question after an event is rarely limited to what value was stored. It is also whether the correct procedure applied, who acted, what information they saw, which system version was in use, who approved an exception, and whether the record has remained intact.
Software designed principally as a data store often cannot answer those questions. It may retain timestamps, user names and status fields, yet lack the context needed to reconstruct a defensible account. The distinction matters in audits, investigations, product-quality reviews and operational recovery. A technically functional system can still be unsuitable for its intended use if its records cannot support confidence in the process that produced them.
Evidence has structure
Data is an observation, value or state change. Evidence is the linked set of records that allows a reviewer to assess the validity and meaning of that data. A temperature reading, for example, gains evidential value only when its source, unit, acquisition time, sensor identity, calibration status, processing method and applicable limits can be established. If an operator overrides an alert, the reason, authority, time, original condition and subsequent review may all be material.
This means evidence must be modelled deliberately. A free-text note attached after the fact is not equivalent to a controlled decision record. Nor is an audit log, by itself, a complete evidential design. Audit trails are useful for recording attributable changes, but they do not define the procedure, enforce decision authority, establish the adequacy of a review, or prove that an instrument was suitable for use.
The software domain model should therefore represent the entities that matter to the controlled process: procedures, versions, roles, assets, measurements, limits, deviations, approvals, attachments and review states. Relationships between these entities must also be preserved. A result should identify the procedure instance under which it was produced, not merely reference the current version of a procedure that may later change.
Procedures and decisions must be executable in context
Where a process requires a defined sequence of checks, software should make the required path visible and enforce it where appropriate. This does not mean replacing engineering judgement with rigid workflow. It means distinguishing routine, permitted decisions from exceptional decisions that need additional authority or rationale.
A well-designed workflow records the state at which a decision was made. For an out-of-tolerance result, that may include the measured value, uncertainty where relevant, acceptance rule, equipment status, selected disposition, justification, and the reviewer who approved it. The system should not silently recalculate the status later using amended limits or altered configuration. Historical decisions need their original context preserved, while corrections should create new, linked records rather than rewrite the original account.
Electronic approvals require similar care. An approval has meaning only if the signer is authenticated, authorised for that action, presented with sufficient information, and bound to the specific record version being approved. Reusing a generic confirmation button across materially different actions weakens both usability and control. The interface should state what is being approved and any consequences of doing so.
Provenance is a system property
Evidence can be lost across boundaries. Measurements may originate in instruments, pass through gateways, be transformed by services, and appear in a browser-based application. At every stage, systems can alter precision, normalise timestamps, drop quality flags, substitute identifiers or merge records. A database row alone may not reveal these transformations.
Provenance design starts with stable identifiers and time handling. Source records should retain instrument or device identity, acquisition time, receipt time where useful, timezone or UTC convention, communication status and relevant quality indicators. Derived values should identify their inputs and processing method. If a calculation changes, records created under the previous method should remain interpretable.
This is particularly important for measurement systems. Raw values are not automatically defensible measurements. Sensor range, resolution, installation, calibration interval, reference standards, environmental conditions and uncertainty can affect whether a value is fit for a decision. Software need not duplicate every metrological control, but it must preserve the links and status information needed to establish measurement traceability.
Controlled change protects the record over time
The evidential quality of a system is tested most severely during change. Schema migrations, revised workflows, updated calculation libraries and identity-provider changes can all make historical records ambiguous or inaccessible. Retention is not enough if the organisation can no longer render, interpret or verify what was retained.
Design controls should include versioned configurations, migration records, access to superseded procedure definitions, and tests that demonstrate historical records remain readable after release. Changes to regulated functionality require proportionate impact assessment, verification and documented approval. The applicable requirements depend on jurisdiction, intended use and operating context, so authoritative regulations and guidance must be identified for the system in question rather than inferred from common terminology.
Security controls also support evidential integrity. Least-privilege access, separation of duties, protected service accounts, tamper-evident logging, backup restoration testing and monitored time synchronisation all reduce opportunities for undetected alteration or loss. No individual control is sufficient. The relevant assurance comes from the combined design, validation, operating procedures and review of the complete system.
Software built for evidence treats the record as an account that must survive scrutiny, not as a collection of fields that happens to be retained. That approach produces systems better able to support sound decisions at the time of use and credible reconstruction when those decisions are later examined.