Part 7 · Reference
Feature availability
What Axelium does today, one line per capability, with the section of the manual that describes it.
How to read this page
Each row has a stable reference you can quote, the capability in one sentence, its status and a link to the manual. Available means it works in every workspace. Early access means it works for teams that have asked for it. A reference is never reused: a changed capability keeps it; a withdrawn one leaves this page but keeps it.
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.
1.1 Question and protocol
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| PROT-01 | A review question is framed with PICO, PEO, PECO, PICOC or PO, and each element of the framework becomes one screening question. | Available | 1.1 Question and protocol |
| PROT-02 | SPIDER, SPICE and PICo frame qualitative and mixed-methods questions. | Early access | 1.1 Question and protocol |
| PROT-03 | The protocol records inclusion and exclusion criteria as one yes/no question per element, each with where it comes from and where it is asked and required. | Available | 1.1 Question and protocol |
| PROT-04 | The search plan carries the protocol’s limits on study design, species, language and date range. | Available | 1.1 Question and protocol |
| PROT-05 | Save and lock checks the protocol before it is locked, lists what is missing or could be better, applies the fixes you tick and keeps a locked copy of the settings as report evidence. | Available | 1.1 Question and protocol |
| PROT-06 | Once the protocol is locked its settings stay as signed off and nothing changes them, not a page, the configuration assistant, a search preview or a screening suggestion. | Available | 1.1 Question and protocol |
| PROT-07 | Unlocking a locked protocol or search strategy requires a reason, which is recorded and shown on the review’s Versions page. | Available | 1.1 Question and protocol |
| PROT-08 | Every save of the settings is a new version, with who saved it, when and what it changed, and any earlier save can be restored as a new version. | Available | 1.1 Question and protocol |
| PROT-09 | The configuration assistant proposes settings and reads an attached published review with page references, and changes nothing until you confirm. | Available | 1.1 Question and protocol |
1.2 Search and sources
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| SRCH-01 | Locking freezes the queries exactly as saved; automated runs refuse to start while the strategy is unlocked, and unlocking asks for a reason that is written to the review’s record with who acted and when. | Available | 1.2 Search and sources |
| SRCH-02 | The plan’s MeSH headings are checked against the MeSH vocabulary before they are used, and the entry terms of each valid heading are added to the query as text synonyms. | Available | 1.2 Search and sources |
| SRCH-03 | The PubMed and ClinicalTrials.gov query strings are editable: change a query, choose Save, and that is what the next search runs. | Available | 1.2 Search and sources |
| SRCH-04 | PubMed and ClinicalTrials.gov are always searched; Europe PMC, Cochrane CENTRAL (approximated from PubMed), OpenAlex, Semantic Scholar, ERIC and MAUDE are searched when chosen. | Available | 1.2 Search and sources |
| SRCH-05 | A review holds at most 5,000 records from all its searches, next batches, database panels, citation chasing and imports together, and one search adds up to the PubMed record limit of 1,500, 2,000 or 3,000 records. | Available | 1.2 Search and sources |
| SRCH-06 | Every record that arrives is matched against the records already in the review by DOI, then PubMed id, then registry number, then normalised title and year; a match is noted on the existing record, never added again. | Available | 1.2 Search and sources |
| SRCH-07 | Each search run records the query sent to each database, what it added of what each database has, and whether it is done, incomplete or failed. | Available | 1.2 Search and sources |
| SRCH-08 | Refine queries rebuilds the queries from the existing plan, keeps your edits to it, follows the note you write beside it and starts from the open findings of a search review. | Available | 1.2 Search and sources |
| SRCH-09 | Before the full search runs, a small sample from each source is screened against the review question and the share that matched is shown on the Search page. | Available | 1.2 Search and sources |
| SRCH-10 | RIS and BibTeX files are imported with a preview of new and duplicate references, and every record is exported as RIS or BibTeX from the Search page. | Available | 1.2 Search and sources |
| SRCH-11 | Start the search over hides every record and sets the searches aside, keeps the strategy, the team and the history, and can be undone for 10 seconds. | Available | 1.2 Search and sources |
| SRCH-13 | Importing a database’s own export file records the database, the platform, the search date and the strategy as run, which becomes a version of the review’s search strategy. | Available | 1.2 Search and sources |
1.3 Screening
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| SCRN-01 | The AI screens each record’s title and abstract against the review’s criteria and records a verdict, its confidence and the passage it relied on per criterion. | Available | 1.3 Screening |
| SCRN-02 | In single-reviewer mode, the default, an AI title and abstract decision stands unless a person changes it. | Available | 1.3 Screening |
| SCRN-03 | AI + human and two-human modes ask a person to decide every record, blinded to the other reviewer’s decision until their own is recorded. | Available | 1.3 Screening |
| SCRN-04 | A re-screen never overturns a person’s decision. | Available | 1.3 Screening |
| SCRN-05 | A decision against the AI’s suggestion, or one that takes a decision back, asks for a reason that is kept in the record’s history. | Available | 1.3 Screening |
| SCRN-06 | Several records can be decided together; a bulk decision keeps the reason with each record that needed one. | Available | 1.3 Screening |
| SCRN-07 | When two people decide the same record differently it goes to the conflicts queue, and a lead reviewer who was not one of them rules with a recorded reason. | Available | 1.3 Screening |
| SCRN-08 | A lead reviewer can split screening work by phase and reviewer slot so each person sees a focused queue. | Available | 1.3 Screening |
| SCRN-09 | Every screening decision is recorded with who made it, when, in which phase, whether it confirmed or went against the AI, and its reason, and is exported in the approval record. | Available | 1.3 Screening |
| SCRN-10 | Each AI verdict is recorded with the model and prompt version it was made with. | Available | 1.3 Screening |
| SCRN-11 | Study protocols, methods-only papers and secondary literature are set aside whatever the protocol says. | Available | 1.3 Screening |
| SCRN-12 | Screening holds a record as unsure when its rationale contradicts its own eligibility answer or exclusion reason. | Available | 1.3 Screening |
1.4 Full text
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| FTXT-01 | Every attempt to get a report’s full text is recorded with the route tried, the site, the outcome, who or what made it, and when. | Available | 1.4 Full text |
| FTXT-02 | Text from PubMed Central is used only when the article’s identifiers match the study. | Available | 1.4 Full text |
| FTXT-03 | Axelium fetches only what is free to read; papers behind a subscription reach the review by upload or by the browser companion using the person’s own access. | Available | 1.4 Full text |
| FTXT-04 | Uploaded files are matched to their study by PubMed ID or title, and a file the study already has is never added twice. | Available | 1.4 Full text |
| FTXT-05 | A report whose paper is never found is closed as not retrieved with a reason, leaves full-text screening and extraction, and is counted among the reports not retrieved in the PRISMA flow. | Available | 1.4 Full text |
| FTXT-06 | When the review allows it, a report can be assessed on its abstract; in a team review a second person, not the one who closed it, confirms that. | Available | 1.4 Full text |
| FTXT-07 | Each document a study holds shows where it came from and whether it is shown to be the study’s own paper. | Available | 1.4 Full text |
| FTXT-08 | The setting “When a paper cannot be found” is part of the protocol and read-only once the protocol is locked. | Available | 1.4 Full text |
1.5 Full-text screening
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| FTSC-01 | The AI reviewer assesses each full text against every eligibility criterion and two publication checks, quoting the passages it relies on, and every quote is located in the paper before it counts. | Available | 1.5 Full-text screening |
| FTSC-02 | A criterion is settled only when enough independent passages support it (two by default, or one or three), and absence of evidence never excludes a study. | Available | 1.5 Full-text screening |
| FTSC-03 | In single-reviewer review, decisions the evidence settles clearly are confirmed automatically by default, once a separate check agrees that the quotes answer each deciding criterion; everything else waits for a person. | Available | 1.5 Full-text screening |
| FTSC-04 | Automatic confirmation can be turned off per kind of decision, and is unavailable in dual review, so that every full-text decision is made by a person. | Available | 1.5 Full-text screening |
| FTSC-05 | A person’s full-text decision is final: it sets the study’s status, no later run screens the study again, and a decision against the AI’s proposal asks for a reason. | Available | 1.5 Full-text screening |
| FTSC-06 | In dual review the AI reviewer’s assessment, verdicts and quotes stay hidden until the reviewer has recorded their own decision, and a disagreement goes to the conflicts queue labelled with its phase. | Available | 1.5 Full-text screening |
| FTSC-07 | Studies whose full text could not be obtained are marked Full text unavailable and are never excluded for that reason. | Available | 1.5 Full-text screening |
| FTSC-08 | Re-check automatic decisions applies the current rules again to automatically confirmed decisions and changes nothing until a person accepts each proposal with a reason. | Available | 1.5 Full-text screening |
| FTSC-09 | Exclusions at full text are counted with their reasons in the PRISMA flow and the RevMan export. | Available | 1.5 Full-text screening |
| FTSC-10 | The report’s Methods paragraph for full-text screening states the model and prompt version, the evidence rule, how many decisions were confirmed automatically, and the exclusions by reason, from recorded data. | Available | 1.5 Full-text screening |
| FTSC-11 | Every full-text decision, the AI’s proposal, an automatic confirmation and a person’s decision, is an entry in the approval record with who, when and why, exported as CSV or NDJSON. | Available | 1.5 Full-text screening |
1.6 Extraction and traceability
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| EXTR-01 | Extracted values, quotations and pinned outputs are traced to the page and passage they came from, and every decision to the person who made it. | Available | 1.6 Extraction and traceability |
| EXTR-02 | Each quoted excerpt is checked against the document it is attributed to, and one that cannot be found there is marked as unconfirmed rather than shown as a verified quotation. | Available | 1.6 Extraction and traceability |
| EXTR-04 | The Verify table files every extracted value as Needs you, Unconfirmed or Ready, and the word says how the evidence was checked, not that the value is right. | Available | 1.6 Extraction and traceability |
| EXTR-05 | A check that questions a value offers what settles it, a confirmation is kept with who gave it and when, and the check opens again if the value changes. | Available | 1.6 Extraction and traceability |
| EXTR-06 | Every extracted value keeps its citation: the quoted sentence, the page, and for stored PDFs where the sentence has been located an evidence excerpt of the source page. | Available | 1.6 Extraction and traceability |
| EXTR-07 | Right and Wrong record whether a quote is in the paper; Wrong asks why, and the reason is kept in the value’s history. | Available | 1.6 Extraction and traceability |
| EXTR-08 | Validating a whole study, a selection or a row takes only complete values that no check questions, and lists what it leaves out and why before anything changes. | Available | 1.6 Extraction and traceability |
| EXTR-09 | Withdrawing a validation asks why, and the reason is kept in each value’s history. | Available | 1.6 Extraction and traceability |
| EXTR-10 | In dual review the second reviewer extracts on a blank form without seeing the AI’s values; agreement validates the value and a disagreement goes to Conflicts. | Available | 1.6 Extraction and traceability |
| EXTR-11 | The review queue offers Keep, Reject with a reason for each outcome, and Re-extract with a note; a rejected value stays excluded until Undo rejection, which asks why. | Available | 1.6 Extraction and traceability |
| EXTR-12 | Each value keeps a history of its extraction, checks, edits with the numbers before and after, validations, withdrawals, rejections and quote verdicts, each with who did it, their role and the reason. | Available | 1.6 Extraction and traceability |
| EXTR-13 | Review health shows extraction as Validated: the share of extracted values that a named person has validated, out of every value that has not been rejected. | Available | 1.6 Extraction and traceability |
| EXTR-14 | By default only validated values go into the analysis. | Available | 1.6 Extraction and traceability |
1.7 Appraisal
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| APPR-01 | The AI proposes an assessment for each included study and result with supporting quotes; where the instrument publishes an algorithm the judgement is computed from the answers by the published rules. | Available | 1.7 Appraisal |
| APPR-02 | Each domain judgement links to the quoted text behind it, and opening a quote shows the document at the cited page. | Available | 1.7 Appraisal |
| APPR-03 | The Review queue shows each waiting assessment on a blank form without the proposal; a review that agrees finalises it and one that disagrees sends it to Conflicts, with one reviewer or two. | Available | 1.7 Appraisal |
| APPR-04 | A ruling on a disagreement keeps the AI’s judgement, adopts the reviewer’s or sets the assessment aside, with the reason, and is recorded. | Available | 1.7 Appraisal |
| APPR-05 | A lead reviewer imports published assessments from a spreadsheet; totals and overall judgements are recomputed by each instrument’s published rules, and imports are attributed to a reviewer label naming the original review. | Available | 1.7 Appraisal |
| APPR-06 | When at least two raters have rated the same studies, the Concordance tab shows percent agreement and Cohen’s kappa per pair and a study-by-rater matrix, from validated assessments only, downloadable as CSV or Word. | Available | 1.7 Appraisal |
| APPR-07 | Qualitative studies are appraised with CASP; the AI drafts each appraisal from parsed full text with a verbatim quote per answer, and a reviewer confirms or edits it, finalises it, and reopening asks why. | Available | 1.7 Appraisal |
| APPR-08 | Only validated assessments reach certainty ratings, the concordance comparison and the report. | Available | 1.7 Appraisal |
| APPR-09 | Who finalised an assessment and when is shown at the foot of its panel and on Sign-off status, and is in the approval record export and the Word report’s Validation and sign-off record. | Available | 1.7 Appraisal |
| APPR-10 | When no full text is held a risk-of-bias proposal is made from the abstract record, and the assessment does not say that it did. | Available | 1.7 Appraisal |
| APPR-12 | Reviews, imports and rulings on risk of bias are refused once the analysis is frozen. | Available | 1.7 Appraisal |
1.8 Synthesis
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| SYNT-01 | A pooled analysis is keyed by the outcome, the timepoint and the effect measure; values that differ in any of them are not pooled together. | Available | 1.8 Synthesis |
| SYNT-02 | By default only values a named person has validated are pooled, and each run says which scope it used. | Available | 1.8 Synthesis |
| SYNT-03 | A value whose effect looks implausible is held for a person in the review queue and is left out of validated-only pooling until it is decided. | Available | 1.8 Synthesis |
| SYNT-04 | Every run keeps its selection and options, the model fitted, a fingerprint of the exact rows it used, who started it and when. | Available | 1.8 Synthesis |
| SYNT-05 | A pinned output is traced to the run that produced it and is the evidence the report is built from. | Available | 1.8 Synthesis |
| SYNT-06 | A network meta-analysis runs one outcome at a time, only after every automatically grouped arm it uses has been confirmed, and each result stays a draft until the outcome is locked. | Available | 1.8 Synthesis |
| SYNT-07 | Custom analyses run against a frozen copy of the dataset, need explicit approval before any code executes, are labelled User-defined and never feed certainty ratings or generated reports. | Available | 1.8 Synthesis |
| SYNT-08 | Ecology and evolution reviews switch to a multilevel model when effects are dependent, with an optional additive meta-regression on recorded moderators. | Early access | 1.8 Synthesis |
| SYNT-10 | An outcome with fewer than two validated rows a meta-analysis can use is summarised instead of pooled, by counting the direction of effect across its studies with a sign test, with an effect-direction plot and a recorded reason for every outcome summarised rather than pooled. | Available | 1.8 Synthesis |
| SYNT-11 | Changing the validated-only default changes nothing about runs already made: each run keeps the scope it used. | Available | 1.8 Synthesis |
| SYNT-12 | Figures and tables lists everything the review's analysis runs and the assistant made, searchable by outcome, method or number and narrowed by kind or by who made it. | Available | 1.8 Synthesis |
| SYNT-13 | An item made before the review's data last changed is marked out of date. | Available | 1.8 Synthesis |
| SYNT-14 | Both assistants can find an earlier figure or table and name it in an answer; a name that matches nothing of the review is shown as plain words. | Available | 1.8 Synthesis |
| SYNT-15 | A published version's manifest lists every figure its report carries, each with a checksum. | Available | 1.8 Synthesis |
| SYNT-16 | The reason an outcome was not pooled is one of seven recorded reasons, proposed from the data where it shows a single study or no reported uncertainty, and confirmed by a person who finalises the summary. | Available | 1.8 Synthesis |
| SYNT-17 | A summary without pooling is a draft until a person finalises it; a finalised summary keeps its result when a later run summarises the outcome again, until it is reopened. | Available | 1.8 Synthesis |
1.9 Certainty
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| CERT-01 | A pairwise outcome gets a GRADE rating with the five domains derived from the run and the confirmed appraisals, each with its basis written out. | Available | 1.9 Certainty |
| CERT-02 | The basis of a derived domain is stored as text and never rewritten, and each domain records whether it was set automatically or by a reviewer. | Available | 1.9 Certainty |
| CERT-03 | The risk-of-bias domain counts only assessments a reviewer has confirmed, weighted by each study’s weight in the pooled analysis. | Available | 1.9 Certainty |
| CERT-04 | A network comparison is rated on six CINeMA-style domains; a concern needs a reason, and another overall level than the suggested one needs a reason. | Available | 1.9 Certainty |
| CERT-05 | A qualitative finding gets a CERQual rating on four components, proposed from the CASP appraisals and the coded data, which the reviewer confirms, edits and finalises. | Available | 1.9 Certainty |
| CERT-06 | Finalising a rating is an approval: it records who finalised it and when, and the roles that may finalise each point are listed. | Available | 1.9 Certainty |
| CERT-07 | Reopening a finalised rating asks why and keeps the reason, with who had finalised it and when, in the history. | Available | 1.9 Certainty |
| CERT-08 | The GRADE page is the Summary of findings table, a row for each outcome of each completed analysis, and it can be pinned to the Evidence board and carried into the report. | Available | 1.9 Certainty |
| CERT-09 | A finalised rating is never overwritten by a later run, and every finalised GRADE rating is snapshotted at sign-off. | Available | 1.9 Certainty |
1.10 Reports and exports
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| REPT-01 | A report draft is generated from the evidence pinned to the Evidence board, in the audience and template chosen, by a lead reviewer or an admin. | Available | 1.10 Reports and exports |
| REPT-02 | Each save keeps the earlier version of a report, numbered, with who saved it and when; an earlier version can be restored; a locked manuscript cannot be changed. | Available | 1.10 Reports and exports |
| REPT-03 | PRISMA counts are computed from the review’s own records — screening in de-duplicated records, retrieval and eligibility in reports — and a flow that does not reconcile is refused rather than stored. | Available | 1.10 Reports and exports |
| REPT-05 | The writer is given the selected pins, the included studies’ characteristics and the PRISMA summary; the review’s methods and the full-text screening paragraph of Methods are written from recorded data. | Available | 1.10 Reports and exports |
| REPT-07 | A saved report exports as Word and Excel; the review exports as RevMan 5, as RIS or BibTeX of the included studies, as a settings file and as a sign-off record in CSV or NDJSON. | Available | 1.10 Reports and exports |
| REPT-08 | RevMan export lists included and excluded studies with their reasons and the supported quantitative outcomes, leaves the risk-of-bias fields empty, and refuses a network meta-analysis. | Available | 1.10 Reports and exports |
| REPT-09 | Every Word report says “Generated via Axelium” with the date under its title. | Available | 1.10 Reports and exports |
| REPT-10 | Every Word report ends with a validation and sign-off record: the milestones and, per approval point, how many were approved by a person, automatically and still need a person, as they stood when the report was generated. | Available | 1.10 Reports and exports |
| REPT-11 | The Word report lists the reports not retrieved, with what was tried, who closed each and why. | Available | 1.10 Reports and exports |
| REPT-13 | The writer is shown the review’s risk-of-bias judgements, one line per assessed study, and its GRADE ratings, one line per outcome and timepoint, each marked finalised or provisional; an ecology review’s draft is given none. | Available | 1.10 Reports and exports |
| REPT-14 | The writer is shown the reports that could not be retrieved and the validation and sign-off record, without naming who closed or approved anything, and is asked never to claim more validation than the record shows. | Available | 1.10 Reports and exports |
| REPT-15 | A saved draft can be regenerated from the pins it was written from; its current text is first kept as a numbered version. | Available | 1.10 Reports and exports |
| REPT-16 | PRISMA flow draws the review’s PRISMA 2020 flow diagram, with the databases and registers in one column and other methods in a second column when the review has records from them. Most numbers open the records they count. | Available | 1.10 Reports and exports |
| REPT-17 | The flow is kept as it stood at each sign-off, at the end of each living-review update, each time it becomes the report’s figure, and with an export when you tick “Keep this moment”; As of opens any of these moments with the records that were in each box then, and compares two moments. | Available | 1.10 Reports and exports |
| REPT-18 | Export gives SVG, PNG at twice the size and a one-page landscape PDF of the figure; a Word file with the figure, its counts table and its caption; the PRISMA 2020 flow-diagram template filled with the review’s counts, as CSV; and the counts as JSON. The app adds no person’s name to any of these files. | Available | 1.10 Reports and exports |
| REPT-19 | The Word report carries the newest PRISMA pin at the time you download as Figure 1, with its counts table; the Excel workbook carries its counts as a PRISMA sheet. | Available | 1.10 Reports and exports |
1.11 Living reviews
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| LIVE-01 | Once the search strategy is locked, an update runs daily, weekly or monthly; the dialog refuses to switch updates on until the queries are locked. | Available | 1.11 Living reviews |
| LIVE-02 | Searched by date: PubMed, ClinicalTrials.gov, Europe PMC and OpenAlex, each update searching the records added since the last one, with a day of overlap so no study falls between two updates, and reading every page for those dates, up to 2,000 studies per database. | Available | 1.11 Living reviews |
| LIVE-03 | Update searches are not held to the review’s 5,000-record limit, and the studies they add do not count toward it. | Available | 1.11 Living reviews |
| LIVE-04 | New candidates wait in the inbox with the AI’s verdict; Accept, Reject and Import data ask for one reason for the batch when it goes against the AI, kept in each study’s history. | Available | 1.11 Living reviews |
| LIVE-05 | A result is flagged as a significant change when, with at least the minimum number of newly included trials, the estimate moves past the threshold, the interval crosses the null in one cycle but not the other, heterogeneity jumps, or certainty is downgraded. | Available | 1.11 Living reviews |
| LIVE-06 | A significant change is e-mailed as “Evidence change detected” at once by default; an update with nothing significant sends the count of new studies instead. | Available | 1.11 Living reviews |
| LIVE-07 | Each update search is recorded with the dates it covered, what it sent to each database, how many studies it found and how many were new, and whether a database was left incomplete. | Available | 1.11 Living reviews |
| LIVE-08 | A network meta-analysis is not re-run by an update, and the pairwise comparison stays paused for network reviews. | Available | 1.11 Living reviews |
2.1 Roles and permissions
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| ROLE-01 | A review lives in a personal library or a team workspace; in a workspace, what a person may do in every review follows one of five built-in roles. | Available | 2.1 Roles and permissions |
| ROLE-02 | The built-in roles are Admin, Lead Reviewer, Reviewer, Commenter and Viewer, each a fixed bundle of permissions. | Available | 2.1 Roles and permissions |
| ROLE-03 | Every workspace permission is listed by role; a role either holds a permission or not, and a review cannot add one for a particular person. | Available | 2.1 Roles and permissions |
| ROLE-04 | Admins and lead reviewers invite people by email, a lead reviewer to a role no higher than their own; each link works once and for seven days and can be resent. | Available | 2.1 Roles and permissions |
| ROLE-05 | A workspace admin can transfer a review to a lead reviewer or admin of the workspace, and the transfer is recorded with who did it, from whom to whom, and when. | Available | 2.1 Roles and permissions |
| ROLE-06 | Deleting a team turns each of its reviews into a personal review of its creator, cancels pending invitations and deletes the team’s own review methods; it cannot be undone. | Available | 2.1 Roles and permissions |
| ROLE-07 | Mentions, assignments, conflicts, sign-off requests, proposals waiting for review and living-review alerts arrive in the notification inbox, with email delivery following each person’s preferences. | Available | 2.1 Roles and permissions |
| ROLE-08 | An approval event keeps the actor’s name and role as they were at the time, so a later change of role never rewrites the record. | Available | 2.1 Roles and permissions |
| ORGS-01 | An organisation brings an institution’s workspaces, people and reviews together; its roles are Owner, Admin, Curator, Billing, Member and Reader, and an organisation role does not by itself open any review. | Early access | 2.1 Roles and permissions |
| ORGS-02 | An organisation’s admins create, attach, detach, archive and restore workspaces; an archived workspace can be read but nothing in it changes until it is restored. | Early access | 2.1 Roles and permissions |
| ORGS-03 | An organisation defines its own roles from the permissions a defined role may hold, publishes and retires them, and assigns them in its workspaces. | Early access | 2.1 Roles and permissions |
| ORGS-04 | Owners and admins read and download the organisation’s audit trail, newest first, filtered by date, kind of actor, action and workspace. | Early access | 2.1 Roles and permissions |
2.2 Approvals, locks and sign-off
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| APRV-01 | A review has sixteen approval points, each approved on its own stage page by a role that allows it, and a milestone locks the points it covers. | Available | 2.2 Approvals, locks and sign-off |
| APRV-02 | Five milestones — Protocol lock, Screening lock, Extraction lock, Analysis freeze, Manuscript lock — are requested by a lead reviewer or admin and approved by another admin; nobody approves their own request. | Available | 2.2 Approvals, locks and sign-off |
| APRV-03 | Before a sign-off request is sent, it lists what the milestone checks and holds the request while anything still waits for a person. | Available | 2.2 Approvals, locks and sign-off |
| APRV-04 | Turning a sign-off down, withdrawing a request and unlocking the protocol each ask for a reason, which is shown on the Versions page. | Available | 2.2 Approvals, locks and sign-off |
| APRV-05 | The Sign-off status page lists every approval point with three counts — approved by a person, automatic, needs a person — and each row and count opens its stage. | Available | 2.2 Approvals, locks and sign-off |
| APRV-06 | Counts no person checked are shown as AI only, Automatic only or person not recorded, and are never counted as approved. | Available | 2.2 Approvals, locks and sign-off |
| APRV-07 | The review’s approval record downloads as CSV or NDJSON, newest first, with the actor, role, reason, before and after states, run and model of each event. | Available | 2.2 Approvals, locks and sign-off |
| APRV-08 | Every Word report ends with a Validation and sign-off record of the milestones and approval points as they stood when the report was generated. | Available | 2.2 Approvals, locks and sign-off |
| APRV-09 | An approval event is written in the same step as the change it describes, can never be edited or removed, and a person’s withdrawal, rejection, override or unlock always carries a reason. | Available | 2.2 Approvals, locks and sign-off |
| APRV-10 | Disagreements between reviewers go to a conflicts queue, adjudicated per phase, and an automated re-screen never overturns a person’s decision. | Available | 2.2 Approvals, locks and sign-off |
| APRV-11 | A risk-of-bias disagreement is resolved by keeping the AI assessment, keeping the reviewer’s, setting it aside, or deciding later, with a reason where one is asked. | Available | 2.2 Approvals, locks and sign-off |
2.3 Audit trail and history
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| AUDT-01 | Extracted values, quotations and pinned outputs are traced to the page and passage they came from, and every decision to the person who made it. | Available | 2.3 Audit trail and history |
| AUDT-02 | A quoted excerpt that cannot be found in its document is marked unconfirmed rather than shown as verified. | Available | 2.3 Audit trail and history |
| AUDT-03 | Every step the AI takes in the approval record names the model and the run, and keeps an identifier of the prompt — a fingerprint, not the prompt’s text. | Available | 2.3 Audit trail and history |
| AUDT-04 | The AI’s steps are recorded as its own and a person’s under their name and role at the time; the AI is never filed under a person. | Available | 2.3 Audit trail and history |
| AUDT-05 | The Versions page lists each protocol version, the milestones and their sign-offs, and an unlock of the protocol or the search strategy with its reason. | Available | 2.3 Audit trail and history |
| AUDT-06 | Provenance shows what each living-review update changed and freezes a snapshot of the record for submission. | Available | 2.3 Audit trail and history |
| AUDT-07 | Ask on Sign-off and Provenance answers from the record: the PRISMA counts, where a person differed from the AI, screener activity, quotes found in documents, sign-offs in place and what the model work cost. | Available | 2.3 Audit trail and history |
| AUDT-08 | Each answer says when its figures were read, marks a figure carried over from an older answer, and marks a number not read from the review as unverified. | Available | 2.3 Audit trail and history |
| AUDT-09 | A thumbs up or thumbs down on an answer is the reader’s own; another person’s verdict on the same answer stays theirs. | Available | 2.3 Audit trail and history |
| AUDT-10 | The record is kept for every review, personal or team, and nothing turns it off. | Available | 2.3 Audit trail and history |
2.4 What the AI does by itself
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| AUTO-01 | In single-reviewer review the AI’s title and abstract decision is the record’s decision; an unsure record waits for a person, and in dual review a person always decides. | Available | 2.4 What the AI does by itself |
| AUTO-02 | A conclusive full-text decision is confirmed without a person only once a separate check agrees that the quoted passages answer each deciding criterion’s question, and only where the review allows it. | Available | 2.4 What the AI does by itself |
| AUTO-03 | Extracted values wait for validation; by default only validated values are pooled. | Available | 2.4 What the AI does by itself |
| AUTO-04 | After extraction each quoted sentence is looked for in the document, and a person answers whether a quote the check could not confirm is in the paper. | Available | 2.4 What the AI does by itself |
| AUTO-05 | Risk-of-bias assessments the AI proposes are drafts; nothing counts towards a certainty rating until a person validates it. | Available | 2.4 What the AI does by itself |
| AUTO-06 | The automated review’s proposals are decided one card at a time on the Proposals page: Approve asks you to confirm and Turn down asks why. | Available | 2.4 What the AI does by itself |
| AUTO-07 | Automatic repair never overwrites values a reviewer has validated or edited, every repair is re-checked before it counts, and anything that cannot be confirmed comes to a reviewer as a proposal. | Available | 2.4 What the AI does by itself |
| AUTO-08 | Where the automatic re-check is on, a value that passes its verification round is marked validated by the system, naming no person, and the record says so. | Available | 2.4 What the AI does by itself |
| AUTO-09 | The assistant is read-only: it answers from lookups over the review’s own data and record and never changes a setting, runs an analysis or edits a value. | Early access | 2.4 What the AI does by itself |
| AUTO-10 | A living review runs its saved searches again on the schedule set, and new evidence returns through screening, full text, extraction and analysis for a person to accept, reject or import. | Available | 2.4 What the AI does by itself |
| AUTO-11 | A running automated run can be cancelled; cancelling asks you to confirm and is recorded as the run’s reason. | Available | 2.4 What the AI does by itself |
| AUTO-13 | Every automatic decision is filed as the AI’s or the system’s, with the model and the prompt version, and a person’s later confirmation, change or withdrawal is recorded as theirs with the reason. | Available | 2.4 What the AI does by itself |
2.5 Review settings and history
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| SETT-01 | Every save of a review’s settings is kept as a version, with who saved it and when, and can be compared with the one before. | Available | 2.5 Review settings and history |
| SETT-02 | A change to a setting marks the results of the stages that read it as out of date, and leaves the others current. | Available | 2.5 Review settings and history |
| SETT-03 | A review’s settings can be copied into a new review, and a team can keep its own method defaults. | Available | 2.5 Review settings and history |
| SETT-04 | Full-text screening’s automatic confirmation and its settings are set per review and shown on the page that uses them. | Available | 2.5 Review settings and history |
3.2 Billing and usage
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| BILL-01 | Remaining review allowance, seats and top-ups are shown before work that uses them starts. | Available | 3.2 Billing and usage |
| BILL-02 | A team’s plan is shared by its members, with seats counted per person and allowances per team. | Available | 3.2 Billing and usage |
| BILL-03 | A past-due account keeps read access to its reviews and is told what is paused. | Available | 3.2 Billing and usage |
3.3 Exporting, archiving, deleting
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| EXPT-01 | A review leaves as separate downloads: each saved report as Word and Excel, the review as RevMan 5, RIS or BibTeX of the included studies, a settings file, and a sign-off record in CSV or NDJSON. | Available | 3.3 Exporting, archiving, deleting |
| EXPT-02 | A new review can start from another review or from its settings file; review intent is copied, never search strategies, locks, schedules or results, and an export refuses rather than leave a setting behind. | Available | 3.3 Exporting, archiving, deleting |
| EXPT-03 | An organisation makes one archive of everything it holds — every table as data files, each review as RevMan and its reports as Word and Excel — with a checksum for every file, downloadable for seven days. | Early access | 3.3 Exporting, archiving, deleting |
| EXPT-05 | Deleting a review hides it from every page and list and is written to the audit trail; its records remain in storage. | Available | 3.3 Exporting, archiving, deleting |
| EXPT-06 | Closing an organisation needs 30 days’ notice and an archive made since notice, then removes its records and files, counts again to confirm none remain, and leaves a certificate of what was removed, what was kept and when backups age out. | Early access | 3.3 Exporting, archiving, deleting |
3.4 Browser companion
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| COMP-01 | The browser companion sends articles, PDFs, supplements and citation metadata from pages you can lawfully access into the right review. | Available | 3.4 Browser companion |
| COMP-02 | The companion lists the papers a review still needs so a person can fetch them in order. | Available | 3.4 Browser companion |
| COMP-03 | Everything the companion fetched is listed in the review with its source page, so a capture can be checked and removed. | Available | 3.4 Browser companion |
| COMP-04 | The companion is authorised with a token a person creates and can revoke from their settings. | Available | 3.4 Browser companion |
4.1 The Axelium method
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| METH-01 | The method is a versioned statement: the page shows its current version and date, and every release that changes what a person checks or a decision rule adds a change-log entry naming the version it moves to. | Available | 4.1 The Axelium method |
| METH-02 | The AI proposes and a person decides: every stage has a named approval point, and a draft binds nothing until a person approves it or a fixed rule confirms it. | Available | 4.1 The Axelium method |
| METH-03 | The lifecycle table names, for every stage of a review, what runs without a person, what a person checks, the decision rules, the approval point and what is recorded. | Available | 4.1 The Axelium method |
| METH-04 | Every extracted value carries the quote, page and position it came from, and each quote is checked against the document; what is traced is the value, not a sentence of the report. | Available | 4.1 The Axelium method |
| METH-05 | A generated report carries the PRISMA counts from the record, a Methods section, the label that it was generated via Axelium and the validation and sign-off record as an appendix. | Available | 4.1 The Axelium method |
| METH-07 | A lead reviewer rules on a conflict between two reviewers and may not rule on one they took part in; five milestones lock a review in order, and every unlock is recorded. | Available | 4.1 The Axelium method |
| METH-08 | What the automated review may apply without a person is a fixed list, never the AI’s judgement; a protocol-level change always waits for approval, and automatic full-text confirmation can be switched off. | Available | 4.1 The Axelium method |
| METH-09 | The method’s validation is public: a reproduction of a published meta-analysis matched three of four endpoints within 6%, with overall survival 16% off, and the risk-of-bias page shows agreement between raters. | Available | 4.1 The Axelium method |
| METH-11 | The PRISMA 2020 flow diagram drawn from the same counts, with databases and registers and other methods in their own columns: the report’s Figure 1 when the flow is pinned, and a page of its own where most numbers open the records they count. | Available | 4.1 The Axelium method |
Validation and limitations
| Ref | Capability | Status | Where it is documented |
|---|---|---|---|
| VALD-01 | In a reproduction of Zhang et al. (2024), three of the four pooled endpoints matched the published estimates within 6%; the overall-survival estimate was 16% off, traced to one trial read from its primary publication rather than updated follow-up data. | Available | Validation and limitations |
| VALD-02 | When two or more raters have assessed the same studies, the risk-of-bias page shows a concordance comparison: percent exact agreement and Cohen's kappa for every pair of raters, with a study-by-rater matrix. | Available | Validation and limitations |
| VALD-03 | Search strategies are checked by replaying saved plans against the live sources and scoring the included studies of a published review they find; full-text screening is checked on a benchmark of reviews with known inclusions, study by study. | Available | Validation and limitations |
| VALD-04 | The statistics are reproducible: every run records the exact rows and options it used, and the same rows and options give the same result. | Available | Validation and limitations |
| VALD-05 | The AI stages are not reproducible bit for bit; what is kept is each decision, its quotes and its reasons, so a person can check it. | Available | Validation and limitations |
| VALD-06 | Every automatic decision is recorded as automatic, can be reversed, and counts as checked only once a named person has looked at it. | Available | Validation and limitations |