Distinguish the kinds of change
Correcting a transcription mistake is different from repeating an experiment. Revising an interpretation is different from replacing the source observation. If the interface treats all of these as a generic edit, a future reader may be unable to reconstruct what happened.
The record model should describe which object is changing. It should also identify whether the activity creates a new record, a new version, or a related note. The choice needs to reflect the workflow rather than the convenience of one screen.
Explain what the reader needs to recognize
A reader may need to know that a value has changed, why it changed, and which version was used in a particular review. Those requirements are different from merely displaying the most recently saved text.
Describe the relevant roles and permissions as requirements for later implementation. A browser prototype can illustrate a change note and version relationship, but it does not establish a secure audit trail or enforce actual access controls. Keep the design intention separate from the system property that must eventually support it.
Keep references understandable
A comparison or handoff may refer to a record that later changes. The workflow should define whether the reference points to a particular version or to the current record. A silent change can alter the meaning of a past review.
Use scenarios to examine the difference. What does the recipient see when a referenced observation is corrected? How can they recognize the version they originally reviewed? The answers should be clear enough for an implementation team to assess the required behavior.
Document the rules before adding history screens
A long activity list is not automatically a meaningful change record. First specify the events, reasons, relationships, and visibility that the task requires. Then consider how the interface helps someone find the relevant change.
Formal record retention, electronic signatures, regulatory compliance, and security assurance need appropriate project-specific work. An early specification can identify those needs without claiming to satisfy them. Its role is to make the expected correction behavior reviewable before implementation is commissioned.
