Your role names. The evidence list this change should satisfy. The content of each step.
Current direction · Clinical / GxP
When an approved document changes again, where does that evidence live?
Each system keeps its own records well. The part no one owns is between systems.
Each system manages the records inside its own room.
But the evidence for one post-approval change crosses several rooms.
No one owns the space between rooms. Today a person reassembles it by hand.
PairTrace takes one such event and bundles the scattered evidence.
And you can re-check that bundle yourself, without us.
One post-approval change, bundled in four stages.
-
1.0
Receive the exported records.
You send the previous approved version, change request, review, test, correction, and re-approval through an agreed path. Collection is manual.
-
2.0
Bind the evidence you declared.
Your own evidence list defines what to look for. Each declared slot is reported present, missing, or unresolved.
-
3.0
Record what replaced what.
An append-only event chain records the correction lineage, including the review that first blocked the change.
-
4.0
Seal it, then re-check it yourself.
You keep the package — event trail, source files, gap ledger, review annex, manifest, package root, and a local verifier. No PairTrace account is needed to re-check it.
Who decides what.
The engine never reads the meaning of what you submit. That is why the same engine serves a test-method revision and a software release.
Bundle the scattered evidence into one event and seal it. What we check is structure — declared evidence present or missing, digests matching, order intact.
Whether the content is right is not judged here — that stays with your team and qualified reviewers. PairTrace does not replace your eQMS, DMS, eTMF, EDC, or LIMS, and it is not a certification or a legal opinion. Recorded times are the ones whoever submitted them stated.
Questions that define the fit.
Can one existing system already export the complete trail?
If one system can immediately export the previous version, change request, review, test, correction, re-approval, and their relationships as a complete package, that change is probably not a PairTrace problem.
Does PairTrace connect to our eQMS or LIMS today?
No live connector is claimed. The first bounded scope receives customer exports. A cross-system connector is a direction being tested, not a shipped feature; where a future connection should begin can only be decided from repeated customer work and an explicit customer request.
What does the public verifier prove?
It proves that the protected file set, hashes, package root, report binding, and receipt are internally consistent. It does not re-derive the event chain, role authorisation, or sequence, so a package rebuilt end to end from altered content can pass — compare the package root you retained separately. It does not prove that the underlying change was correct, compliant, sufficient, approved, or independently witnessed.
What happens in the first conversation?
A 10-minute interview about one recent post-approval change: where the evidence lived, who assembled it, what took time, and whether one system could already produce the complete trail. Do not send files, real data, credentials, or confidential output.
Start with one change that was already approved, then changed again.
Share the workflowSee it working: verify a synthetic sample in your browser the first reference pack (hiring)