Part 1 · The review, stage by stage

1.8Synthesis

The Analysis stage pools the values a person has validated, keeps every run with its settings and a fingerprint of the data it used, and leaves the reading of the result to you.

Manual v1.0 · Last changed 2 November 2026 · Method: Statistical analysis, Network meta-analysis, Ecology meta-analysis, Qualitative synthesis

What it does

The Analysis tab supports pairwise meta-analysis, common sensitivity checks, publication-bias views and qualitative synthesis outputs, with network meta-analysis and ecology/evolution synthesis on their own paths. You choose an outcome, a timepoint and an effect measure; the statistics assistant fetches the matching rows, runs the fixed-effect or random-effects model the protocol names and returns the forest plot, heterogeneity, study weights and diagnostics. By default it pools only values a named person has validated. Every run is kept with the selection and options it was asked for, the model it fitted, a fingerprint of the exact rows it used and who started it. It never decides whether a pooled estimate is sound: you interpret each result, pin the outputs the team reviewed to the Evidence board, and the report is built from those pins.

www.axelium.aiAnalysis
The results of one analysis run: the run summary, the model fit summary with Trace lineage, and the contributing studies
  1. 1. What the run pooled: the timepoint, the measure, the method and the number of studies.
  2. 2. The model fitted on the selection: the pooled estimate, its interval, I² and τ².
  3. 3. Trace lineage follows a pooled estimate back to the rows and quotes it used.
Fig 1The Analysis tab's results for one run: what was pooled, the model fitted on it and the studies that contributed. Captured 2 Nov 2026

What you do

What gets pooled

A pooled analysis is keyed by three things: the outcome, the timepoint and the effect measure. Values that share all three are pooled; values that differ in any of them are not, so a change score and an endpoint value, or a six-week and a twelve-week result, never land in the same model. Ratio measures are pooled on the log scale and reported back on the ratio scale (pairwise pooled analysis).

By default only validated values are pooled: a value counts once a named person has validated it on the Extraction page, and a value that was rejected, or whose validation was cleared by a later extraction, is left out. Each run and its header say which scope it used, Validated only or Includes unvalidated data, so a result can never pass as validated when it was not. The default can be changed for a review (see Settings).

Run an analysis

  1. Open Analysis and choose the outcome, timepoint and measure in the dataset picker. The picker only offers combinations that have data in the scope you chose.
  2. Start with the starter prompts: they keep common analyses one click from the dataset summary.
  3. Read the model summary and the forest plot together: the pooled estimate and its interval, I², τ², the study weights and the direction of benefit. Always check heterogeneity before interpreting the pooled estimate; above 75% the summary number may mislead, and a subgroup analysis is the next step, not a conclusion.
  4. Open Trace lineage on two or three pooled estimates and follow each back to the source document snippet. It is the fastest way to catch an arm swap, a unit mismatch or a subgroup-versus-overall mix-up before anything is reported.
  5. If the result is unstable, go back to eligibility, effect measures, extraction and subgroup assumptions before reporting it.

Plausibility flags and the review queue

A value whose effect looks implausible is held before it reaches a model. On the Extraction page such a value is filed under Needs you, with the reason beside it, and is left out of Validate all; the review queue lists it for a person to decide. Until its numbers change or a person validates it from the form, it is not a validated value and a validated-only run does not use it. The queue itself is described in Extraction and traceability.

Sensitivity, subgroups and publication bias

  • Run sensitivity analysis before finalising. Leave-one-out shows whether a single study drives the result; comparing estimators shows whether the choice of τ² method matters.
  • Do not skip publication bias when there are ten or more studies. Below ten the tests lack power; above ten, report it.
  • Label exploratory analyses as exploratory in the report, and justify the model from the protocol and the data, not from the result you prefer.

Network and ecology meta-analysis

A network meta-analysis is set up in three steps on its own tab: check the data, confirm the treatment groups, then run the analysis for one outcome at a time. Each outcome runs on its own settings, and an outcome without a measure, a direction of benefit, a reference treatment or a follow-up window does not run; the setup page says which is missing. The analysis runs only after every automatically grouped arm it uses has been confirmed, and each result stays a draft until the outcome is locked. The method is on the network meta-analysis page and the walkthrough in the worked example.

Ecology and evolution reviews default to a pairwise random-effects model and switch to a multilevel model when effects are dependent, with an optional additive meta-regression on recorded moderators. Results are reported on the measure's natural scale with its null anchor, and certainty is narrative rather than clinical GRADE. See ecology and evolution meta-analysis.

Early access
Early access. This works today for teams that have asked for it; ask us to turn it on for your workspace. What it does and records may still change.
Ecology and evolution synthesis.

Custom analysis and the Analysis Workbench

When a method falls outside the curated toolset, you can run your own. A single custom script runs inline; a larger job can be handed to the Analysis Workbench, which works through it in the background and reports live progress in the chat. Both run against a frozen, versioned copy of the same dataset, with network access disabled, and both require your explicit approval before any code executes. Their outputs are user-defined results: they appear beside curated results with a distinct “User-defined” badge and never feed certainty ratings or generated reports. A custom analysis you intend to cite can be frozen as a re-runnable recipe that captures the code, the package manifest and the frozen data. Details: custom analysis and the Workbench.

Narrative and qualitative synthesis

Where enabled for your workspace, a review whose evidence is coded rather than pooled synthesises it on the Qualitative page: passage coding with verbatim provenance, theme development and CERQual confidence in each finding. The AI drafts the descriptive groundwork; analytical findings and every confidence rationale are reviewed, edited and finalised by the review team. The method is on the qualitative synthesis page; the ratings are in Certainty.

Axelium does not check comparability before a run: whether the studies selected for one model share a population, a comparison and an outcome definition is your judgement.

Planned
Planned: not yet available. This describes what is coming and may change before it ships.
A comparability gate before pooling: a check that the values selected for one model share a population, a comparison, an outcome definition and a measure, with the reasons a run was refused or allowed kept with it.

Outcomes summarised without pooling

An outcome with fewer than two validated rows a meta-analysis can use (a single study, or studies that report an effect without its uncertainty) can be summarised instead of pooled. The Not pooled tab of the Analysis page lists every such outcome with the reason the data suggests. Summarise asks the assistant to count the direction of effect across the outcome's studies: how many favour the intervention, how many the comparator, with a sign test on the count and the same count over the studies at low risk of bias. Vote counting by statistical significance is never done. The result is one templated sentence, a per-study table and an effect-direction plot, and the reason the outcome was not pooled is recorded with it. The Overview offers this step when validated outcomes exist and none can be pooled.

Each summary is a draft until a person reviews it: open it from the tab, change the reason or add limitations while it is in review, and finalise it. A finalised summary stays as it was when a later run summarises the outcome again; reopen it to take the new result. The plot pins to the report like any plot. The method is on the statistical analysis page.

Pin the evidence

Pin plots, model summaries, dataset views and important explanations to the Evidence board as you go; it is easier to build the report from pinned outputs than to scroll back through the chat. A pinned output is traced to the run that produced it. If you rerun a model after changing data or assumptions, pin the updated evidence and explain the change.

Find a figure or table again

Figures and tables, under Analysis in the review's sidebar, lists everything the review's analysis runs and the assistant made: forest and funnel plots, charts, tables, data views and the assistant's answers. Search it by outcome, method or number (“mortality 0.78”), narrow it by kind or by who made it, and open an item to see it large with its caption, where it came from and every earlier version of the same outcome with its pooled estimate. From an item you can open the analysis it came from, pin it to the report, download the figure (and, for a meta-analysis, the per-study data as a CSV file), or remove it from the list. A removed item leaves the list and the assistant's searches; the result itself, its run and anything pinned from it stay.

An item whose pooled studies changed after it was made is marked Data changed since, with Re-run analysis beside it; the page says how many are. An item made before an unrelated change, to a study its run did not pool, is not marked.

Figures in the assistant's answers

Both assistants can find an earlier figure or table and name it in an answer. A named figure appears as a small button in the text: open it to see the figure or table beside the answer, or go to it on Figures and tables. A name the assistant could not match to anything of this review is shown as plain words, never as a link.

Settings

The review settings that change this stage are the endpoints, their effect measures and directions of benefit, the analysis defaults, and for a network review the treatment groups and each outcome's reference treatment and follow-up window. They are described in Review settings and history.

The validated-only default

Unless a review says otherwise, an analysis pools validated values only. A review's analysis defaults can turn that default off, so unvalidated values are included unless a run asks for validated values only, or forbid unvalidated analysis altogether, so every run is validated-only whatever it asks for. Changing the default changes nothing about runs already made: each run keeps the scope it used, and the Sign-off status page counts a review that pools unvalidated values as not requiring validation of its values.

Settings are versioned (earlier results).

What is recorded

Every run is a record of its own, kept whether it succeeded or failed.

RecordWhere you see itExported in
Each run: the outcome, timepoint and measure selected, the options asked for, the model fitted, its status, who started it and when it started and finishedAnalysis › Run history; the run headerThe report, through pinned outputs
The data fingerprint: a hash of the exact rows the run used, with how many studies, which fields and which row identifiersKept with the run; Trace lineage lists the rows it covers—
The scope of each run: Validated only, Includes unvalidated data, or Scope not recorded for older runsAnalysis › Run history and the results panel—
The analysis environment and package versions the run usedKept with the run—
Every tool call a run made, its inputs and its outputs, in orderAnalysis › Activity—
Each figure, table and answer a run or the assistant made: its title, caption, kind, who made it and when, the run it came from, and the version it replacedFigures and tablesThe organisation export
For a published version of a review, every figure its report carries, each with a checksum of the figureThe published version’s manifestThe published version
Each outcome summarised without pooling: the reason it was not pooled, the per-study directions, the count and sign test, the limitations, who finalised it and whenAnalysis › Not pooled; Sign-off statusThe report, through the pinned plot and the sign-off appendix
Each output (plot, table, model summary, dataset view) and the run and tool call that produced itAnalysis › Plots and Results; Trace lineageThe report, when pinned
Pinned outputs: which outputs are report evidence, as a snapshot taken when pinnedEvidence boardThe generated report
A network outcome lock: the treatment groups, settings and evidence an outcome was locked with, and a run marked out of date when they changeAnalysis › Network; Sign-off statusSign-off CSV/NDJSON
Confirmation of automatically grouped treatment arms, who confirmed and whenAnalysis › Network set-up; Sign-off statusSign-off CSV/NDJSON
A custom run: your approval, the code, the package manifest and the frozen dataset version it ran onAnalysis › the run; Recipes—
An extracted value changed from the Analysis stage: the edit, by whom, with the validation kept and the override recordedExtraction › the value’s historySign-off CSV/NDJSON
A plausibility flag and its resolution: Keep, Re-extract or Reject, who decided and the reasonExtraction › Review queue; the value’s historySign-off CSV/NDJSON

Approvals made from this stage, the network locks and the arm confirmations, are listed with the rest of the review's record in Audit trail and history.

Limits

Statistical limits

  • Small numbers of studies make heterogeneity, asymmetry and subgroup checks unstable.
  • A single multi-arm randomised trial can provide direct comparisons but cannot estimate between-study heterogeneity or independent inconsistency. Its shared-arm comparisons are correlated, so a three-edge triangle is not three independent trials. Prediction intervals and rankings are withheld in this case; a displayed numerical zero would not establish homogeneity.
  • Effect measures, timepoints and direction of benefit must be harmonised before pooling; the app keys a model by them but does not convert between them for you.
  • Model choice should be justified by the protocol and data, not selected after seeing the preferred result.
  • The app does not judge whether a pooled estimate is clinically meaningful, or whether the studies were comparable enough to pool.
  • A summary without pooling gives every study one vote whatever its size or precision and says nothing about the size of the effect. An outcome whose better direction is not set in the review settings is counted as higher or lower, not as favouring an arm. A summarised outcome has no automatic certainty rating; the review team's own judgement goes in its limitations.

Custom (user-defined) analyses

  • User-defined results never feed certainty-of-evidence assessments or generated reports; treat them as exploratory until independently verified.
  • Reproducibility depends on the recorded package manifest; methods from third-party or unpublished packages carry that package's own correctness risks.

Figures and tables

  • Data changed since means the studies the run that made an item pooled changed after it ran, or the check could not be made for a run made before the check existed; it does not say what changed or whether the result would differ.
  • A removed item cannot be brought back from the page.
  • Items made before Figures and tables existed are listed once they have been catalogued, and an earlier run of the same outcome appears among an item's versions only from then on.
  • In the public demo the list is read-only, and the assistant's answers listed are only your own.

Network meta-analysis

Network setup warnings, multi-arm study caveats, sparse evidence and inconsistency signals should prompt methodological review before results are reported.

  • A network in separate parts cannot compare treatments across the parts; consistency cannot be assessed without independent indirect evidence. A loop drawn entirely by the arms of one multi-arm trial is not an independent evidence loop. Both are said plainly rather than estimated around.
  • A treatment group excluded from the network is left out of every outcome.
  • Randomised roster numbers stay distinct from outcome numbers; reviewers must confirm a denominator's population rather than borrow a count from another outcome.
  • Results are drafts until an outcome is locked. Locking, or finalising the certainty review, fixes that outcome's treatment groups, settings and evidence; other outcomes stay open. A run whose evidence or settings changed since is marked out of date.
Living network reviews
One-off network preparation and synthesis is not recurring living-review network automation. Scheduled living-review cycles still import, screen and extract new evidence for network reviews, but pairwise statistical comparison is paused for them so pooled results never mix different treatment comparisons. See Living reviews.

Ecology and evolution

  • Phylogenetic meta-analysis is not supported.
  • Moderator meta-regression is additive only; interaction terms between moderators are not fitted.
  • A total heterogeneity summary with prediction intervals is reported for multilevel models; a partitioned breakdown across variance components is not.
  • When sampling covariances among dependent effects are not supplied, those effects are treated as independent and the pooled uncertainty may be understated; this assumption is shown on the result.

Qualitative and mixed-methods synthesis

Coding, theme development and CERQual ratings are reviewer-owned; drafts accelerate the groundwork, and the review team finalises every finding.