# 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?