3.3.1. The evidence: representation is the root, kind is a leaf🔗

The quantity-value hierarchy is rooted in value representation, not in quantity kind. The most general value is TensorQuantityValue, a tensor of any order, and the specialization chain runs toward the scalar, each more specific type being a lower-order tensor — VectorQuantityValue :> TensorQuantityValue, then ScalarQuantityValue :> VectorQuantityValue (SysML v2, 2026-04 — Quantities.sysml, lines 17–46): \text{Scalar} \sqsubseteq \text{Vector} \sqsubseteq \text{Tensor}. So a scalar is a tensor of order 0 and a vector is a tensor of order 1. What a value's type primarily records is the apparatus of that representation:

• its tensor order,

• the split of that order into contravariant and covariant indices — the attributes contravariantOrder and covariantOrder on TensorQuantityValue, constrained to sum to the order (SysML v2, 2026-04 — Quantities.sysml, lines 33–36)

• whether a vector is bound or free, and

• a matching measurement reference (tensor / vector / scalar) carrying the coordinate frame and its transformations.

Each of these is a statement about how a quantity is measured, coordinatized, and valued, not about what kind of property it is. The contravariant/covariant split is the sharpest case of this representation-centric view — the one record-field that is unambiguously representational, on three escalating counts.

1. Pure coordinate bookkeeping. It records only how a value's components transform under a change of frame — nothing about what the quantity is. The other three fields each record a facet of the quantity itself:

   • tensor order tracks its mathematical character,

   • bound-versus-free is a genuine physical distinction (and one the library actually uses), and

   • the measurement reference names a dimension and a frame.

   The variance split alone carries no information about the quantity kind.

2. Not quantity-invariant. Using the metric to raise a covariant (lower) index or lower a contravariant (upper) one moves a unit between the two counts — say from contravariantOrder 2, covariantOrder 0 to a mixed 1 and 1 — while the order, and the physical quantity, stay fixed. That the quantity is unchanged is a fact of tensor algebra — the metric's raising/lowering isomorphism — not a SysML v2 statement: the library defines no raise- or lower-index operation, so it would record the two splits as distinct TensorQuantityValues with nothing to mark them as one quantity. A feature that a pure change of representation can move while the quantity is held fixed is thus a property of the representation, not of the quantity's kind. Hold the quantity fixed and the other three fields are pinned with it — order, bound-status, and reference do not change — so the variance split is the one field free to vary while the modeled quantity stays put (worked through just below).

3. Empirically inert. The split is declared on the abstract root and named by its constraint, yet assigned by no quantity anywhere in the library: even the genuine order-2 kinds — Cartesian3dStressTensor, with strain and moment of inertia alongside it — inherit the two slots and leave them unset, fixing only isBound, num, and mRef (SysML v2, 2026-04 — ISQMechanics.sysml, lines 730–746). The apparatus is carried at the root whether or not any kind exercises it. By contrast isBound is used (88 free against 7 bound), so the point is precise rather than blanket: bound-versus-free is live machinery, while the variance split is declared-but-unexercised overhead inherited from the tensor root.

To see why the second count bites — and what the model loses by it — follow the library's own machinery. Cartesian3dStressTensor stores its value as num: Real[9], nine bare reals, with the variance split left blank (same listing). In an orthonormal Cartesian frame that omission is harmless: under the Euclidean metric the contravariant components \sigma^{ij}, the mixed \sigma^i{}_j, and the covariant \sigma_{ij} are numerically equal, so it does not matter which the nine numbers are. But TensorCalculations::transform is defined to carry a tensor value from a source frame to a target frame through a CoordinateTransformation (SysML v2, 2026-04 — TensorCalculations.sysml, lines 45–49, MeasurementReferences.sysml, lines 126–135), and the transformation rule is keyed on the split: a contravariant index transforms by the Jacobian of the coordinate change, a covariant index by its inverse — mutually inverse rules, so the two generally yield different numbers. Move to a frame where they differ — any non-orthonormal frame, which is to say the everyday cylindrical, spherical, or material coordinates of continuum mechanics — and the nine numbers transform by different rules depending on a datum the model declared but never filled in.

What is missing, then, is the ability to transform an order-2 (or higher-order) quantity between frames at all: the transform contract cannot be met without the split, so for exactly the quantities where it would matter the operation is underdetermined. And the gap is silent. The concrete types are pinned to a Cartesian frame, where the omission never shows; the model type-checks and looks complete, and fails only where one would actually rely on it — in the curvilinear frames it was never exercised in. That is precisely a representational hole that validation cannot see: correct on every case anyone tested, wrong on the first case anyone needed.

The lone constraint the library attaches to the split sharpens the reading. orderSum requires contravariantOrder + covariantOrder == order (SysML v2, 2026-04 — Quantities.sysml, line 36). Metrologically it is a well-formedness invariant, not a statement about the quantity: it says only that the chosen split must be a valid partition of the quantity's actual order. Its content is that order is the frame-invariant datum and the split is a convention that must respect it — raising or lowering an index slides one unit between covariantOrder and contravariantOrder but holds their sum, the order, fixed. So orderSum is exactly what makes the same quantity, a different split formally coherent: the order — which carries the quantity's mathematical character — is conserved while the representation changes underneath it. It constrains nothing metrological: not dimension, unit, scale, or kind, only that the coordinate bookkeeping adds up. The one rule SysML v2 writes about variance is thus itself a pure-representation consistency check — the section's thesis in miniature.

The kind-of-quantity sits one level down, as a leaf, and the source is decisive on this point: there is no first-class "kind" entity. Length, mass, temperature, and the other base quantities are each declared as a subtype of the scalar value type — attribute def LengthValue :> ScalarQuantityValue — with the dimension carried only by the corresponding unit's quantityDimension, e.g. LengthUnit (SysML v2, 2026-04 — ISQBase.sysml, lines 16–38), and that quantityDimension attribute itself lives on ScalarMeasurementReference (SysML v2, 2026-04 — MeasurementReferences.sysml, lines 82–99). In other words, "length-the-kind" exists only as (i) a nominal subtype hanging beneath ScalarQuantityValue and (ii) a power-product of base quantities on its unit — never as a property whose nature is named in its own right. To reach a kind one must already have committed to a representation branch: the kind is nested under the representation. The proportions confirm the weight — across the ISQ library 319 kinds are declared on the scalar branch, against 2 vector, 4 tensor, and 51 fixed-three-vector kinds.

That places the concern precisely. A valued quantity has two independent classification axes:

• (A) kind-of-property — its nature, fixed by Dybkær's examination principle, common to all mutually comparable quantities;

• (B) value representation — scalar / vector / tensor order, coordinate frame, bound-versus-free — what SysML v2 packages as the measurement reference.

Dybkær's ontology lives entirely on axis (A) and is deliberately agnostic to (B): whether a position is recorded as one number, three Cartesian components, or a tensor in a chosen frame does not change what kind of property it is. SysML v2 makes axis (B) the root and nests (A) beneath it. The model even flags the departure from its own source: it quotes the VIM3 "quantity" Note 5 — "A quantity as defined here is a scalar. However, a vector or a tensor, the components of which are quantities, is also considered to be a quantity" — then notes that "the rest of [VIM] does not explicitly define how tensor and vector quantities can be or should be supported" (SysML v2, 2026-04 — MeasurementReferences.sysml, lines 29–31). The tensor-rooted hierarchy is thus SysML's own interpretation, and it inverts the VIM's priority — both the quoted VIM3 and the VIM4 2CD (quantity, 1.1 Note 4: "As defined here, quantities are scalar … vectors, and tensors are considered quantities in a broader sense if their components are (scalar) quantities") make the quantity fundamentally scalar, with vectors and tensors as composites of scalar quantities; SysML v2 makes the tensor primary and the scalar the degenerate order-0 case.

3.3.2. How PropertyKindCalculus takes the kind as root instead🔗

PropertyKindCalculus inverts the nesting: axis (A) is the root. A kind-of-property is a first-class value (KindOfProperty), and a quantity is indexed by its kind — Quantity (k : KindOfProperty) — so the kind is fixed before, and independently of, any choice of how the value is recorded. Dimension is not the organizing principle but a forgetful functor \dim : \mathrm{Kind} \to \mathrm{Dimension} that certifies coherence without deciding what is allowed (developed in the next section). Two consequences fall out directly: two kinds that share a dimension remain distinct types — so the dimension-1 disambiguation is expressible — and an operation across kinds is a type error rather than a silent success. Value representation — the axis SysML v2 puts at the root — sits here as an orthogonal index over the kind, never a layer the kind hangs beneath: R20's InFrame f var k R adds the frame and the variance above a Quantity k R whose kind was already fixed without reference to either.

3.3.3. The two designs side by side🔗

The table is honest in both directions: SysML v2's representation-first design buys real, first-class machinery for coordinate frames, transformations, and stress and strain tensors that systems engineering genuinely needs. R20 supplies the Cartesian part of it — frames, the three variances, the scalar product and its invariance — while curvilinear coordinates and the covariant/contravariant split remain machinery PropertyKindCalculus does not yet have. The claim is not that one model is right; it is that the axes are orthogonal and should not be nested, and R20 is that claim carried out rather than asserted: the frame index sits over a kind that was fixed without it.

3.3.4. Limitations of the SysML v2 approach🔗

Rooting the hierarchy in representation has three consequences that bear directly on PropertyKindCalculus's problem statement:

1. A kind cannot be named without first choosing a representation, so one kind fragments. Position is a single kind-of-property, yet appears as CartesianPosition3dVector, CylindricalPosition3dVector, SphericalPosition3dVector, and PlanetaryPosition3dVector — individuated by coordinate frame, not by the nature of the property. The cylindrical and spherical forms even carry mixed-dimension components (a length and two angles), so the single documented "quantity dimension \mathrm{L^1}" does not survive its own representations (SysML v2, 2026-04 — ISQSpaceTime.sysml, lines 304–353).

2. The within-dimension conflation is left untouched. On the scalar branch the dimension is the only discriminator, so volumetric and gravimetric water content, relative permittivity, reflectivity, and emissivity remain indistinguishable — exactly the confusion that motivates PropertyKindCalculus. Putting representation at the root does nothing about it; the two are orthogonal.

3. The calculus is kind- and dimension-blind. Scalar addition is declared ScalarQuantityValue × ScalarQuantityValue → ScalarQuantityValue, so adding a length to a mass is well-typed; nothing gates an operation on agreeing kind or dimension (SysML v2, 2026-04 — QuantityCalculations.sysml, line 29).