Quick Start

Before writing a single results sentence, build three artifacts:

1. A property ledger: enumerate every claim as a falsifiable property with (a) a precise statement, (b) the specific observation that would falsify it, (c) a status of Tested-and-passed / Partly-tested / Not-tested, and (d) the exact configuration that produced the evidence.
2. A provenance label set: define a closed vocabulary (e.g., Silicon-measured, CPU-simulated, Derived, Estimate, Designed, Target) and tag every single number in the document with one label.
3. A configuration map: give every distinct experimental setup a letter/ID and require every result row to cite it. If two claims were tested on different builds/setups, say so explicitly rather than letting the reader assume continuity.

Then write Abstract → Properties table → System → Results → Negative Results and Boundaries (mandatory section) → Implications-as-argument → Reproducibility.

Workflow

Progress:

• Extract the actual mechanisms/claims from the work (strip marketing language down to falsifiable statements)
• Assign each claim a letter-coded property (P1, P2, ...) with a one-sentence falsifier
• Build the configuration map (A, B, C...) before writing results — never let a number float without a named source
• Tag every number with a provenance label as you draft, not after
• Write the Abstract last, compressing the property statuses and the two or three most surprising numbers (including the withdrawn/negative ones)
• Write a dedicated "what this does NOT claim" paragraph early (introduction-level), enumerating adjacent claims a reader might wrongly infer
• Write the Negative Results / Boundaries section — minimum one entry per property that was only partly tested, plus every instrumentation artifact discovered during review
• Write the Implications section as explicitly labeled argument, never blending it with measured results
• Build the falsification program: a table of未-run experiments with a stated pass criterion for each
• Cross-check: every number in the body appears in the appendix claims ledger with its label and receipt

Examples

Example 1: Input: "Our cache hit rate is excellent and the system is very fast." Output: "Cache hit rate: 94.2% over 10,000 requests (measured; configuration B, single host, warm cache only — cold-start hit rate was not measured and is a target). Latency: 2.1 ms median (measured; same configuration); this number is dispatch-bound, not compute-bound, per the breakdown in §4, and should not be read as a property of the algorithm."

Example 2: Input: A benchmark comparing System X to a GPU baseline shows a large speedup, but the power measurement for one leg used the wrong physical device. Output: Explicitly withdraw the derived efficiency ratio ("the energy ratio that accompanied this figure is withdrawn because its power leg sampled the wrong chip"), keep the throughput ratio that remains valid, and add a Negative Results entry naming the exact instrumentation defect so a reader cannot accidentally resurrect the withdrawn number from raw logs.

Example 3: Input: A mechanism was verified in isolation (bare-metal kernel) but not in the full integrated pipeline. Output: State the property as "Partly tested" and write the precise boundary: "X is bit-exact and measured in configuration D (synthetic input, standalone kernel); in the live pipeline (configuration G) the same mechanism runs through a different code path and its bit-exactness was not re-verified there — the two configurations should not be conflated."

Best Practices

• One property, one falsifier. If you can't state what observation would prove a claim false, the claim isn't ready to publish — weaken it to an argument or a target.
• Never let a derived number outlive its inputs. If an input measurement is later found flawed, immediately withdraw every number derived from it, by name.
• Name the configuration every time, even when it feels repetitive. Silent configuration-switching between a claim and its evidence is the single most common credibility failure.
• State what an instrument cannot see, not just what it shows (e.g., "the allocator delta does not measure bytes moved; kernel binary re-fetch traffic is unquantified").
• Separate measurement from argument explicitly, including with section headers ("stated as argument, not measurement").
• Report smoke-test instability and protocol sensitivity (e.g., a result that inverts under a smaller fit) rather than hiding it — this is evidence of fragility, which is itself a finding.
• Distinguish host/infrastructure effects from the mechanism under test (e.g., dispatch-bound latency vs. silicon capability) and say so even when it weakens the headline number.
• Give a falsification program: list the specific unmeasured experiments that would most change the paper's conclusions, each with a pass/fail criterion.
• Write a "what is not claimed" paragraph before writing results — it prevents scope creep in every subsequent section.

Common Pitfalls

• Do not average across provenance labels. Mixing a Silicon-measured number with an Estimate into one headline figure destroys the auditability of both.
• Do not let a withdrawn number's companion survive unflagged. If a power measurement is invalid, every ratio built from it is invalid too, even the "obviously fine" half.
• Do not claim generality from a single seed/run. State the exact N and flag single-sample results as such, even when the result is favorable.
• Do not bury negative results in a discussion section. Give them a dedicated, numbered, skimmable section with the same formatting rigor as the positive results.
• Do not describe infrastructure bottlenecks as if they were properties of the core contribution (e.g., don't let dispatch overhead masquerade as a statement about an accelerator's compute capability).
• Do not conflate "designed" with "measured." A specified-but-unbuilt mechanism must never appear in the same table as a measured one without a clearly distinguishing label.
• Do not let the abstract claim more certainty than the body delivers. The abstract should compress the hedges, not drop them.