The function-space sum peels its first index into an ordinary range sum

Identifier: F:int-sum-maps-succ
Proof route: kernel-lean
External status: proved
Axiom footprint: Empty

Recorded description

`Int.sumMaps (m+1) n F = Int.sumRange (fun k => Int.sumMaps m n (fun g => F (cons k g))) n`, the recursive equation of the function-space-indexed sum, and the statement that FIXES the convention. Closes by `Eq.refl`. `cons k g` appears in the type as its raw `AxNat.rec` -- `k` at index 0 and `g j` at index `succ j` -- because it is deliberately not a declared definition: it occurs only inside `Int.sumMaps`'s own body and inside proofs about it, and naming it would put a name into the shared `Nat` namespace from the `Int` prelude, a hazard this repository has measured. That `cons` is a bare recursor is what makes BOTH its equations hold by iota-reduction alone, which in turn is why the induction in `Int.prodRange_sumRange_expand` needs no ordering lemma. WHAT NO EVALUATION CAN CHECK: peeling the LAST index instead of the FIRST computes the identical value at every argument, since the sum ranges over all maps either way; only this stated type distinguishes the two. `Kernel::axiom_footprint` is EMPTY.

Formal statement

theorem Int.sumMaps_succ : ((x0 : AxNat) -> ((x1 : AxNat) -> ((x2 : ((x2 : ((x2 : AxNat) -> AxNat)) -> Int)) -> Eq.{1} Int (Int.sumMaps (AxNat.succ x0) x1 x2) (Int.sumRange (fun (x3 : AxNat) => Int.sumMaps x0 x1 (fun (x4 : ((x4 : AxNat) -> AxNat)) => x2 (fun (x5 : AxNat) => AxNat.rec.{1} (fun (x6 : AxNat) => AxNat) x3 (fun (x6 : AxNat) => fun (x7 : AxNat) => x4 x6) x5))) x1))))

Dependencies

The graph shows direct ledger edges. Follow a node to open its artifact page.

0 direct dependencies 0 direct dependents

Evidence

kernel-Int.sumMaps_succ

Kind: kernel-term
Status: checked

Supports: Int.sumMaps_succ is admitted by the trusted kernel gate with the type recorded in formal.statement.

Checker command

cargo run -q --release -p axeyum-lean-kernel --example theorem_dependency_inventory -- Int.sumMaps_succ 2>/dev/null | grep -cE '^Int\.sumMaps_succ[[:space:]]'

Evidence notes

Two independent failure modes, so the exit status depends on the finding rather than on the run completing: theorem_dependency_inventory exits non-zero when a NAMED filter matches nothing, and grep -c exits 1 printing 0 when the anchored line is absent. Anchored with [[:space:]], never \t -- in a scripted (GNU) grep \t is a literal t. grep -c rather than grep -q, which would SIGPIPE the producer under pipefail. --release is MANDATORY: this tool builds creal/complex/cpoint, which overflow the default debug thread stack. Pass ONE name per invocation: this tool silently keeps only the FIRST name argument.

footprint-Int.sumMaps_succ

Kind: exhaustive-enumeration
Status: checked

Supports: axiom_footprint: [] -- the integer prelude's trusted surface is empty, which bounds Int.sumMaps_succ.

Checker command

cargo run -q --release -p axeyum-lean-kernel --example nat_axiom_inventory -- --require-axiom-free integer

Evidence notes

--require-axiom-free exits non-zero when the named prelude's trusted surface (Axiom + Opaque + Quotient) is not empty, and errors rather than silently passing for a prelude the run never built. A declaration cannot depend on a trusted declaration the environment does not contain, so an empty integer surface bounds every declaration in it. This is a whole-prelude bound, not a per-declaration measurement; the per-declaration figure is the footprint column of kernel_declaration_projection, measured 0 for this row.

Provenance

{
  "date": "2026-08-31",
  "curation": "curated",
  "established_by": "axeyum-lean-kernel build_int_prelude (crates/axeyum-lean-kernel/src/int_prelude/sum_maps.rs)",
  "source": "formal.statement and axiom_footprint are taken verbatim from `cargo run -q --release -p axeyum-lean-kernel --example kernel_declaration_projection`, whose TSV rows are (prelude, kind, display name, axiom-footprint size, direct type declarations, direct declarations, direct theorems, Kernel::render_lean(declaration.ty())). depends_on is the direct-theorem column intersected with this ledger's registered facts, supplied by scripts/check-fact-depends-derived.py --fix. Nothing about the statement was hand transcribed; title, statement and the evidence notes were authored (lane aggregates)."
}