Living Reviews in Practice, Monitors and Refresh Cadence
Pull-quote: “A conventional review answers the question as of its search date and then ages in silence. A living review replaces the finish line with an operating cadence.”
From artifact to operation
A systematic review is a snapshot: rigorous up to its final search date, silent about everything after. In fast-moving evidence areas, the gap between search date and reader opens within months. The living systematic review answers this by pairing continual surveillance of the literature with scheduled incorporation of what surveillance finds. The concept is established; what decides success in practice is operational: what watches, what triggers a refresh, how deep the refresh goes, and how conclusions carry their version.
The loop
baseline review (v1.0), protocol includes living plan
│
▼
literature monitors watch the sources
│
▼
new records ──► deduplicated into the screening queue
│
▼
triage screen against the existing criteria
│
├─ not relevant ──► logged, no action, trail records it
│
└─ relevant ──► refresh: screen, extract, re-synthesize
│
├─ conclusions unchanged ──► version note
│
└─ conclusions changed ──► updated review
with a changed-conclusions log
▲ │
└────────── loop continues ──┘The loop’s integrity depends on one rule: new records flow through the same machinery as the baseline. Same criteria, same dual-reviewer enforcement, same extraction schemas. A living review with a lighter-weight side door for updates is two reviews wearing one citation.
The four cadence decisions
| Decision | Options | The discipline |
|---|---|---|
| Monitor frequency | Continuous alerts, weekly or monthly sweeps | Match the field’s publication velocity, and write it down |
| Refresh trigger | Calendar, volume threshold, or signal, a study large enough to move conclusions | Pre-specify in the protocol, not in the moment |
| Refresh depth | Incremental update or full re-synthesis | Incremental by default, full when methods or criteria change |
| Retirement | Question closed, velocity collapsed, or decision passed | A living review needs an exit criterion too |
The trigger decision earns the most argument. Calendar triggers are predictable but can refresh nothing or lag something important. Signal triggers respond to the evidence but need a pre-specified definition of what counts as conclusion-moving, or every borderline study becomes a meeting.
Version discipline
Versioning is what separates a living review from a frequently edited document. A refresh that adds studies without moving conclusions is a minor version: the record grows, the answer stands, and the version note says so. A refresh that changes a conclusion, or any change to the criteria or methods themselves, is a major version, announced rather than absorbed, because readers who cited the previous conclusion need to know the ground moved. Criteria changes deserve particular suspicion: widen the population definition mid-life and the review is no longer answering quite the same question, which makes it a protocol amendment with a rationale, not a quiet edit.
What makes it sustainable
The honest objection to living reviews is cost: run manually, the surveillance and re-screening burn out the team that volunteered for them. This is where automation earns its place. Scheduled monitors watch the literature and queue new studies as they land; new records join the same deduplicated queue and face the same screening and dual-reviewer workflow as the baseline; and an append-only audit trail versions every update, so the review’s history is a record rather than a reconstruction. Explicit team roles keep the standing rota visible, because a living review is a staffed process, not a subscription.
One habit completes the discipline: conclusions carry their date. “As of the January refresh” is part of the claim, and the changed-conclusions log is the first thing a returning reader should find.
Closing
A living review is a commitment to an operating loop: monitors watching, triggers pre-specified, refreshes run through the same rigor as the baseline, versions logged, and an exit criterion written down. Teams that treat it as an operation keep their conclusions current. Teams that treat it as a promise re-discover, months later, why the promise was hard.