Paper Logic

Academic Writing: Logic & Consistency Review

Review the paper at $ARGUMENTS (a directory of sections or specific files) for argument-level logic and cross-section consistency. If no argument is given, locate the paper sources (e.g., sections/*.tex plus the main file containing the abstract) and confirm the file set with the user.

This skill checks the whole-paper layer: does the argument hold together, do the numbers reconcile, is the terminology stable. For sentence-level prose (nominalizations, weak openings, word choice), run /paper-review per section; for applying fixes, run /paper-fix. Do not duplicate their sentence-level findings. The one exception is section M's mechanical greps (punctuation, agreement), which enforce house style at whole-paper scope because they catch drift that per-section review misses.

All examples below are from a fictional paper about a fictional adaptive caching system. They illustrate the shape of each antipattern; never copy them into your report. Every finding must quote the actual paper under review.

Output contract (non-negotiable)

Your report is incomplete unless ALL of the following hold. Re-walk the checklists until they do.

1. Every checklist ID (A1–A7, B1–B5, C1–C7, M, P) appears in the report, either with findings or with the line [Xn] checked — no findings, plus one sentence saying what you looked at. Silent skips are not allowed.
2. Every finding has all four parts: file:line, a verbatim quote from the paper under review, a problem statement that names the reasoning error (not "this is unclear"), and a concrete fix — for prose problems, a full rewritten sentence, not "consider rephrasing".
3. The three working tables are filled in and printed (term, number, promise), built from the paper under review. Do not write any finding before the tables are complete: most logic findings fall out of the tables, and skipping them is how reviews end up shallow.
4. The mechanical greps in section M were actually run and each hit triaged (finding / false positive, one line each).
5. Calibration: a mature 5-section systems paper typically yields 15–30 findings across severities. If you have fewer than 10, you have under-checked — re-walk A and B with the tables in front of you. If you have zero Must-fix findings, explicitly state which Must-fix categories you verified and how.
6. Findings are sorted Must fix → Should fix → Consider, and the report ends with the three tables, the top-5 list, and the verdict paragraph.

Severity rubric

• Must fix: a reviewer can reject on it — circular argument, numbers that contradict each other, claim without support, garbled contribution item, undefined term a reader cannot decode.
• Should fix: weakens credibility but doesn't break the argument — terminology drift, late definitions, false precision, renumbering debris.
• Consider: judgment calls — paragraph splits, citation placement, hedging word choice when scope is preserved. A dropped scope qualifier or a body-hedged claim turned absolute is A4/A5 (Must or Should), never Consider.

Process

1. Read all section files in order, plus any terminology-conventions file the project keeps (e.g., wording.md) if present. Logic problems are invisible in a single section — never run this skill on one file alone.
2. First pass (build, don't judge): fill the three working tables below.
3. Run the mechanical greps (section M); triage every hit.
4. Second pass (judge): walk checklists A–C against the tables.
5. Walk the per-section protocol (section P).
6. Write the report per the output contract.

The three working tables

Formats below, illustrated with fictional rows. Build them from the actual paper.

Term table

One row per recurring concept. The "names used" column exposes drift.

A concept with 2+ names, or one name covering 2+ concepts, is a C1 finding. A "first defined at" that comes after a use is a C2 finding.

Number table

One row per quantitative claim. Same fact in multiple places = one row with multiple locations; mismatched forms are B1 findings, reader-derivable-only values are B2 findings.

Promise table

One row per claim in the abstract, intro, or contributions list.

A. Argument-structure antipatterns

A1. Solution vocabulary in the motivation

Motivation/empirical/background sections must describe the problem in problem-domain terms. If they classify the world using the system's own mechanisms, the study stops being independent evidence and begs the question.

Bad (in a workload-study section):

These access patterns map directly to our epoch-counters and ghost-list primitives.

Good (same section):

Three recurring patterns emerge: bursty re-reference, scan pollution, and slow drift. All three require admission decisions that depend on history beyond the current request.

…and in Design: "The three patterns identified in §2 reduce to two mechanisms: epoch counters and ghost lists."

How to check: list the design section's mechanism nouns, then grep for each in every section that precedes the design. Each hit in motivation/background is a finding unless it is citing prior work.

A2. Self-referential categories used as neutral populations

Defining a category by reference to the system, then reporting its size as an independent finding, is circular.

Bad:

…the subset of requests that \sys{} can intercept is \emph{trackable}. […] Our study finds that 73% of requests are trackable.

Good:

A request is \emph{trackable} if it carries an object identifier visible at the proxy layer, independent of any particular system. The study finds 73% of requests are trackable, and \sys{} targets exactly this class.

How to check: for every \emph{}d or defined category, ask "does the definition mention the system?" If yes, every later use of that category's count as a population is a finding.

A3. Broken requirement→challenge→component chains

If the motivation derives N requirements, the design must visibly consume all N. Count both ends and demand an explicit mapping.

Bad: the motivation summary lists four requirements (history-aware admission, low memory, isolation, observability); the design opens "Two key challenges arise" and resolves them with "three techniques"; isolation and observability map to neither.

Good: a mapping sentence at the start of design: "Requirements R1–R2 raise challenge C1, addressed by epoch counters (§4.1) and ghost lists (§4.2); R3 raises C2, addressed by per-tenant partitions (§4.3); R4 is an implementation property, evaluated in §6.3."

How to check: write out three literal lists (requirements, challenges, components) with locations; draw the mapping; report every orphan on either side as a finding.

A4. Conclusion outruns the evidence

Claims scoped to a selected subset must stay scoped in every restatement, and hedging level for the same claim must be identical everywhere.

Bad: eval says "These results suggest that history-aware admission improves tail latency on the 12 cache-sensitive workloads"; conclusion says "\sys{} improves tail latency on production workloads."

Good: the conclusion repeats both the hedge and the scope, or the eval explicitly justifies upgrading the claim.

How to check: for each promise-table row, diff the qualifiers ("suggest", "on the subset", "up to", "in our setting") between the eval sentence and every restatement in abstract, intro, and conclusion. Any dropped qualifier is a finding.

A5. Absolute claims for non-absolute limitations

Reserve "cannot", "never", "impossible", and "guarantees" for structural, by-construction facts (a stateless mechanism cannot track cross-event state; tool-call interception cannot observe effects outside the tool boundary). Limitations that are a matter of cost or effort ("an administrator could, with enough work") take "hard", "impractical", or "rarely". Also check the reverse drift: a claim hedged in the body must not strengthen to an absolute in the abstract or intro.

A6. A leap presented as an observation

"X has property P; this makes X the natural Y" is an argument, not a fact. Either rebut the obvious objection in place or forward-reference where it is handled.

Bad:

Application developers already know their access patterns. This makes them the natural authors of admission policy.

Good:

Application developers already know their access patterns, so they hold the context that admission policy needs. Letting tenants author policy raises an isolation problem, which we address by bounding each tenant's policy to its own partition (§4.3).

How to check: grep for natural|clearly|obviously|therefore|this makes| this means in intro/motivation; for each hit, ask "what objection would a hostile reviewer raise here, and is it answered or forward-referenced?"

A7. Two arguments packed into one paragraph

One paragraph, one claim. How to check: for each intro/motivation paragraph, write its one-line claim; if the line needs "and also", split the paragraph and report it, naming both claims.

B. Quantitative-consistency antipatterns

B1. Numbers that don't reconcile across sections

Every number in abstract/intro/conclusion must appear verbatim in (or be trivially derivable from a single labeled place in) the evaluation, and the same result must keep one canonical form.

Bad: intro "1.8–2.4×"; eval text "15–22 percentage points" and "2×"; table raw counts — three forms, no anchor sentence connecting them.

Good: one headline form, printed next to its table, reused verbatim: "serves 61 of 90 bursty workloads from cache, 1.8–2.4× the 25–34 of the baselines (Table 2)".

B2. Forced reader arithmetic

If the headline claim is a ratio or delta, print it beside the table it comes from. How to check: for each abstract/intro number, search the eval for it verbatim; if you had to compute it from table cells, so will the reviewer — that is the finding, and the fix is an anchor sentence.

B3. Denominator hygiene

Every rate names numerator and denominator at first use; exclusions are stated before the rate; subset selection states the rule, counts the remainder, and scopes conclusions (cross-check A4).

Bad: "\sys{} eliminates 70% of avoidable misses. […two paragraphs later…] Cold-start runs are excluded from the miss-rate denominator."

Good: "Of 120 avoidable misses, \sys{} eliminates 84 (70%). The 40 cold-start runs are excluded up front because no admission policy can serve a first access."

How to check: grep for % and rate; for each, write value = N/D with both numbers named in the same paragraph. Missing N or D, or a post-hoc exclusion, is a finding.

B4. False precision and unsourced constants

Significant digits must match measurement reliability; constants from outside the experiment need citations.

Bad: "$0.0314 per query […] At typical cloud egress rates, about $12.47 per workload." (four significant digits against an uncited price assumption)

Good: "about $0.03 per query, versus roughly $12 per workload at list-price cloud egress~\cite{cloudpricing2026}".

How to check: grep for \$[0-9], orders of magnitude, and 3+ significant-digit values; each needs a source (measurement, citation, or shown derivation).