Itcs Writing Style

ITCS Writing Style

At ITCS the reader must feel the innovation before the theorem. Reviewers are briefed to reward a new model, question, or connection over a deeper result on an old one, so a paper that opens like a STOC depth paper — leading with a bound and a technique — reads as if it mistook the venue. The whole job of the first pages is to make a skeptical expert think "I hadn't thought to ask that, and I want to" before they reach a single lemma. Because ITCS has no rebuttal (see itcs-review-process), the writing must also pre-empt objections there is no later chance to answer.

The ITCS first-page arc

Structure the abstract and introduction as:

1. The new question or model — the first breath. Name the object or ask the question the standard setting cannot phrase. Not "we study X with parameter Y," but "here is a thing worth thinking about that we did not have a way to talk about."
2. Why the field lacked it — isolate the silent assumption or missing seam that hid the question. This is the honest delta (see itcs-related-work).
3. The conceptual payoff — what the new lens lets us see or do: a connection, a reorganization of known questions, a new axis of measurement.
4. A result that shows the model is alive — at least one crisp theorem (a separation, a surprising possibility, an impossibility) proving the model is neither empty nor everything. ITCS PCs probe every new model for exactly this.
5. Scope and directions — own what is unresolved and frame the open problems as the deliverable. At ITCS a candid "first map" beats a polished increment.

See the before/after in ../../resources/worked-examples/01-introduction.md.

Lead with the idea, not the machinery

• State the contribution as a new noun. "We introduce forgetful certificates" beats "we analyze memory-bounded provers." A named object the community can adopt is the ITCS currency.
• Motivate the model as a lens, not a tweak. Do not write "we add a bound"; write what the bound reveals. The move that earns ITCS acceptance is showing the new setting makes an old thing look different.
• Spend the abstract's real estate on why-it-matters, not on constants. "Improving the constant" or "tightening the bound" is a depth-venue virtue; at ITCS it can actively signal the wrong fit. Report the result, then immediately its conceptual consequence.
• Do not over-claim finality. ITCS respects a bold, incomplete direction. Overselling a first foray as the last word invites the reviewer to test it as one and find the gaps.

The first-10-pages merits window

ITCS submissions have no hard page limit, but the community norm (stated in the call) is that the first ~10 pages give a clear, self-contained presentation of the paper's merits, significance, innovations, and place in the literature, with complete proofs following (in an appendix if needed). Treat those ten pages as the document a busy PC member actually reads to decide:

• The model, the motivation, the main results, and the why-new must all fit and cohere there.
• Proof ideas (a paragraph of intuition per main theorem) belong here; full proofs can defer.
• Do not bury the innovation on page 14 behind preliminaries — if the merits are not legible by page 10, the paper is effectively judged as if they are absent.

Pre-empting objections (because there is no rebuttal)

Write the three reviewer objections into the paper:

• "Is the model trivial or all-powerful?" -> the anchoring result in the intro, and a remark placing your model between two known extremes.
• "Is this actually new?" -> a delta-first related-work paragraph that names the closest prior model and says exactly what it did not ask (not a citation dump).
• "Why should the community care?" -> a concrete payoff: a connection drawn, a question reframed, an application sketched — even if informal.

Technical presentation

• Definitions before use, self-contained. A reviewer should parse every theorem statement without your prior papers open — which lightweight double-blind would expose anyway.
• One idea per definition. Resist bundling three parameters into a mega-definition; ITCS readers value a clean object they can carry away.
• Proof intuition in the body, full proofs deferred cleanly. Each main theorem gets a "proof sketch / idea" paragraph in the merits window; the complete proof lives later or in an appendix, clearly cross-referenced. Never write "the proof is standard" for a central claim.
• Keep the open problems as a real section. At ITCS they are part of the contribution — a good open-problems section is an invitation the community accepts by working on your model.

Common failure modes at ITCS

Output format

[ITCS framing status] innovation-first / buried / mis-venued
[First breath] does p.1 pose a NEW question/model before any theorem? yes/no
[Alive] anchoring result present (not empty / not everything)? yes/no
[Merits window] model+motivation+results legible within ~10 pages? yes/no
[Objections pre-empted] trivial? / new? / why-care? all answered in-text? yes/no
[Proofs] every central claim fully proved (appendix ok)? yes/no
[Fix queue] <ordered edits>

Source: brycewang-stanford/Awesome-Journal-Skills → ITCS-Skills/skills/itcs-writing-style/SKILL.md