> ## Documentation Index > Fetch the complete documentation index at: https://docs.consensus.app/llms.txt > Use this file to discover all available pages before exploring further. # Write the search-strategy section of your methods > Turn a logged search into the reproducible methods paragraph reviewers ask for — accurate because it was recorded as it ran. ## What you get The paragraph that says exactly what you searched, with which filters, on what date, returning how many records — written from a log rather than reconstructed from memory weeks later. ## Who it's for Anyone publishing a review, meta-analysis, or scoping study. Also anyone who has been asked by a reviewer to "provide the full search strategy" and discovered they cannot. ## Why this is worth automating Search strategies are almost always written last, from half-remembered queries, after the interesting work is done. The result is a paragraph that does not reproduce the corpus it claims to describe — which reviewers increasingly check. If the agent logs each call as it runs, this section costs nothing and is actually true. ## What to log, as you go | Field | Why a reviewer wants it | | ----------------------------- | ----------------------------------------------------------------------- | | Query text, verbatim | The only way anyone reproduces your set | | Every filter, exactly as sent | `study_types`, `human`, `year_min`, `sjr_max` all change the result set | | Date the search ran | Literature moves; a search has an as-of date | | Records returned per query | Pre-deduplication totals for the flow diagram | | Records after deduplication | Reported separately from the above | | Pages walked | Shows whether you exhausted the result set or took page one | | Any failed or retried call | A gap in coverage you must disclose | ## The prompt ```text theme={null} You are writing the search-strategy subsection of a methods section from the log below. Write prose, not a table — journals want a reproducible narrative. Cover, in this order: 1. The source searched, named precisely, with the date the search was run. 2. The query set. Give the queries verbatim; do not paraphrase them. 3. Every filter applied, with the value used and one clause on why. A filter with no stated rationale reads as arbitrary. 4. How records were deduplicated and on what key. 5. The counts: records identified, duplicates removed, records screened. 6. Any limitation: failed searches, truncated result sets, plan-imposed caps on returned results, or coverage restricted to a subset of the literature. Rules: - Use only the log. If a field is missing, write [NOT RECORDED] rather than reconstructing it — an invented search strategy is worse than an incomplete one. - Do not describe the search as comprehensive or exhaustive unless the log shows every query was paginated to completion. - State plainly that this was one search source and name any others used separately. Log: [PASTE THE AUDIT LOG] ``` ## Getting the filter rationale right Reviewers reject filters that look like convenience. Each one needs a defensible reason: * `study_types` — the designs that can answer the question, not the ones that returned pleasing results * `human=true` — scope of the review, stated in the question * `year_min` — tie it to an event, a guideline change, or a method's introduction, not to a round number * `sjr_max` — quality thresholds are contestable; say why the cut is where it is * `exclude_preprints` — a real methodological choice with a cost either way; justify the direction ## Audit requirements This use case *is* the audit log, rendered as prose. Follow the [grounding rules](/use-cases/best-practices#grounding-and-auditability), and keep the machine-readable table as a supplement — many journals now accept it as an appendix, which is stronger than the paragraph alone. ## What to check before you trust it * **Reproduce your own corpus from the paragraph.** If you cannot, a reviewer cannot either, and that is the entire test. * **Check for `[NOT RECORDED]`.** Each one is a real gap. Fill it by re-running, not by remembering. * **Do not claim comprehensiveness you did not achieve.** A truncated sweep described as exhaustive is a correctable error before submission and a serious one after. ## Related The sweep that generates this log. Where the exclusion reasons come from. Grounding rules and the audit-log format. Browse the gallery by persona.