Foundation Ledger Comparison To Composition Has Multiplicative Consistency Iff C

The cost-determined condition

A comparison cost is a function that assigns a number to the ratio between two observable states. The declaration hasMultiplicativeConsistency_iff_costDetermined establishes an equivalence: such a cost admits a binary combiner P with F(x·y) + F(x/y) = P(F x, F y) if and only if its symmetric combination is cost-determined, meaning the value F(x·y) + F(x/y) depends only on the pair of single-point costs (F x, F y), not on the specific ratios x and y that produced them. In plain terms, the combiner exists exactly when the symmetric combination is a function of the costs alone.

This matters because the existence of the combiner was previously assumed, not derived. The framework's library now proves that the combiner is not an arbitrary analytic input; it exists precisely under a well-definedness condition that the ledger already supplies. The reverse direction constructs P by choosing, for each cost pair in the image, a witnessing ratio pair; cost-determinedness makes that choice irrelevant. The theorem is non-vacuous: the framework's own cost function J satisfies the condition, since J composes through a specific combiner.

The declaration does not claim that every cost function is cost-determined, nor that the combiner P is unique. It also does not claim that the cost function J is forced by this equivalence alone; the full forcing result requires additional hypotheses, including reciprocal symmetry, normalization, calibration, continuity, and a ledger-posting combiner with directional regularity. The equivalence is a structural condition, not a derivation of J by itself.

/-- **Factorization existence ⇔ cost-determined combination.**  A comparison cost
admits a binary combiner `P` with `F(x·y) + F(x/y) = P(F x, F y)` (the d'Alembert
`HasMultiplicativeConsistency` factorization input) **iff** its symmetric
combination is cost-determined.  So the combiner is not an arbitrary analytic
assumption: it exists exactly when the combination is a function of the costs
alone.  The reverse direction builds `P` by choosing, for each cost pair in the
image, a witnessing ratio pair; cost-determinedness makes the choice irrelevant. -/
theorem hasMultiplicativeConsistency_iff_costDetermined (F : ℝ → ℝ) :
    DAlembert.Ultimate.HasMultiplicativeConsistency F ↔ CombinationCostDetermined F := by
  constructor
  · rintro ⟨P, hP⟩ x₁ y₁ x₂ y₂ hx₁ hy₁ hx₂ hy₂ hFx hFy
    rw [hP x₁ y₁ hx₁ hy₁, hP x₂ y₂ hx₂ hy₂, hFx, hFy]
  · intro hdet
    classical
    refine ⟨fun u v =>
      if h : ∃ p : ℝ × ℝ, 0 < p.1 ∧ 0 < p.2 ∧ F p.1 = u ∧ F p.2 = v
      then F (h.choose.1 * h.choose.2) + F (h.choose.1 / h.choose.2)
      else 0, ?_⟩
    intro x y hx hy
    have hex : ∃ p : ℝ × ℝ, 0 < p.1 ∧ 0 < p.2 ∧ F p.1 = F x ∧ F p.2 = F y :=
      ⟨(x, y), hx, hy, rfl, rfl⟩
    show F (x * y) + F (x / y) =
      (if h : ∃ p : ℝ × ℝ, 0 < p.1 ∧ 0 < p.2 ∧ F p.1 = F x ∧ F p.2 = F y
        then F (h.choose.1 * h.choose.2) + F (h.choose.1 / h.choose.2)
        else 0)
    rw [dif_pos hex]
    obtain ⟨hp1, hp2, hpx, hpy⟩ := hex.choose_spec
    exact (hdet hex.choose.1 hex.choose.2 x y hp1 hp2 hx hy hpx hpy).symm

/-- **`J`'s combination is cost-determined.**  Since `J` composes through
`rclCombiner`, its symmetric combination is a function of the single-point costs,
so the factorization-existence condition is non-vacuous. -/
theorem jcost_combinationCostDetermined :
    CombinationCostDetermined Cost.Jcost :=
  (hasMultiplicativeConsistency_iff_costDetermined Cost.Jcost).mp
    ⟨rclCombiner, jcost_composesThrough_rclCombiner⟩

What this page does not claim

The equivalence alone forces the cost function J. Every cost function is cost-determined. The combiner P is unique when it exists.

Verify this page

Every tagged claim above names its theorem. To check one yourself rather than trust this page, elaborate the source module with Lean 4 and audit its axiom basis:

$ lake env lean IndisputableMonolith/Foundation/LedgerComparisonToComposition.lean
expected axiom basis: [propext, Classical.choice, Quot.sound] (the Lean kernel's standard three; no RS-specific axioms)

A page whose claims cannot be reproduced this way does not ship. In production, every anchor links to the exact declaration in the public source release, and this block carries the build receipt for the page itself.

Derived articles

This page is generated by a question-recursion engine: the questions its answers raise become the next pages. The current agenda, with open targets marked red: