ORIGINAL COMPANY-CONTEXT PRACTICE
Make a batch review record immutable
Original practice scenario inspired by Amgen Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A fictional biotechnology manufacturing tool collects review evidence for a batch. Several reviewers may update records while an approval is being recorded. Design versioning and tests for a trustworthy software audit trail; do not define clinical or regulatory policy.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Bind a review action to an exact evidence version. An approval should not float forward automatically when measurements or supporting documents change after the reviewer saw them.
Work through it
- Store immutable evidence versions with checksums and provenance. Use an optimistic concurrency token so approval fails clearly if its reviewed version is no longer current.
- Record reviewer identity, timestamp, decision, and referenced version in an append-only action log. Separate software authorization from the organization's approval policy.
- Test simultaneous edits, duplicate approval submissions, withdrawn evidence, and recovery after a response is lost. A new evidence version should trigger the defined re-review state.
Tradeoffs to discuss
- Immutable history increases storage and user-interface complexity but makes changes attributable. Deleting or correcting sensitive records needs a documented retention process.
Common pitfalls
- A timestamp alone does not identify reviewed content.
- Updating a previously approved record in place destroys the connection between evidence and decision.