ICALP Experiments (proof strategy, and computation in service of proofs)

SkillDev tools

Use when matching the argument of an ICALP (EATCS) theory paper to its claim, choosing the proof strategy for an upper or lower bound, deciding when supporting computation (SAT/SMT-verified base cases, computer-assisted case analysis, exhaustive small-case checks) legitimately backs a theorem, and keeping any such computation reproducible without turning a proof paper into an experimental one.

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the ICALP Experiments (proof strategy, and computation in service of proofs) skill

What this skill tells your AI

The instructions your AI receives, as published by brycewang-stanford/awesome-journal-skills in ICALP-Skills/skills/icalp-experiments/SKILL.md and read by ahel’s review.

At ICALP there is usually no experiment section — the evidence for the claim is the proof. This skill is therefore about matching the argument to the claim shape, and about the narrow, real cases where computation supports a theorem (a computer-assisted proof, an SMT-checked base case, an exhaustive small-case verification). It is deliberately not an empirical-evaluation guide: a paper whose contribution is a benchmark result is mis-routed (icalp-topic-selection).

Match the argument to the claim

Claim shapeThe argument that fitsCommon failure caught by referees
Upper bound / faster algorithmAlgorithm + correctness proof + complexity analysisCorrectness hand-waved; complexity ignores a hidden cost
Approximation ratioAn analysis bounding cost vs optimum, with a tight exampleRatio proved only on the easy case; no tight instance
Lower bound (unconditional)A reduction, adversary, or information-theoretic argumentModel too weak to be interesting, or gap left open
Conditional lower boundA fine-grained reduction from SETH/3SUM/APSPWrong assumption invoked; reduction loses a factor
Decidability / complexity (Track B)A decision procedure + matching hardnessProcedure sketched; hardness for a different fragment
Dichotomy / characterizationExhaustive case analysis with each case provedA case silently dropped; "similarly" hiding a hard case

When computation legitimately supports a theorem

Some ICALP results genuinely rely on computation. It must be rigorous and checkable, not suggestive:

  • Exhaustive small-case verification — checking a property for all objects up to size k as a base case of an induction. State the exact range, the encoding, and make the search reproducible.
  • SAT/SMT-certified steps — using a solver to verify a finite gadget or unsatisfiability. Ship the encoding and, where possible, an independently checkable certificate (UNSAT proof, Farkas witness), not just "the solver said so."
  • Computer-assisted case analysis — a program enumerating cases in a proof. The program is part of the proof; its logic must be described and its output verifiable.

The bar: a referee (or a reader of the full version) must be able to re-run or independently check the computation. A number a solver produced with no reproducible input is not a proof step.

Keep it a proof paper, not an experiment paper

  • Supporting computation certifies a step; it does not replace the theorem. If the only evidence for the main claim is "it worked on our instances," the paper is experimental and belongs elsewhere.
  • Do not add a benchmark table to a theory paper to look more complete — ICALP referees read it as either irrelevant or as a signal the theorem is weak.
  • Running time measured is not running time proved. The contribution is the provable bound.

Reproducibility of the computational part

If computation backs a proof, treat it like the full version (see icalp-reproducibility):

  • Provide the code and inputs (or precise pseudocode) in the appendix / full version or a public repository referenced at camera-ready.
  • Provide certificates an independent checker can verify where the technique allows.
  • Pin versions (solver, seed if randomized search) so the check is deterministic.

Worked vignette: a dichotomy with a computer-checked base

A Track B paper proves a dichotomy over a family of constraint languages: tractable vs NP-hard. The inductive step is by hand; the base cases (finitely many small languages) are verified by an exhaustive program. To meet the bar: state the finite base set precisely, describe the enumeration, ship the code and its output in the full version, and — for the hardness base cases — include reductions a referee can check by hand rather than leaving them to the program alone. State clearly which cases are machine-verified and which are proved analytically.

Output format

[Claim shape] upper / approximation / lower (uncond) / lower (conditional) / decidability / dichotomy
[Argument fit] the proof strategy matches the claim? gaps: <where>
[Computation role] none / base-case check / solver-certified step / computer-assisted cases
[Checkability] certificate or reproducible input provided? independent check possible? yes/no
[Not-an-experiment guard] is the theorem the evidence (not benchmark performance)? yes/no
[Fix queue] <ordered: proof gaps, missing certificates, mis-routed empirical framing>

Signals

GitHub stars
1k
Forks
155
Last commit
Sep 2026
Advanced
Item type
skill
Key
icalp-experiments
Source
github.com/brycewang-stanford/awesome-journal-skills