Every submission checked the same way, every time.
Imaging and document submissions arrive from every site in a study, in formats nobody controls, on timelines nobody can slow down. Quantscope automates the checking and produces the evidence that the checking happened.
Six places the work is currently manual
- Submission intake QC
- Completeness, format conformance, series and sequence expectations, and protocol match, checked at the point of entry rather than discovered downstream.
- Metadata reconciliation
- Header against transmittal against tracking system, with disagreements surfaced as a query rather than propagated into the record.
- De-identification verification
- Confirming that what should have been removed was removed, burned-in text included, rather than trusting that the upstream step ran.
- Duplicate and prior detection
- The same subject, study or image arriving twice, across sources and across time.
- Provenance and manipulation checks
- Whether an image has been resaved, cropped or regenerated between the source and the submission.
- Reproducibility evidence
- A scored, versioned record of every check that ran, on what version of what rule set, with the result and the reason.
Built for a regulated context
The modules run under your quality system, not beside it: 21 CFR Part 11 for electronic records and signatures, computer system validation against the applicable GAMP 5 category, change control with a complete audit trail, and QA release.
| Deliverable | Purpose |
|---|---|
| Validation Plan | Scope, approach and responsibilities for the validation effort |
| User Requirements Specification | What the system must do, in your terms |
| Functional and Design Specification | How the system does it |
| Risk Assessment | Where failure matters and what controls answer it |
| IQ, OQ and PQ protocols | Installation, operational and performance qualification |
| Requirements Traceability Matrix | Every requirement traced to a test |
| Validation Summary Report | The evidence, summarised for QA release |
| Release notes and version history | What changed, when, and why |
The acceptance criteria in the statement of work are the same criteria the PQ tests. One agreed set serves both commercial acceptance and the validation record, which removes the gap where a system passes a demonstration and then fails qualification.
Model governance
- Frozen evaluation corpus
- A versioned corpus under the same change control as the code. Every model, prompt or threshold change is scored against it before release.
- Model identity in the release record
- Which model and which configuration produced a given result has a written answer, not a reconstruction.
- Drift monitoring
- Measured against a re-qualification threshold agreed in the statement of work rather than argued about afterwards.
- Human in the loop by design
- The review queue is the mechanism by which a qualified person owns every judgement the software cannot settle, not a fallback for when the model fails.
Questions a first review asks
Why would we go first with a vendor who has no references?
The structure answers it: fixed scope, fixed fee, acceptance criteria agreed before build, milestone billing. If the software does not meet the criteria it is not accepted and not billed. An established vendor on time and materials is paid whether or not the thing works.
The company page describes where the pipeline already runs in production.
Do you hold SOC 2 or ISO 27001?
No. Neither certification is held, and no report exists to send. Quantscope will not describe itself as SOC 2 compliant, which is not a state a company can be in.
The trust page states every status in plain language, including the negative ones, and what is available instead: a completed security questionnaire under NDA, and an invitation to audit before signature.
Where does our data go?
Under the preferred deployment, nowhere: the modules run inside your environment, against your storage, under your identity provider. Quantscope holds no client data and initiates no inbound connection.
Where a hosted deployment is required, region, retention and deletion are set in the agreement rather than left to a default.
Can we audit you?
Yes, and before signature rather than after. The right to audit is written into the agreement.
The trust page describes what an audit gets access to and how to schedule one.
Who owns what we pay you to build?
You own your configurations, your integrations and any model trained on your data, and you receive a licence to run the modules. Quantscope keeps the underlying platform and tooling, which is what lets the modules exist as products rather than one-off builds.
The split is written into the statement of work before work begins, not negotiated after delivery.
What happens if you stop operating?
Source escrow and documented handover are available as terms in the agreement.
Every engagement is scoped to end with software your team runs without Quantscope present, so continuity is a property of the delivery, not a promise layered on top of it.
How large is the team, and does that matter?
A founder and two contractors, stated plainly, because a vendor of this size presenting itself as larger fails diligence at the first question.
The protections that matter at this size are contractual: chain of title on the code, documented handover, optional source escrow, and engagements scoped to a finished end state.
Can you work under our SOPs rather than your own?
Yes, and that is the expected arrangement. The software is validated under your quality system, against the applicable GAMP 5 category, with your QA holding release.
Acceptance criteria, re-qualification thresholds and audit trail expectations are all written in your terms in the statement of work.
Start with the data
Send the data type, the volume, and what currently has to be checked by hand. If a module cannot be scoped against acceptance criteria, you will be told so rather than sold an engagement built around it. Write to info@quantscope.ai. Response within two business days.