Official Lean's own kernel accepts every representable declaration of the constructed-real carrier, and refuses the rest by a rule of its own

Identifier: F:lean-kernel-accepts-the-whole-constructed-real-carrier
Proof route: kernel-lean
External status: unknown
Axiom footprint: Empty

Recorded description

Every declaration that build_creal_prelude admits and that Lean's kernel will accept as the KIND this kernel declares it -- 1,985 of the carrier's 2,058 on 2026-08-30, with no reachability filter -- is accepted by official Lean 4.30.0's own kernel via Lean.Environment.addDeclCore starting from mkEmptyEnvironment, including the two that Lean's ELABORATOR refuses when the same development is handed to it as .lean source. The number of constants Lean's environment ends with equals the size of that population, so acceptance cannot mean acceptance of a subset. The remaining 73 are excluded by a rule of LEAN's rather than a choice of ours, and the same binary demonstrates it: 48 are Theorems whose type is not a proposition (Lean's kernel refuses those; this kernel has no such rule, and CReal.UniformConvergesOn is deliberately Type-valued so a convergence rate is data), 25 depend on one of those, and folding addDeclCore over the UNFILTERED export FAILS, naming one of the 48. The same binary also rejects the representable stream when CReal.Equiv.not_zero_one's proof is replaced by another closed proof, naming that theorem's own type when it does.

Formal statement

Let K be the kernel state after `build_creal_prelude(&mut Kernel::new())`. Call a declaration NON-REPRESENTABLE if either (a) it is a `Declaration::Theorem { ty, .. }` whose `ty` is not a proposition -- `K.infer(ty)` does not whnf-reduce to `Sort 0` -- or (b) its `K.declaration_dependency_closure` reaches one of (a); and let R be every other declaration of `K.environment()`. Let S = `K.render_lean4export_ndjson_roots(Lean4ExportMetadata::axeyum("4.30.0"), R)` be the official lean4export NDJSON 3.1.0 encoding of R (no reachability filter: R is defined by Lean's admission rule, not by what any query cites). Let L be the Lean binary that `lean-toolchain` pins (4.30.0, commit d024af099ca4bf2c86f649261ebf59565dc8c622). Then `scripts/lean/replay-lean4export.lean`, which folds `Lean.Environment.addDeclCore` over S starting from `mkEmptyEnvironment`, succeeds under L, and the resulting environment holds exactly |R| constants (|R| = 1,985 of a population of 2,058 on 2026-08-30; non-representable 73 = 48 of (a) + 25 of (b)). In particular `CReal.Equiv.not_zero_one` and `CReal.not_le_one_zero` are in R and are admitted by L's kernel, although L's ELABORATOR refuses both when the same development is rendered as `.lean` source (ADR-0517). The narrowing to R is L's rule and not ours: folding `addDeclCore` over the UNFILTERED `K.render_lean4export_ndjson(...)` FAILS under L, and the declaration L names in refusing it is one that K independently classified under (a) (ADR-0775).

Dependencies

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

0 direct dependencies 1 direct dependents

Evidence

lean-kernel-accepts-the-whole-constructed-real-carrier-1

Kind: kernel-term
Status: checked

Supports: The representable carrier, and the WHOLE of it. Lean's kernel ends with exactly as many constants as that population holds -- 1,985 = 1,985, both numbers read out of the run rather than transcribed, and compared by the checker itself. This is the row that distinguishes `accepted` from `accepted a subset`, which is the failure mode every other real-Lean check in this repository is exposed to: they render the closure of one refutation, so Lean only ever sees the declarations some query happens to cite.

Checker command

out=$(AXEYUM_REQUIRE_LEAN=1 cargo test -q -p axeyum-lean-kernel --test real_lean_creal_carrier_kernel_replay -- --nocapture 2>&1) && test "$(printf "%s\n" "$out" | sed -n 's/.*AXEYUM-CREAL-CARRIER counts_agree population=[0-9]* representable=\([0-9]*\) lean_kernel_constants=\([0-9]*\).*/\1 \2/p' | awk '$1==$2 && $1>=1900 {c++} END {print c+0}')" -ge 1

Evidence notes

The checker COMPARES rather than transcribes: it extracts both counts and passes only if they are equal and above the committed replay floor. Deliberately NOT pinned to 1,985 -- the carrier grew 2,045 -> 2,058 in the hours between L0/S4's census and this run, so a pinned population would be red every day for a reason that is not the claim. What is pinned is the relation the claim is about. The line is printed only after the equality assertion, so its presence is the finding; and `out=$(...) &&` makes a crashing run fail rather than read as absence, which is how this suite hid a real finding for twelve days.

lean-kernel-accepts-the-whole-constructed-real-carrier-2

Kind: kernel-term
Status: checked

Supports: Lean actually RAN, three times -- the representable replay, the unfiltered refusal, and the tampered-proof rejection. An exit status cannot distinguish `checked 3 streams` from `checked none`, and this repository has shipped suites that were inert for weeks. Each Lean-running test prints its own invocation count and the pinned toolchain it used; `scripts/check-lean-gate.sh` sums those counts and cross-checks the binary.

Checker command

out=$(AXEYUM_REQUIRE_LEAN=1 cargo test -q -p axeyum-lean-kernel --test real_lean_creal_carrier_kernel_replay -- --nocapture 2>&1) && test "$(printf "%s\n" "$out" | grep -Ec 'AXEYUM-LEAN-CHECKED creal-carrier-kernel-replay checked=1')" -ge 3

Evidence notes

Anchored on the suite's own `AXEYUM-LEAN-CHECKED` markers, not on the exit status, and requires all THREE Lean-running tests to have reached their end. Dropping any one of them -- which is how a narrowed claim would quietly become an unchecked one -- takes the count to 2 and fails.

lean-kernel-accepts-the-whole-constructed-real-carrier-3

Kind: kernel-term
Status: checked

Supports: The SUPERSEDED statement, refuted by the binary it named. Until 2026-08-30 this fact claimed Lean's kernel accepts the carrier with no filter at all. It does not, and the correction is not a matter of opinion: the suite hands pinned Lean the unfiltered export and requires it to FAIL, and requires the declaration Lean names to be one this kernel independently classified as a theorem whose type is not a proposition. That is what makes the narrowing a rule of Lean's rather than a convenience of ours -- and it goes red if Lean ever accepts the unfiltered stream, which is the outcome the follow-on work aims at.

Checker command

out=$(AXEYUM_REQUIRE_LEAN=1 cargo test -q -p axeyum-lean-kernel --test real_lean_creal_carrier_kernel_replay -- --nocapture 2>&1) && test "$(printf "%s\n" "$out" | grep -Ec 'AXEYUM-CREAL-CARRIER superseded-claim-refuted rejected_by_lean=CReal[.][A-Za-z0-9_.]+ reason=theorem-type-not-prop theorem_type_not_prop=[0-9]+')" -ge 1

Evidence notes

The name Lean happens to reject FIRST is a property of stream order, so the pattern does not pin it; the test pins something stronger, that whatever Lean names is a member of the set this kernel classified independently. Pinning the first-refused name here would go red the day a non-proposition theorem is declared earlier in the carrier, for a reason that is not the claim.

lean-kernel-accepts-the-whole-constructed-real-carrier-4

Kind: kernel-term
Status: checked

Supports: The residue is enumerable, typed and named -- 48 theorems whose type is not a proposition plus 25 blocked behind one, with `untyped=0`, and every one printed by name. A narrowed claim is only honest if what it excludes can be listed by someone who never read the correction; before 2026-08-30 nothing in this ledger said 73 declarations of the flagship carrier held no independent-replay grade.

Checker command

out=$(AXEYUM_REQUIRE_LEAN=1 cargo test -q -p axeyum-lean-kernel --test real_lean_creal_carrier_kernel_replay -- --nocapture 2>&1) && test "$(printf "%s\n" "$out" | grep -Ec 'AXEYUM-CREAL-CARRIER residue reason=theorem-type-not-prop name=CReal[.]weierstrassMTest')" -ge 1 && test "$(printf "%s\n" "$out" | grep -Ec 'AXEYUM-CREAL-CARRIER residue-typed population=[0-9]+ representable=[0-9]+ theorem_type_not_prop=[0-9]+ blocked_by_dependency=[0-9]+ untyped=0')" -ge 1

Evidence notes

Name-anchored on the declaration that makes the class real: `CReal.weierstrassMTest` concludes in the deliberately `Type`-valued `CReal.UniformConvergesOn`. Verified discriminating in BOTH directions on 2026-08-30 -- 1 match on the real name, 0 on a fabricated one (`CReal.weierstrassMTestX`), same captured run. The second clause is what makes `untyped=0` load-bearing: an exclusion nobody has a typed reason for is a declaration quietly dropped.

lean-kernel-accepts-the-whole-constructed-real-carrier-5

Kind: kernel-term
Status: checked

Supports: The NEGATIVE control on a PROOF rather than a kind, which is what makes rows 1 and 4 mean anything. The suite replays the same representable stream with `CReal.Equiv.not_zero_one`'s proof replaced by another closed proof, and only passes if Lean's kernel REJECTS it naming `CReal.Equiv` -- i.e. only if it really type-checked that declaration against that type.

Checker command

out=$(AXEYUM_REQUIRE_LEAN=1 cargo test -q -p axeyum-lean-kernel --test real_lean_creal_carrier_kernel_replay -- --nocapture 2>&1) && test "$(printf "%s\n" "$out" | grep -Ec 'AXEYUM-CREAL-CARRIER tampered-proof-rejected subject=CReal[.]Equiv[.]not_zero_one')" -ge 1

Evidence notes

Aimed at one of the two declarations Lean's ELABORATOR refuses and its kernel accepts, so the control also pins the coverage the whole-carrier route exists for. The marker is printed only after the rejection was observed AND found to name the type being checked.

Provenance

{
  "date": "2026-08-18",
  "established_by": "lane `agent-creal-lean-divergence`, crates/axeyum-lean-kernel/tests/real_lean_creal_carrier_kernel_replay.rs; CORRECTED and re-established 2026-08-30 by lane `carrier-replay-overclaim` after L0/S4's census (docs/plan/status/386-l0-s4-independent-replay.md) measured 73 declarations Lean's kernel will not admit as declared",
  "source": "Measured while investigating a handover claim that this kernel admits four `CReal` declarations Lean's kernel rejects. It does not: Lean's ELABORATOR refuses them and Lean's kernel accepts them, which is ADR-0517. The whole-carrier replay exists because the refusal had gone unnoticed -- emission is reachability driven, so 122 of the carrier's declarations had never been handed to any Lean.",
  "correction": "2026-08-30. The statement was narrowed from the whole carrier to the representable population, and the residue was made a typed, counted, named boundary (ADR-0775). The previous statement is preserved verbatim in `notes` below, recorded as an amendment in `artifacts/ontology/settled-fact-statement-pins.json`, and kept EXECUTABLE as `the_superseded_whole_carrier_claim_is_refuted_by_the_same_binary` -- so the claim this fact used to make now has a test that fails if it ever becomes true again."
}