> For the complete documentation index, see [llms.txt](https://docs.nested-knowledge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nested-knowledge.com/guides/guidance-by-review-type/systematic-literature-review.md).
# Systematic Literature Review
Learn how to set up a systematic literature review in Nested Knowledge.
A systematic literature review (SLR) identifies, appraises, and synthesizes all available evidence on a specific question using a predefined, reproducible method. Choose an SLR when your question needs a comprehensive, defensible answer including an HTA submission or a publication.
An SLR typically takes several months and at least two reviewers, so if your timeline or scope doesn't support that, see the [Targeted literature review](/guides/guidance-by-review-type/targeted-literature-review.md) or [Scoping review](/guides/guidance-by-review-type/scoping-review.md) guides instead.
For general methodology guidance independent of the software, see [Systematic literature review best practices](/best-practices/best-practices-by-review-type/systematic-literature-reviews.md).
### Run An SLR In Nested Knowledge
**Inputs:** a structured research question (PICO), a predefined, ideally registered protocol, a data extraction template and formatted table exports.
**Outputs:** a PRISMA flow diagram, a fully screened and appraised study set, extracted data in formatted tables and a synthesis ready to report or publish.
| Stage | Recommended tools | Why |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Search | | SLRs depend on comprehensiveness, which is why users can build and upload searches from a range of sources, to import publications to gray literature. |
| Screening | | Two independent reviewers, multiple screening stages and a documented reason for every exclusion are necessary to maintain rigor in an SLR. |
| | Optional: [**Robot Screener**](/review-workflow/screening/exclusion-based-screening/robot-screener.md) | Once your team has adjudicated enough decisions, Robot Screener can fill the second reviewer seat under Exclusion Reasons — useful for high-volume or living SLRs where the same team screens repeatedly and the model has real decisions to learn from. It doesn't replace the human adjudicator. |
| Tagging and extraction | | An SLR's extraction needs to cover everything your synthesis/outputs will report, which is why CSTs provides an immediate baseline, Smart Config and templates allow you to match tags to your exports, ASTs extract this data at full-text depth.
Review tags before and after extraction thoroughly.
|
| Critical appraisal | | Two reviewers and one adjudicator report quality or risk of bias for every included study for applicable study designs, use Smart Critical Appraisal to generate recommendations. |
| Synthesis | | Build a range of exports: living interactive visuals, Dashboards of tables and summaries, generate traceable insights, PRISMA and more. |
### Next Steps
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.nested-knowledge.com/guides/guidance-by-review-type/systematic-literature-review.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.