Encyclopedia Foundation Foundation Pair Kernel Owner Channel Occurrence Bridge Constant Occurrence Contr
ARTICLE 4 claims 4 theorems
Foundation Pair Kernel Owner Channel Occurrence Bridge Constant Occurrence Contr
A single account cannot be both a debit and a credit at once, and the framework proves this as a theorem about its own ledger.
Why occurrences cannot collapse
The ledger, a discrete record of events, treats every posting as an occurrence with a side: debit or credit. The declaration constant_occurrence_contradicts_injectivity is a theorem in the framework's machine-checked library of formal theorems. It states that no single oriented-pole record can be the result for every possible posting. In plainer terms, the framework proves that two different postings, a debit and a credit on the same account, cannot both collapse into the same record.
The proof works by taking any fixed record r₀ and assuming every posting maps to it. It then picks one account and looks at its debit and credit sides. The theorem swapped_poles_rejected shows these two sides must produce different oriented poles, because the debit pole and credit pole are distinct. Since the constant assumption forces them to be equal, the assumption fails. This is a direct consequence of the injectivity property: distinct postings map to distinct oriented pole data.
This result is not about physics directly. It is a structural fact about the framework's own representation. It guarantees that the bridge from owner-indexed horizon data to oriented pair-kernel postings does not lose information by merging distinct occurrences. The theorem rules out a degenerate case where the ledger's record of events becomes a single undifferentiated blob.
What the theorem does not claim is equally important. It does not say that all occurrences are distinguishable by their boundary records alone. In fact, the companion theorem heat_flux_scalar_join_not_occurrence_identity shows that for at least two accounts, two distinct debit occurrences can share the same scalar boundary record. Identity is carried by the oriented poles, not by the scalar flux value. The constant-collapse theorem only rules out the extreme case where every posting yields the same oriented-pole record.
The consequence is that the framework's occurrence bridge is faithful at the level of its own data. A reader can trust that a legal tick, a single posting event, corresponds to a unique oriented-pole record. This is a necessary precondition for any later physical interpretation of the ledger, because a representation that collapsed distinct events would have no way to tell one transaction from another.
THEOREM constant_occurrence_contradicts_injectivity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (ii) Constant occurrence assignment contradicts injectivity. -/
theorem constant_occurrence_contradicts_injectivity {d : Nat} [NeZero d]
(r₀ : OrientedPostingBoundaryRecord (2 * d)) :
¬ (∀ (k : Fin d) (side : Side), orientedPolesOfOwner k side = r₀) := by
intro hconst
-- Two sides of the same account cannot both equal r₀.
let k : Fin d := ⟨0, Nat.pos_of_ne_zero (NeZero.ne d)⟩
have hde := hconst k Side.debit
have hcr := hconst k Side.credit
exact (swapped_poles_rejected k).1 (hde.trans hcr.symm)
THEOREM swapped_poles_rejected · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (i) Bridge rejects swapped-pole identification: forward ≠ reversed. -/
theorem swapped_poles_rejected {d : Nat} [NeZero d] (k : Fin d) :
orientedPolesOfOwner k Side.debit ≠
orientedPolesOfOwner k Side.credit ∧
occurrenceBoundaryRecord k Side.debit ≠
occurrenceBoundaryRecord k Side.credit := by
refine ⟨?_, ?_⟩
· intro h
have hs :=
(orientedPostingBoundaryRecord_eq_iff_same_poles _ _).1 h
exact debitPole_ne_creditPole k hs.1
· rw [occurrenceBoundaryRecord_debit, occurrenceBoundaryRecord_credit]
norm_num
THEOREM orientedPolesOfOwner_injective · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (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
/-- (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
That all occurrences are distinguishable by their scalar boundary records. That the theorem applies to any physical system outside the framework's own ledger representation. That the occurrence bridge is complete without the open normalization target.
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:
- What physical interpretation does the oriented-pole record carry in the framework?
- How does the injectivity of oriented poles relate to the uniqueness of ledger postings?
- What is the role of the source covector normalization in the occurrence bridge?
MACHINE LAYER · GROUNDED CLAIM TABLE · CLICK TO EXPAND
THEOREM constant_occurrence_contradicts_injectivity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (ii) Constant occurrence assignment contradicts injectivity. -/ theorem constant_occurrence_contradicts_injectivity {d : Nat} [NeZero d] (r₀ : OrientedPostingBoundaryRecord (2 * d)) : ¬ (∀ (k : Fin d) (side : Side), orientedPolesOfOwner k side = r₀) := by intro hconst -- Two sides of the same account cannot both equal r₀. let k : Fin d := ⟨0, Nat.pos_of_ne_zero (NeZero.ne d)⟩ have hde := hconst k Side.debit have hcr := hconst k Side.credit exact (swapped_poles_rejected k).1 (hde.trans hcr.symm)No single oriented-pole record can be the result for every possible posting. constant_occurrence_contradicts_injectivity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.leanTHEOREM swapped_poles_rejected · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (i) Bridge rejects swapped-pole identification: forward ≠ reversed. -/ theorem swapped_poles_rejected {d : Nat} [NeZero d] (k : Fin d) : orientedPolesOfOwner k Side.debit ≠ orientedPolesOfOwner k Side.credit ∧ occurrenceBoundaryRecord k Side.debit ≠ occurrenceBoundaryRecord k Side.credit := by refine ⟨?_, ?_⟩ · intro h have hs := (orientedPostingBoundaryRecord_eq_iff_same_poles _ _).1 h exact debitPole_ne_creditPole k hs.1 · rw [occurrenceBoundaryRecord_debit, occurrenceBoundaryRecord_credit] norm_numThe theorem <code>swapped_poles_rejected</code> shows these two sides must produce different oriented poles, because the debit pole and credit pole are distinct. swapped_poles_rejected · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.leanTHEOREM orientedPolesOfOwner_injective · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (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 => rflDistinct postings map to distinct oriented pole data. orientedPolesOfOwner_injective · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.leanTHEOREM heat_flux_scalar_join_not_occurrence_identity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean
/-- (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)For at least two accounts, two distinct debit occurrences can share the same scalar boundary record. heat_flux_scalar_join_not_occurrence_identity · IndisputableMonolith/Foundation/PairKernelOwnerChannelOccurrenceBridge.lean