Validated
In development — not open yet
A managed methods engagement with the people who build the engines, with qualified, signed releases and validation documentation — for HTA and regulated work where the engagement matters more than the binder. This page describes what it will be. Register your interest and we will tell you when it opens.
We are building it now, and this page sets out what it will be so that teams planning submission work can see whether it fits — and tell us what they would need from it while that is still an open question.
It will be a managed engagement with the engine authors, structured around contractual methods support for your team’s submission and regulated work. A qualified, signed release of the engine your work depends on, and the supporting validation documentation, will be included — they are what make the engagement defensible in a regulated procurement process — but the engagement itself is the offering. The release is the wrapper.
The reason to want it is that submission risk concentrates around getting a methods question right under pressure: a reviewer challenge to an extrapolation assumption, an audit query about a cure-model identification, an internal disagreement about which baseline family to use. Under Validated the engine authors will be on contract to answer those questions, fast and authoritatively, throughout the engagement.
Validation itself is rarely a formal requirement of the HTA agencies — NICE, CADTH, IQWiG, HAS scrutinise methods, not software. It is, however, strong practice for serious analytical work, and the internal quality processes that govern submission workflows in pharma, in CROs, and in mature HEOR consultancies typically require it before any new package can be used in regulated work. Validated supplies the documentation, the relationship, and the qualified release that make that practice straightforward.
Named experts on contract
Engagements will be led by the people who designed the engines. Each engagement will have a named technical contact from the engine team and a defined response SLA for methods questions, reviewer-response support, audit queries, and methods-specification advice.
Michael Crowther
Author of the original Stata merlin (Crowther, Stata Journal 2020), of the merlin for R rewrite, and of the methodological work the package is built on. Available as the named technical contact for new Validated engagements.
Methods access and a qualified release
Two distinct things in one engagement. The methods access is what you sign for; the qualified release is what makes the engagement defensible in a regulated procurement process.
The evidence underneath both is public, and it is not a summary written for this page. The R packages publish what their test suites check: what merlin’s test suite checks →, which packages its results are compared against, at what tolerance, and where no external check exists at all. Every engine in the family carries a certification suite — scripts that assert rather than eyeball, each naming the implementation it was checked against and the tolerance it holds to, and each suite keeping a conformance record that lists the places the answer deliberately differs alongside the places it agrees. merlin for Stata ships its suite in the public package repository, where anyone can run it; gawain’s conformance record is on its page →. A qualified release is that apparatus, signed and pinned — not a separate exercise performed for the binder.
The engagement itself
- Named technical contact from the engine team
- Defined response SLA for methods questions and issues
- Contracted methods hours for specification and review
- Reviewer-response support during submission cycles
- Scope for bespoke methodology under the same engagement (in Strategic partnership)
The procurement wrapper
Each release is built from a tagged, signed commit with a deterministic pipeline. Clients will receive the artefact, the build manifest, and the signature, and can reproduce the artefact at any time.
We write analysis plans as a structured register rather than a prose document — the estimand, populations, endpoints and causal assumptions each recorded as a field a reviewer can read — checked and frozen before any result exists.
Three shapes, same offering
Same methods access and qualified-release wrapper across all three shapes. They differ in scope, duration, and the depth of the relationship.
Submission support
Scoped to a specific submission cycle. Right for teams using one of the engines on a defined deliverable: one NICE submission, one regulatory filing, one HTA dossier.
- Single named-expert contact
- Standard SLA
- Qualified release and documentation
Methods retainer
Ongoing access across multiple projects. Right for organisations running multiple submissions or methods projects per year where the methods relationship has compounding value beyond any single deliverable.
- Higher contracted methods hours
- Expanded named-expert access
- Quarterly methods review
Strategic partnership
Across a programme of work. Right for organisations standardising on the merlin family across multiple teams or building a long-term methods capability with the engine authors.
- Dedicated named-expert team
- Custom SLA · training included
- Bespoke methodology hours
Pricing will be per engagement and discussed directly with each prospective client. Shape, named-expert allocation, contracted hours, and SLA terms will be agreed during the initial conversation. There is no self-serve subscription path — every engagement is a relationship.
What we can answer now
Is this just consulting?
The methods access at the core of the engagement is the kind of work an experienced methods consultancy provides. What Validated will add is the qualified release of the software, the evidence pack that travels with it, the contracted SLA, and the long-term relationship structure — the things that make the engagement defensible in a regulated procurement process and that don't fall out of a one-off consulting brief. Teams who don't need those wrappers should reach out about standalone methods consulting instead.
What if I only need the qualified release and not the methods support?
A “release-only” structure is planned for teams that have their own methods capability and just need the procurement wrapper, and it will be priced below the full engagement. Register your interest → and say that is the shape you want — which shapes get built first depends on what people ask for.
Is this the same software as the open-source releases?
Yes. A Validated release is built from the same source tree as the open-source release, pinned at a tagged, qualified version. The methodological behaviour is identical; what's added is the qualification, documentation, support, and named-expert engagement around the release.
Can we use the open-source release for some work and Validated for submission work?
Yes — that is the intended split. The open-source package is appropriate for methods development, exploratory analysis, and academic use; the Validated release is for the artefacts that go into the submission and the qualification record.
Do you support both R and Stata under Validated?
Yes. A Validated release covers both the R and the Stata package for the engine in scope — for merlin, merlin for R and merlin for Stata — with shared documentation and a single named-expert team across both.
When does it open?
We are not naming a date here until the qualification pipeline and the documentation are finished, because a date on a page is a promise and this one is not ready to be made. What we can say is who hears first: everyone who has registered an interest, directly, before it is announced anywhere else.