cubical-transport-hott-lean4/HYPOTHESES.md

Topolei — Hypothesis Log

Scientific tracking for the cells interface project. Each hypothesis has: statement, prediction, falsification condition, test protocol, status.

---

H1 — EML as Computational Cell Primitive

Statement: eml(x,y) = exp(x) − ln(y) with constant 1, embedded as a single primitive 1-cell, is sufficient to generate all elementary function cells via transport composition. No other arithmetic primitives are needed in the computational layer.

Prediction: sin, cos, +, ×, √, π can each be type-checked as EML tree cells in Lean 4 with verified derivation proofs.

Falsification: Any elementary function requiring a primitive outside the EML grammar S → 1 | eml(S,S).

Test protocol: Formalize each derivation in Topolei/EML/Derive.lean. A failed #check or sorry-free proof attempt falsifies.

Status: Supported by Odrzywolek (2026) constructive proof. Not yet formalized in Lean.

---

H2 — Uniform Tree Structure Enables Intuitive Interface

Statement: Because all EML expressions share the grammar S → 1 | eml(S,S), the interface can present math manipulation as composing identical nodes — subjectively more intuitive than a multi-button calculator or ad-hoc function syntax.

Prediction: After N interactive sessions, user reports EML-tree manipulation feels natural for expressing the math they care about (calculus, ODEs, geometry).

Falsification: User finds EML trees opaque or mechanical for expressions of practical interest, even after familiarity. Specific failure case: depth > 4 trees feel unmanageable without additional abstraction.

Test protocol: Subjective sessions recorded in this file under H2-Sessions. Scale: 1 (not intuitive, not powerful) to 5 (intuitive and powerful).

Status: Untested.

H2-Sessions

---

H3 — Text and Graph Rendering Are Co-Projections of EML Cells

Statement: Text layout and graph rendering are both sections of the same cell fibration — RenderCell parameterized by a projection map — not architecturally distinct subsystems. EML provides the shared computational substrate for both.

Prediction: A single RenderCell type with two projection instances (text, graph) compiles and renders correctly without duplicated primitives.

Falsification: Text rendering requires primitives (glyph rasterization, string indexing, Unicode) with no EML analog, forcing a separate non-cell subsystem.

Test protocol: Implement RenderCell in Phase 4. If the text projection requires falling outside the EML/cell framework, H3 is falsified. Partial falsification (glyph lookup is external but layout is EML) is recorded as a refinement.

Status: Partially supported by cells-spec §1.5 (rendering context as a cell). EML connection is new and untested.

---

H4 — FM^fr as the Mathematical Foundation for Mathematical Notation

Statement: Mathematical notation should be modeled as factorization homology ∫_M A over a framed syntactic space M with an E_n-algebra A encoding local mathematical operations. Under this model:

• A mathematical expression is an element of ∫_M A, where M is a framed manifold (1-manifold for linear text; 2-manifold for 2D layout — fractions, matrices, integrals)
• A rendering (typeset, graph, interactive widget) is a choice of framing on M, not a separate compilation pipeline
• A transport between framings is a provably structure-preserving language transformation — syntax ↔ geometry ↔ interactive manipulation
• Custom functionality = changing A while holding M fixed (same syntactic space, different algebra — e.g. symbolic vs. numeric vs. proof-term interpretation)
• Custom language transformations = changing the framing of M (same expression, different geometric embedding — e.g. inline text vs. displayed equation vs. 3D surface)

LaTeX, under this model, is not a compiler but a particular choice of framing with a fixed algebra. "Parsing" is not a pipeline but section selection. The ⊗-excision property of FM^fr guarantees that local composition rules are globally consistent — which is exactly what LaTeX currently enforces by convention and fragile macros.

Prediction: The RenderCell type from H3 is correctly typed as a section of the FM^fr fibration ∫_{M^fr} A, where:

• M^fr is the framed syntactic manifold of the expression
• A is an E_n-algebra in the cells/EML framework
• Different renderings are provably related by framing transports

Falsification: Mathematical notation requires operations that cannot be expressed as local E_n-algebra data over any framing of a finite-dimensional manifold — i.e., some notational structure is genuinely global and not ⊗-excisive.

Connection to existing framework:

• Refines H3: FM^fr is the reason text and graph are co-sections, not just an architectural claim
• Fits cells-spec §1.6: the Grothendieck fibration whose sections are programs is precisely ∫_{(−)} A as M varies over framed manifolds
• Lives in the ∞-operad / (∞,1)-category world that the cubical embedding targets
• EML is the computational algebra A; the framed syntactic space M is what the cells-spec calls the "rendering context" (§1.5)

Test protocol: Formalize a minimal FM^fr structure in Lean 4:

1. Define a framed 1-manifold type (for linear text)
2. Define an E_1-algebra over EMLExpr
3. Show that ∫_M A recovers the standard left-to-right evaluation of a formula
4. Show that a framing change (1-manifold → 2-manifold embedding) recovers a 2D layout (e.g., fraction bar as a geometric separator)

Status: Proposed. Not yet formalized. Depends on Phase 1 (EML evaluator) and the cubical core (transport, composition) being in place first.

---

Open Questions

• OQ1: Does the EML framework extend to complex-valued rendering (i.e. shaders that need ℂ arithmetic natively, not just as derived operations)?
• OQ2: Can EML tree depth be bounded for all functions needed in practical math visualization, or do some require unbounded depth (infinite series)?
• OQ3: Is there a ternary EML variant (hinted at in the paper) that removes the need for the distinguished constant 1, and does that simplify the cell primitive?