Current direction · Clinical / GxP

When an approved document changes again, where does that evidence live?

The change request sits in eQMS, the test result in a folder, the review in email. PairTrace takes those exports, binds them into one post-approval change, and returns a package your team can re-check.

Share one post-approval change See the workflow

Sponsor QA / CSV / validation is the primary buyer. CRO QA and data management are secondary. Software vendors are informants and referral channels. Current stage: 10-minute problem interviews. We test the problem before building further — this page is not a sales offer.

change · CHG-017 illustrative

01
approved_document_v3.pdf state: approved
02
change_request_017.pdf source: customer export
03
validation_test_017.json slot: present · digest: recorded
04
approved_document_v3.1.pdf supersedes_event_id: evt-approved-v3

Illustrative lineage only. It is not a customer case, a clinical/GxP case, or a compliance verdict.

package root →

One change, across the systems that already exist.

Each system can keep its own audit trail. The unresolved work begins when QA must reconstruct the evidence trail for one change across those boundaries.

The work today

Find, connect, and explain the change by hand.

The change request may sit in eQMS, the requirement in a document file, the test result in a folder, the review in email, and the vendor material in a portal. QA still has to show what changed, what it replaced, what was tested, who reviewed it, and who re-approved it.

PairTrace’s role

Complete the last mile of evidence.

PairTrace is a vendor-neutral, cross-system evidence layer. It receives customer exports, records declared gaps and correction lineage, and returns a customer-owned package with deterministic, customer-runnable internal-consistency checks.

A post-approval change, reconstructed in four stages.

The first scope is manual and bounded. PairTrace does not claim live integrations or automatic collection that do not exist.

1.0

Receive the exported source set.

The customer submits the previous approved version, change request, review, test, correction, re-approval, and relevant vendor outputs through an agreed safe path. Collection is manual.
2.0

Bind the declared evidence slots.

A customer-approved, change-specific evidence schema defines what to look for. PairTrace reports each declared slot as present, missing, or unresolved; it does not decide what evidence the customer must require.
3.0

Record what replaced what.

The append-only event chain records correction lineage through supersedes and replaces. Structural comparison stays limited to deterministic path and hash differences; business meaning remains with human reviewers.
4.0

Seal the package and check it locally.

The Evidence Package contains the event trail, linked source files, gap ledger, HTML review annex, exact-set manifest, package root, and a local verifier. The customer keeps the copy and can re-check internal consistency without a PairTrace account.

The package answers factual questions first.

It shows what was submitted, what is linked, what is missing, what superseded an earlier record, and whether the protected package still matches its manifest.

Source inventory: Customer-submitted files, declared identifiers, byte sizes, and SHA-256 digests.
Correction lineage: The record that was superseded, the correction that replaced it, and the resulting effective state.
Gap ledger: Declared evidence slots marked present, missing, or unresolved without inventing absent provenance.
Independent check: A local verifier recomputes the protected file set, hashes, package root, report binding, and receipt consistency.

manifest.json internal checks · pass

{
  "change_id": "CHG-017",
  "correction": {
    "replaces": "evt-approved-v3"
  },
  "declared_slots": {
    "present": 5,
    "missing": 1,
    "unresolved": 0
  },
  "verification": "local"
}

Illustrative structure, not a customer result. A passing integrity check does not establish GxP conformity, evidence sufficiency, approval, correctness, legal validity, or independent witnessing.

What PairTrace does, and what stays with your team.

The product boundary is part of the output contract, not a footnote.

Existing systems: PairTrace does not replace eQMS, DMS, eTMF, EDC, LIMS, document authoring, electronic signatures, or approval workflows. It works outside those systems on one cross-system change event.
Collection: Today, PairTrace receives customer-exported materials. It does not claim automatic connectors or live production collection.
Evidence requirements: PairTrace checks the evidence slots the customer declares. It does not decide which evidence is required or sufficient.
Review and approval: GxP conformity, evidence sufficiency, approval, and business acceptability remain with customer QA and qualified human reviewers.
Integrity: Local verification establishes package integrity and internal consistency within the recorded boundary. It is not an external signature, trusted timestamp, legal opinion, or certification.

Current direction and technical references are now separate.

The existing public artifacts remain useful proof of mechanics. They are not presented as current clinical customer evidence or proof of demand.

Technical proof · domain-neutral core

Verify the public process-integrity sample.

The synthetic sample uses an earlier screening-era scenario to prove package mechanics: append-only events, protected files, manifest binding, package root, and local verification. It is not a clinical/GxP case or a market signal.

Verify package mechanics

Historical reference · hiring AI

Open the first reference pack.

The hiring demo preserves the first working PairTrace package and its truthfulness boundaries. It remains a regression and format reference; it is not the current market or offer.

Open historical hiring pack

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. 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 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 workflow