General

This document is the sixth document of the Plurimath specifications series. It specifies pma: the notation Plurimath owns end to end, written for measured quantities and first-class features. Every token is reserved or registry-carried, every form is unambiguous, every error is strict, and nothing is sugar over another parser.

This document is a forward specification: the notation is specified here for implementation, and its first edition as an implemented surface is its first release. Until that release pma carries no compatibility obligation; from it, the surface is editioned and change-controlled like every notation in this series. The grammar is carried by a checksummed artifact generated from the shared registry (clause 13), in the artifact pattern the asciiunits content language established.

Documents in the series

Maintainers

This document is maintained by the Plurimath project at https://github.com/plurimath/plurimath.

1.1  General

This document specifies the pma notation:

This document does not specify: the model the notation materialises into (PM 1001), the uncertainty fields (PM 1002), the evaluation that will consume it (PM 1004), the units grammar behind unit(...) (CalConnect 36817), or the quantity semantics behind the assertions (CalConnect 36815 and 5) — each is referenced where it applies.

1.2  Relationship to the series

1.3  Audience

Implementers of pma, authors who will write it, and the maintainers of the registry and the artifacts it generates.

4.1  General

pma text is shown verbatim; the canonical ASCII form is normative and the ± spelling is its fenced sugar. Trees are named in the model terms of PM 1001. The ± character is U+00B1.

4.2  Examples

Examples carry an Expected outcome paragraph. Where an example shows a refusal, the outcome names the error class per PM 1003’s Annex A and the message shape this document fixes.

4.3  Forward-specification status

This document specifies the notation for implementation. Rules stated here are the specification the implementation follows; until first release, an implementation gap is a defect of the implementation against this document, not of the document.

4.4  The artifact references

Where a clause says the grammar carries a form, the artifact is the carrier: this document states the form, the artifact makes it runnable, and the two are checked against each other in the build. References to CalConnect 36817’s grammar are by content, not by copy — the unit grammar appears once, in its own series, and both notations point at it.

5.1  The six rules

Everything in this notation follows from six rules:

5.2  What the rules buy

The rules are why pma errors can be exact. A reader that owns its tokens knows every input is either one of its forms or an error; there is no third case where a spelling might be legacy content. PM 1003’s typed errors become exhaustive here: every refusal names a rule of this document, and every acceptance materialises a tree the model fully defines.

5.3  The rules against the features

Each feature exists because a rule allows it, and each rule kills a class of mistakes:

The table is this document in miniature: the clauses that follow are the features, and every one of them sits inside a rule.

6.1  General

The grammar of pma is stated here in full, in PARG — the grammar language of the asciiunits artifact pattern (CalConnect 36817) — as the normative source the pma artifact generates from. A developer implements the reader from this grammar, the materialization rules of clauses 7 and 8, and nothing else: every input is derivable to exactly one tree, or refused by exactly one error.

The unit expressions inside unit(...) are not re-stated here: the rule references the CalConnect 36817 grammar (the UnitsmlAscii artifact), embedded by reference at compile time — one unit grammar, two notations.

6.2  The grammar

# The pma grammar: arithmetic core, measurement constructors, measured
# literals, quantity assertions. Edition 1. Generated into the pma
# artifact; reserved words are checked against the registry's symbol
# space and the UnitsDB symbol space at generation time.

grammar Pma version "0.1.0" edition 1 {

  # lexical terminals
  ws = %x09 / %x0A / %x0B / %x0C / %x0D / %x20
  spaces = 1*ws
  digit = %x30-39
  digits = 1*digit
  lparen = "("
  rparen = ")"
  comma = ","
  plus = "+"
  minus = "-"
  star = "*"
  slash = "/"
  caret = "^"
  percent = "%"
  e_mark = "e"
  tilde = "~"
  colon_colon = "::"
  plus_slash_minus = "+/-"
  plusminus = "±"
  equals = "="
  not_equals = "!="
  lt = "<"
  le = "<="
  gt = ">"
  ge = ">="

  number = (["-"] digits ["." digits]) as number

  # names: identifiers for evaluation bindings. The name table is
  # generated as the identifier shape minus the reserved words — the
  # same generation-time subtraction the unit tables use.
  letter = %x41-5A / %x61-7A
  underscore = "_"
  name = (letter 1*(letter / digit / underscore)) as name

  # the reserved words: checked against registry ∪ unitsdb at generation
  reserved_unit = "unit"
  reserved_ustd = "ustd"
  reserved_uexp = "uexp"
  reserved_ucov = "ucov"
  reserved_diff = "diff"

  # distribution tags: the closed set
  tag_name = ("rect" / "tri" / "u") as distribution

  # unit expressions: the CalConnect 36817 grammar, embedded by reference
  unit_expression = @UnitsmlAscii.expression

  kind_name = from_table "kinds" column "name" as kind

  # ---- expressions ----

  expression = relation

  relation = additive [ (equals / not_equals / lt / le / gt / ge) additive ]

  additive = multiplicative 1*((plus / minus) multiplicative)

  multiplicative = unary 1*((star / slash / keyword_mod) unary)
  keyword_mod = "mod"

  unary = [plus / minus] power

  power = primary [caret unary]

  primary = number / literal / constructor_call / name / (lparen expression rparen)

  # ---- measured literals ----

  literal = lparen number plus_slash_minus magnitude rparen [exponent] [tag] [trailing_unit] as literal
  literal_sugar = lparen number plusminus magnitude rparen [exponent] [tag] [trailing_unit] as literal
  magnitude = (number [percent]) as magnitude

  exponent = e_mark ["-"] digits as exponent
  tag = tilde tag_name as tag

  # ---- constructors ----

  constructor_call = ustd_call / uexp_call / ucov_call / diff_call / unit_call

  ustd_call = reserved_ustd lparen number comma [spaces] number rparen [trailing_unit]
  uexp_call = reserved_uexp lparen number comma [spaces] number comma [spaces] number [comma [spaces] number] rparen [trailing_unit]
  ucov_call = reserved_ucov lparen number comma [spaces] number comma [spaces] number [comma [spaces] number] comma [spaces] kind_name rparen [trailing_unit]
  diff_call = reserved_diff lparen expression rparen
  unit_call = reserved_unit lparen unit_expression [colon_colon kind_name] rparen

  trailing_unit = unit_call

  # ---- entry ----

  entry pma: expression

  test pma {
    accept "(10.3 +/- 0.2) unit(m)"
    accept "(10.3 +/- 2%) unit(m)"
    accept "(3.85 +/- 0.23)e4 unit(m)"
    accept "(0.5 +/- 0.01) ~rect unit(m)"
    accept "(10.3 ± 0.2) unit(m)"
    accept "ustd(10.3, 0.2) unit(m)"
    accept "uexp(10.0, 0.3, 2, 0.95) unit(cm)"
    accept "ucov(10.0, 9.7, 10.3, 0.95, shortest) unit(cm)"
    accept "ucov(10.0, 9.7, 10.3, probabilistically-symmetric)"
    accept "unit(kg m/s^2)"
    accept "unit(Bq)::frequency"
    accept "diff(5 unit(degC))"
    accept "x^2 + 1"
    accept "2 * (3 + 4)"
    reject "10.3(2)"
    reject "3+-1"
    reject "10.3 +/- 0.2"
    reject "(0.5 +/- 0.01) ~magic"
    reject "2x"
    reject "\"unitsml(g)\""
  }
}

6.3  Reading the grammar

6.4  What the grammar deliberately lacks

6.5  The tree, in one table

What each derivation yields, for the materializer:

6.6  Completeness, stated

The grammar derives every input this document’s clauses describe and nothing else. A form the clauses describe but the grammar does not derive is a defect in one of the two; a form the grammar derives but no clause describes is likewise. The test block, the vectors of Annex E, and the clause cross-checks are the mechanics of that statement — the statement itself is the standard this document is held to.

7.1  General

A constructor is atomic: keyword(args) with the argument list its table fixes, materialising one node. A malformed argument list is a parse error — there is no partial record, no default-filled form, no interpretation of what the author probably meant.

7.2  unit

unit(<expression>) carries one unit expression in the CalConnect 36817 grammar and materialises a Unitsml node (PM 1001). Alone it states a unit; following a value or a literal it scopes the unit of the whole quantity (the trailing-unit rule below).

7.3  ustd, uexp, ucov

The uncertainty constructors carry PM 1002’s categories with their argument orders:

Optional arguments are omitted without empty positions, as in AsciiMath. The kinds are shortest and probabilistically-symmetric — the full model names; AsciiMath’s symmetric respelling does not exist here, because this notation owns its tokens and has no minus-sign ambiguity to dodge.

The constructors validate through PM 1002’s rules at materialisation: field rules per category, the positive factor, the bounded probability, the exact decimals. A violation is a construction error naming the field — the same typed refusal the model defines, surfaced at parse time.

7.4  diff

diff(<quantity>) materialises its operand as a difference-typed quantity: the node structure of the operand with the difference typing of the quantity algebra (clause 12). The name diff is the register’s current choice; the register is the place a successor spelling (delta) would land, through the reserved-word process, never by overloading.

7.5  The trailing-unit rule

A unit(...) following a value or a measured literal scopes the unit of the entire quantity, uncertainty included: ustd(10.3, 0.2) unit(m) states a value of 10.3 m with a magnitude of 0.2 m — the magnitude is a difference in that unit (clause 12). The unit is stated once; nothing in the form repeats it per field.

7.6  The constructors against PM 1002’s rules

The uncertainty constructors do not restate PM 1002’s validation — they invoke it. The table maps each constructor’s refusal to the rule that refuses it:

The error shapes are this document’s, the rules are PM 1002’s, and the split is deliberate: one model, one validation, two notations surfacing it.

7.7  The trailing unit’s scope, precisely

ustd(10.3, 0.2) unit(m) — the unit scopes the value and the magnitude. uexp(10.0, 0.3, 2, 0.95) unit(cm) — the unit scopes value, magnitude and the interval the factor describes: everything in the record is centimetres. A form with two trailing units is a parse error: the scope is the whole quantity, stated once. A constructor whose operand already carries a unit takes no trailing unit — the scope is decided at the innermost statement, and re-stating it outside is ambiguous about what it would override.

7.8  The unit expression’s strictness

The expression inside unit(...) is the CalConnect 36817 grammar, and its strictness is that grammar’s: an expression the unit reader refuses is a parse error here naming the expression and the unit reader’s message. The channel-less design pays here — in AsciiMath the channel’s content was quoted data; here it is grammar, and the errors are parse errors with positions, not text-channel refusals.

8.1  The canonical form

(v +/- u) is the measured literal: value v, uncertainty magnitude u, category standard. +/- is one terminal — the canonical ASCII spelling — and the literal desugars to ustd(v, u) before materialisation. The parenthesised form is the literal’s whole shape; without the parentheses it is not a literal, it is arithmetic.

8.2  The relative form

+/- n% states the magnitude as a percentage of the value. The magnitude is computed at materialisation — exactly, per the decimal discipline, never at render or evaluation time — so the tree carries the absolute magnitude and the category, and every surface renders the same record. A percentage that does not produce an exact decimal at the value’s precision is a materialisation error naming both numbers.

8.3  The shared exponent

(3.85 +/- 0.23)e4 shifts value and magnitude by the same exponent: 38500 and 2300. The shift is exact — digit movement, no rounding — and the desugared record carries the shifted decimals. The exponent belongs to the literal, not to the unit: (3.85 +/- 0.23)e4 unit(m) states metres throughout.

8.4  The distribution tag

~name after a literal attaches the distribution family the uncertainty came from: a closed set grounded in the JCGM families (rect for the rectangular, tri for the triangular, u for the normal, and the set’s remaining members as PM 1002’s categories ground them). The tag rides the node as metadata; it changes no arithmetic in this edition, and evaluation (document 1004) will consume it when propagation arrives. A tag outside the closed set is a parse error naming the tag — the set is closed so that consumers can switch on it.

8.5  The ± sugar

(10.3 ± 0.2) is the canonical literal spelled with the fenced ±. It desugars identically; the sugar is fenced-only — the ± appears between the parenthesised literal’s value and magnitude and nowhere else. Outside a fence, ± is not a token of this notation at all: pm names the picometre in unit expressions, and the notation will not overload it.

8.6  What the literals are not

The concise reporting form of PM 1002 is not an input form here (clause 10); the literals carry absolute magnitudes, and the concise rendering of a standard category is a writer’s act. The literal is input-side syntax; the reporting form is output-side convention; the two meet only in the rendering surfaces.

8.7  The literal grammar, precisely

The literal is: (, the value, +/-, the magnitude, ), then in any order at most one shared exponent (e and an integer) and at most one distribution tag (~ and a tag name), then optionally the trailing unit. The relative form replaces the magnitude with an integer-or-decimal and %. Each modifier appears at most once; two exponents or two tags are parse errors. The desugar order is fixed: relative resolution, then the shared exponent shift, then the tag attachment, then the trailing unit — so (3.85 +/- 0.23)e4 and (0.5 +/- 0.01) ~rect compose unambiguously, and (3.85 +/- 0.23)e4 ~rect unit(m) is one literal carrying all three modifiers.

8.8  The desugar table

8.9  Why the desugar is normative

The desugar is the whole semantics of the sugar: a literal means exactly its desugared constructor shape, and nothing the surfaces do may distinguish a literal from its desugar. The corpus carries each row in both spellings, and a writer that renders the sugar form where the record was written canonically has not misbehaved — the record is the same — but the byte corpus freezes the canonical emission, because the canonical form is what the writer writes.

8.10  Refusals

9.1  The :: form

A unit expression followed by :: and a kind name asserts the quantity: unit(m/s2)::acceleration states that the expression denotes an acceleration. The kind names are the UnitsDB quantity kinds (CalConnect 36815); the assertion invokes the static semantics of CalConnect 36816 — the expression’s dimension must resolve to the kind’s dimension, and a mismatch is an error at materialisation, not at evaluation time.

9.2  What the assertion is for

The assertion settles what units leave ambiguous: Bq and Hz share a dimension and are different quantities; Sv and Gy likewise. An author who writes unit(Bq)::frequency has said something checkable — and the static semantics check it. An author who writes unit(Bq) without an assertion gets the registry’s primary quantity for the unit (the default), stated so the record is still complete.

9.3  Gating

The strict gating of CalConnect 36816 applies to assertions: an assertion that contradicts the registry’s quantity assignment for the unit refuses, and the refusals the units model defines (becquerel is not a hertz, sievert is not a gray) are materialisation errors here, exactly as they are conversion errors there. The notation does not carry its own quantity logic; it invokes the units model’s.

9.4  Assertions on literals

The trailing unit of a literal carries assertions like any unit expression: (10.3 +/- 0.2) unit(m)::length asserts the metre as a length — redundant with the registry’s default, checked anyway, and stated because the author preferred the record complete.

9.5  The assertion grammar, precisely

The assertion rides a unit expression at the positions a unit expression appears: inside unit(...), and on the trailing unit of a literal or constructor. unit(m/s2)::acceleration, (10.3 +/- 0.2) unit(m)::length, uexp(10.0, 0.3, 2, 0.95) unit(cm)::length — each states the kind of the quantity the unit denotes. An assertion on a bare unit(...) inside an arithmetic product states the product’s operand’s kind, and the static semantics check what the product then builds — the checks are the units model’s, at every position.

9.6  The kinds, named

Kind names are the UnitsDB quantity identifiers in their form: length, acceleration, activity, and the rest of the register. A name the register lacks is a materialisation error naming it — the kinds are data (PM 1001’s registry discipline), and this notation carries no kinds of its own.

9.7  Matched, gated, defaulted

The three assertion outcomes:

Every outcome leaves the record complete: an author either asserts, or the registry’s default is asserted on their behalf — a tree never carries a unit without a quantity statement.

10.1  General

Every rejected form is recorded with its replacement and its reason. The record is the decision: a proposal to admit one of these forms must argue with the reason, not rediscover it.

10.2  The concise form as input

10.3(2) is not an input form. The shape collides with the notation’s own arithmetic — a number followed by parentheses is multiplication or application territory — and accepting it would make the parser guess between a reported result and a product. The concise form is a reporting convention (PM 1002): writers emit it for the standard category, and the reporting-form reader of AsciiMath (PM 1005) is the input path that exists for it, with its decimal-places rule. pma, which owns its tokens, declines the ambiguity instead.

10.3  +- as the separator

+/- is one token; +- is two characters with a life of their own: 3+-1 is genuinely ambiguous between “three plus minus one” and “three, plus-or-minus one” — the reading the Python uncertainties heritage made famous. This notation resolves it by never offering it: the canonical separator is +/-, and +- is a parse error inside a literal.

10.4  Bare pm and the ± token outside fences

pm is the picometre — a unit token inside unit(...), never a separator. The ± character outside the fenced sugar is not a token: 10.3 ± 0.2 without the parentheses is a parse error, because an unfenced ± invites the same reading ambiguity the fenced form exists to close.

10.5  Conversion syntax

No form of pma converts: (10.3 +/- 0.2) unit(m) -> unit(ft) is not a notation, it is a wish. Conversion is convert(quantity, target) — an operation of evaluation (document 1004), with the conversion law, the exactness rules and the difference typing of the UnitsML series applied where they belong. A notation that converts inline drags those rules into its grammar; pma keeps its grammar a notation.

10.6  Why the record exists

Each rejection is a feature someone will ask for. The annex carries the full rationale (Annex C); this clause carries the rule: the rejected forms stay rejected until an edition argues them back in, with the corpus extended and the rationale answered.

10.7  The rejections at a glance

10.8  The one-line rule behind them all

pma separates input syntax from output convention and from evaluation operations, and refuses any form that blurs the lines. The concise form is output; conversion is evaluation; the separator is input and must be unambiguous. Every rejection in this document is one of those lines held.

11.1  Shared, unchanged

These parts of AsciiMath carry into pma with identical syntax and identical meaning:

11.2  Changed

These exist in AsciiMath under one spelling and in pma under another:

11.3  Added

These exist only in pma:

11.4  Removed — not carried in this edition

AsciiMath’s surface has four areas pma does not carry in this edition, stated so the boundary is exact:

The script tokens ^ and _ in pma belong to the arithmetic’s power operation only: x^2 is the power, and there is no subscript form in edition 1.

11.5  Lexical differences

11.6  Error differences

Both notations raise PM 1003’s typed errors. The differences: pma’s error set is exhaustive over its grammar (every input is derivable or named by one error — no legacy corner survives to be interpreted leniently), and pma carries no compatibility fallbacks by definition: AsciiMath’s reader honours its baseline’s leniencies where the baseline has them; pma’s reader honours none, because there is no baseline to honour. The practical consequence for implementers: the pma error table of clause 6 is complete, and conformance to it is testable edge to edge.

11.7  The MECE claim, stated

Every token of pma is either shared, changed, added, or removed by the tables above; every construct is derivable from clause 6’s grammar alone; every input is either derivable — to exactly one tree — or refused by exactly one error. This clause and clause 6 are the whole language; the remaining clauses explain it.

12.1  One tree

pma materialises into the one math model (PM 1001): the constructors into their nodes, the literals into desugared constructors, the arithmetic into the model’s operators. Nothing about pma survives into the tree — no syntax marker, no provenance flag — because every renderer and the evaluator consume the model, and a tree that remembered its notation would break that for everyone.

The consequence is the system’s economy: pma’s features render to every surface PM 1001 defines with no per-format work beyond the encodings those documents already define. An uncertainty written in pma renders in OMML through PM 1002’s marker convention exactly as one written in AsciiMath does.

12.2  Rendering into AsciiMath

Rendering a pma tree into AsciiMath emits the AsciiMath encodings: the uncertainty calls, the channel for units, the reporting form where the notation carries a concise node. The quoted channel is an AsciiMath device — a pma author never reads their own output through it as input, because pma’s own forms are native; the channel is what the AsciiMath side consumes.

Compatibility relationship. AsciiMath renders into pma natively: the shared tree is pma’s input vocabulary too, and an AsciiMath-read tree writes as pma through the shared constructors. The reverse — pma into AsciiMath — goes through the encodings, and the shared-exponent and tag forms of the literals render into the AsciiMath forms that exist for them.

12.3  The strict error surface

pma’s reader surfaces PM 1003’s typed errors with this document’s rules: parse errors from the grammar, construction errors from the model’s validation, and nothing else. Every error names its clause here. The error corpus of clause 14 freezes the shapes.

12.4  Materialization, worked

(10.3 +/- 0.2) unit(m) + uexp(4.1, 0.3, 2) unit(m):

Expected outcome. a tree that says exactly what was written, in the model’s terms, with the semantics pending in the documents that own them.

12.5  What materialisation refuses

The desugar’s exactness (the relative form’s product), the constructors’ field rules, the assertions’ gating, and the grammar’s strictness — each refusal is a named rule of this document or of PM 1002, at parse or materialisation time, before any tree escapes. A pma reader yields only complete records; the half-built forms the legacy notations tolerated do not exist here because the rules run before the tree does.

12.6  The two notations, side by side

The same measured statement in both notations, and what each promises:

The tree is the shared centre, which is why the table has one identical row: everything below the notation is common. The notations are front doors; the system behind them is one system.

12.7  The rendering relationship, precisely

A pma tree writes to AsciiMath through the encodings: the uncertainty calls, the channel, the reporting form where a concise node exists. The forms pma has that AsciiMath’s writer lacks — the distribution tags, the relative form — render into the encodings AsciiMath has (the tag as its statement, the relative as the computed absolute), because the tree carries the record, not the sugar. An AsciiMath tree writes to pma natively: the constructors are the AsciiMath encodings’ native shapes, and the round trip AsciiMath→tree→pma is lossless by the shared model.

12.8  Migration

The unreleased uncertainty call forms that earlier plurimath work prototyped migrate into pma unchanged in meaning: ustd(v, u) and kin keep their shapes and gain the strict errors, the trailing-unit scoping and the artifact discipline. Nothing released changes — the forms were never released — and the migration note lives here so the history is stated once.

13.1  The difference quantity

diff(5 unit(degC)) materialises a difference-typed quantity: the value five with the unit degree Celsius, typed as a difference — five degrees hotter than something, not five degrees above absolute zero. The typing is the quantity algebra’s (the invariants of the UnitsML series): differences are the values subtraction yields, and they convert factor-only, because offsets do not apply to them.

13.2  Where differences come from

Two roads: the diff(...) constructor states one directly; the subtraction of two absolute quantities of the same unit and quantity kind produces one. Both roads land in the same typing, and the arithmetic gating follows the units model: an absolute and a difference may combine in the ways the invariants define, and the model refuses the rest.

13.3  Why the constructor exists

The subtraction road needs two absolutes to make a difference; an author who starts from “the temperature rose by 5 degrees” has a difference and no base quantity to subtract. diff(...) states it without inventing a base, and the typing carries the statement — so the eventual conversion (diff in kelvin is the same five) and the eventual evaluation see the truth the author stated.

13.4  Differences and the literals

A literal’s magnitude is itself a difference — 0.2 m in (10.3 +/- 0.2) unit(m) is a difference quantity, which is why the trailing unit scopes it and why its conversion is factor-only. The trailing-unit rule and the difference typing meet in every literal: the rule states the unit once because both the value and the difference-in-that-unit share it.

13.5  The invariants, invoked

The quantity algebra’s invariants (the UnitsML series) govern what may combine with what: an absolute plus a difference yields an absolute, a difference plus a difference yields a difference, and the rest refuses. pma states these as materialisation-time checks where the operands are static, and leaves the dynamic cases to evaluation — the notation refuses what it can see, and the evaluator owns what it cannot.

14.1  The artifact pattern

The pma grammar is carried by a checksummed artifact, generated from the shared registry — the pattern the asciiunits content language established (CalConnect 36817): the grammar source lives with the registry, generation is deterministic, the artifact is committed with its checksum, and consumers verify the checksum before use. Artifact bytes are authoritative; nothing re-derives them at runtime.

14.2  The runtimes

The artifact serves every runtime in the artifact pattern: the Ruby reader first, and the TypeScript runtime from the same artifact. Byte-identical behaviour across runtimes is the pattern’s guarantee — the same artifact, the same parse, the same tree, the same errors — and the corpora of clause 14 pin it cross-runtime as they pin it across versions.

14.3  Editions

The notation is editioned from its first release. Before that release, this document is the specification and the surface may still move; after it, the surface changes only at an edition, per the change discipline of the series: new constructors and literals join through the reserved-word process, the corpus extends, and nothing published changes. The registry’s growth (PM 1001) flows into the unit expressions immediately — the unit grammar is the artifact’s, and its growth is that artifact’s editioning.

14.4  The artifact lifecycle

The lifecycle is the asciiunits pattern’s, and its guarantees transfer: the same checksum serves every runtime, a regenerated artifact that differs is a broken build, and the artifact a release names is the artifact forever.

14.5  The TS runtime and the shared corpora

The TypeScript runtime reads the same artifact and replays the same corpora; the cross-runtime class of clause 14 exists to make that a claim rather than a hope. The uncertainty, conversion and conformance sets of the testsuite run on both runtimes and their outputs compare byte for byte — the pattern’s end-to-end statement, checked.

15.1  General

Conformance to this document is the implementation of the pma reader per clauses 5 to 12, with the artifact discipline of clause 13. The claims follow PM 1003’s shape.

15.2  Conformance classes

15.3  The corpora

pma’s own corpus covers: every constructor with its argument orders and omissions; every literal form and its desugar; every assertion, matching and gated; every rejected form as a refusal vector; the difference forms; and the strict error table. The shared corpora — the uncertainty, conversion and conformance sets of the testsuite — pin the cross-runtime and cross-notation behaviour: a pma-written uncertainty and its AsciiMath-written twin render identically everywhere.

15.4  Claims

A claim names the artifact checksum and the corpus generation. An implementation against a moved artifact is a different claim; the discipline is the series’, and pma’s forward-specification status ends at its first release, when the first generation freezes.

16.1  The constructors’ composition

Constructors compose through the arithmetic: uexp(10.0, 0.3, 2, 0.95) unit(cm) + uexp(4.1, 0.2, 2) unit(cm) is an addition of two expanded uncertainties — valid syntax, materialised nodes, and an evaluation question (document 1004) rather than a notation question. The notation carries what the author stated; the evaluator answers what it means.

17.1  The register at this edition

17.2  The process

A reserved word joins the register through proposal, collision check, and edition: the collision check runs against the registry’s symbol space and the UnitsDB symbol space, and the word joins only if both are clean. The check is the build’s, not a reviewer’s memory. A word never leaves the register (editioned surfaces do not shrink), and a word’s role never changes — a new role is a new word.

17.3  Why the register is small

Six words and three tags is the whole surface, because pma’s features are composable rather than enumerable: the literals desugar to the constructors, the assertions ride the unit expressions, and the arithmetic is the model’s. A notation that needed a keyword per feature would be a command language; this one is a notation.

18.1  The concise form

The argument for accepting 10.3(2) as input: authors have results in that shape from reports, and re-typing them is friction. The argument against: the shape is the notation’s own application/multiplication territory, and the input that accepts it must choose between a reported result and a product on syntax that does not distinguish them. The resolution: the reporting form is an output convention of PM 1002 everywhere, and its input path exists where the ambiguity is resolvable — the AsciiMath reader, whose positional rule recovers the magnitude exactly. pma authors convert reported results once, into (10.3 +/- 0.2), and the conversion is data entry, not notation.

18.2  +-

One character of separation, and the reading collapses: 3+-1 is either 3 + (−1) or the literal. The uncertainties heritage chose the literal; the notation chooses the operators, because 3 + (-1) is already unambiguous and the literal already has a spelling. Two spellings for one form is the ambiguity budget spent twice.

18.3  Bare pm

pm is the picometre. A unit-bearing notation that also makes pm a separator has unit(5 pm) meaning two things, and the resolution cannot be syntactic. The ± character keeps the same rule outside fences: it appears exactly where the fence closes it, and nowhere else.

18.4  Conversion syntax

The arrow forms are attractive and wrong here: conversion carries exactness rules, difference typing and quantity gating — whole clauses of the UnitsML series. Inline conversion syntax would restate them as grammar, in a place the grammar cannot check. convert(q, target) is where those rules live; the notation stays a notation.

18.5  The general principle

A rejected form returns through an edition, with its corpus and its rationale answered — not through a reader that accepts it quietly. The refusals are the notation’s promises as much as its acceptances.

19.1  A measurement statement

(10.3 +/- 0.2) unit(m) — the canonical literal with its trailing unit.

Expected outcome. rendered to AsciiMath: ustd(10.3, 0.2) "unitsml(m)"; to LaTeX: 10.3(0.2) m; to every surface per PM 1002 — one statement, six encodings, no per-format authorship.

19.2  A relative statement

(5.0 +/- 1%) unit(V) — one percent of five volts.

Expected outcome. the tree carries magnitude 0.05; the surfaces render 5.0(0.05) V shapes; nothing recomputes the percentage at render or evaluation time.

19.3  A shared-exponent statement

(3.85 +/- 0.23)e4 unit(m).

Expected outcome. the exact decimals of the shifted form; no rounding anywhere in the shift.

19.4  A tagged statement

(0.5 +/- 0.01) ~rect unit(V).

Expected outcome. the tree with the tag; the surfaces render the tag where their encoding carries it (per PM 1002’s statements) and drop it as presentation where they do not.

19.5  An asserted unit

unit(Bq)::frequency.

Expected outcome. a materialisation error naming the gating: the becquerel is not a hertz, and the assertion said it was. unit(Bq)::activity — the kind the registry assigns — materialises with the assertion recorded.

19.6  A difference

diff(5 unit(degC)) — the temperature rise.

Expected outcome. the typed difference; the arithmetic that combines it with absolutes follows the invariants; the evaluation that converts it applies no offset — the typing carried the truth the author stated.

20.1  Constructor vectors (class read-pma)

20.2  Literal vectors (class read-pma)

20.3  Refusal vectors (class read-pma)

20.4  Assertion vectors (class read-pma)

20.5  Round-trip and cross-runtime vectors (classes roundtrip-pma, cross-runtime)