brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
podc-experimentsUse when building the evidence for an ACM PODC paper — where "evidence" is a proof, not a benchmark. Covers matching upper and lower bounds, tightness arguments, model and assumption stress-tests, adversary-strength calibration, and the honest, clearly-optional role of any simulation in a distributed-computing-theory paper.
Independent GitHub snapshot · Automated classification · Original documentation governs
At PODC the "experiment" is a proof, and the strongest result is a matching bound. This skill is the theory analogue of an empirical-evaluation section: it is about making the evidence for correctness and optimality as strong as the venue expects. There is no benchmark leaderboard, no artifact track, and a simulation never establishes the result — it can only illustrate it.
| Claim | What counts as evidence at PODC | Common failure caught |
|---|---|---|
| "Algorithm A solves problem P in model M" | A proof of the required properties (e.g., agreement, validity, termination) in exactly M | Property proved in a stronger model than claimed |
| "A costs O(f(n))" | A proof of the upper bound over all executions/adversary choices | Bound holds only in the best case, not worst/expected as stated |
| "A is optimal" | A matching Ω(f(n)) lower bound in the same model | "Optimal" asserted with no lower bound |
| "P is impossible in M" | An impossibility proof (valency, indistinguishability, covering) | Impossibility shown for a weaker model than claimed |
| "A self-stabilizes" | A proof of convergence from every state + closure | Convergence shown from some states only |
A PODC upper bound is good; an upper bound plus a matching lower bound is the venue's gold standard, because together they close the problem. Before submission, ask:
The most common fatal flaw at PODC is a proof that quietly relies on an assumption stronger than the stated model. Audit every assumption:
[Timing] does any step assume a message arrives "soon" in an asynchronous model? (illegal)
[Faults] does the proof assume a Byzantine party behaves in a bounded way? (only if justified)
[Adversary] is the adversary adaptive as claimed, or does the analysis secretly need oblivious?
[Atomicity] in shared memory, are the assumed primitives (CAS, LL/SC, registers) really available?
[Randomness] does correctness need a shared coin the model does not provide?
[Initialization] for self-stabilization, does convergence hold from *every* configuration?
For each, either the proof survives the weakest form of the assumption in your model box, or the theorem statement must be weakened to name the stronger assumption. This audit is the theory equivalent of a threats-to-validity section, and reviewers perform it whether or not you do.
If your paper includes a simulation (many PODC papers include none), it must be framed as optional:
podc-topic-selection).podc-reproducibility and podc-submission).[ ] Every claimed property is proved in exactly the stated model (no assumption creep)
[ ] Upper bounds hold in the stated case (worst/expected), not just best case
[ ] Optimality claims carry a matching lower bound (or are downgraded to "we conjecture / leave open")
[ ] Resilience threshold stated and, if claimed optimal, backed by an impossibility
[ ] Adversary strength and randomness assumptions match the proof's real needs
[ ] Any simulation is labeled optional, with ranges/trials/seeds, and establishes nothing
[Claim -> evidence] each theorem mapped to its proof; property proved in the stated model?
[Tightness] matching lower bound present / cited / proved / honestly left open?
[Assumption audit] timing/faults/adversary/atomicity/randomness/initialization all consistent with the model box?
[Adversary/regime] strength and parameter range stated correctly?
[Simulation] absent / present-and-labeled-optional (ranges, trials, seeds)?
[Fix queue] <assumption creep to fix; missing lower bound; overclaimed optimality>