This document specifies the math model of the Plurimath system:

• the formula tree and its ownership rules;

• the node classes — formula containers, symbols, numbers, functions, tables, font styles, unit embeddings and uncertainty nodes — with their attributes and relationships;

• the registry of symbols and functions, its entry shape, its generation and its versioning;

• the rendering surfaces: the contract each output format satisfies and the stability rules that govern them;

• the rules by which the model is extended;

• conformance of an implementation of this model.

This document does not specify:

• the syntax of any input representation, or the behaviour of any reader (format interfaces, document 1003);

• the representation of uncertainty inside specific notations, nor uncertainty arithmetic (uncertainty model, document 1002);

• numeric evaluation, propagation or coverage (evaluation, document 1004);

• the UnitsML unit-expression language, which is specified in the UnitsML series (asciiunits content language, CalConnect 36817), and is consumed by the model through the Unitsml node defined here.

Implementers of Plurimath itself, implementers of independent readers or writers that must interoperate with it, and authors of the neighbouring documents in this series.

Trees are written as indented lines, one node per line:

The class name appears first; a quoted string after the name is the node’s value (Symbol, Number, Text). This is the shape the math zone printer emits.

Examples appear in blocks titled Example and end with an Expected outcome paragraph. The expected outcome states what a conforming implementation does; an implementation that does something else does not conform to the clause the example illustrates.

Class names are written as they appear in the implementation: Plurimath::Math::Function::Frac is written Frac when the module is clear from context. The registry entries for symbols are written with the displayed glyph followed by the class name in parentheses when the glyph alone is ambiguous.

Behaviour is pinned to model versions. “0.11.x” names any version whose version string begins 0.11.; a clause that names a specific version, such as 0.11.12, applies to that version and is revisited at the next edition of this document.

The LML blocks of this document are the model. Attribute lines read as attribute name, Type with the cardinality following in braces where it is not one: attribute parameters, Node { cardinality 1..n } reads “every Formula carries one or more parameters, each a Node”. A cardinality left implicit is exactly one ([1]). Enumerations list their values; a node’s attribute of enumeration type carries one of them.

The LML blocks are checked: the model compiles with the LutaML toolchain, and a block that fails to compile fails the build of this document. The prose and the LML state the same model; where they appear to differ, the LML is corrected or the prose is — the two are never allowed to settle into disagreement.

Conceptual class names are written without their implementation namespace: Formula stands for the implementation’s Plurimath::Math::Formula. Implementation namespaces appear once, here, and in the conformance vectors where byte output is frozen. A reader of this document needs no Ruby knowledge; an implementer maps each conceptual class to the implementation class of the same name.

Examples carry an Expected outcome paragraph. The outcome is stated as the observable behaviour of a conforming implementation: rendered bytes where the example is about rendering, tree shape where it is about the model, and refusal behaviour where it is about a prohibition. An example whose outcome cannot be observed is a defect in this document.

The formula tree is specified as an LutaML model. The model is normative: classes, attributes, types and cardinalities are defined in the LML blocks of this clause, and the prose states the rules the diagrams cannot.

Every concrete function class of Annex A is a Function with a fixed operand count and order; the abstract shapes above (unary, binary, ternary, nary) are the families the concrete classes specialise.

A formula tree has exactly one root, a Formula. The root holds the ordered top-level nodes and the presentation options; descendant nodes carry none. Display style, font defaults and line width are decided once, at the root, and applied during rendering.

A Symbol holds one registry reference: a glyph, an operator name or a named constant from the symbol space of the registry (1 438 entries at this edition). The class carries the per-format renderings; the tree carries only the reference.

A Number holds the numeral as written. The tree does not parse numbers into machine values — evaluation is a separate step (document 1004). Negative signs are not part of a Number; a minus is a Symbol sibling.

A Text holds literal text to be typeset upright, copied verbatim by every surface, escaping only what the target format requires.

A function node is an instance of one of the concrete classes of Annex A. Operand order is normative and stable across editions: Frac renders its first operand as the numerator and its second as the denominator in every surface; Root renders its first operand as the radicand and its second as the degree. A reader may not reverse operand order to accommodate a quirk of its input; the surface writers absorb those quirks.

The nary family carries a nary_value (∑, ∏, ∫, ∮) that the MathML and OMML surfaces emit on nary constructs.

A Table holds Tr rows of Td cells; the concrete table class determines the delimiters and alignment semantics of the output, the row and cell structure is shared. Mlabeledtr is a row carrying a label. Cases renders a left brace with a null right delimiter on every surface.

A FontStyle holds one operand and one FontVariant; MathML emits it as mathvariant, OMML as run properties, LaTeX as the corresponding command, UnicodeMath as the corresponding mathematical alphanumeric character where one exists.

A Fenced holds its content and its open and close symbols; Left and Right declare the halves separately in the linear surfaces.

A Unitsml embeds a unit expression written in the asciiunits content language (CalConnect 36817) together with the four renderings the UnitsML system supplies (CalConnect 36816). The tree performs no unit arithmetic: every surface emits the UnitsML-provided form for its format, and the XML form stays available machine-readably.

An Uncertainty attaches an uncertainty to a value expression. Its fields are specified in document 1002 and stated here in summary: the value, the category (standard, expanded, coverage interval), the magnitude or endpoints, the coverage factor and probability where present, the interval kind, the notation and the unit; the model-level contract stated here is that an uncertainty is carried as a node, rendering never recomputes it, and a surface without a faithful form for its category renders the category’s declared fallback from document 1002 and nothing else.

Intent and Semantics carry the MathML 4 intent and semantics constructs. Phantom renders its operand as space of the operand’s measure. Menclose, Merror, Mglyph, Mpadded, Ms, Msgroup, Msline, Multiscript, Mlabeledtr, Linebreak, None, Longdiv, Cancel, Scarry, Scarries, Obrace, Ubrace, Rule and Color model their host-format constructs under the names of those constructs.

These properties hold for every tree a conforming implementation produces and consumes.

• Syntax independence. No node records the input notation the tree was read from. Two readers given equivalent inputs produce equal trees.

• Operand totality. Every function node’s operands are present and in the class-defined order before rendering; a class’s operand count is fixed.

• Render totality. Every surface renders every well-formed tree; where a construct has no faithful form in a format, the surface emits the construct’s declared fallback for that format.

• No formatting in the tree. Layout hints live at the root or in surface options, never in descendant nodes.

• Structural equality. Two trees are equal when their classes, values and operand structure are equal. Equality does not consult rendering.

• Byte stability. A writer given the same tree and the same model version emits the same bytes on every conforming implementation.

A tree may carry a quantity assertion: a statement that a subtree denotes a named quantity kind. The assertion is data — an intent annotation — and the tree performs no arithmetic gating with it. The semantics of assertions and their use in evaluation are specified in document 1004.

The tree form is canonical within a model version. Constructions that differ only in incidental ways — a lone parameter held directly versus wrapped in a single-child container, equivalent fence pairings, a unary function written with or without explicit grouping — produce the same canonical tree after normalisation, and normalisation is applied at construction time, not at render time. Writers therefore never normalise: they render what the tree holds.

Structural equality () compares normalised trees. Two trees that are equal up to normalisation are equal.

The registry is the versioned catalogue of everything the model can name: the symbol entries () and the function entries (). It exists so that the vocabulary of the system is data, not code spread across readers and writers.

A registry entry names one thing the model can represent and carries its renderings. The entry is an LML model:

Prose restatement of the fields:

Entries are immutable once published. A correction to an entry is a new registry edition, never a mutation.

The symbol registry at this edition contains 1 438 entries, one implementation class each, generated from the registry data. The space covers the Greek alphabet (upper and lower), Latin letters in their mathematical roles, binary and relation operators, arrows, set and logic symbols, integrals and nary operators, accents and decoration forms, and the named constants of the input notations.

The complete listing is generated from the registry; this document does not print it. Annex B shows representative entries per category and the lifecycle of an entry.

The symbol classes and the parser vocabulary of each input notation are generated from the registry data. Generation is deterministic: the same registry edition produces byte-identical generated sources. A build that regenerates and finds a diff fails.

The generated artifacts are committed, and the build compares them against the registry as a drift check; a hand-edit to a generated file that survives regeneration is a defect.

A new entry whose name or glyph collides with an existing entry, or with a name reserved by the model (Formula, Symbol, Number, Text, Function, the class names of ), fails the build. The registry does not permit two entries to share a class name, and the model does not permit an entry to shadow a model class.

The registry is editioned with this document series. An entry’s renderings are stable within an edition: a writer using edition 1 entries produces the same bytes for the same tree across all model versions that declare edition 1. New entries join at the next edition; renderings of existing entries do not change within an edition.

The unit expressions that may appear inside a Unitsml node are not registry entries of this document. They come from the UnitsDB dataset through the asciiunits artifact of the UnitsML series (CalConnect 36814, 1006), and the model consumes them as opaque validated content. Nothing in this registry duplicates a unit name, a prefix, or a quantity — the registry’s single source of truth for units is the UnitsDB dataset.

The model renders to six surfaces:

Each surface has one entry point on the root and one rendering rule per node class. The math zone printer (to_asciimath_math_zone and its per-format siblings) is the diagnostic surface: it prints the tree as the indented notation of -style examples.

Writers are deterministic. The same tree rendered by the same model version produces the same bytes, and a conforming implementation reproduces those bytes. Renderer output is covered by replay corpora: for each surface there is a frozen set of trees with frozen expected byte sequences, and a writer change that changes any of those bytes is a model-version change, not a patch.

Some constructs have no faithful form in some surfaces. Each such pair has one declared fallback, recorded with the class in , and the writer emits the fallback and nothing else: no marker, no warning channel in the output. Typical fallbacks: colour is dropped in LaTeX output when no colour package context is present, intent annotations are dropped in surfaces without annotation mechanisms, Mglyph degrades to its alt text in OMML.

A surface is lossless when reading its output back yields a tree equal to the rendered tree. AsciiMath, MathML, OMML, LaTeX and UnicodeMath are the lossless directions of the readers defined in document 1003, each with the exceptions that document enumerates. HTML is a display surface: reading it back is not part of the contract, and its renderings optimise presentation.

The same tree renders through every surface. The mapping below is the normative correspondence between node families and the constructs each surface emits; the per-class notes of refine it.

Where a family has no faithful construct in a surface, the declared fallback applies (); the mapping above lists only the faithful forms.

The OMML surface emits run properties (fonts, styles) from font style nodes, nary constructs from the nary classes, matrices from the table classes, and preserves linebreak semantics from Linebreak nodes and from the root’s linebreak option. Display style: the root’s display flag selects m:oMathPara wrapping; inline rendering omits it.

The MathML surface emits MathML 4. Intent annotations carried by Intent nodes become intent attributes; Semantics nodes become semantics elements with their annotations as annotation children. Font style nodes become mathvariant. Tables become mtable/mtr/mtd, with labelled rows as mlabeledtr. Numbers become mn, symbols become mi or mo per their registry entry, and text becomes mtext.

The root’s display style selects between the display and inline forms of each surface: MathML toggles display="block"; OMML toggles the m:oMathPara wrapper; LaTeX and UnicodeMath choose display-only constructs (display fractions, centred nary limits) over their inline forms; HTML applies the display style class. The tree content is identical in both forms; only the surface presentation changes.

A new construct enters the model as a new class with: its operands, its registry entry (if it names a symbol), its per-surface rendering rules, and — where a surface has no faithful form — its declared fallbacks. No existing class changes. The collision build of applies.

A new symbol or constant joins the registry per the entry lifecycle of Annex B. Generated sources regenerate; existing byte sequences are unchanged.

A new output format is a new set of per-class rendering rules behind one root entry point. The node classes are untouched: the per-format field printers on the base are extended with the new surface’s printer, and each class supplies its rule. A surface that ships without a rule for a class fails the build — render totality () is enforced at build time, not discovered at run time.

Readers are outside this document (document 1003). This document constrains them in one way: a reader ends at the tree. A reader that requires a change to a node class to accommodate its input is a model change and follows .

A node class or registry entry is deprecated by marking it in the registry and this document, keeping its behaviour byte-stable, and removing it at a stated edition. Nothing is removed silently and no published output changes between the deprecation and the removal.

An implementation of this document is an implementation of the math model: the tree, the node classes of , the registry behaviour, and the writers of the six surfaces. Readers and the uncertainty and evaluation semantics are covered by documents 1003, 1002 and 1004; conformance to those documents is claimed separately.

A conformance claim names the classes it makes. A claim of render-<format> carries model with it: no surface can be claimed without the tree it renders.

The render corpus is a frozen set of trees and, per surface, their expected bytes. A corpus entry states its provenance (the tree’s construction, the model version that froze the bytes) and is replayed without modification. Corpus bytes change only at an edition: a new corpus entry joins frozen; a frozen entry never changes.

An implementation whose output for any frozen entry differs from the corpus bytes does not conform at the model version the corpus was frozen against, whatever its own version string says. Divergence is resolved by a model-version change and a new corpus entry, or by fixing the implementation.

This annex enumerates every function class of the model at this edition: 103 function classes, 14 font styles and 10 table classes. The list is normative. A class’s operands column uses 1, 2, 3, or “rows” for the table containers.

The operand shape of each class is the family it belongs to in : the Elementary and Trigonometric classes are unary with an optional limit where their input notation carries one; Log and Lg are unary with an optional base operand; the ScriptPlacement classes are binary (Power, Over, Underset, and the rest) or ternary (PowerBase, Underover); the Calculus classes are nary; the Tables containers hold rows. The tables below give the semantics and surface notes per class.

Elementary function classes:

Trigonometric and hyperbolic classes:

Logarithmic and exponential classes:

Script placement and limit classes:

Fraction, root and cancellation classes:

Fence and delimiter classes:

Accent and decoration classes:

Calculus and nary operator classes:

Table classes:

Text and annotation classes:

Presentation construct classes:

Unit and uncertainty classes:

These are the abstract bases the concrete classes specialise. They appear in trees only when a reader needs a function with no concrete class, which is a defect to be fixed at the model level.

The 14 font style classes apply a mathematical font variant to their operand. Each carries one operand; the surfaces carry the variant per the mapping.

Where an alphanumeric range does not exist for a character, the UnicodeMath surface renders the plain character with the variant dropped, per the fallback rule.

An entry is a row of the registry data: name, glyph, the four format renderings, categories. Two examples:

The generated symbol class is derived from the name: Plurimath::Math::Symbols::Alpha, Plurimath::Math::Symbols::Plusminus. The class holds the entry; the tree and the readers refer to the class.

The steps of a new entry, in order:

1. The entry is added to the registry data with all fields filled; a field for which no rendering exists carries the declared empty rendering, not prose.

2. Generation runs; the new symbol class appears in the generated sources.

3. The collision build checks the name and the glyph against the existing registry, the model class names, and the UnitsDB symbol space. A collision fails the build.

4. The render corpus gains an entry exercising the new glyph in all six surfaces, frozen against the model version that ships it.

5. The registry edition is published; this document’s symbol-space count (1 438 at edition 1) is updated.

No step reorders: a glyph that fails collision never ships; a corpus entry is never retrofitted after publication.

Function classes are not registry rows in the same sense — their semantics live in this document () and their renderings in their class definitions — but they obey the same discipline: a new function class ships with its operand definition, its per-surface rules, its fallbacks, and a frozen corpus entry per surface.

A deprecated entry keeps its class, its glyph and its renderings byte-stable. The registry marks it deprecated with the edition of removal. Readers that encounter the entry keep parsing it; writers keep writing it. At the removal edition, the class is deleted, the corpus entries that used it are superseded, and the registry count decreases.

The symbol-space count is asserted by the build against the registry data, so this document’s count and the registry cannot disagree silently. Edition 1: 1 438 symbol entries, 103 function classes, 14 font styles, 10 table classes.

The entries below are drawn from the registry at this edition; each row is one symbol entry with its input tokens and its LaTeX rendering as published.

An entry carries more than the table shows: each row’s registry record also holds the MathML and OMML renderings and the additional input tokens (an entry may have several accepted tokens per notation; Alpha accepts alpha and the numeric character reference, for instance). The tables show the primary tokens.

Vectors illustrative of the conformance classes of . Each vector states the construction, the property under test, and the expected outcome. The replay corpora carry the frozen versions of these vectors.