TauCeti multi-angle review: the full conflict inventory

Companion report to the ITP 2026 talk Three Roads to de Finetti’s Theorem in Lean. Survey of roughly 50 Exchangeability / de Finetti PRs in TauCeti, each reviewed independently from ten angles: api-design, attribution, correctness, documentation, generality, naming, placement, proof-quality, reuse, scope. Eleven PRs produced 14 genuine cross-rubric conflicts; 13 of 14 involved api-design. Compiled July 2026.

Conflict inventory

PRAnglesConflictMerged resolution
#755API vs namingroadmap condExp_tendsto_iInf vs Mathlib-shaped nameprimary tendsto_ae_condExp_iInf
#755API vs proof-qualityprivate helpers vs reusable cross-file factsgeneral helpers extracted in #687 / #772
#824API vs namingpublic deFinetti primary vs conclusion-shaped nameconditionallyIID_of_exchangeable primary; later facade alias in #891
#824API vs reuseprivate core vs duplicated integrationcolocate consumers; private shared core
#743API vs namingroadmap spelling vs conclusion-shaped theoremidiomatic primary + roadmap alias
#549API vs namingexport ..._eq/..._implies_... planning namesconclusion-first names
#526naming vs APIgeneric revFiltration name vs roadmap aliasfutureFiltration at merge; later deleted as dead API
#526API vs APIremove @[expose] vs keep characteristic lemmasbuild failure established that exposure must remain
#746reuse vs APIdelete duplicate permutation wrappers vs re-add public wrappersreuse Mathlib theorem; no wrappers
#734generality vs APIdrop unused Integrable f vs exclude unneeded caserefactor so the hypothesis becomes load-bearing
#596correctness vs generalityfinite-measure hypothesis prevents vacuous real identitysplit lintegral / integral / integrable lemmas
#612API vs APIrequire _def lemma vs remove @[expose]compiler evidence; keep exposure
#666API vs APIrequire permReindex_apply vs hide definitioncompiler evidence; keep exposure
#451API vs APIpublic unfold/simp surface vs remove all exposurekeep the API and @[expose]

Pattern 1: naming governs the primary slot

condExp_tendsto_iInf (planning handle) → tendsto_ae_condExp_iInf (Mathlib-shaped primary). deFinetti (eponymous roadmap handle) → conditionallyIID_of_exchangeable (conclusion-shaped primary). condExp_exists_ae_limit_antitone (roadmap spelling) → exists_integrable_tendsto_ae_condExp_of_antitone (primary + alias). Idiomatic primary names remain. A roadmap is a target list, not a naming authority, and an alias survives only while it stays semantically faithful: #1192 later retired the deFinetti* aliases rather than let them name a mixture-only statement.

Pattern 2: sharing constrains privacy, but does not automatically defeat it

The governing question is whether a helper eliminates real duplicated reasoning. Cross-file consumers: extract general public API (#687 / #772). Consumers can be colocated: private shared core in one file (#824). Duplicates Mathlib: delete the wrapper (#746). Review was about avoiding duplicated proof logic, not maximizing the number of public declarations.

Pattern 3: refactor to dissolve generality/correctness conflicts

#734, an “unused” integrability hypothesis: generality said drop it; api-design said do not expose an irrelevant non-integrable case. Resolution: restructure the proof so hf.neg is genuinely used, keeping an honest load-bearing hypothesis. #596, finite measure vs vacuity: generality said remove [IsFiniteMeasure μ]; correctness observed the naive real-valued identity becomes vacuous at infinite mass. Resolution: split into an unconditional lintegral lemma, a toReal integral identity, and an integrability theorem under finiteness.

Pattern 4: the compiler arbitrates @[expose] conflicts

One review round requires a characteristic theorem such as foo_def := rfl or foo_apply; a later round requests removal of @[expose] from the opaque definition. lake env lean then fails: the requested public theorem is no longer definitionally provable. When removing @[expose] breaks a required characteristic lemma, the compiler determines the answer. Observed in #451, #526, #612, and #666.

The conflict-resolution playbook

  1. Contest-and-link. Quote the opposing finding and show the contradiction explicitly.
  2. Let naming govern primary names. A roadmap is a target list, not a naming authority. Keep a handle as an alias only when it does not promise a stronger proposition.
  3. Share reasoning at the right visibility. Public cross-file API, private same-file core, or no wrapper if Mathlib already owns it.
  4. Refactor to satisfy both rubrics. Split statements, relocate consumers, or make a hypothesis genuinely load-bearing.
  5. Use the build as arbiter. A reproducible compiler failure beats an aesthetic assertion.