Foundation Ledger Comparison To Composition Ledger Comparison Forces Jcost

The ledger's forced cost

A comparison between two observable states is just a ratio of their measured values. If one state has value 3 and another has value 6, the comparison is 2; swap the states and the comparison becomes 1/2. This ratio is always a positive number, and comparing a state with itself always gives 1. These are not assumptions. They are read directly off the ledger, a discrete record of observable values, in the framework's account.

The framework then asks what a cost function on these ratios must look like. A cost is a number assigned to a comparison, and the framework demands it obey five plain conditions: it must assign the same cost to a ratio and its reciprocal, it must cost zero for a self-comparison, it must be calibrated, it must be continuous, and it must compose through a simple combining rule. The combining rule is the subtle part. It says the cost of a product ratio plus the cost of a quotient ratio depends only on the two individual costs, not on the particular ratios that produced them. This is a well-definedness condition, not a free choice. The framework proves this condition is exactly equivalent to the existence of a binary combiner, a function that takes two costs and returns the combined cost. The combiner is not an arbitrary analytic input; it exists precisely when the combination is a function of the costs alone.

The central result, a theorem in the framework's machine-checked library of formal theorems, is that any comparison cost satisfying these conditions must equal J(x) = (x + 1/x)/2 - 1. The proof proceeds by showing the ledger supplies the combiner, which forces the composition law, which then forces J. The factorization combiner is not assumed; it is derived from the ledger-posting semantics. This closes a gap in earlier work, where the existence of the combiner was taken as a hypothesis. Now it is a consequence of the ledger structure itself.

What this does not claim is important. It does not claim that any cost function on ratios must be J; the conditions are real restrictions. A cost that is not reciprocal, or not continuous, or whose combination is not cost-determined, can be something else. The theorem also does not claim that the ledger itself is the only way to arrive at J; it shows that within this ledger-based framework, the conditions force the formula. The comparison object is a positive ratio, but the theorem does not say all comparisons in all possible frameworks must be ratios. It says that when they are, and when the five conditions hold, the cost is fixed.

/-- **The comparison object is a positive ratio.**  Read off the framework's
strictly positive observable `r`: the domain of the recognition cost is the
positive ray, derived rather than assumed. -/
theorem compRatio_pos (F : ClosedObservableFramework) (s₁ s₂ : F.S) :
    0 < compRatio F s₁ s₂ :=
  div_pos (F.r_pos s₁) (F.r_pos s₂)

/-- **State swap inverts the comparison ratio.**  Swapping the two states sends the
ratio to its reciprocal, the geometric origin of reciprocal symmetry. -/
theorem compRatio_swap (F : ClosedObservableFramework) (s₁ s₂ : F.S) :
    compRatio F s₂ s₁ = (compRatio F s₁ s₂)⁻¹ := by
  unfold compRatio
  rw [inv_div]

/-- **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

/-- **Phase 3 composite.**  A comparison cost that is reciprocal, normalized,
calibrated, and continuous, whose symmetric combination is realized through a
primitive ledger-posting combiner with per-slice directional regularity, is forced
to be `J`.  The factorization combiner is supplied through the ledger (so it is
forced to `rclCombiner`), the composition law follows, and
`law_of_logic_forces_jcost` finishes, with no analytic composition-law hypothesis
assumed. -/
theorem ledgerComparison_forces_jcost
    (F : ℝ → ℝ) (P : ℝ → ℝ → ℝ)
    (hRecip : IsReciprocalCost F) (hNorm : IsNormalized F)
    (hCalib : IsCalibrated F) (hCont : ContinuousOn F (Set.Ioi 0))
    (hP : LedgerToFactorization.PrimitiveLedgerPostingSemantics P)
    (hdir : ∀ u, Monotone (fun v => P u v) ∨ Antitone (fun v => P u v))
    (hCompose : CostComposesThrough F P) :
    ∀ x : ℝ, 0 < x → F x = Cost.Jcost x :=
  ledgerComposition_forces_jcost F P hRecip hNorm hCalib hCont hP hdir hCompose

What this page does not claim

This does not claim that all cost functions on positive ratios must equal J; the five conditions are real restrictions. This does not claim that the ledger is the only possible origin of the cost function J.

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: