Methodologies

Statistical validation evidence and reproducibility record

How Coventra records numerical validation evidence by comparing app outputs with direct R package results, what the current validation library covers, and what remains a human methodological responsibility.

16 min readUpdated June 16, 2026

What this validation evidence means

Coventra validation evidence is a reproducibility record for the current statistical implementation. It compares Coventra's prepared analysis inputs and displayed outputs with direct calls to the relevant R packages using the same dataset and method profile wherever that profile is available.

The goal is not to ask users to trust a proprietary calculation. The goal is to make the calculation path inspectable: raw validation input, direct R package output, Coventra analysis output, selected method profile, package version, and generated visual artifacts are kept together.

A successful validation checkpoint means the tested workflow produced the same numerical result as the direct package call for that dataset, scale, method profile, and package version, within the rounding used for display. It does not mean every possible dataset, design, extraction value, or user-selected method has been proven correct.

Important

This is validation evidence for tested implementations, not a blanket guarantee of statistical validity for every review. Review teams remain responsible for extracted data, selected methods, assumptions, interpretation, and manuscript claims.

How the validation library is structured

The validation library stores each test case as a small reproducibility package. The raw dataset is exported in Coventra's expected input shape, the corresponding direct R package result is saved, the Coventra analysis result is saved, and generated plots are archived separately from the numerical JSON output.

For each dataset, the validation record can include package-native defaults and recommended settings. Package-native defaults mean the installed R package version's own defaults. Recommended settings mean Coventra's explicit, documented settings for that analysis family. They should be reported by model, package, version, effect measure, and interval settings rather than by a broad label.

  • Input files preserve the Coventra rows and analysis settings needed to reproduce the comparison.
  • Direct R results come from package calls such as meta, netmeta, metafor, bayesmeta, or mada where the analysis family has a direct package analogue.
  • Coventra results come from the same statistical analysis service used by saved analysis runs in the app.
  • Stored fields include pooled estimates, confidence or credible intervals, tau-squared, I-squared, p-values, and model-specific outputs such as P-scores, posterior summaries, or diagnostic accuracy summaries when applicable.
  • Visual outputs are stored in a separate archive so figures can be inspected without embedding base64 images into the numerical result file.

Current coverage snapshot

The June 16, 2026 validation record contains 11 validation datasets. Public built-in datasets are used where available, and demo fixtures are used where the installed package library does not provide a compact public dataset matching Coventra's input schema for that analysis family.

The current validation set covers pairwise binary arm-level synthesis, pairwise continuous synthesis, generic inverse-variance synthesis, single-arm proportion synthesis, single-arm rate synthesis, single-arm raw mean synthesis, contrast-based network meta-analysis, arm-level binary network meta-analysis, Bayesian pairwise random-effects synthesis, survival hazard-ratio synthesis, and diagnostic test accuracy synthesis.

Validation coverage snapshot

Analysis familyValidation dataDirect R packageProfiles compared
Pairwise continuous mean differencemeta::Fleiss1993contmeta 8.5-0Package-native and recommended
Single-arm proportionmeta::Fleiss1993bin aspirin armmeta 8.5-0Package-native and recommended
Pairwise binary risk ratioMetadat/metafor BCG vaccine datametafor 5.0-1 and meta 8.5-0 comparison contextPackage-native and recommended
Generic inverse-varianceMetadat/metafor Berkey periodontal estimatesmetafor 5.0-1 and meta 8.5-0 comparison contextPackage-native and recommended
Contrast network meta-analysisnetmeta::Senn2013netmeta 3.5-0Package-native and recommended
Arm-level binary network meta-analysisnetmeta::smokingcessationnetmeta 3.5-0Recommended settings
Bayesian pairwise random-effects modelbayesmeta::Rubin1981bayesmeta 3.5Package-native and recommended
Diagnostic test accuracyCompact Reitsma bivariate-model fixturemada 0.5.12Direct bivariate-model comparison
Survival HR, single-arm rate, and raw meanSchema-shaped fixturesR package calls matching each analysis familyRecommended settings
Important

Demo fixtures are marked as demo data in the validation record. They are useful for checking integration, scale handling, and output shape, but they are not substitutes for published worked examples or external statistical review.

Package and method provenance

Each validation result records the analysis family, method profile, package name, package version, and selected or resolved settings returned by the statistical service. This matters because package defaults can change between versions, and a result is only reproducible when the package version and method profile are known.

At this validation point, the statistical environment reports R 4.3.3 and includes meta 8.5-0, netmeta 3.5-0, metafor 5.0-1, metamedian 1.2.2, mada 0.5.12, bayesmeta 3.5, rjags 4-17, gemtc 1.1-1, and brglm2 1.1.0. A separate Zenodo environment manifest can be used to cite the analysis environment, but a software-environment citation is not the same thing as peer-reviewed statistical validation.

  • Package-default mode means the installed package version decides package-controlled defaults.
  • Recommended settings means Coventra sends explicit settings documented in the methodology resources.
  • Manual settings means the user or advanced caller supplies exposed method settings explicitly.
  • Effect measure and estimand are not left to package defaults; generic and network contrast inputs require an explicit summary measure because the same TE/seTE values can represent different estimands.

Selected numeric agreement examples

The tables below show selected validation comparisons. Small differences are expected rounding differences between direct package output and the rounded values returned for display by Coventra.

These examples are included because they are easy to inspect: a pairwise continuous model, a single-arm proportion model, a Bayesian pairwise model with explicit recommended priors, and a diagnostic test accuracy bivariate model.

Pairwise continuous mean difference: meta::Fleiss1993cont, recommended settings

MetricCoventraDirect R package
Random-effects pooled MD-0.7509-0.750881
95 percent CI-1.7224 to 0.2207-1.722439 to 0.220678
tau-squared0.27420.274161
I-squared29.33 percent29.3302 percent
p-value0.09840.098444

Single-arm proportion: meta::Fleiss1993bin aspirin arm, recommended settings

MetricCoventraDirect R package
Random-effects pooled proportion0.10450.104461
95 percent CI0.0808 to 0.13400.080819 to 0.134011
tau-squared0.13010.130125
I-squared96.86 percent96.8579 percent

Bayesian pairwise: bayesmeta::Rubin1981, recommended priors

MetricCoventraDirect R package
Posterior median mu1.47291.472867
95 percent credible interval for mu-2.0614 to 5.0071-2.061377 to 5.007102
Posterior median tau0.33680.336815
95 percent credible interval for tau0.0156 to 1.11930.015649 to 1.119258
Posterior P(mu <= 0)0.20700.207021

Diagnostic test accuracy: Reitsma bivariate-model fixture

MetricCoventraDirect mada::reitsma
Pooled sensitivity0.80620.806201
Sensitivity 95 percent CI0.7480 to 0.85360.748007 to 0.853587
Pooled specificity0.89480.894804
Specificity 95 percent CI0.8564 to 0.92390.856350 to 0.923879
AUC0.90700.907009

What remains outside this validation claim

Validation evidence reduces integration risk. It does not remove the need to review the science. The same software can be numerically faithful to R and still produce an inappropriate result if the wrong input values, scale, design assumptions, or method settings are supplied.

For journal use, the review team should preserve the validation record, export the analysis data, report the package versions and settings, and obtain appropriate statistical or methodological review when the design or assumptions are complex.

  • The validation library does not prove that PDF extraction values in a user's project are correct.
  • It does not prove that the selected effect measure matches the protocol or clinical question.
  • It does not prove transitivity, proportional hazards, missing-data assumptions, exchangeability, or absence of selective reporting.
  • It does not replace published worked-example validation for every advanced design.
  • It does not convert local R-service validation into a guarantee that every production project workflow has been independently reviewed.

How reviewers should use this record

  1. Check that the analysis family and effect measure selected in the project match the review protocol.
  2. Confirm the package, package version, method profile, and effective settings saved with the analysis run.
  3. Inspect the extraction rows and source evidence for the studies contributing to the model.
  4. Use the validation resources to understand how Coventra's statistical output was compared with direct R package calls.
  5. Export the data and reproducibility materials when a statistician, methodologist, co-author, journal reviewer, or auditor needs to inspect the result outside the app.
  6. Describe the method specifically in manuscript text instead of relying on broad claims such as automated meta-analysis.