anti-defensive-writing

Anti-Defensive Writing

A research paper argues from evidence. It does not keep an audit log of its own project, argue with an imagined reviewer, criticize itself, document its repository, or make promises. This skill removes those voices from every part of the paper, Supplementary Information included, and keeps everything a reader needs to understand, trust and reproduce the work.

The paper should feel controlled because the design is clear, not because the authors keep saying that it is controlled.

Read What stays before deleting anything, and Local integration for where this skill sits in the paper-workflow chain.

Rule zero: do not add it

Most audit and defensive text is added during editing, not during drafting: an edit fixes an ambiguity, answers a co-author or reviewer comment, or adds provenance "to be safe". While editing any text:

• Add no qualifier, disclaimer or provenance note unless the sentence would otherwise be literally false.
• Fix an ambiguity with a precise definition, not with a caveat. "Labels A to D denote four dataset regimes" beats a sentence explaining what the labels should not be taken to mean.
• A request for a small change gets a small change: one sentence, not a protective paragraph around it.
• Do not weaken a claim in advance because a control or baseline is not yet in the draft. Whether a claim needs qualifying is decided when that evidence arrives.

The six voices

Each voice has recognition cues and one fix. A cue is a candidate, not a verdict; classify it with the procedure below before changing it.

1. Audit voice: the project's process leaking into the paper

The text reports how the work was run and checked instead of what it found. Typical cues:

• process status: locked, frozen, hashed, scored once, fixed in advance, deterministic assignment, identical comparison arms restated, configuration hashes;
• verification talk: verified rather than assumed, the numerical check that, to verify, sanity check, leakage-safe, implementation verification, the pipeline was confirmed to;
• provenance qualifiers in Results: post hoc, added after the original evaluation, historical locked recomputation, primary arm of the original design;
• internal vocabulary: phase and gate names, PASS or FAIL verdicts, retired metric names (files, folders and code names are the developer voice, below);
• checker language presented as a finding: "no additive cost is resolvable";
• attempt narration, what was tried before the final design and what did not work: "we first tried", "an earlier version", "we also experimented with", "did not help".