results_to_claims_mapping v1.0.0

name: results_to_claims_mapping description: "Mapping results to claims: list every claim a paper or report makes, tie each claim to the specific result inside the same document that supports it, flag claims with no support or with support that is weaker, narrower, or different from the claim, and rewrite each flagged claim to match the evidence. Ships a claim ledger, a tested ledger checker and claim scanner, ten support checks, and worked examples of claims cut down to size. Use when drafting or reviewing an abstract, discussion, conclusion, executive summary, release post, or report whose conclusions need to match its results, when a claim sounds stronger than the data, or before a paper or report ships. For checking external citations use citation_integrity_audit, for full manuscript review use peer_review_assistant."

Results to Claims Mapping

Purpose

Keep a document honest with itself. A citation audit checks whether outside sources back a claim. This skill checks something different and more basic: whether a paper or report's own results back its own claims, in the same document, at the strength the claim uses.

The failure is common and measured. Boutron and colleagues defined spin as reporting strategies, whatever their motive, that highlight a benefit despite a nonsignificant primary outcome or distract from nonsignificant results. In their sample of 72 trial reports with nonsignificant primary outcomes, 42 (58.3 percent) had spin in the abstract conclusions. The CONSORT guidance for abstracts states the plain rule this skill enforces: conclusions must be consistent with the results, balance benefits and harms, and avoid over-generalisation.

The output is a claim ledger: every load-bearing claim, the result that carries it, a verdict, and a rewrite for every claim that fails. The document does not ship with OVERSTATED, UNSUPPORTED, or CONTRADICTED claims still standing in their original wording.

Workflow

1. Build the result register first

List what the document actually found before reading what it claims. One row per result, numbered R1, R2, and so on:

• What was measured, in whom, over what period.
• The value for each group or condition, the effect size, and its precision (confidence interval where reported).
• Whether the analysis was prespecified or exploratory, primary or secondary, and where it sits: table, figure, or results paragraph.
• Null results and harms get rows too. A result nobody claims is still part of the evidence, and step 6 needs it.

If the document reports a prespecified plan, registry entry, or analysis plan, note which results match it. The COMPare project built its whole method on that comparison, registry against published report, and found outcome discrepancies in most of the trials it assessed. A result that appears in the report but not the plan is exploratory by default, whatever the text calls it.

2. Extract the claims

Go section by section: title, abstract, summary, discussion, conclusion, recommendations, and any headline or release copy shipped with the document. A statement is a claim for the ledger if it:

• Asserts a finding, an effect, a comparison, or a cause.
• Gives or implies a number, a direction, or a size.
• Recommends an action on the basis of the findings.
• Characterises the whole study ("the first to show", "safe and effective", "ready for use").

Copy the claim verbatim. Do not tidy it before judging it, because the tidying is often where the overstatement hides.

Start the ledger from assets/claim-ledger.csv, or generate one:

python3 scripts/claim_map.py init ledger.csv
python3 scripts/claim_map.py scan draft.md

The scanner prints candidate sentences (strong verbs, causal verbs, numbers, recommendation wording). Candidates only: decide each one by hand, and add claims the scanner missed, especially claims carried by a heading or a figure caption.

Split compound claims. "The program works, is safe, and should be rolled out" is three claims with three different evidence needs.

3. Map each claim to its results

For each claim, name the result IDs that are supposed to carry it and the locator for each: table, figure, or results paragraph. Then state the warrant in one sentence: why does this result justify this claim? Use Toulmin's split, claim, data, warrant, qualifier. Most failures surface at this step, because the warrant has to be said out loud:

• No result named: the claim is UNSUPPORTED until one is found.
• The warrant needs a fact the study did not measure (a mechanism, a longer timeframe, a different population): the claim outruns its data.
• The warrant works only with a qualifier the claim does not carry (one site, four weeks, exploratory): the claim is OVERSTATED and the qualifier goes into the rewrite.

4. Run the ten support checks

Run every mapped claim through all ten checks in references/support-checks.md: outcome identity, direction, magnitude, statistical status, population and setting, timeframe, design and causality, certainty and qualifiers, completeness, and claim type separation. Record which check failed, not just that something feels off. The named spin patterns at the end of that file (misleading reporting, misleading interpretation, inappropriate extrapolation, following Yavchitz and colleagues) are the fast scan for the common shapes.

Two checks catch the most damage:

• Statistical status. A nonsignificant primary outcome cannot be carried by a significant secondary one. A nonsignificant result also cannot be claimed as proof of no effect or of equivalence. Both upgrades fail.
• Design and causality. Observational, survey, and cross-sectional results carry association verbs. Causal verbs, and causal nouns such as "the effect of X on Y", need an experimental design or an explicit argument for why the leap is earned.

5. Give a verdict per claim

• SUPPORTED: every check passes at the claim's stated strength.
• QUALIFIED: the result supports the claim once its scope, population, timeframe, or certainty is stated. The rewrite adds the qualifier.
• OVERSTATED: a real result sits underneath, but the claim is stronger, broader, more certain, or more causal than the result.
• UNSUPPORTED: no result in the document carries the claim.
• CONTRADICTED: a result in the document points the other way, or a result the claim depends on omitting contradicts it.
• NOT_A_RESULT: interpretation, speculation, or background that makes no claim on this document's data. Allowed, if it is written as what it is and not dressed in result language.

Validate the ledger before rewriting:

python3 scripts/claim_map.py check ledger.csv
python3 scripts/claim_map.py summary ledger.csv

The checker fails the run if a SUPPORTED or QUALIFIED claim names no result, or a failed verdict has no rewrite. It warns on causal language attached to a non-experimental design and on results named without a locator.

6. Check the orphans in both directions

Claims with no result are half the audit. Results with no claim are the other half. List results that no claim mentions and ask why:

• A null primary outcome with no claim is a reporting failure, not a relief. The abstract and conclusion still have to carry it.
• A harm with no claim has to appear wherever the benefit claim appears.
• A result that was prespecified and never reported anywhere in the document gets named in the report as missing, with the reason if the document gives one.

7. Rewrite each flagged claim to match the evidence

Rewrite rules, in order:

1. Keep the true part. Most overstated claims have a supported claim inside them. Find it and keep its numbers exact.
2. Lead with the primary result. If the headline claim rests on a secondary or exploratory result, the rewrite states the primary result first.
3. Downgrade the verb to the design: causes becomes was associated with, proves becomes suggests, eliminates becomes reduced in this sample.
4. Add the missing scope: population, setting, timeframe, and the comparison actually made.
5. Restore what was omitted: the null result, the harm, the group where the result reversed, the count of outcomes tested.
6. Move recommendations out of result language. A recommendation states the result, then the judgement, then what would change the judgement.
7. If nothing in the results can carry any version of the claim, cut the claim. A cut is a valid outcome and gets recorded as one.

Worked rewrites for a null primary trial abstract, an observational churn report, a benchmark release post, and one claim that passes untouched are in references/worked-examples.md.

8. Final consistency sweep

• Read the title, abstract, and conclusion against the ledger, not against memory. Every claim there must have a SUPPORTED or QUALIFIED verdict in its rewritten form.
• Check every number in a claim against the result register, digit for digit.
• Check that the limitations section and the claims agree. A limitation that would sink a claim if it were true cannot sit quietly at the back while the claim runs unqualified at the front.
• Re-run the checker. The ledger ships with the report.

Output Contract

Deliver, in this order:

1. The result register: numbered results with locators, including nulls and harms.
2. The claim ledger (CSV plus a readable rendering): claim verbatim, section, result IDs and locators, design, verdict, and the rewrite for every claim that is not SUPPORTED.
3. The orphan list: results no claim mentions, with a line on each saying whether it must enter the text or can stay in the results section, and why.
4. A short summary: counts by verdict, the three worst failures with the check each one failed, and the cuts made.
5. The corrected text for the title, abstract, and conclusion, or a statement that they already match the results.

Operating Rules

• Judge the claim as written, in the section where it appears. A claim qualified in the discussion is still unqualified in the abstract, and most readers only meet the abstract.
• Never upgrade a failed check into a pass because the claim matters to the authors. Importance is a reason to gather more evidence, not to borrow strength the results do not have.
• Never invent a supporting result. If the locator cannot be named, the verdict cannot be SUPPORTED.
• Keep prevalence claims tied to their samples. The spin figures in this skill come from biomedical trials with nonsignificant primary outcomes. They show the failure is real and common in that setting. They do not measure any other field, and the skill text must not present them as if they do.
• A mapping that flags every claim is as broken as one that flags none. Record clean passes as SUPPORTED and leave the wording alone.
• Speculation is allowed when it is labelled as speculation. Recommendations are allowed when they are argued, not smuggled in as findings.
• Do not soften a verdict in the summary that the ledger states plainly. The summary and the ledger tell the same story.