This document specifies the uncertainty model of the Plurimath system:

• the uncertainty node and its fields;

• the three uncertainty categories — standard, expanded, coverage interval — with the fields each requires and forbids;

• the notation distinction (absolute and concise) and the concise-form rule;

• the exact-decimal discipline that governs every number the node carries;

• the representation of each category in each output format, including the marker conventions of MathML, OMML and UnicodeMath;

• units on an uncertainty, through the UnitsML embedding;

• conformance of an implementation of this model.

This document does not specify:

• the syntax with which each input notation writes an uncertainty, beyond what the per-format encodings of clause 9 imply for the formats that read (document 1003 specifies the reading contracts);

• uncertainty arithmetic: propagation, combination, degrees of freedom, coverage-factor computation — evaluation is document 1004;

• which numerical tolerance conventions apply to evaluation output (CalConnect 36813 governs those).

Implementers of Plurimath, implementers of independent readers and writers that must carry uncertainty through these formats, and authors of documents 1003 and 1004.

Encodings are written as literal output: 10.3(0.2) is the two-character-group rendering with a full-width-free ASCII parenthesis pair; ± is the Unicode character U+00B1. Format names follow PM 1001: MathML, OMML, LaTeX, UnicodeMath, HTML, AsciiMath.

Examples appear in blocks titled Example and end with an Expected outcome paragraph stating the observable behaviour of a conforming implementation. Where an example shows per-format output, the outcome lists the rendering of every format the example names.

Number fields carry exact decimals as text. This document never rounds: where a rule compares decimals it compares them exactly, digit by digit, without converting to floating point.

The node model is written in LML (clause 5) as in PM 1001; the LML blocks are normative and compile with the LutaML toolchain.

Marker strings are shown in monospace; ± denotes U+00B1; the ⓘ and ⓐ characters are U+24D8 and U+24D0. Encodings in tables are literal: what the table shows is what a conforming writer emits, byte for byte, apart from the number slots.

The uncertainty node is specified as an LML model. It is one indivisible result: rendering never splits it across lines, and no surface recomputes any of its fields.

The ExactDecimal of the model corresponds to a Number node of the tree (PM 1001) whose text is a plain decimal; the node never holds computed values.

The category determines which fields are required and which are forbidden. A node is well formed when, for its category:

Constructing a node that violates its category’s field set raises InvalidUncertainty with a message naming the field and the category. The validation runs at construction; a tree therefore never contains a malformed uncertainty node.

The value is a signed plain decimal: an optional minus sign, digits, and an optional fractional part. It is carried verbatim: no canonicalisation of trailing zeros, no exponent forms, no thousands separators.

The node renders as one unit in every format. A line break inside a rendered uncertainty never occurs; a surface asked to break inside one places the break before or after the whole node.

The marker is the machine-readable name of the node, carried by the intent mechanisms of MathML, OMML and UnicodeMath:

Marker arguments are the node’s numbers in the fixed order of clause 9’s encodings, comma-separated without spaces.

Two nodes are equal when their categories and all ten fields are equal, field by field. Equality is exact: 0.2 and 0.20 are different magnitudes and therefore different nodes. Equality does not consult encodings: two nodes with equal fields have equal encodings by the determinism of clause 9.

Copying a node copies the tree structures it holds (its value, numbers and unit) and shares nothing mutable. A copy is created through the constructor and revalidated; a validation passing at construction time cannot be bypassed by copying.

The field rules of clause 5, written as the model they enforce:

with the populations: StandardRule requires value, magnitude and forbids coverage_factor, coverage_probability, lower, upper, interval_kind; ExpandedRule requires value, magnitude, coverage_factor and forbids lower, upper, interval_kind; CoverageIntervalRule requires value, lower, upper, interval_kind and forbids magnitude, coverage_factor. The notation check is the standard category’s alone; every refusal raises InvalidUncertainty at construction.

The standard uncertainty (JCGM 100 7.2.1) reports the result v with its standard uncertainty m. It carries value and magnitude, and its notation distinguishes the absolute form from the concise form (clause 7). It carries no coverage factor, no coverage probability and no endpoints.

The expanded uncertainty (JCGM 100 6.2.1, 7.2.3) reports the result v with uncertainty magnitude m and coverage factor k, optionally with the coverage probability p that was used to choose k. The magnitude here is the expanded uncertainty itself, not a standard uncertainty.

The coverage factor is a positive unsigned decimal: 0, 0.5 and negative factors do not describe coverage factors and are refused. The coverage probability, when present, lies strictly between 0 and 1; both bounds are exact decimal comparisons, not float comparisons.

The coverage interval (JCGM 101 5.3, 5.5) reports the result v with the interval [l, u] and its kind: shortest or probabilistically-symmetric, optionally with the coverage probability p. The magnitude and coverage factor fields do not apply.

The interval kind is carried because the two kinds differ semantically — the shortest interval of a distribution need not be its probabilistically symmetric one — and the distinction survives every encoding that can carry it. In AsciiMath the symmetric kind is spelled symmetric (the - of probabilistically-symmetric would read as minus); the model carries the one kind and each format spells it its own way.

The category is part of the node’s identity: two nodes with the same numbers and different categories are different nodes. A round trip that loses the category is a lossy round trip, and the encodings of clause 9 are designed so that no lossless format loses it.

The category is the author’s statement about their result, and the model carries it rather than inferring it:

Converting between categories is not a rendering act: turning a standard uncertainty into an expanded one requires multiplying by a factor — a computation belonging to document 1004, performed on request, producing a new node. An encoding never silently upgrades one category’s shape to another’s.

Every encoding that can carry semantics carries the category name explicitly: the AsciiMath call names it (ustd, uexp, ucov), and the markers begin with it (standard-uncertainty, expanded-uncertainty, coverage-interval). The shape-only encodings (LaTeX, HTML) distinguish the categories by shape alone — the reporting form, the ± form, the interval form — which is unambiguous precisely because the model defines exactly three shapes and refuses everything else.

The model adds no metrology of its own. Everything metrological — which k to choose, which interval is shortest, whether the distribution is symmetric enough for the symmetric interval — is the author’s or the evaluator’s (document 1004); the node records what was reported.

The shortest coverage interval of a probability distribution and its probabilistically symmetric interval coincide only for symmetric distributions. JCGM 101 distinguishes them because Monte Carlo results need not be symmetric; a reported interval says which one it is, and downstream consumers treat them differently when combining or comparing results. The model carries the distinction on every interval node; the encodings carry it in every channel that carries anything.

A standard uncertainty is written in one of two notations. The absolute notation carries the full magnitude: 10.3(0.2) means v = 10.3 with u = 0.2. The concise notation carries the magnitude as a digit string aligned to the value’s last decimal places: 10.3(2) means the same result with u = 0.2.

The concise form is well defined only when the magnitude has exactly as many decimal places as the value. The magnitude’s digits after its decimal point, with leading zeros of the fraction removed, form the concise digit string. A magnitude whose decimal places do not match the value’s cannot be written concisely after it, and constructing such a node is refused:

The notation is a property of the standard category alone. The model always carries the full magnitude; the concise notation says that the AsciiMath and any other reporting-shaped encoding of this node uses the concise reporting form. Reading a concise form back yields a node with notation concise and the reconstructed full magnitude: 10.3(2) reads back as value 10.3, magnitude 0.2.

A notation argument accompanying an expanded uncertainty or a coverage interval is refused: the notion belongs to the standard-uncertainty reporting form. This keeps the concise digit string unambiguous: it appears only where its decimal-places rule is defined.

The concise rule binds the magnitude’s decimal places to the value’s, so its behaviour at the edges is pinned by examples:

A zero magnitude is well formed (10.0(0)) — a reported uncertainty of zero is the author’s statement. The negative value carries its sign on the value; the magnitude stays unsigned.

A writer that receives a concise node and renders the absolute reporting form has not honoured the model: the notation is carried precisely so the reporting shape follows the author’s choice. The encodings of clause 9 emit the concise reporting form exactly where this document says (AsciiMath) and the qualified marker where the format carries semantics.

Reading 10.3(2) reconstructs the full magnitude by aligning the digit string to the value’s decimal places: one digit at one decimal place gives 0.2. The reconstruction is defined only because the concise rule guaranteed the place counts match; a malformed concise form is a reading error, not a reconstruction opportunity (document 1003 owns the error behaviour).

Every number the node carries is a plain decimal:

No exponent forms, no signs on the unsigned fields, no separators. A value carried as anything else — a computed float, a Number with a base or a size qualifier, an empty string — is refused at construction.

The node stores the digits as written. 2.10 and 2.1 are different exact decimals: the trailing zero is the author’s statement of precision, and the model does not speak over it. Every encoding emits the digits verbatim; every exact comparison in this model — the concise rule, the probability bounds — compares the decimal strings digit-wise without converting to floating point.

The node never calculates, rounds or converts its numbers (JCGM 100 7.2.2). Where evaluation (document 1004) produces numbers, they are produced as exact decimals by the evaluation rules of CalConnect 36813 and attached to new nodes; an existing node’s fields are never rewritten in place.

The two comparisons the model performs — the concise decimal-places rule and the coverage-probability bounds — are defined on the digit strings:

• the probability check requires the first nonzero digit of the fraction to exist (strictly greater than zero) and the string to compare strictly less than "1" digit-wise;

• the concise rule compares decimal-place counts, which is a property of the strings alone.

Both refuse inputs whose comparison would require rounding.

The comparisons are on strings, and the examples below pin the edge behaviour.

JCGM 100 7.2.2 fixes the reporting forms and assigns rounding to the reporter. The exact-decimal discipline is that assignment made executable: the model cannot round because it does not compute, and it cannot silently normalise because its numbers are text. The same discipline governs the whole Plurimath stack through CalConnect 36813; this document applies it to the uncertainty fields.

Each format has one encoding per category. The matrix states which formats carry the semantics machine-readably (via the marker) and which carry the reported shape only.

The category call names are ustd, uexp, ucov. Arguments are the node’s numbers in category order, comma-space separated. The interval kinds are spelled shortest and symmetric in AsciiMath (the model’s probabilistically-symmetric, respelled because AsciiMath reads - as minus). The concise notation renders the reporting form v(digits) instead of a call. The unit travels in the quoted UnitsML channel "unitsml(...)" when the unit is expressible there (clause 10).

The standard category renders the reporting form v(m) — the full magnitude in the parentheses, whatever the notation. The expanded category renders (v \pm m) followed by the statements ~(k = K) and (p = P) for the fields present. The interval category renders v,~[l, u] followed by the kind and probability statements. Statements are appended after the unit.

The HTML encoding is the LaTeX encoding with the Unicode ± (U+00B1), plain spaces, and no TeX-specific spacing. Interval and statement shapes are identical.

The whole node is wrapped in an intent: ⓘ("marker" visible), where marker is the full marker string of clause 5 and visible is the display shape — the reporting form for standard, (v±m) plus statement text for expanded, v, [l, u] plus statement text for the interval. A unit travels in ⓐ(unit ...) inside the wrapper.

The node renders as an mrow carrying the intent attribute with the marker string. Its content: mn for the value, a fenced group for the magnitude ((m)), (v ± m) for expanded, mn(v), mfenced[l, u] for the interval, followed by the unit’s MathML form when present.

The OMML surface carries the marker as a convention: a run holding the marker string precedes the shape runs (value run, fence with magnitude run, and so on), and the unit, when present, is boxed. OMML has no intent mechanism; the marker run is the machine-readable channel, and consumers that do not understand it ignore one run of text.

The appended statements of LaTeX, HTML and UnicodeMath state the fields the shape cannot show: the coverage factor as k = K, the coverage probability as p = P, the interval kind as its spelled name. Statements appear in one fixed order — kind, factor, probability — after the unit.

The encodings are stated as algorithms so that two implementations cannot diverge over punctuation or order.

The reading contracts of the lossless encodings belong to document 1003. This document constrains them with one rule each:

• AsciiMath: the call forms and the concise reporting form read back to the node with the fields the arguments carry;

• UnicodeMath: the ⓘ wrapper is authoritative for the fields; the visible shape is regenerated;

• MathML: the intent attribute is authoritative;

• OMML: the marker run is authoritative;

• LaTeX and HTML: display surfaces, not read.

A reader that finds a marker and a visible shape disagreeing follows the marker.

The statement texts are a small fixed grammar, so that a reader can recover k, p and the kind from the shape-only encodings:

Statements appear in the order kind, factor, probability, separated by a space in HTML and by ~ in LaTeX. The readers of document 1003 use this grammar to recover the fields; a statement outside the grammar is not part of a node’s encoding.

A node may carry one unit, held as a UnitsML embedding (PM 1001, Unitsml node). The unit qualifies the value, the magnitude and the endpoints alike: the node reports “10.3 g with 0.2 g”, and the unit appears once.

When the unit is expressible in the asciiunits content language (CalConnect 36817) — a single symbol such as g, kg, m/s2 — the AsciiMath encoding embeds it in the quoted UnitsML channel: ustd(10.3, 0.2) "unitsml(g)". The embedding is attempted at encoding time; the attempt uses the UnitsML reader, and a unit the reader refuses falls back to visible placement.

When the unit is not expressible in UnitsML — arbitrary text the reader rejects — the AsciiMath encoding places the unit visibly after the call, which is the only place the AsciiMath reader accepts it: ustd(10.3, 0.2) <unit>. The unit then travels as ordinary trailing content, and the format’s own encoding carries it (LaTeX after the shape, UnicodeMath inside ⓐ(...), and so on).

The unit is either a Unitsml node or a non-empty formula holding no uncertainty: a unit containing an uncertainty is refused (InvalidUncertainty, “unit must not contain an uncertainty”). A unit is not a place for content; it names the measurement unit and nothing else.

The unit survives every lossless round trip. The quoted channel and the visible placements of clause 9 read back to the unit field; a format transition that silently drops the unit is a defect of the encoding, not a permitted loss.

The expressibility question is answered by the UnitsML reader at encoding time, not by a table in this document: a unit the reader accepts travels in the channel, and a unit it refuses travels visibly. The same node encodes differently across the two cases only in where the unit sits; the unit field itself is identical.

The interval endpoints share the value’s unit; the unit appears once. [9.9, 10.7] g is one unit for the interval, not one per endpoint — reporting two units would double-count the measurement unit and is not a defined encoding.

Conformance to this document is the implementation of the uncertainty node per clause 5 with the encodings of clause 9. Claims are per class; every claim is discharged by replaying frozen vectors.

An encode-<format> claim carries uncertainty-model with it.

The corpus is a frozen set of nodes with, per format, their expected encodings. Entries state their provenance (the node’s fields, the model version that froze the encodings) and replay without modification. Encodings change only at an edition of this document.

A claim of round-trip for a format means: reading the format’s encoding of a corpus node back yields a node equal to it. Round-trip claims exist for the formats whose readers are specified in document 1003; this document defines the property, that document its mechanics.

The uncertainty corpus is owned like every corpus in the series: entries are frozen with provenance, replay byte-identically, and change only at an edition. A change to any encoding of this document — a punctuation move, a statement rewording, a marker change — produces a model-version change and a new corpus generation, never a patch over frozen bytes.

The corpus covers, at minimum: every category in every format; the concise and absolute notations; the two interval kinds; optional fields present and absent; the unit expressible and not expressible; and every refusal vector of Annex C.

An implementation whose encodings differ from the corpus does not conform at the corpus’s model version. An implementation whose tree differs from the clause 5 model does not conform, whatever its encodings do. Disagreements between this document and the implementation are resolved by fixing one of the two and recording which moved.

This annex fixes the remaining details the clause 9 tables summarise: argument orders, statement texts, spelling tables and the marker grammar. The encodings here are normative to the byte for the fixed parts (call names, punctuation, marker strings); the numbers are verbatim by clause 8.

Omitted optional arguments do not leave empty positions: uexp(10.3, 0.5, 2) is the encoding of an expanded node without probability, and ucov(10.3, 9.9, 10.7, shortest) of an interval without one.

Statements appear in the order kind, factor, probability. The kind statement appears only for the interval category, the factor statement only for the expanded category, the probability statement for either when the field is present.

The AsciiMath respelling exists because - reads as minus there. Every other surface uses the full model name.

The concise digit string is computed from the magnitude’s text: remove the decimal point, remove the leading zeros of the result. An empty result renders as 0.

The :concise qualifier appears only on the standard marker, the :kind qualifier only on the coverage-interval marker. Where the enclosing format shows marker arguments, they are the numbers in the call argument order of this annex, comma-separated without spaces.

Carrying uncertainty as an arithmetic property that propagates through every operator automatically (the design of Python’s uncertainties package, where ufloat(10.3, 0.2) * 2 yields a value with a propagated uncertainty) was rejected. Plurimath’s tree is a formula tree, not an evaluation graph: propagation happens in evaluation (document 1004), on demand, with the GUM rules applied where the author asked for them. Attaching propagation to the node would force every rendering to be an evaluation and would give reported results and computed results different semantics in the same tree.

Wolfram’s Around[10.3, 0.2] renders 10.3 ± 0.2 and reads back symmetrically. The ± form was rejected as the model’s carrier because it is ambiguous between the standard-uncertainty reading (± one standard uncertainty, the GUM convention) and the expanded reading (± U with a coverage factor) — the ambiguity the GUM itself warns about when the form is used without qualification. The ± shape remains a rendering of the expanded category, never the carrier.

Accepting 10.3(2) as an input shorthand everywhere was rejected: the concise rule needs the value’s decimal-place count, and a reader that accepts it must silently reconstruct the magnitude — a transformation that belongs to a defined reading contract, not to every surface. The concise form is a reporting form the AsciiMath encoding emits and the AsciiMath reader of document 1003 reads under its stated rule.

The AsciiMath-style +- infix was rejected outright: 3+-1 is genuinely ambiguous, and the node model has no operation it could denote. The ± character is output-only, inside the encodings of clause 9.

Encoding uncertainties as format-native layout per format (say, OMML phantom boxes that simulate reporting forms without any marker) was rejected: the semantics would live nowhere machine-readably. Every format’s encoding carries the marker where the format has any machine-readable channel at all (intent in MathML and UnicodeMath, the marker run in OMML, the call in AsciiMath).

The GUM family gives exactly three reported shapes: the standard uncertainty (one number), the expanded uncertainty (magnitude with a factor and optionally a probability), and the coverage interval (endpoints with a kind and optionally a probability). A fourth category — “coverage factor with asymmetric magnitudes”, say — would need a shape no encoding defines and a semantics no JCGM document states; when such a category appears in practice, this document gains it at an edition, with its fields, its encodings and its corpus, rather than by stretching an existing one.

A stricter design would carry only absolute magnitudes and let writers choose the reporting form. The concise notation is carried because the reporting form is part of how the author reported the result: 10.3(2) and 10.3(0.2) are the same measurement but not the same document. The model carries the distinction; the encodings honour it.

The k and p statements of the LaTeX and HTML encodings could be typeset as subscripts or marginal notes. Statements were chosen because they round-trip: a subscript would need parsing conventions in every reader to recover k and p, while the statement text is recoverable by the readers of document 1003 from the fixed statement grammar of this document’s encodings.

A cleaner-looking alternative to the OMML marker run and the UnicodeMath wrapper is a “profile” convention: publish per-format stylesheets that recognise uncertainty shapes by their layout. Rejected: layout recognition is ambiguous exactly where the shapes overlap ((v ± m) is a legitimate ordinary expression), and a profile makes every consumer trust typesetting for semantics. The marker is explicit, travels inside the document, and needs no stylesheet.

ustd, uexp and ucov name the category in the AsciiMath encoding itself. A single call with a category argument (unc(std, 10.3, 0.2)) was rejected: the three forms differ in arity and argument meaning, so the argument list is only interpretable once the category is known — putting the category in the name keeps every call self-describing and keeps the concise reporting form a natural special case rather than a branch.

One vector per validation rule, so the corpus pins every refusal message.

The author reports: “the length is 500.0 mm with standard uncertainty 0.5 mm”.

The node: category standard, value 500.0, magnitude 0.5, notation absolute, unit the UnitsML embedding of mm.

The encodings:

Reading the AsciiMath encoding back yields the node. The trailing zero of 500.0 is present in every encoding and in the read-back node.

The author reports: “the mass difference is 10.3 g, U = 0.5 g (k = 2, p = 95%)”.

The node: category expanded, value 10.3, magnitude 0.5, coverage factor 2, coverage probability 0.95, unit g.

The encodings:

Dropping the probability from the report drops the p argument and the (p = 0.95) statement everywhere; no empty positions remain.

The author reports: “10.3 g, 95 % coverage interval [9.9, 10.7], shortest interval (JCGM 101 §9)”.

The node: category coverage-interval, value 10.3, lower 9.9, upper 10.7, interval kind shortest, coverage probability 0.95, unit g.

The encodings:

The same result with the probabilistically symmetric kind changes three things and nothing else: the AsciiMath kind spells symmetric, the markers and kind statements spell probabilistically-symmetric, and the model’s interval_kind field reads back as probabilistically-symmetric from every lossless encoding.

• The category, the kind and the notation travel through every encoding that can carry them, and the shapes differ across categories in every format.

• The numbers are verbatim everywhere; nothing normalises, rounds or reorders digits.

• The unit appears exactly once per encoding, in the channel that format uses for units.

• Round trips recover the node, not an approximation of it.