Encyclopedia Foundation Foundation Pair Kernel Owner Channel Occurrence Bridge Heat Flux Scalar Join Not

ARTICLE 3 claims 3 theorems

Foundation Pair Kernel Owner Channel Occurrence Bridge Heat Flux Scalar Join Not

In the framework's ledger, two different events can carry the same numerical boundary value, so a scalar alone never identifies which event happened.

Verify this page

Scalar equality does not identify an occurrence

The declaration heat_flux_scalar_join_not_occurrence_identity proves a negative result about how occurrences are identified in the Recognition Science ledger, a discrete record of events where each event is a posting between two accounts. The theorem states that for any ledger with at least two accounts, there exist two distinct debit postings on different accounts whose boundary records, the scalar values attached to each posting, are equal. At the same time, the oriented pole data, the full structural description of which accounts are involved and in which direction, are different for those two postings.

This means that the scalar boundary record alone cannot serve as a unique identifier for an occurrence. Two different events can produce the same numerical value, so if you only knew that value, you could not tell which event had occurred. The theorem establishes that occurrence identity is carried by the oriented poles and by profile recovery, the process of reconstructing the posting from the before and after ledger states, not by the scalar boundary record.

The theorem is a formal result in the machine-checked library of formal theorems. It is proved for any dimension d with at least two accounts, and it does not rely on any additional physical assumptions. In particular, it does not use the equality of unit heat with unit Gauss flux as a join, nor does it assume the normalization of the source scale, which remains an open target. The result is a structural fact about the ledger's own bookkeeping, not a statement about any specific physical system.

What the theorem does not claim is that scalar boundary records are useless. They are still meaningful as signed magnitudes, with debits giving +1 and credits giving -1. The theorem only shows that the scalar value is not a unique key. It also does not claim that occurrences cannot be identified at all; it shows they are identified by the oriented poles, which are injective, meaning distinct postings always give distinct pole data.

THEOREM heat_flux_scalar_join_not_occurrence_identity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
heat_flux_scalar_join_not_occurrence_identity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean:445 
/-- (iii) Heat=flux scalar join is absent from the occurrence identity.
Equal unit boundary fluxes do not identify oriented poles (inherited
scalar-coincidence decoy); the bridge uses poles, not heat. -/
theorem heat_flux_scalar_join_not_occurrence_identity {d : Nat}
    (hd : 2 ≤ d) :
    ∃ k₁ k₂ : Fin d,
      occurrenceBoundaryRecord k₁ Side.debit =
          occurrenceBoundaryRecord k₂ Side.debit ∧
        orientedPolesOfOwner k₁ Side.debit ≠
          orientedPolesOfOwner k₂ Side.debit := by
  have hpos : 0 < d := lt_of_lt_of_le (by decide : (0 : Nat) < 2) hd
  have h1 : 1 < d := lt_of_lt_of_le (by decide : (1 : Nat) < 2) hd
  let k₁ : Fin d := ⟨0, hpos⟩
  let k₂ : Fin d := ⟨1, h1⟩
  refine ⟨k₁, k₂, ?_, ?_⟩
  · rw [occurrenceBoundaryRecord_debit, occurrenceBoundaryRecord_debit]
  · intro h
    have hs :=
      (orientedPostingBoundaryRecord_eq_iff_same_poles _ _).1 h
    have hk := debitPole_injective hs.1
    exact (by decide : (0 : Nat) ≠ 1) (congrArg Fin.val hk)
THEOREM orientedPolesOfOwner_injective · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
orientedPolesOfOwner_injective · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean:135 
/-- (a) Injectivity: distinct owner addresses give distinct oriented poles. -/
theorem orientedPolesOfOwner_injective {d : Nat} :
    Function.Injective (fun p : Fin d × Side => orientedPolesOfOwner p.1 p.2) := by
  intro ⟨k₁, s₁⟩ ⟨k₂, s₂⟩ h
  apply Prod.ext
  · -- accounts equal
    cases s₁ with
    | debit =>
      cases s₂ with
      | debit =>
        have hs :=
          (orientedPostingBoundaryRecord_eq_iff_same_poles
            (orientedPolesOfOwner k₁ Side.debit)
            (orientedPolesOfOwner k₂ Side.debit)).1 h
        exact debitPole_injective hs.1
      | credit =>
        have hs :=
          (orientedPostingBoundaryRecord_eq_iff_same_poles
            (orientedPolesOfOwner k₁ Side.debit)
            (orientedPolesOfOwner k₂ Side.credit)).1 h
        exact False.elim (debitPole_ne_creditPole_of k₁ k₂ hs.1)
    | credit =>
      cases s₂ with
      | debit =>
        have hs :=
          (orientedPostingBoundaryRecord_eq_iff_same_poles
            (orientedPolesOfOwner k₁ Side.credit)
            (orientedPolesOfOwner k₂ Side.debit)).1 h
        exact False.elim (debitPole_ne_creditPole_of k₂ k₁ hs.1.symm)
      | credit =>
        have hs :=
          (orientedPostingBoundaryRecord_eq_iff_same_poles
            (orientedPolesOfOwner k₁ Side.credit)
            (orientedPolesOfOwner k₂ Side.credit)).1 h
        exact creditPole_injective hs.1
  · -- sides equal
    cases s₁ with
    | debit =>
      cases s₂ with
      | debit => rfl
      | credit =>
        have hs :=
          (orientedPostingBoundaryRecord_eq_iff_same_poles
            (orientedPolesOfOwner k₁ Side.debit)
            (orientedPolesOfOwner k₂ Side.credit)).1 h
        exact False.elim (debitPole_ne_creditPole_of k₁ k₂ hs.1)
    | credit =>
      cases s₂ with
      | debit =>
        have hs :=
          (orientedPostingBoundaryRecord_eq_iff_same_poles
            (orientedPolesOfOwner k₁ Side.credit)
            (orientedPolesOfOwner k₂ Side.debit)).1 h
        exact False.elim (debitPole_ne_creditPole_of k₂ k₁ hs.1.symm)
      | credit => rfl
THEOREM heat_flux_scalar_join_not_occurrence_identity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
heat_flux_scalar_join_not_occurrence_identity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean:445 
/-- (iii) Heat=flux scalar join is absent from the occurrence identity.
Equal unit boundary fluxes do not identify oriented poles (inherited
scalar-coincidence decoy); the bridge uses poles, not heat. -/
theorem heat_flux_scalar_join_not_occurrence_identity {d : Nat}
    (hd : 2 ≤ d) :
    ∃ k₁ k₂ : Fin d,
      occurrenceBoundaryRecord k₁ Side.debit =
          occurrenceBoundaryRecord k₂ Side.debit ∧
        orientedPolesOfOwner k₁ Side.debit ≠
          orientedPolesOfOwner k₂ Side.debit := by
  have hpos : 0 < d := lt_of_lt_of_le (by decide : (0 : Nat) < 2) hd
  have h1 : 1 < d := lt_of_lt_of_le (by decide : (1 : Nat) < 2) hd
  let k₁ : Fin d := ⟨0, hpos⟩
  let k₂ : Fin d := ⟨1, h1⟩
  refine ⟨k₁, k₂, ?_, ?_⟩
  · rw [occurrenceBoundaryRecord_debit, occurrenceBoundaryRecord_debit]
  · intro h
    have hs :=
      (orientedPostingBoundaryRecord_eq_iff_same_poles _ _).1 h
    have hk := debitPole_injective hs.1
    exact (by decide : (0 : Nat) ≠ 1) (congrArg Fin.val hk)

What this page does not claim

The scalar boundary record is meaningless or carries no information. Occurrences cannot be identified at all in the ledger. The source scale normalization is proved or assumed.

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/PairKernelOwnerChannelOccurrenceBridge.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:

MACHINE LAYER · GROUNDED CLAIM TABLE · CLICK TO EXPAND