uai-supplementary

UAI Supplementary

UAI's packaging model (2026 cycle, verified 2026-07-08) has three tiers with sharply

different review status. Getting content into the right tier is a strategic decision,

not a formatting chore. Reconfirm tier rules in the current submission instructions

before finalizing.

The three tiers

| Tier | 2026 constraint | Review status | Belongs here |

|---|---|---|---|

| Main part | ≤ 8 pages, UAI template | Read by everyone, judged on all four criteria | Claims, assumptions, method, key evidence, limitations |

| Appendix | Unlimited, same PDF, after references | Part of the reviewed submission; consulted when reviewers verify | Full proofs, protocols, extra experiments, derivations |

| Supplementary ZIP | ≤ 50 MB, separate upload | Explicitly optional for reviewers | Code, data, generators, logs, checkpoints |

Two structural consequences follow. First, because the appendix travels inside the

reviewed PDF, UAI has no "the reviewers never saw my proofs" excuse — but also no mercy

for identity leaks buried on appendix page 30. Second, because the ZIP is officially

optional reading, nothing decision-critical may live only there.

Placement heuristics

• A result whose absence would change the accept/reject argument goes in the main part,

even as a two-line proof sketch pointing to the appendix.

• A step a skeptical reviewer must verify to trust a theorem goes in the appendix — in

full, with the theorem restated so the appendix reads without page-flipping.

• Anything executable goes in the ZIP, plus a pointer sentence in the paper so its

existence is on the reviewed record.

• Never cite the ZIP as evidence for a claim ("see supplementary code for the full

results"): reviewers are entitled to ignore it, so the claim becomes unbacked.

Appendix architecture that works here

Statisticians and probabilistic-ML researchers navigate by statement numbers. Structure

for that reading style:

• One appendix section per theorem or per experiment family, in main-text order.
• Restate every assumption with its original label (A1, A2…) before using it; an

appendix proof invoking an unlabeled assumption is where correctness objections start.

• Give experimental appendices the same table discipline as the body: full

hyperparameter grids, per-dataset results, per-seed dispersion.

• Cross-reference forward from the body precisely ("proof in App. B.2", not "proofs in

the appendix").

% Single-PDF assembly, UAI style: appendix follows references in the same document
\bibliography{refs}          % references end the main part
\clearpage
\appendix
\section{Proofs for Section 3}\label{app:proofs}
\paragraph{Assumption A2 (restated).} The mixing weights are bounded away from zero.
\begin{proof}[Proof of Theorem 3]
  ... % full argument; the body kept only the sketch
\end{proof}
\section{Experimental Protocols}\label{app:protocols}
% grids, seeds, per-dataset tables, compute

ZIP assembly under the 50 MB cap

• Ship generators and configs rather than bulky outputs; include checksums for anything

regenerable.

• Structure by claim, not by code module: a reviewer looks for figure2/, not for

src/utils/.

• Keep the archive as anonymous as the PDF: no .git history, no notebook author

metadata, no cluster paths, no account-bound experiment-tracker URLs.

• Test the unzip-and-run path on a clean machine; a broken optional artifact is worse

than no artifact, because it documents carelessness.

Pre-merge integrity checklist

Run after the last content edit, before assembling the final PDF:

• [ ] Every theorem/lemma/proposition statement in the body is character-identical to

its restatement in the appendix (diff them mechanically, not by eye).

• [ ] Every assumption label used in an appendix proof is defined in the body.
• [ ] Every "App. X.Y" reference in the body resolves to an existing section after

the latest appendix reshuffle.

• [ ] Appendix figures and tables are numbered in a scheme that cannot collide with

the body's (e.g., Table 7 vs Table A.3 — pick one convention).

• [ ] No appendix section silently introduces a claim absent from the body; reviewers

may treat body-less claims as unreviewable.

• [ ] The references section sits between main part and appendix per the current

template's convention.

• [ ] Page count of the main part re-verified after the merge; late appendix

edits sometimes push floats forward into page 8.

• [ ] The ZIP's README points into the appendix ("protocol details in App. C") and

not vice versa for anything decision-critical.

Budgeting the 50 MB

A workable allocation when the archive is tight: code and configs are effectively

free (rarely over 5 MB); reserve the bulk for whichever single item most de-risks

your weakest claim — a gold-standard posterior sample set, a preprocessed data

extract with checksums, or trained-model files for the headline table. Everything

else ships as a generator script plus a hash of its output. If two heavyweight items

compete, keep the one a reviewer cannot regenerate in minutes.

Failure patterns seen at single-PDF venues

• Overflow laundering: pushing the method description itself into the appendix to make

the 8-page cap. Reviewers score clarity on the main part; an unintelligible body with

a beautiful appendix fails.

• Appendix drift: editing a theorem in the body during deadline week without touching

its appendix proof. Diff statement text mechanically before upload.

• Reference squeeze: trimming citations to save space, forgetting references are outside

the 8-page cap and cost nothing.

• ZIP-only ablations: the reviewer asks "why no ablation?" and the answer "it was in the

ZIP" wins no points, because the rules told them they could skip it.

Output format

[Tier map] main <pages> / appendix <pages> / ZIP <MB>
[Misplaced content] <items in the wrong tier, with target tier>
[Appendix integrity] statements match body? assumptions labeled?
[ZIP status] runs clean? anonymous? claim-indexed?
[Pointer sentences] <paper locations announcing appendix and ZIP contents>