Tips for creating better extraction fields

Write fields the way you want the table to read

Extract Data turns a pile of papers into a table you can read down a column instead of reading front to back. How good that table is depends almost entirely on one thing: how you write your fields.

This page shows you how to write fields that come back precise, comparable, and citable — with weak-vs-strong examples from clinical research, pharma, computer science, social science, HEOR, education, and engineering.

What an extraction field actually is

Every column in your table is one extraction field: one question, asked of every paper, answered independently for each row.

A field has three parts:

The Instructions box does the heavy lifting. The name is just a label — the AI reads the instructions.

Start from your research question, not from a blank column

When you create a table, the setup dialog asks for your research question. Fill it in. Extract Data reads it together with your paper titles and proposes a full set of typed columns — usually 5–8, tuned to the vocabulary your specific papers actually use.

Two ways to use it:

• Describe the goal and let it design the columns: I'm comparing digital CBT trials for adolescent anxiety and need enough to build an evidence table and check whether pooling is sensible.
• Name the columns yourself and let it sharpen them: Extract: study design, sample size, app or platform used, number of sessions, primary outcome measure, effect size, attrition. If you name specific fields, you get exactly those — refined and typed.

Then edit what comes back. Suggested columns are a starting draft, not a verdict — the tips below are how you improve them.

Every new table also starts with a Summary column so you have something to read immediately. Delete it if you do not need it.

Twelve tips for fields that come back right

Tip 1 — One field, one fact

A column that asks two things gets a half-answer to each, and it cannot be sorted or filtered by either.

The same rule splits subgroups, timepoints, and arms. If you need the 12-week and 52-week results, that is two columns, not one.

Tip 2 — Put the work in Instructions, not the Name

The name is a header you scan; the instructions are the brief the AI follows. A perfect name with a vague instruction gets you a vague column.

Tip 3 — Disambiguate when several numbers compete

This is the single most common cause of a confidently wrong column. Papers contain many numbers that all look like sample size: screened, eligible, randomised, analysed, per-protocol, and the number the power calculation targeted. Say which one you want.

Non-clinical versions of the same trap:

• CS/ML: training set size vs test set size vs total dataset size.
• Social science: respondents invited vs completed vs retained in the final regression sample.
• Materials: specimens fabricated vs specimens tested to failure.
• Economics: observations vs clusters vs individuals in a panel.

Tip 4 — Specify the output format, and give an example

The AI follows format instructions literally. A one-line format example is the cheapest quality improvement you can make, and it is what makes a column comparable down the page instead of a paragraph pile.

What Format: means, and which kind to write

This is the convention Paperguide itself uses — accept the suggested columns and you will see instructions ending the same way. It describes the shape of the value, never a value to output. Two kinds, and the right one depends on what the column returns:

• An instance, for numbers and structured values: Format: "294 (148/146)". Safe here, because the extractor is separately bound to copy numbers exactly as the paper prints them — the example can only teach shape.
• A shape description, for categorical or free-text values: Format: "mean ± SD, original units" or Format: "design as the authors name it". Prefer this over a sample phrase like Format: "Randomized controlled trial", which can nudge the wording of a paper that says something slightly different. On a Specified column the question disappears — your choice list is the format.

Either way, keep the "if reported" clause in the sentence before it, so a thinner paper is not forced into the shape of your example.

Tip 5 — Pick the strictest output type that fits

This is the decision users get wrong most, and it decides whether the column is something you read or something you use.

Rule of thumb: if you will filter, sort, or count by the column, use Yes/Maybe/No or Specified. If you will read the column, use Answer.

Concretely:

• Was the study randomised? → Yes/Maybe/No, for screening.
• What was the randomisation method? → Answer, for description.
• Study design → Specified, with labels such as RCT, Cohort, Case-control, Cross-sectional, Qualitative, Review.
• Sample size → Answer, not Specified. Counts vary infinitely; a choice list cannot hold them.

How Yes/Maybe/No actually decides — read this before you screen

The three verdicts are not probably yes, probably no, and unsure. Your instructions define them, and the extractor follows those definitions literally:

The last clause is the default worth knowing: if your instructions are silent about absence, a paper that says nothing comes back maybe, never no. That default is deliberate — the paper does not mention ethics approval is not evidence that approval was not obtained.

But for many screening questions, absence is the answer. An RCT always announces its randomisation; a paper with no adverse-event data anywhere genuinely reports none. For those, say so in the instructions — no if no random allocation is described anywhere in the Methods — and the extractor follows it, recording in the justification that the verdict rests on the information being absent.

One question decides which way to write it: would a paper meeting this criterion necessarily say so?

• It would, such as randomisation, adverse-event reporting, code availability, or trial registration → define absence as no. Leaving it out sends every failing paper to maybe and your screen stops separating anything.
• It could meet it silently, such as ethics approval obtained but not stated, or independence from industry funding → leave absence as maybe. A no here would assert something the paper never said — no funding statement is not evidence of independence.

A complete screening instruction names all three verdicts, including what absence means. If you have not said what belongs in maybe, it collects whatever is left over, differently on different papers. And if your criterion has a genuine not applicable state, such as were outcome assessors blinded? on a single-arm study, consider Specified instead — your own Yes / No / Not applicable labels — because Yes/Maybe/No has nowhere honest to put does not apply.

Every Yes/Maybe/No cell also generates a one-line justification with its citation, whether or not Explanations are on for the table — so a screen leaves you an audit trail of why each paper was kept or dropped. A verdict resting on absence says so in the justification with not found in the paper instead of citing a sentence.

Tip 6 — Write choice lists that cannot overlap

For Specified columns you supply 2–10 labels, up to 60 characters each. Good lists are mutually exclusive, exhaustive for your corpus, and use the words your papers use.

Two things you do not need to add:

• No catch-all Other. It becomes a dumping ground and tells you nothing.
• No Not reported, Not applicable, or Unclear. These are always available automatically — a paper that fits none of your labels gets an honest marker instead of being forced into the closest wrong one.

More examples that work well as Specified:

• Funding: Industry, Public/government, Charity/foundation, Mixed, None stated
• Setting: Primary care, Hospital inpatient, Outpatient clinic, Community, Online/remote
• Region: North America, Europe, Asia, Africa, South America, Oceania, Multi-region
• CS evaluation: Public benchmark, Private/internal dataset, Synthetic data, Human evaluation only
• Economic perspective: Healthcare payer, Societal, Provider, Patient

Tip 7 — Use the vocabulary your papers use

The AI searches the full text by matching both wording and meaning. Field instructions written in the corpus's own terminology find the right sentences; generic textbook phrasing drifts.

If your set spans two vocabularies, such as randomised and randomized, or machine learning and statistical learning, mention both in the instructions — it costs a few words and prevents empty cells.

Tip 8 — Say what to do when there is more than one answer

Papers with Study 1 / Study 2, several cohorts, several arms, several timepoints, or several models have more than one correct value. Without a rule, you get whichever one the AI saw first.

Multi-item fields work well as short bullets. Completeness comes from more bullets, never from longer prose.

Tip 9 — Scope the field to this paper

Reviews, background sections, and secondary analyses are full of other studies' methods and numbers. Without a boundary, those get extracted as if they belonged to the paper in front of you.

The same guard is worth adding to any field where a mixed corpus, such as primary studies plus reviews plus protocols, is likely.

Tip 10 — Separate what was planned from what happened

Protocols, registrations, and design sections state intentions, such as we will enrol 350; results state outcomes, such as 312 completed. Both are in the same PDF.

Tip 11 — Design for absence

Absence is a legitimate, informative answer. Blinding does not exist in observational work; registration does not exist for most preprints; effect sizes do not exist in qualitative studies. When a field can legitimately not apply, say so — you will get Not applicable instead of a forced answer.

And read the empty cells as data. A column that comes back mostly Not reported is your finding — it is how you show that a field does not report adverse events, or does not release code, or never measures the outcome you care about. See the gap-analysis use case on the examples page.

Tip 12 — Nail units and denominators

Numbers travel badly. Say the unit you want, the denominator you want, and whether you want it per arm.

Do not ask a field to do arithmetic

A common request is to find the IQR, then calculate the SD from it. Extract Data will not do this, and the instruction cannot override it — extraction copies what the paper prints and nothing else. Ask for a computed value and you get the printed value, or a marker.

That is deliberate, and it protects something you need. Every value in the table is bound to the sentence it came from — that is what the citation markers are. A derived number has no sentence behind it, so it would be the one unverifiable figure in a column of verifiable ones, exactly where a reviewer will look hardest.

Extract the ingredients, convert downstream:

Then export to CSV or Excel and apply the conversion, such as Wan et al. 2014 or Luo et al. 2018, in R or your sheet. You gain two things over a computed cell: the Spread statistic column tells you at a glance how many studies need converting before you commit to pooling, and the formula lives in your analysis where a reviewer can check it — which is where Cochrane expects it anyway.

The same pattern covers every derived quantity: percentages from counts, absolute risk differences, currency conversions, unit changes, effect sizes you want recomputed on a common metric. Extract the inputs, do the maths where the maths is visible.

Instruction patterns you can reuse

Swap the subject; keep the shape.

The disambiguated number

[Quantity] as reported for [which group / which analysis], with unit and denominator exactly as printed. Not [the value it's often confused with]. Format: "…".

The clean category

Classify [what] using the authors' own description. Pick the single option that fits best.

Use this with a Specified choice list.

The screening question

Does the paper [condition]? yes if [what the paper states]. no if [what the paper states instead] — or, if a qualifying paper would necessarily say so, if no mention appears anywhere. maybe if [the ambiguous middle].

Use this with Yes/Maybe/No.

The multi-item list

List all [items] reported, one short bullet each, in the paper's own wording. Include [what qualifies]; exclude [what doesn't].

The graded judgement

Judge [domain] based only on what the paper reports about [method detail]. Choose the level the reported methods support.

Use this with a Specified list such as Low, Some concerns, High.

The provenance field

[Identifier / statement] exactly as printed, including [format detail]. If the paper does not state one, answer "Not reported".

Common problems, and the fix

Working smarter with the table

• Prototype on a handful of papers. Create the table with 5–10 papers, get the fields right, then add the rest. Adding papers extracts only the new rows; nothing already correct is redone.
• Check three cells against the PDF before trusting a column. Click a citation marker — it opens the exact sentence, with its page. If the column is right on three deliberately different papers, it is usually right.
• Edit, do not start over. Editing a field's name, instructions, output type, or choice list re-runs only that column. Iterating is cheap.
• Turn on Explanations while you are tuning. Each cell then shows how the value was determined, which tells you whether a wrong answer is a bad instruction or a hard paper. Turn it off for the final read if you want a tighter table. It is a table-level setting with a per-column override.
• Save fields you will use again. A good field is reusable across projects — save it to your column library and add it to the next table in one click. Your saved fields sit alongside Paperguide's default catalogue in Manage Columns.
• Disable rather than delete. Turning a column off keeps its definition and its extracted values; deleting throws them away.
• Retry failures. If some cells error, the Retry action re-runs just those cells.
• Sort and filter before exporting. Sort by title or date, filter by source, such as Reference Manager, public papers, or uploaded files, select the rows you want, and export only the selection to CSV or Excel.
• Limits worth knowing: up to 100 papers and 20 columns per table. For bigger reviews, split by question or by subset and export each table.

A quick checklist before you hit extract

• Does each field ask for exactly one fact?
• Would two careful researchers reading my instruction extract the same value?
• Have I named which value, when several similar ones exist?
• Did I give the output format, with an example?
• Is the output type the strictest one that fits?
• Do my Specified labels cover this corpus without overlapping?
• Have I said what to do when the field does not apply?
• Am I using the words my papers use?