---
name: research-report-compilation
description: >
  Compiles a complete research project into one coherent report from many
  heterogeneous inputs: brief, questionnaire, raw data, analysis tables,
  transcripts, voice notes, images, quotes, previous waves, charts and desk
  research. Use for "pull the report together", "compile the findings",
  "turn all of this into one report", "we have everything, now write it",
  "assemble the deck", "the analysis is done, build the story".
category: 12 Report Design and Compilation
ref: 12.03
tier: 0
inherits: [K2, K3, K4, K5]
---

# Research Report Compilation

## 1. One-line description
Takes a finished research project with many heterogeneous inputs and compiles it into one coherent report that reads as though a single senior researcher wrote it, with the evidence trail from source material to recommendation intact and inspectable.

## 2. What this skill is used for

**The research problem it solves.** A finished project is not a report. It is a pile: a brief written three months ago, a questionnaire nobody has reread since fielding, a data file, four analysis workbooks made by two analysts, twenty transcripts, a folder of voice notes, an image set, a previous wave in a different template, some desk research, and a set of charts built for a progress meeting. Turning that pile into a report is where most of the value of a research project is either realised or lost. The characteristic failures are structural rather than analytical. The report follows the order the work was done in rather than the order the argument needs. Chapters read as though different people wrote them, because different people did. Numbers disagree between the summary and the chart. A recommendation appears that no finding supports. A source reference survives into the working document and dies in the rewrite. The story gets cleaner as the evidence gets thinner, because narrative pressure and evidential pressure push in opposite directions and nobody arbitrates. This skill is the arbitration.

**Where it sits.** Reporting. Downstream of all analysis, insight development and narrative work. Upstream of design, executive summary and quality review. It is the assembly point where every stream of the project meets, and the last point at which traceability can still be preserved cheaply.

**Typical use cases.**
- A mixed-method study with survey, qualitative and desk research phases going into one report.
- A tracking wave that must be comparable to previous waves and still say something new.
- A multi-market study where separate market analyses have to become one document.
- A project where several analysts produced separate workbooks and one report is owed.
- A report inherited mid-flight from a colleague who has left the project.
- A long project whose findings were delivered piecemeal in interim sessions and now need a single authoritative version.

**Who uses it.** Research directors and senior researchers who own the deliverable and the sign-off; project leads assembling other people's work; consultants compiling multi-source evidence for a client; anyone who has to answer "where did this come from" in a debrief.

## 3. When to use it

- The analysis is complete and signed off, and the remaining work is turning it into a document.
- Inputs arrive from more than one source, more than one method, or more than one hand.
- The report must be internally consistent on numbers, terminology and confidence, across sections nobody will read side by side except a critic.
- The evidence must remain traceable after compilation, because the client will interrogate specific claims.
- Previous waves or a previous report exist and comparability is expected.
- The deliverable will be quoted, extracted and reused, so every headline has to be safe travelling alone.
- The project produced more material than the report can hold and something has to be cut on principle rather than by fatigue.
- Several stakeholders need one document rather than the several partial versions currently circulating.

## 4. When NOT to use it

- **The analysis is not finished.** This is the most important line in this section. Compilation performed over incomplete analysis does not surface the gap, it disguises it: the report architecture creates slots, the slots demand content, and content gets written from the strongest available fragment rather than from a completed analysis. If cross-tabs are still running, if the code frame is still moving, if a segment has not been cut yet, or if a key question has not been analysed at all, stop. Finish the analysis (Category 06 and 07), then compile. The tell is a sentence beginning "we can put a placeholder in for now".
- **The data is still in field, or the sample is not final.** Numbers compiled from a partial field will be recompiled, and the second version rarely gets the same QA attention as the first. Wait.
- **The evidence base has not passed quality review and there is reason to doubt it.** Compiling a report over an unreliable dataset produces a well-made vehicle for a wrong answer. Run **13.01 Research Quality Review** first where quality is genuinely in question.
- **The question is purely one of structure.** If the ask is "what should the chapter order be" or "how should this report be organised", that is **12.01 Research Report Architecture**. Compilation uses architecture, it does not substitute for it.
- **The question is purely one of visual design.** Layout, typography, chart styling and template application are **12.02 Research Report Design**.
- **The task is writing a single-source report from one clean analysis.** One dataset, one method, one analyst, one narrative: use **11.03 Research Report Writing**. Compilation carries overheads (inventory, source codes, conventions register, evidence map) that earn their keep only when inputs are heterogeneous.
- **The methodological problem is how to reconcile two evidence streams that measure the same thing differently.** That is **12.04 Research Evidence Integration**, and it is a prior step. Compilation records a divergence and reports it. It does not resolve a measurement conflict on the page.
- **The report already exists and needs checking.** That is **12.06 Research Report QA**. Do not recompile a finished report as a way of reviewing it, which loses the original's decisions and creates a second version in circulation.
- **The deliverable is a short executive artefact only.** A one-page summary, a board note or a five-slide readout is **12.05 Executive Research Reporting**, working from a compiled report rather than instead of one.
- **The conclusion has been fixed in advance.** Where a stakeholder has specified what the report must say and the compilation task is to arrange evidence behind it, this is not compilation. Say so, per K4 §4.2, and offer either an honest compilation or a clearly labelled assessment of the stated position against the evidence.
- **The inputs cannot be traced.** Where analysis tables arrive with no question references, quotes with no participant IDs, and figures with no source, compilation would launder unverifiable material into an authoritative document. Send the inputs back for referencing, or compile only the traceable subset and state what was excluded and why.

## 5. Required inputs

**Required.** Without these the skill cannot run. If absent, ask. If no answer is available and work must proceed, state the assumption at the point where it bites, per K5 §5.

- **The research brief and the agreed objectives**, in the form finally agreed rather than the first draft. Objectives are the spine of prioritisation and the test of completeness at the end.
- **The completed analysis outputs**: analysis tables, cross-tabs, theme records, code frames, statistical test results, each carrying question references, base descriptions and base sizes.
- **The questionnaire or discussion guide as fielded**, including routing. Without it, base descriptions cannot be checked and prompted material cannot be distinguished from volunteered.
- **The decision the report informs, and its audience.** A report compiled without knowing what it is for gets ordered by topic, which is the failure mode this skill exists to prevent.
- **Source identifiers on every input**: participant IDs on quotes, file and tab references on tables, dates and provenance on client-supplied material. Per K2 §4, an unattributable claim cannot be compiled into a report that will be interrogated.

**Optional, and what each one adds.**

- **Raw data file**: makes it possible to recompute a disputed number at source rather than adjudicating between two derived files.
- **Interview and voice-note transcripts**: supply the verbatim evidence layer and let a survey finding be explained rather than only reported. Voice notes in particular carry fieldwork observation that never reaches an analysis table.
- **Images and video**: give a report evidence a chart cannot carry (a shelf, a form, a queue, a gesture). Each needs a capture reference, consent status and a caption stating what it shows rather than what it proves.
- **Previous reports and waves**: enable trend claims, but only where question wording, sample definition and method match. Their real value is comparability, and their real risk is false comparability.
- **Secondary and desk research**: places findings in market context and supports sizing. Each source carries its own provenance and age, per K2 §4.3.
- **Client-supplied figures** (sales, traffic, complaints, operational data): let research findings be connected to business outcomes. They are labelled client-supplied throughout, per K2 §6, because their provenance is not yours to vouch for.
- **Brand and template guidelines** supplied by the commissioning organisation: determine format, and nothing else. Guidelines govern how the report looks. They never govern what it concludes.
- **The narrative or storyline already agreed** (from 11.01): removes the largest single judgement from compilation and makes step 5 a check rather than a construction.
- **Stakeholder hypotheses on record**: useful as things to test and visible as things to confirm, which is the point of recording them.

## 6. Questions to ask before starting

1. **What decision does this report inform, who makes it, and when?** Sets the prioritisation of findings and the shape of the narrative. *Default if unanswered:* order by objective, lead with the strongest evidence, and flag that decision-led ordering requires the researcher.
2. **Is the analysis final and signed off?** Determines whether compilation should begin at all (see Section 4). *Default:* ask explicitly. Do not infer completion from the existence of files.
3. **Is questionnaire order or a fixed template required by the client, a tracking convention, or a submission format?** Determines whether narrative order is available. *Default:* narrative order, with the exceptions in step 6 of the methodology checked first.
4. **What reporting conventions are already in force?** Base definitions, rounding, wave comparison rules, segment names, terminology from previous waves. Determines the conventions register, and determines whether this report will look consistent with its predecessors. *Default:* adopt the previous wave's conventions where they are defensible, and document any change on the page where it first bites.
5. **What is the length and format ceiling, and is there a separate appendix or data book?** Determines how much can be reported in the narrative and where the rest goes. *Default:* narrative report plus appendix, with everything analysed appearing in one or the other.
6. **Which inputs are client-supplied, previous-wave, or unverified, and who vouches for each?** Determines labelling per K2 §6 and determines what may carry a headline. *Default:* label all three categories explicitly and never lead a chapter on an unverified input.
7. **Is there a stated or implied preferred answer in play?** Determines what to watch during prioritisation. *Default:* record it before compiling so that any convergence is visible and examinable rather than invisible.

## 7. Step-by-step methodology

**What compilation actually is.** Not writing up, but the construction of a single argument from heterogeneous evidence, with the joins engineered rather than hidden. Three instruments do the work, all built before any prose: the **evidence inventory**, the **evidence map** (per K2 §5), and the **conventions register**.

**Step 1. Inventory all evidence.** List every input the project has produced, before reading any of it for content. Give each a short source code used in every later reference (`S-QNT-01` for the survey tables, `S-QUAL-03` for a transcript set, `S-CLI-02` for a client-supplied file, `S-W2-01` for a previous wave). Record what it is, who produced it, the date, the method behind it, the base or sample it describes, whether it has been through your own analysis, and its verification status (verified, client-supplied, unverified, superseded). Include items that will not be used, marked as such: an inventory listing only what you used cannot prove you looked at the rest. Flag duplicates and near-duplicates immediately, since two files carrying the same numbers in different states cause most compilation errors. *Correct result:* a table in which a colleague could find any source in under a minute, and no item is called "the latest version" without a date.

**Step 2. Understand the research objectives.** Reread the brief as agreed and write each objective as a question the report must answer, in the client's vocabulary rather than yours. Then do the thing that gets skipped: separate the **commissioned objectives** from the **decision behind them**. A brief asking how customers perceive a service usually exists because someone must decide whether to fund a redesign. Objectives determine completeness. The decision determines emphasis. Where they diverge, both are served, and the divergence is worth naming to the client. Note any objective the fieldwork drifted away from: that is an evidence gap at step 8, not a surprise at step 10. *Correct result:* objectives as numbered questions, each with the decision it feeds, and a note of any the study is unlikely to answer.

**Step 3. Establish the evidence hierarchy.** Decide, before you know which findings you like, how sources rank when they disagree. A workable default, strongest first: primary data you analysed on adequate bases, converging across independent streams, then the same from a single stream; primary qualitative evidence with prevalence and counter-evidence recorded; small-base or single-item primary evidence; client-supplied operational data (unverified by you, and measuring the business rather than the customer); previous-wave data of established comparability; secondary research, ranked by its own method and age; and last, stakeholder assertion, which is context and never evidence. **Setting it before the findings are known is the entire point**: a hierarchy chosen afterwards is a rationalisation of a preferred story. Record exceptions with reasons: a client's transaction log outranks your survey on what customers actually bought. *Correct result:* a short ranked list with named exceptions, agreed with the project lead, applicable at step 4 without further argument.

**Step 4. Identify major findings.** Work through every analysis output and extract findings as claims, not topics. A finding is a statement of fact about the data carrying its own reference: "Satisfaction among customers who had a service issue is 24 points lower (Q12 x Q30, n=1,204, 418 with an issue, tested at 95%)". Harvest widely from every stream, then prioritise on five criteria. **Objective coverage** is a floor, not a ranking: every objective is answered somewhere, or appears in "what we could not establish". Rank the rest by **evidence strength** (base, convergence, directness, per K3 §3), **strategic importance** (proximity to the decision, consequence if true), **novelty** (does the client know it already, and would they act differently if they believed it), and **decision relevance** (can anyone act on it). Two rules govern conflicts. A finding that is strong but irrelevant to the decision goes to the appendix. A finding that is decision-relevant but weak goes in with its confidence marked, and never as a headline, per K3 §4.3. *Correct result:* a prioritised register, typically 15 to 40 findings, each with source code, base, confidence and the objective it answers, and each phrased as a claim a reader could disagree with.

**Step 5. Determine the narrative.** The narrative is the logic that makes the findings one argument rather than a list. Where 11.01 has produced one, verify it against the finding register rather than accepting it: narratives written before the evidence was final tend to survive past their evidence. Where none exists, build it from the one or two findings that explain the others, then arrange the rest as the argument moving a reader from their current belief to the conclusion. Test it three ways: can you state it in three sentences without using "and" to join unrelated ideas; does every major finding either advance it or explicitly qualify it; does it survive the strongest contradicting evidence in the register, which you locate deliberately rather than wait to meet? A narrative requiring a finding to be omitted is not a narrative, it is a selection, and per K4 §4.1 it fails here rather than in review. *Correct result:* a narrative in three to five sentences, the findings that carry it, and the evidence cutting against it with a note of how it will be handled.

**Step 6. Create the report architecture.** Turn the narrative into chapters. Each gets a working title stating what it establishes, a one-line statement of its job in the argument, the level of abstraction it operates at, and a page budget. Structural craft belongs to **12.01**, and where the structure question is genuinely open, hand it there. Compilation owns the fit between structure and evidence: an architecture whose chapters cannot be filled from the finding register is the wrong architecture, and it is cheaper to discover that now than at step 10.

**Order the report by the argument, not by the instrument.** Questionnaire order is the default only because it requires no decision, and it reliably produces chapters that end without conclusions. The honest exceptions are four: a tracking study whose stakeholders read waves side by side against a fixed template; a tender, regulatory or syndicated deliverable whose format the buyer specifies; a data book or appendix, which is a reference rather than an argument; and the case where the instrument already followed the journey that is the natural narrative. In the first two the narrative relocates rather than disappears, into the executive summary and chapter openers, while the body holds the required order. State which order was used and why, so a reader knows whether they hold an argument or an index.

**Build the conventions register here**, because it is an architectural decision, not a copy-editing one. It fixes: the terminology lexicon (one term per concept, including what the customer, the product and each segment are called); base conventions (what "all respondents" means, how routed questions are based, when a base appears on the page); rounding (whole percentages by default per K3 §4.4, when a decimal is permitted, and the rule that a rounded verbal expression never appears without its exact figure on the same page); comparison conventions (the comparator wave, what counts as a change worth reporting, how untested differences are described per K4 §3.1); confidence vocabulary (the K3 registers, and which words are reserved for which level); headline grammar (step 10); the quote editing convention (K4 §2.3, stated once); and visual labelling. *Correct result:* a chapter plan mapped to the narrative, a stated order rule with its justification, and a register a second writer could apply without asking you a question.

**Step 7. Map evidence to chapters.** Assign every prioritised finding to exactly one chapter, building the evidence map required by K2 §5 as you go. The map is a working artefact of compilation, not a deliverable produced afterwards for an auditor: it is built during assembly because that is the only moment when the link between a claim and its source is still in front of you. Each row carries the reference, the report location, the claim, its level on the K2 chain (finding, interpretation, insight, implication, recommendation), the source codes it rests on, base and question reference, and confidence. A finding that wants to appear twice means either the chapter boundaries are wrong or the second appearance should reference the first, not restate it. Findings with no chapter go to the appendix or are cut, and the decision is recorded. **Every recommendation gets its row populated backwards**, naming the findings beneath it; one that cannot be traced backwards is deleted here rather than defended later. *Correct result:* an evidence map with no empty source cells, in which every chapter has enough material for its page budget.

**Step 8. Identify evidence gaps.** Read the architecture against the map and find where the narrative wants something the evidence cannot supply. Gaps are structural: a thin chapter, a transition asserting a link nothing measured, a recommendation whose second premise came from a meeting rather than the data. There are exactly four honest responses. **Fill it** by returning to the analysis, if the material exists and time permits, the only response that adds evidence. **Reframe it** by restating the section at the level the evidence does support, usually one step less specific. **Demote it** to "what we could not establish", per K3 §5.2, where it becomes the strongest part of the next brief. **Cut it**, and adjust the narrative so the argument no longer requires it. There is no fifth response. Writing across a gap with confident connective prose is the commonest way an honest project produces a dishonest report, and it is most tempting when the narrative is otherwise elegant and one link is missing. Per K4 §1, a slot in a template is not evidence. *Correct result:* a gap list with one of the four dispositions against every entry, and a "what we could not establish" section that has content before writing begins.

**Step 9. Develop visuals.** Write the claim each visual must carry before choosing its form: one visual, one idea, and the idea is the chart title. Chart type selection is **11.04**, visual styling **12.02**. Compilation owns the match between claim, chart and base, and the consistency of that match across the report: fix scales, colour meaning and segment order once and apply them everywhere. Every visual carries its question reference, base description and base size on the page, per K4 §4.3 and §7. Images and video stills carry a caption stating what is shown, a capture reference, and consent status. Where a finding is stronger as a sentence than a chart, write the sentence: a chart built to fill a page is the visual form of the gap-filling prohibited at step 8. *Correct result:* a visual list where every entry has a claim, a source, a base and a reason for its form.

**Step 10. Write the report.** Write chapter by chapter, in narrative order, applying the conventions register without exception. Three disciplines carry the writing.

**Answer-first communication.** Lead with the conclusion, then the evidence. "62% of respondents prefer messaging" leaves the reader to do the interpretive work. "Messaging is the dominant communication preference, chosen by nearly two thirds of respondents (Q4, total sample, n=1,204)" does that work for them and remains exactly as true. The limit is where this technique goes wrong: **never let the upgrade claim more than the evidence carries.** "Customers have abandoned phone and email for messaging" is overreach, because preference was measured and behaviour was not, and because abandonment is a change over time this study did not measure. "Messaging is what customers want, so the phone line can be scaled back" is worse: a recommendation has been smuggled into a finding and the reader cannot see the join. The test: strip the sentence of its evidence and ask whether what remains is a fair statement of what was measured, on the base it was measured on. Note that "nearly two thirds" is permitted only because the exact figure and base sit on the same page, per K2 §7.

**Headlines that communicate the finding.** "Customer Satisfaction" is a label: it says what the page is about and leaves the reader to work out what it says. "Satisfaction falls sharply after customers experience their first service issue" is a headline. It states the finding, it can be disagreed with, and it is safe travelling alone into somebody's summary email. Test every headline three ways: is it a claim rather than a topic; is it true of the page beneath it and nothing more; would it survive being quoted with no chart attached. Watch the overreach here too, since "First service issues destroy customer satisfaction" adds causation the design does not license, per K4 §3.2. **One primary idea per page**, always. A page carrying two ideas has one that is being ignored.

**One voice.** The defining standard of the skill, and it is produced mechanically rather than stylistically. Hold **one level of abstraction per section**, so a chapter on market structure contains no paragraph about a button label. Use **one term per concept**, from the lexicon, even where a source document used another word. Apply **one base and rounding convention** everywhere. Use the **K3 confidence registers consistently**, so "suggests" always means moderate and never high. Apply the **same headline grammar** to every page, and keep tense, person and number formatting constant. Where an input arrives in another author's voice, rewrite it into the register and verify the rewrite against source, because rewriting is where quotes get smoothed and references get lost. *Correct result:* a draft in which a reader cannot tell which sections came from which analyst, and in which the point where reporting becomes arguing is visible on every page, per K2 §3.3.

**Step 11. QA every major claim.** A major claim is any headline, any executive summary sentence, any recommendation, any number in a chart title or callout, any quote, and any comparative, trend or significance claim. For each, walk the chain: locate its row in the evidence map, open the named source, and confirm the number, the base, the question, the direction and the wording, recomputing anything transcribed by hand. Verify every quote word for word, with the participant ID checked against the segment it is attributed to. Confirm that no claim gained confidence between the analysis and the summary, the commonest defect in compiled reports, per K3 §7. Then run three sweeps: the same number reported identically everywhere; the same term for the same concept everywhere; every objective answered or listed as unanswered. **Where two sources give different numbers for the same thing, investigate the discrepancy to its origin. Never resolve it silently, and never adopt the more convenient figure.** The usual causes (a different base, a different filter, a different rounding point, an excluded "don't know", a wave with reworded questions) are each themselves reportable. Where the origin cannot be established, report neither figure as fact: state the range, name both sources, and flag it per K5 §3.1. This pass does not replace independent review: hand the report and its evidence map to **12.06 Research Report QA**, and to **13.01 Research Quality Review** where methodological soundness itself needs assessment. *Correct result:* a QA log recording every claim checked, what changed, and every discrepancy with its investigated cause, alongside a report containing no claim you could not defend from source.

## 8. Analytical framework

The compilation chain, which runs on top of the K2 evidence chain rather than beside it:

    Inventory → Objectives → Hierarchy → Findings → Narrative → Architecture
        → Evidence map → Gaps → Visuals → Draft → QA
                              ↑
              Every arrow after this point must preserve the source code
              attached at Inventory. A claim that arrives at Draft without
              its code has broken the chain and cannot be repaired by memory.

**Applying it.** The first six steps converge (many inputs to one argument). The last five diverge (one argument back out to many checked claims). The evidence map is the hinge, and it is the reason the return journey is possible at all.

**The single-hand test.** Before the report leaves, read three sections chosen at random, from different chapters, in sequence. Ask: could a reader tell these were written by different people? Consistency of terminology, base convention, confidence language, headline grammar and abstraction level is what produces the answer "no". Style is not what produces it, and matching style without matching conventions produces a report that sounds uniform and contradicts itself.

**The four archetypes of report order**, for step 6: **decision-led** (organised around the choice the client must make, strongest when there is a live decision), **journey or chronological** (organised around a customer or process sequence, strongest when the experience is the subject), **segment-led** (organised around audiences, strongest when different teams own different audiences, and weakest at producing one argument), and **objective-led or questionnaire order** (organised around the instrument, appropriate only in the cases named in step 6 of the methodology). Choose one and hold it. A report that changes archetype at chapter 4 reads as two reports.

## 9. Output format

The structure below is a starting architecture, not a template to be filled. **How to decide the structure:** take the archetype from Section 8 that matches the decision and the audience, set the chapter count from the number of distinct arguments the narrative requires (not from a habitual number), and give each chapter a page budget proportional to its weight in the decision rather than to the volume of data behind it. Then test the plan against the finding register: if a chapter cannot be filled from prioritised findings, it is the wrong chapter. Pure structural questions go to **12.01**; pure visual questions go to **12.02**. Compilation owns the fit between structure and evidence, the conventions that hold across sections, and the traceability that survives assembly.

**A. Front matter**
Title, date, author and sign-off; the decision and audience the report was written for; objectives as questions; method summary with sample, fieldwork dates, weighting status and any non-probability disclosure per K4 §7; the conventions used (bases, rounding, comparison rules, quote editing convention); disclosure of AI involvement and what a human verified, per K5 §7; consolidated review points, per K5 §3.3.

**B. Executive summary**
The narrative in full, with each headline conclusion carrying its confidence in words, per K3 §5.2. Written last, after QA, from the checked report. Handed to **11.02** where the summary is itself a substantial deliverable.

**C. Body chapters**
Each chapter opens with the claim it establishes, holds one level of abstraction, carries one primary idea per page, and closes by handing to the next. Every page: a finding headline, the evidence, the base and question reference, and the interpretation marked as interpretation.

**D. Implications and recommendations**
Each recommendation states the action, the findings it rests on by reference, its confidence per K3 §5.2, what would change it, and a `RESEARCHER SIGN-OFF REQUIRED` marker per K5 §3.1. Developed in **08.03** and **08.04**; compilation's job is to ensure none arrives without its chain.

**E. What we could not establish**
Objectives not answered, questions the evidence cannot settle, gaps demoted at step 8, and contradictions left unresolved. Required in any substantial report, per K3 §5.2.

**F. Evidence map**

| Ref | Report location | Claim | Level | Source codes | Base / question | Confidence |
|---|---|---|---|---|---|---|

Per K2 §5. Every recommendation and every executive summary claim appears. A row with no source is a defect, not a gap.

**G. Source inventory**

| Code | Input | Producer | Date | Method | Base / sample | Verification status | Used |
|---|---|---|---|---|---|---|---|

**H. Appendix and data book**
Everything analysed that did not earn a place in the narrative, plus full tables, the questionnaire as fielded, and the discrepancy log from step 11.

**When the evidence is thin.** The structure contracts rather than filling. A chapter with two findings becomes a section inside another chapter. A recommendation with no finding behind it is deleted, not softened. An objective with no answer appears in section E under its own heading, which is more useful to the client than a thin answer and is frequently the origin of the next project. Where a client-supplied or unverified input is the only support for a point, the point is reported with that label attached and never as a headline, per K2 §6. The report is as long as the evidence, and a shorter report that says what it can defend outperforms a complete-looking one that cannot.

## 10. Quality checks

Run before anything is presented. Sits on top of K4 §8.

1. Does every input in the project appear in the source inventory with a code and a verification status, including the ones not used?
2. Does every claim in the report trace to a source code, and does every source code resolve to a real file?
3. Is the same number reported identically in every location it appears, including the summary, the chart, the chart title and the appendix?
4. Was every discrepancy between sources investigated to its cause and logged, rather than resolved to the convenient figure?
5. Is every base size shown where a proportion is reported, and does each base description match the questionnaire routing?
6. Is one term used for each concept throughout, and does the lexicon match the previous wave where comparability is claimed?
7. Are client-supplied figures, previous-wave data and unverified inputs labelled as such at every appearance, not only at first mention?
8. Does every previous-wave comparison confirm matching question wording, base definition and method, or state that it does not?
9. Is every headline a claim rather than a topic, true of its page, and safe if quoted alone?
10. Does any headline or answer-first sentence claim more than its evidence supports, particularly causation, behaviour from stated preference, or change over time?
11. Does every page carry one primary idea, and does every section hold one level of abstraction?
12. Has any claim gained confidence between the analysis output and the executive summary?
13. Does every recommendation name the findings beneath it, carry a confidence marker, and hold a sign-off flag?
14. Is every quote verified word for word against source, with a participant ID that belongs to the segment claimed?
15. Is every objective either answered in the report or listed in "what we could not establish"?
16. Is contradicting evidence present in the report rather than resolved in the narrative, per K4 §4.1?
17. Could a colleague who was not on the project reconstruct the top three conclusions from the evidence map alone?

## 11. Common failure modes

| Failure | How to recognise it | How to prevent it |
|---|---|---|
| **Compiling over unfinished analysis** | Placeholders, "TBC", a chapter waiting on a cut that has not been run | Step 2 of Section 6. Do not begin. Finish the analysis first |
| **Seam-smoothing** (the signature AI failure) | Elegant transitional prose that asserts a link nothing in the evidence map supports | Step 8. Every connective claim needs a row in the map or it is cut |
| **Silent number reconciliation** | Two analysts' files disagreed and the report shows one figure, with no record of why | Step 11. Investigate to origin, log the cause, never adopt the convenient figure |
| **Confidence inflation in transit** | The analysis says "appears to", the chapter says "shows", the summary says "proves" | Fix the K3 registers in the conventions register and check the summary against source, not against the chapter |
| **Source code decay** | A claim in the draft with no reference, where the working document had one | Never rewrite a sentence without carrying its reference. Build the map during assembly, not after |
| **Questionnaire order by default** | Chapters map one to one onto sections of the instrument, and no chapter has a conclusion | Step 5 before step 6. Narrative order unless an exception in step 6 applies |
| **The topic headline** | Headlines are noun phrases; a reader must read the chart to learn the finding | Every headline is a claim with a verb. Test it standing alone |
| **The over-upgraded headline** | Answer-first phrasing that has quietly added causation, behaviour or trend | Strip the evidence and check what the sentence still asserts |
| **Template completion** | A section exists because the template has one, filled from the strongest nearby fragment | K4 §1. Format is not evidence. Use one of the four dispositions at step 8 |
| **The vanishing contradiction** | A clean story, and the register's contradicting findings appear nowhere | Locate the strongest contradicting evidence at step 5 and decide where it goes before writing |
| **Many hands, visible** | Segment names change between chapters; bases described three ways; a chapter reads at a different altitude | Conventions register at step 6, applied without exception at step 10. Run the single-hand test |
| **Quote drift on rewrite** | Quotes read fluently, in the report's voice, in a consistent register | Verify against transcript after rewriting the surrounding prose. Permitted edits only, per K4 §2.3 |
| **False wave comparison** | A trend chart across waves where the question was reworded or the sample redefined | Check wording, base and method before any comparison. Where they differ, report the waves separately and say why |
| **Client input laundering** | A client-supplied figure carrying a headline, indistinguishable from analysed data | K2 §6. Label at every appearance and never lead with it |
| **The orphan recommendation** | A recommendation everyone agrees with, with no finding behind it | Populate recommendation rows backwards at step 7. No chain, no recommendation |

## 12. AI guardrails

Skill-specific only. Universal prohibitions are inherited from K4 and are not repeated here. Traceability under compilation follows **K2 §6**; quote handling follows **K4 §2.3**.

1. **Never write connective tissue that asserts a relationship no input establishes.** Transitions carry argument, and an argument needs evidence. If the join cannot be sourced, the two sections do not join, and the report says so.
2. **Never reconcile conflicting numbers silently.** Two figures for the same quantity means an investigation, logged, per step 11. Where the cause cannot be found, report the range and both sources rather than choosing.
3. **Never let a claim change confidence level between an input document and the report.** The wording in the summary is checked against the analysis it came from, not against the chapter that paraphrased it.
4. **Never present client-supplied, previous-wave or unverified material as though it had been through your analysis.** The label travels to every appearance, per K2 §6.
5. **Never compare across waves without confirming that question wording, base definition and method match.** Where they do not, the comparison is not made, and the reason is reported.
6. **Never resolve a contradiction between two evidence streams by choosing the one that fits the narrative.** Report the divergence, per K2 §4.4, and assess which source is stronger under the step 3 hierarchy, showing the reasoning.
7. **Never fill a chapter, a page or a slot because the structure created it.** Use one of the four dispositions at step 8. Format is not evidence, per K4 §1.
8. **Never rewrite a quote, a base description or a number while rewriting the prose around it.** Voice consistency applies to the analyst's words, never to the evidence.
9. **Never upgrade a finding into a headline that claims causation, behaviour, change over time, or population reach the study did not measure.**
10. **Never drop a caveat during compilation.** Caveats travel with their claim into every downstream document, per K3 §7, and a caveat that appears only in the appendix has been dropped.
11. **Never let brand or template guidelines determine what the report concludes.** They govern format. Where a template cannot accommodate a required disclosure, the template changes.

## 13. Best-practice principles

1. **Compilation is an act of argument, not an act of assembly.** The pile does not contain the report. Someone has to decide what it means, and that decision is the deliverable.
2. **Build the evidence map while you compile, never afterwards.** Reconstructed traceability is memory dressed as record, and it is wrong in exactly the places that matter.
3. **Decide the evidence hierarchy before you know which findings you like.** A hierarchy set afterwards is a justification, and everyone downstream can tell.
4. **The report is the client's, and the order is the argument's.** The order the work was done in is a fact about your project plan and of no interest to the reader.
5. **Consistency is what makes many hands read as one, and it is mechanical.** Terminology, bases, rounding, confidence words, headline grammar and abstraction level. Style is downstream of these and cannot compensate for their absence.
6. **A headline is a promise that the page keeps.** If the page under it says something smaller, the headline is wrong, however good it sounds.
7. **Answer-first is a service to the reader, not a licence to conclude harder.** The upgrade is in the framing, never in the claim.
8. **The gap you most want to write across is the one you most need to name.** Elegance is the warning sign, not the reward.
9. **A discrepancy is information.** Two analysts disagreeing about a number is usually telling you something true about a base, a filter or an exclusion. Investigating it improves the report; resolving it quietly hides a defect.
10. **What you cut matters as much as what you keep.** Record the cuts. The material that did not earn a place in the narrative is the appendix, the next brief, and the answer when a stakeholder asks whether you looked at something.
11. **Write the executive summary last, from the checked report.** Written first, it becomes a brief the report is then written to satisfy, which inverts the whole process.
12. **Read the report as the person who disagrees with it.** They will find the unsupported transition, the base that changed, and the recommendation with nothing behind it. Better that you find them first.
13. **The compilation is finished when every claim can be defended from source in under a minute.** Not when it reads well, and not when it is long enough.

## 14. Worked example

*Fictional scenario, used for illustration only. The organisation, inputs, figures and quotes below are invented for the purpose of demonstrating method.*

**INPUT.** A regional public transport authority commissions research into a two-year decline in off-peak ridership. Inputs: a four-objective brief; a survey of 1,180 residents with cross-tabs produced by two analysts in separate workbooks; 18 depth interviews with lapsed off-peak users; 40 participant voice notes recorded at the moment of deciding not to travel; station-visit photographs; a wave-one report from two years earlier; a client-supplied ticketing extract; and three published sector sources. The decision behind the brief: whether to fund an off-peak fare reduction next year.

**PROCESS.**

*Steps 1 to 3.* Inventory assigns 14 source codes. Two survey workbooks carry different figures for off-peak usage frequency, so both are coded and flagged as a duplicate pair. The wave-one report is marked "comparability unverified". Objectives are rewritten as four questions, with a note that the live decision is a fare decision, which will pull emphasis toward price even though the brief does not lead with it. The hierarchy is agreed before findings are read, with one exception recorded: the ticketing extract outranks the survey on actual journey frequency, because it measures behaviour rather than recall, while remaining client-supplied.

*Step 4, and the discrepancy.* The two workbooks report off-peak weekly usage as 34% and 29%. The convenient figure is 34%, which implies a larger addressable base for a fare cut. Investigation to origin shows a base decision: one analyst based the question on all respondents, the other on those who had travelled in the past year, excluding 61 non-travellers. Neither is wrong, and the discrepancy is itself reportable, because it changes what the fare decision is aimed at. The travelled-in-past-year base becomes the convention, both figures appear once with an explanatory note, and the cause is logged. Twenty-seven findings are prioritised.

*Step 5, and the judgement call.* The survey ranks price first among stated reasons for reduced off-peak travel (Q18, n=812). The interviews and voice notes place price third, behind reliability and personal safety after dark, and several participants describe price as the reason they give rather than the reason they feel. The narrative pressure is obvious: the client is deciding on fares. Per K4 §4.1 the divergence is reported, not averaged. The hierarchy resolves the lead: two independent primary streams converge on reliability and safety, while price rests on a single stated-reason item, indirect evidence of behaviour under K3 §3.4. The narrative becomes: price is what off-peak users say and reliability and safety are what they describe doing, so a fare reduction alone is unlikely to recover the trips. Stated at moderate confidence, with the divergence on the page, and flagged `RESEARCHER REVIEW RECOMMENDED` per K5 §2.3, because whether the authority can act on reliability is organisational knowledge the study does not contain.

*Steps 6 and 7.* Decision-led architecture, five chapters. The register fixes the base convention, whole-number rounding, the term "off-peak journey" (three inputs used three terms), and the rule that untested differences are described as observed. An inherited recommendation, "improve station lighting", is traced backwards to one stakeholder comment and no finding, and deleted here rather than defended later.

*Step 8, and the gap.* The narrative wants a chapter on whether lapsed users would return under improved reliability. Nothing measured it, and the tempting move is a paragraph inferring return propensity from stated dissatisfaction. Instead the section is reframed to what the evidence supports (the conditions participants described as necessary before reconsidering, 11 of 18 interviews, as counts), and the unanswered question moves to "what we could not establish", where it becomes the first objective of a follow-up. Two of four wave-one trend charts are dropped, because the frequency question was reworded between waves, and the reason is reported.

*Steps 9 to 11.* Three charts collapse into sentences. QA finds a summary line reading "reliability is driving the decline", causal language the design does not license per K4 §3.2, corrected to an association. Two quotes tidied during the voice-consistency rewrite are restored to source wording. The ticketing figure carries its client-supplied label in all four appearances.

**OUTPUT.** A five-chapter report in decision-led order; an evidence map covering every summary claim and all six recommendations; a 14-item source inventory; a discrepancy log with the base investigation recorded; a "what we could not establish" section naming return propensity and two dropped wave comparisons; and a fare recommendation at moderate confidence, with the divergence between stated and described reasons visible on the page rather than resolved behind it.

## 15. Advanced usage

**Very large or multi-market projects.** Compile market by market to a single conventions register, then compile the compilations. The register must exist before the first market is written or the merge becomes a rewrite. Where markets diverge, report the divergence as a finding rather than reporting an average nobody lives in, and have a reviewer with the relevant context read each market before findings are fixed, per K5 §2.2.

**Tracking and repeated waves.** Freeze the conventions register between waves and version it. Any change to a base definition, a question, a segment or a term is logged with the wave it entered and is disclosed at the point of first comparison. The register becomes the study's institutional memory and is worth more than any single wave's report.

**Compiling other people's work.** Inventory first and read for content second, or you will inherit their narrative before you have seen the evidence. Treat every claim in an inherited document as unverified until it has a source code, and expect the strongest-sounding claims to be the weakest sourced, because they have been repeated the most.

**When findings and previous published claims conflict.** Where this report will contradict something the client has already said publicly, that is a materiality and reputational judgement, not an analytical one. Compile the honest version, mark it `RESEARCHER DECISION REQUIRED` per K5 §3.1, and let a named human decide how it is handled.

**When the standard approach does not fit.** A project with genuinely irreconcilable evidence streams should not be forced into one narrative: compile it as two readings with the evidence for each and the conditions under which each would be right, and say plainly that the study cannot adjudicate. That is a more useful document than a false synthesis, and it is a legitimate output of this skill.

## 16. Skill chain

**Recommended previous skills:**
- **12.01 Research Report Architecture.** Hands over a structural plan and chapter logic, which compilation tests against the finding register and fills.
- **12.04 Research Evidence Integration.** Hands over evidence streams already reconciled at the measurement level, with convergence and divergence assessed, so compilation records rather than resolves them.
- **11.01 Research Narrative Development.** Hands over the storyline, which compilation verifies against the final evidence rather than assumes.
- **08.03 Implication Development** and **08.04 Recommendation Development.** Hand over implications and recommendations with their reasoning attached, which compilation traces backwards to findings before admitting them.

**Recommended next skills:**
- **12.02 Research Report Design.** Takes the compiled, checked report and applies layout, typography and visual system without altering claims.
- **11.02 Executive Summary Development.** Takes the QA'd report and builds the summary from checked content, with confidence stated per conclusion.
- **12.06 Research Report QA.** Takes the report and its evidence map and runs independent structured checking, which the author's own pass at step 11 does not replace.
- **13.01 Research Quality Review.** Assesses the methodological soundness of the study the report rests on, as distinct from the report's internal consistency.

**Runs well alongside:**
- **07.04 Quote and Evidence Extraction**, for verified, correctly attributed verbatim during step 10.
- **11.04 Data Visualisation and Chart Selection**, at step 9.
- **13.03 AI Output Verification**, run against the compiled draft before it is trusted.
- **K2 §5 and §6**, which define the evidence map and the compilation rules this skill operationalises, and **K5**, at the review points compilation typically generates: strategic implication, materiality of a contradicting finding, and sign-off on every recommendation.

---
A Yazi Supplied Skill and resource.