Methodology
How SynapseR thinks about clinical research methodology.
SynapseR's value is not in writing more text. It is in the constraints it applies to that text. Three of those constraints — reporting-framework alignment, R-powered statistics, and versioned audits — are described below.
EQUATOR alignment
SynapseR binds every methods section, statistical analysis plan, and protocol draft to the appropriate EQUATOR-network reporting framework for the study design.
For parallel-group randomised controlled trials, that is CONSORT. For cross-sectional studies, STROBE. For trial protocols, SPIRIT. The framework version is attributed in the output so that a peer reviewer or ethics committee can verify which guideline the draft was written against.
This is not stylistic decoration. The framework determines which items must be reported, in what order, and at what level of detail. SynapseR's methods generation is template-bound to those items, so the output passes the structural requirements of the framework before any human review begins.
When the EQUATOR network publishes updates, the underlying templates are updated. The labels on this site stay version-less so that the platform can keep pace with reporting-framework evolution without the public copy lying.
R-powered statistics
Power analysis in SynapseR is not estimated by a language model. It is computed in R — the same statistical environment biostatisticians have used for thirty years.
SynapseR's R service can run any R script the methodology calls for. Today, four power-analysis flows are wired through end-to-end with click-and-go user interfaces:
- Continuous endpoints: two-sample t-test (effect size as Cohen's d)
- Binary endpoints: two-proportion z-test (effect size from control and treatment rates)
- Cross-sectional prevalence: sample size from expected prevalence and margin of error
- Chi-square for association: from observed odds ratios or proportions
The full R statistical ecosystem — survival analysis, mixed models, multiple imputation, meta-analysis, Bayesian methods — is reachable from the underlying service boundary. Workflows for these will be wired progressively during the beta.
Errors come back in plain English (e.g. treatment and control rates are equal — effect size is zero), not stack traces. The signed effect direction is taken from the R output and used verbatim downstream so that the methods and SAP cannot disagree with the power calculation.
Versioned audits
Every major artefact in a SynapseR project — hypothesis, endpoints, power plan, methods block, SAP, protocol draft — is versioned. Nothing changes silently between drafts.
When you edit an artefact, a new version is created with a reference to the version it supersedes. The full lifecycle is queryable: which version was approved, which was locked, which was used to generate the next downstream artefact.
The Statistical Analysis Plan can be locked and versioned with a SHA-256 hash. This creates an audit trail for preregistration and protocol amendments: any change after the lock is visible by comparing hashes against the registered version.
This matters for two reasons. First, peer reviewers and ethics committees increasingly expect evidence that the analysis plan was specified before unblinding. Second, in a solo-clinician workflow without a CRO, the audit trail is the only thing standing between a defensible study and a re-litigation of every decision after the fact.
