max/cubical-transport-hott-lean4
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
Lean 4 cubical-transport HoTT engine + Rust naga-IR FFI. The backend that powers topolei. Cells-spec implementation; the proof IS the implementation.
25 commits 3 branches 0 tags 2.1 MiB
Find a file
Maximus Gorog e26ada2fbc
Some checks are pending
Lean Action CI / build (push) Waiting to run
Details
Extract Algebra/ foundation to Infoductor; require it from forgejo 
The six generic methodology / repo-organization modules
(Meta / Edit / Restructure / MacroAlias / MetaPath / Methodology)
move out of CubicalTransport/Algebra/ into the new Infoductor repo
at http://maxgit.wg:3000/max/infoductor.

cubical-transport-hott-lean4 now `require`s `infoductor` from that
forgejo URL.  Imports updated:
- import CubicalTransport.Algebra.X → import Infoductor.Foundation.X
- open CubicalTransport.Algebra → open Infoductor

Files that stay (cubical-domain-specific):
- CubicalTransport/Algebra/EngineMethodologies.lean (cubical
  closing-form @[methodology] tags)
- CubicalTransport/Algebra/Test.lean (integration tests)

Files deleted (moved to Infoductor.Foundation):
- CubicalTransport/Algebra/Meta.lean
- CubicalTransport/Algebra/Edit.lean
- CubicalTransport/Algebra/Restructure.lean
- CubicalTransport/Algebra/MacroAlias.lean
- CubicalTransport/Algebra/MetaPath.lean
- CubicalTransport/Algebra/Methodology.lean

Architecture rationale (per memory: "Infoductor — generic
methodology / repo-organization project"):
- Foundation primitives are domain-agnostic; anyone can register
  their own methodology atop them, regardless of cubical interest.
- Cubical-transport keeps the question-form (CompQ etc.) and
  cubical-specific @[methodology] / @[metaPath] decls.
- topolei (next, separate work) will consume both
  Infoductor.Foundation and cubical-transport, picking cubical
  as its methodology.
- "Info-ductor" — conducts information through a codebase; pairs
  with Pantograph (the conductor sits atop the pantograph
  hardware on an electric train).

93/93 tests pass (47 smoke + 46 property).  53 build jobs total
(43 cubical + 10 Infoductor.Foundation + linker stages).  No new
axioms, no behavioural change — pure code-organization refactor.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-01 07:22:20 -06:00
.forgejo/workflows
CubicalTransport Extract Algebra/ foundation to Infoductor; require it from forgejo 2026-05-01 07:22:20 -06:00
docs
native/cubical
.gitignore
build.sh
CubicalBench.lean
CubicalTest.lean
CubicalTransport.lean Extract Algebra/ foundation to Infoductor; require it from forgejo 2026-05-01 07:22:20 -06:00
lake-manifest.json Extract Algebra/ foundation to Infoductor; require it from forgejo 2026-05-01 07:22:20 -06:00
lakefile.toml Extract Algebra/ foundation to Infoductor; require it from forgejo 2026-05-01 07:22:20 -06:00
lean-toolchain
LICENSE
NOTICE
README.md

README.md

cubical-transport-hott-lean4

A Lean 4 implementation of cubical-transport homotopy type theory (CCHM-flavor), with a fast Rust kernel exposed through C ABI.

The Lean side defines the syntax, semantics, and soundness theorems. The Rust side discharges the per-step β-rules of the evaluator. Lean axioms are routed through @[implemented_by] to Rust functions that return Lean objects in the same shape Lean would have produced; the soundness layer (CubicalTransport/Soundness.lean) certifies the backend at the boundary, so the kernel speed of the Rust code preserves the Lean-level proofs.

What's here

  • CubicalTransport/ — 22 Lean modules for syntax, substitution, dimensional structure, faces, typing, evaluation (eval / value / readback), transport, Glue, composition, and the soundness theorems.
  • native/cubical/ — Rust kernel (#![no_std], dual-target native staticlib + cdylib, wasm32 cdylib).
  • CubicalTest.lean, CubicalBench.lean — engine smoke + property tests (62/62 passing) and microbenchmarks.

Consuming the engine (with permission)

This Software is proprietary. See LICENSE — no use is granted by virtue of the repository being public. The instructions below are for the copyright holder and any party with prior written consent from mgorog@gmail.com.

Add as a Lake dependency from another Lean 4 project:

[[require]]
name = "cubicalTransport"
path = "../cubical-transport-hott-lean4"   # or git = "..."

Then import CubicalTransport.Syntax, import CubicalTransport.Eval, etc. Link against native/cubical/target/release/libtopolei_cubical.a in your own moreLinkArgs so the FFI symbols resolve.

Build

(cd native/cubical && cargo build --release)
lake build
./.lake/build/bin/cubical-test    # 62/62 tests pass

Reference

  • docs/FFI_DESIGN.md — C ABI contract between Lean and the Rust kernel.
  • docs/FFI_COMPLETENESS.md — per-function axiom audit.
  • docs/KERNEL_BOUNDARY.md — what this delivers in unmodified Lean 4 vs. what would need upstream Lean kernel work.
  • docs/NUMERICAL.md — numerical implementation principles.
  • docs/PHASE1_HISTORY.md — original transport/composition formalisation plan (archived; Phase 1 closed; preserved as methodology template for future phases).
  • docs/ZIGZAG_PORT.md — step-by-step Lean port plan for the n-category combinatorial engine (Phase 2+ higher-cell backend). Lands here in the engine. Read the cascade caveat at the top before editing: changes in the ported zigzag layer cascade to the sibling topolei repo.
  • native/cubical/README.md — Rust crate build + dev guide.
  • native/cubical/WASM.md — wasm32 ABI integration contract.

Used by

  • max/topolei — the cells-spec workspace interface, built on this engine. See its docs/cells-spec.md and docs/STATUS.md for the application-side picture.