Mathematical contexts
MMT provides a language for mathematical theories and mappings between them. OMDoc supplies document representation; MathHub organizes libraries and associated services. Together they address a problem that grows as formal libraries expand: a result has a meaning in a particular context, and reuse across contexts needs a justified relationship. The foundational language and module structure are explicit parts of the design. A Scalable Module System
That makes this work a close precedent for Axeyum’s proposed operating system for mathematics. A theory graph can carry information about where a theorem applies. It need not be a diagram added after the mathematics is complete.
A theorem crossing a boundary
Consider a proposed Axeyum experiment. A theorem establishes uniqueness of a limit in an abstract metric space. A later task concerns a sequence of constructed real numbers. The task can use the abstract theorem only after the concrete objects and distance operation satisfy the required metric laws.
The connection needs a source context, a target context, and assignments for the source symbols. It also needs proofs of the conditions that make those assignments valid. A matching word such as “distance” does not supply those proofs. Nor does a link between two documentation pages.
MMT’s views and foundation-dependent validity judgments provide a formal account to study for that experiment. Axeyum would need to demonstrate its own checked mapping; the existence of its current fact dependency graph does not establish one. The example here proposes a validation task, not a report of a completed Axeyum transport.
Libraries and their documents
MathHub’s published architecture connects versioned source documents to semantic transformations and reader-facing services. It allows formal and partially formal material to coexist, with services using the information each document supplies. Dependency information supports different operations from type information. MathHub system description
For a maintained mathematical library, this raises a practical question: what should become stale when a definition changes? A proof depending on the definition and a rendered explanation generated from it both need attention, but for different reasons. A useful implementation should preserve that difference in its dependency records.
The historical architecture should also be distinguished from the current service. The research group’s present system page describes archives, MMT services, indices, and a web interface. This comparison does not reproduce the current deployment or measure its capacity. MathHub project page
Comparison with Axeyum
Axeyum records proof routes and dependencies, then uses its frontier selector to identify ready work and relevant producer contracts. The next architectural question is how those records should relate to mathematical context mappings. Pinned Axeyum selector
A proposed mapping should identify every generated obligation. An accepted mapping should retain the evidence that discharges those obligations. The scheduler could then distinguish a reusable theorem from a theorem whose application still requires work. Invalidating the mapping should invalidate uses that depend on it.
That is a concrete research direction for the Axeyum vision. MMT supplies prior work on theories and mappings; Axeyum’s experiment concerns how its producers, acceptance rules, and task selection can use such structure. The constructive statement families provide useful test cases because their carriers and hypotheses must remain explicit.