Add research workflow guide

README.md

@@ -1,3 +1,88 @@
-# evidence-table-design
+# Designing Evidence Tables That Survive Peer Review
 
-Designing Evidence Tables That Survive Peer Review
+An evidence table is the backbone of almost every serious review: systematic reviews, scoping reviews, technology assessments, competitive analyses and even internal decision memos. It is where individual studies are lined up side by side so that patterns, gaps and contradictions become visible. It is also the part of a manuscript that reviewers check most carefully, because errors in the table propagate into every conclusion drawn from it. This guide explains how to design evidence tables that are accurate, readable and easy to defend.
+
+## Start from the question, not from the papers
+
+The most common design mistake is to build columns around whatever information the first few papers happen to report. The table then grows sideways as new papers introduce new variables, and ends up wide, sparse and hard to read.
+
+Instead, derive the columns from your review question. If your question follows a PICO structure (population, intervention, comparison, outcome), those four elements are your core columns. Add study design, setting, sample size and follow-up because they determine how much weight each row deserves. Add a column for risk of bias or quality appraisal. Anything else should earn its place by being necessary to answer the question.
+
+## A sensible default structure
+
+For a typical review of intervention studies, the following columns work well:
+
+| Column | What goes in it |
+|---|---|
+| Study | First author, year, and a short identifier |
+| Design | RCT, cohort, case-control, cross-sectional, qualitative |
+| Setting | Country, care setting or market segment |
+| Population | Who was studied, with key inclusion criteria |
+| n | Number analysed, not just enrolled |
+| Intervention | What was done, with dose or intensity |
+| Comparator | What it was compared against |
+| Outcome | The specific outcome measure used |
+| Result | Effect estimate with uncertainty, or a concise qualitative finding |
+| Risk of bias | Overall judgement plus the main concern |
+| Source locator | Table or page in the paper where the result appears |
+
+The last column is the one most tables omit and the one that saves the most time. When a co-author or reviewer questions a number, the locator lets anyone verify it in seconds.
+
+## Report results the same way across rows
+
+Readers compare rows, so inconsistent reporting misleads them. Decide in advance how results will be expressed: risk ratios or odds ratios, mean differences or standardised mean differences, percentages or counts. Where papers report different statistics, either convert them using standard methods and note the conversion, or report them as published and flag that they are not directly comparable. Always include uncertainty, such as confidence intervals, alongside point estimates.
+
+For qualitative or mixed evidence, write short, parallel statements: "Participants valued X because Y" rather than long quotations of varying length.
+
+## Extract once, check twice
+
+Accuracy is the property reviewers care about most. Good practice for extraction includes:
+
+- **Piloting the form.** Extract three or four studies, then review the form. Ambiguous columns become obvious quickly.
+- **Double extraction for key fields.** Have a second person independently extract the results and risk of bias columns for at least a sample of studies, then reconcile differences.
+- **Recording where each value came from.** The source locator column makes reconciliation fast.
+- **Keeping raw and derived values separate.** If you calculated an effect size from reported means and standard deviations, keep the raw numbers in an appendix or a hidden column.
+
+## Make the table readable
+
+A table can be accurate and still unusable. A few presentation choices make a large difference:
+
+- **Sort meaningfully.** Group rows by design, by intervention type or by outcome, rather than alphabetically by author.
+- **Use abbreviations sparingly** and define every one in a footnote.
+- **Split very wide tables.** A characteristics table and a results table are easier to read than one giant grid.
+- **Avoid empty cells.** Write "not reported" explicitly, which also tells the reader you looked.
+- **Highlight the main comparison.** If one outcome is primary, place it first and make it visually distinct.
+
+## Connecting the table to the narrative
+
+The text of your review should interpret the table, not repeat it. Each paragraph in the results section should make a point that the table supports, and refer to specific rows: "Three of the four trials in primary care (Table 2, rows 3 to 6) reported reductions in..." This makes the argument checkable and discourages vague generalisations.
+
+When you write the discussion, return to the table to confirm that your conclusions reflect its overall pattern, including the studies that did not fit your expectations. Reviewers often look specifically for studies that contradict the conclusion and check whether the authors addressed them.
+
+## Version control for evidence tables
+
+Evidence tables change: new studies are added, extraction errors are corrected, risk of bias judgements are revised. Keep a dated version history and a short change log ("2026-03-14: corrected n for Lee 2021 from 212 to 198; source Table 1"). This protects you when a co-author asks why a number changed, and it is invaluable when updating a review months later.
+
+## Tooling that keeps tables traceable
+
+Spreadsheets remain the most common extraction tool, and they work well if you are disciplined about locators and versions. Dedicated tools can reduce the manual effort. Research workbenches that keep extracted values linked to their source passages make the "check twice" step much easier, because each cell can be traced back without searching. Yila (https://yila.ai) takes this approach: comparison tables built from a set of papers keep a link from each cell to the passage it came from, so a reviewer's question about a number can be answered by opening the linked evidence rather than hunting through PDFs.
+
+## Handling studies that report several outcomes
+
+Many studies report more than one outcome, several time points or multiple subgroups. Decide in advance which result goes into the main table, for example the primary outcome at the longest follow-up, and record that rule in your protocol. Place secondary results in a supplementary table rather than squeezing them into one crowded cell. When a study reports the same outcome in different ways, prefer the measure that most other studies used, and note the choice. Pre-specified rules like these protect you from accusations of cherry-picking the most favourable numbers.
+
+## A short pre-submission check
+
+Before you submit, run through these questions:
+
+1. Does every column serve the review question?
+2. Is every result expressed consistently, with uncertainty?
+3. Can every value be traced to a specific location in its source?
+4. Were key fields double-extracted or at least spot-checked?
+5. Are missing values marked as "not reported" rather than left blank?
+6. Does the narrative refer to specific rows rather than vague patterns?
+7. Is there a change log for the table?
+
+## Conclusion
+
+An evidence table is a compact argument. Designed around the review question, extracted carefully, presented consistently and linked to its sources, it lets readers see exactly how you reached your conclusions and check them for themselves. That transparency is what allows a review to survive peer review with its conclusions intact.