The revision request versus the revision
A change request says what the revision is supposed to do: update step 6.3, add a new safety note. The revised SOP is what actually changed, and the two are not always the same. QA sign-off should be on the actual difference between the two versions, not on the description of it.
The review in practice
- Upload the current effective SOP as the older version and the proposed revision as the newer one.
- Read the change list. It should contain the items in the change request and nothing else.
- Attach the redlined PDF to the approval record as evidence of what was reviewed.
- Use the side-by-side view for training, so staff see the old and new step together.
Why determinism matters here
A comparison that depends on a language model can produce different output on different days. In a regulated QA process that is a problem: the record of what was reviewed must be reproducible. The engine here is rules-based, and the same two documents always produce the same change list.
Beyond SOPs
The same review applies to work instructions, validation protocols, batch record templates and specifications. Enterprise deployments run inside the company's own infrastructure with pinned versions, which supports IQ/OQ documentation.
Try it on your own documents. Upload two versions on the homepage. Documents up to 30 pages need no account, and nothing is stored.
Industry page: PDF comparison for pharma and life sciences