This document specifies the pma notation:

• the design rules the notation is built under;

• the grammar surface and its token discipline;

• the constructors: unit, ustd, uexp, ucov, diff;

• the measured literals and their modifiers;

• quantity assertions and the static semantics they invoke;

• the rejected syntaxes, and what replaces each;

• materialization into the math model and the rendering relationships to AsciiMath;

• the artifact and runtime model;

• conformance.

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.

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

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.

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.

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.

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.

Everything in this notation follows from six rules:

1. Owned grammar. The reserved words are terminals of the grammar; the grammar is generated from the shared registry, and the artifact is checksummed. Plurimath owns the notation, so there are no shims to write and none to maintain.

2. Reserved-word safety. The build fails on any collision between a reserved word and any name in the registry’s symbol space or the UnitsDB symbol space. The failure happens at grammar generation — a collision never reaches a parser.

3. Explicit input. Values are typed explicitly: the constructors and literals carry their fields in their syntax. Reporting conventions — the concise form above all (PM 1002) — are output-only renderings, never input.

4. Strict errors. A malformed form is a parse error. There is no fallback-to-letters reading, no best-effort interpretation, no load-bearing whitespace trick.

5. No strings as syntax. The quoted-string channel is an AsciiMath device (PM 1005); this notation has none of it. unit(...) is unquoted — it is a constructor, and it can afford to be.

6. No conversion syntax. Converting a quantity is an operation evaluation performs (document 1004’s convert), not document syntax. A notation that converts inline is a calculator; pma is a notation.

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.

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.

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.

• The repetition, option and alternative operators are PARG’s (1*, [...], ordered /), as in the asciiunits artifact; the ordered choice makes the alternative order decisive, exactly as it is there.

• The as captures name the tree positions the materializer consumes: number, name, literal, magnitude, exponent, distribution, kind.

• The name rule’s table is generated as the identifier shape minus the reserved words — the generation-time subtraction, the same discipline the unit tables use, so a reserved word can never read as a name.

• @UnitsmlAscii.expression embeds the CalConnect 36817 grammar by reference at compile time; the unit expressions carry that grammar’s captures into the tree under the unit node.

• The test block is normative: the artifact’s conformance runs the accepts and rejects on every build, and this document’s vectors extend them.

• No quoted strings. There is no double-quote token; a quote anywhere is a lexical error (clause 10).

• No implicit multiplication. Adjacency is not an operator: 2x does not derive, and the test block rejects it. Multiplication is written *.

• No comments. A pma input is one expression; there is nothing to comment.

• No statement terminators or sequences. Edition 1’s input is one expression; sequences are an edition’s addition, with their separator.

• No subscript. The _ token does not exist; ^ is the power operator only.

What each derivation yields, for the materializer:

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.

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.

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).

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.

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.

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.

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.

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.

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.

(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.

+/- 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.

(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.

~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.

(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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.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.

+/- 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.

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.

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.

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.

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.

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

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

These exist only in pma:

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.

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.

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.

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.

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.

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.

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

1. the literal desugars: ustd(10.3, 0.2) unit(m);

2. the constructor parses with its arguments and trailing unit;

3. both materialise: two uncertainty nodes, categories standard and expanded, both metres;

4. the addition builds over them — syntax, not semantics: the tree states the sum;

5. rendering: every surface encodes both nodes per PM 1002; evaluation will answer the sum when it can, per its rules.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

1. the literal desugars to ustd(10.3, 0.2);

2. the trailing unit scopes both fields;

3. materialisation: one uncertainty node, category standard, value 10.3, magnitude 0.2, unit the metre.

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.

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

1. the relative magnitude computes at materialisation: exact decimal 0.05;

2. the record is the absolute form.

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.

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

1. the exponent shifts both: 38500 and 2300, digit movement only;

2. the desugared record is ustd(38500, 2300) unit(m).

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

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

1. the tag attaches to the literal: the uncertainty’s distribution family is the rectangular;

2. the node carries the tag as metadata; arithmetic is unchanged in this edition.

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.

unit(Bq)::frequency.

1. the assertion names the kind; the static semantics check the dimension;

2. the registry’s assignment for Bq is the becquerel’s own quantity — and the gating refuses the frequency claim.

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.

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

1. the constructor types the quantity as a difference;

2. the conversion to a kelvin difference is factor-only: 5 K of difference, no offset.

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.