Roadmap

Roadmap

What the project is for, where each part is going, and how it fits with compute-engine. The four names (compute-engine, Epsil, enumeratio, notatio) are defined on Names.

This page gives direction, not tasks. Work in flight is in the lane backlog (Lanes), designs are the pages under Design, and ideas nobody owns yet are on Ideas.

The aim

Give mathematical objects, combinatorial ones first, a permanent home where each is:

• live: it can be computed with, drawn and explored in a browser, a terminal or a notebook;
• checked: what the page claims is tested, and compared with other systems wherever a claim can be computed;
• addressable: it has a URL that keeps working, so it can be cited.

Three things make that: an engine that computes (compute-engine), a catalogue of the objects (enumeratio), and a way to write and show them (notatio).

compute-engine: where the mathematics lives

We build on compute-engine and do not fork it. Its language, Epsil, is the only text syntax we read or write.

Direction: as much of the mathematics as compute-engine will take lives in compute-engine. Every release changes behaviour under our definitions, our overrides and our compile paths. Mathematics that lives upstream is exercised by compute-engine's own tests and moves with it; mathematics that lives here has to be re-fitted at each release.

How each kind of thing moves:

What	How it moves
A fix, or a head compute-engine would plausibly take (Wolfram or mpmath has it, or it widens a native head)	Written in packages/ce-patches/ as a patch, proposed as an issue with its PR, retired when tests/landed.test.ts says compute-engine ships it
Built-in functions compute-engine lacks (IntegerPartitions, HarmonicNumber and their kind)	Pull requests to compute-engine's core, one head each
The combinatorial collections, their statistics and maps, and the FindStat tables	An optional library inside compute-engine's repository, beside Rubi and Fungrim, which we maintain there. Ours shrinks to the records and the glyphs ([[the split, file by file
Special functions, modular arithmetic and number theory, the generic heads over compute-engine's protocols	Core pull requests, after the above
The algebras, adèles, modular and braid groups	Stay enumeratio libraries; offered one at a time when ready
Oracle answers for the heads we send	Test data in compute-engine

Keeping in step while that happens:

• A nightly builds compute-engine's main and runs our tests against it (ce-main.yml), keeping one rolling issue with the commit range and the failures.
• The same suite is packaged for compute-engine to run on its side (tools/ce-downstream), so that a breaking change shows there before it is released.
• A bump pull request opens on each compute-engine release (ce-release.yml).
• Every place we override compute-engine is listed, classified, and drained in batches (Compute-Engine-Overrides).

The default is upstream. A new fix compute-engine would take is written as a patch and proposed, not kept as a local override (Contributing, "Upstreaming to compute-engine").

Epsil: a definition is data

A definition is written in Epsil. A hand-written TypeScript kernel is only an optional fast path, held equal to the Epsil definition by a test. Fast paths otherwise come from compiling the Epsil, at run time or ahead of time (Computation).

This is what lets a library move. A library that is records plus Epsil reads no engine internals, so it can go into compute-engine's repository or into one of its own without being rewritten. Closing the speed gap between compiled Epsil and the hand kernels is mostly compiler work, and those asks go upstream.

enumeratio: the catalogue

For surfacing mathematical objects so they can be explored now and referenced for good.

Where it is going:

1. Every object has an address. Heads have pages and examples have anchors. Next come collections, single elements and specific structures, each addressed by the expression that names it. A published address is permanent (Sites).
2. A head is its record. Signature, definition, examples, crosswalks and notation are tables kept beside the record, so a library is its tables and nothing has to be extracted from code (Examples as Data, Manifest).
3. Every claim is checked. Examples are the tests. Oracle lanes compare them with Wolfram, Sage, SymPy, mpmath, the OEIS, FindStat and Fungrim; Plausible samples the properties a space declares (Plausible). A disagreement is triaged, never dropped.
4. A registry of libraries. A thin core, with the mathematics in libraries the registry indexes. Anyone, a person or an agent, can publish a library of definitions with its records. The census grows from an in-repo check into the crawler that validates published libraries: records present, examples passing as the install check, no head or notation colliding with another library's. Libraries leave the monorepo through pilots, one at a time (Per-Package Repositories, Lazy Engine).
5. Breadth. Enumerative combinatorics is the base: collections as lazy indexed families, with statistics and maps as fields of their elements. Around it sit number theory, the special functions and the algebras. The frontier lists below say what is missing.

notatio: writing and showing

For writing and showing an expression, any expression, in every environment.

Where it is going:

1. Boxes are general layout. One presentation tree sits between an expression and its rendering, and every head that draws lowers to it. Tables, diagrams, combinatorial structures and rich text are laid out the same way formulas are (Boxes).
2. A markup that lasts. The vdom is an expression's FullForm written as JSX: semantic, framework-free, and readable by people and agents who have no interest in mathematics (Vdom).
3. Every environment. The web, the terminal, print and native each get their own primitives over the same boxes, and each form says what it becomes in each (Rendering Environments, Native Rendering).
4. Graphics. Plots, figures and scenes as layers in shared frames, drawn from sampled fields (Figures, Plotting).
5. The notebook. The notebook and the worksheet, kernels reached by message, sessions kept as data, controls generated from the expression they steer, and the documentation itself written as notebook documents (Notebooks, Sessions as Data).
6. On its own. notatio works over a bare compute-engine. It has its own site, and later its own domain and published packages (Sites).

What stays ours

What	Why it does not go to compute-engine
The records, the crosswalks and the catalogue site	They are facts about objects and what other systems call them. Nobody needs them to evaluate
The oracle lanes, Plausible and the census	They check across systems, some of them proprietary. Their results go upstream as test data
All of notatio	compute-engine is headless; presentation is a separate concern
The libraries compute-engine has not taken	Until it takes them
packages/ce-patches/	Temporary by design: each patch is a deletion waiting for a release

Phases

In order of dependency, not of date. They overlap.

1. Draw the line. The names mean the same thing everywhere: this wiki, AGENTS.md, the READMEs, the site. The site becomes two, built from one repository, and the catalogue's published URLs are held by a ledger.
2. Mathematics upstream. The core heads land, combinatorics becomes an optional library in compute-engine's repository, the overrides are drained, and both nightlies run. Definitions are Epsil throughout, so a library can move without a rewrite.
3. The catalogue as a registry. Object addresses, records as tables, libraries in their own repositories, and the census crawling what others publish.
4. notatio on its own. Its own domain and published packages, the terminal and native environments at parity with the web, and the markup documented as a format for general use.

Where the work is listed

• The lane backlog and log: what is in flight and who has it (Lanes).
• compute-engine: issues and pull requests by enumeratio, and Compute-Engine-Overrides for what is still to send.
• Designs: the pages under Design. A Speculative- page is a proposal not yet adopted.
• Ideas: ideas with no design and no owner.
• The frontier lists: committed, regenerable data saying what the catalogue cannot do yet. These, not any wiki page, are the source of truth for what is missing.

List	What it holds
packages/census/src/wolfram-frontier-data.ts FRONTIER	Heads that Wolfram's documentation examples use and we cannot answer, ranked by use
packages/census/src/wolfram-frontier-data.ts CALL_FORMS	Argument shapes Wolfram shows for a head we do map, beside ours
statistics.frontier.ts in each area of packages/symbols/combinatorics/combinatorics/	Statistics with no definition, each with its reason
packages/symbols/combinatorics/combinatorics/src/frontier-maps.ts UNDEFINED_MAPS	Maps not defined yet, each with its reason
packages/reference/src/fungrim-verified-data.ts fungrimFrontier	Heads whose Fungrim identities we cannot evaluate, ranked by how many each holds up
packages/census/src/rename-queue.ts RENAME_QUEUE	Heads still declared under a spelling we have decided against
Examples with role: aspirational in a record's examples.tsv	Results we claim and do not produce yet

The Wolfram frontier is the one to open first for "what should this be able to do that it cannot". Regenerate it with a Wolfram kernel on the path: node packages/census/scripts/collect-wolfram-frontier.ts.