Encyclopedia Foundation Foundation Pair Kernel Tick Locality Max Separated Schedule Is Valid Atomic Tick

ARTICLE 4 claims 4 theorems

Foundation Pair Kernel Tick Locality Max Separated Schedule Is Valid Atomic Tick

A theorem about a schedule that jumps between opposite ends of an account list shows why one-per-tick posting cannot explain spatial locality.

The scrambling schedule

An atomic tick, a single discrete posting event in a recognition ledger, has one defining rule: exactly one site posts at each tick. The question is whether that rule, by itself, forces nearby sites to interact more strongly than distant ones. The theorem maxSeparatedSchedule_isValidAtomicTick answers no, and it does so with a deliberately extreme example.

Consider a ledger with n accounts arranged in a line, labeled 0 through n−1. The theorem constructs a posting schedule that sends site 0 at the first tick, then site n−1 at every later tick. Consecutive posts are therefore as far apart as the index metric allows: the distance between the first two posts is n−1, the maximum possible. The theorem proves that this scrambling schedule is a perfectly valid atomic tick, because it still posts exactly one site per tick. Tick-adjacency, the fact that two posts happen one after the other, carries no information about index-adjacency, how close the sites are in the line.

The point is structural, not pathological. The atomic tick rule constrains only the timing of posts, not which sites are coupled. A separate theorem makes the same point with an all-to-all graph where every site interacts with every other, which also coexists with a valid atomic tick. Together these results close a proposed route: one cannot derive a finite interaction range, a cutoff beyond which sites do not couple, from the one-post-per-tick schedule alone.

In Recognition Science, the framework's machine-checked library of formal theorems uses this result to mark a boundary. The temporal primitive, the atomic tick, does not adjudicate the spatial coupling range. Locality, if it holds, must come from the recognition relation itself, the structure that says which sites are neighbors, not from the schedule. The framework's own mean-field model sets that relation to all-to-all by definition, while a band-weight model realizes a finite range of one. The theorem does not say locality is false; it says the tick schedule is the wrong place to look for its origin.

THEOREM maxSeparatedSchedule · IndisputableMonolith/Foundation/PairKernelTickLocality.lean
/-- A schedule posting site `0` at tick `0` and site `n − 1` thereafter: consecutive posts are
    index-maximally separated. -/
def maxSeparatedSchedule (n : ℕ) (hn : 2 ≤ n) : ℕ → Fin n :=
  fun t => if t = 0 then ⟨0, by omega⟩ else ⟨n - 1, by omega⟩
THEOREM maxSeparatedSchedule_consecutive_maximally_separated · IndisputableMonolith/Foundation/PairKernelTickLocality.lean
maxSeparatedSchedule_consecutive_maximally_separated · IndisputableMonolith/Foundation/PairKernelTickLocality.lean:153
/-- The first two (tick-adjacent) posts of `maxSeparatedSchedule` are index-maximally separated:
    `cellDist (s 0) (s 1) = n − 1`. Tick-adjacency is not index-adjacency. -/
theorem maxSeparatedSchedule_consecutive_maximally_separated (n : ℕ) (hn : 2 ≤ n) :
    cellDist (maxSeparatedSchedule n hn 0) (maxSeparatedSchedule n hn 1) = n - 1 := by
  have h0 := maxSeparatedSchedule_val_zero n hn
  have h1 := maxSeparatedSchedule_val_one n hn
  unfold cellDist Nat.dist
  rw [h0, h1]
  omega
THEOREM maxSeparatedSchedule_isValidAtomicTick · IndisputableMonolith/Foundation/PairKernelTickLocality.lean
maxSeparatedSchedule_isValidAtomicTick · IndisputableMonolith/Foundation/PairKernelTickLocality.lean:163
/-- The scrambling schedule is itself a valid `AtomicTick`, so the maximal separation above is
    realized by a genuine atomic-tick posting order — no schedule regularity is entailed. -/
theorem maxSeparatedSchedule_isValidAtomicTick (n : ℕ) (hn : 2 ≤ n) :
    Nonempty (AtomicTick (tickCarrier n)) :=
  ⟨scheduleAtomicTick (maxSeparatedSchedule n hn)⟩
THEOREM atomicTick_does_not_force_finiteRange · IndisputableMonolith/Foundation/PairKernelTickLocality.lean
atomicTick_does_not_force_finiteRange · IndisputableMonolith/Foundation/PairKernelTickLocality.lean:126
/-- **Null test / decoy.** For every radius `R`, a carrier of size `R + 2` carries a valid
    `AtomicTick` instance while its all-to-all mean-field weight graph fails `FiniteRange R`.
    Atomic-tick validity does not make the weight graph finite-range. -/
theorem atomicTick_does_not_force_finiteRange (R : ℕ) :
    ∃ n : ℕ, Nonempty (AtomicTick (tickCarrier n)) ∧ ¬ FiniteRange (meanFieldWeight n) R := by
  refine ⟨R + 2, ⟨scheduleAtomicTick (fun _ => ⟨0, by omega⟩)⟩, ?_⟩
  exact meanFieldWeight_not_finiteRange R (R + 2) (le_refl _)

What this page does not claim

The theorem does not claim that finite interaction ranges are impossible; it only says the atomic tick schedule does not force them. The theorem does not claim that the all-to-all mean-field graph is the only counterexample, nor that it is physically preferred. The theorem does not derive any specific coupling strength or range from the recognition primitives.

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/PairKernelTickLocality.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