A.19:5.1 - U.CharacteristicSpace

A.19:5.1 - `U.CharacteristicSpace`

A.19:5.1.1 - Type signature

Each slot i names one U.Characteristic and one chosen Scale:

slot_i = (Characteristic_i, Scale_i).

The Characteristic supplies its subject/input signature: the entity kinds and roles required when it is assigned a value. For a relation Characteristic the signature also gives the role order, or states that the relation is symmetric. A use of the slot binds that participant tuple separately. The tuple is not the Coordinate; the Coordinate is a value on the chosen Scale. C.16 uses the same separation between measurand or subject tuple and measured Coordinate.

The CharacteristicSpace is the Cartesian product of the slots’ genuine Scale value sets:

CS = product_i ValueSet(Scale_i).

A point x in CS supplies one Coordinate x(i) from ValueSet(Scale_i) for every slot. Using that point for a subject separately binds a conforming subject/input tuple b_i and states or evaluates the characteristic assignment between b_i and x(i). For example, the distance Characteristic may bind (Machine-A, Machine-B) while its Coordinate is 3.5 m.

A complete state is total over the selected basis. An observation or evaluation input may instead be partial: it supplies Coordinates only for a subset of slots and records missing, censored, unknown, or another observation status separately. A consumer applies its own applicability and tri-state or error rule before treating such input as a state. not-applicable is normally an applicability fact, not a Scale value; a domain may use it as a genuine value only when the Scale explicitly defines that meaning.

Any U.Dynamics.stateSpace refers to a declared CharacteristicSpace. The dynamics model states the constraints selecting its admitted states within that product, and its trajectories use points satisfying the applicable state constraints. A.3.3.CC constructs the configuration description; A.3.3 supplies additional state information, the dynamic law, time base, observation relation and prediction-use conditions.

A.19:5.1.2 - Slot discipline (invariants)

To ensure consistency and comparability, a CharacteristicSpace must obey the following invariants:

A19-CS-1 (Exactly one per slot). Each slot binds exactly one Characteristic to exactly one Scale (including a specific Unit or kind, if applicable). This mirrors the CSLC clause of “one aspect – one scale”: there are no ambiguous or compound mappings in a single slot. (If a Characteristic can be measured on multiple scales, only one is chosen for a given space; others would require separate slots or a different space.)
A19-CS-2 (Named basis). A CharacteristicSpace declaration contains an ordered basis of slots. Each slot has a stable technical name and makes its Characteristic, Scale, position, and the Characteristic’s subject/input signature recoverable. Plain-language aliases may aid recognition but do not change the basis.
A19-CS-3 (Stable meaning). Do not silently change a slot’s Characteristic, Scale, or position while claiming the same space. Declare the changed space and an explicit mapping from the earlier space. Call that mapping an embedding only when it is point-injective and preserves every named structure; use a lossy normalization or projection for deliberate coarse-graining.
A19-CS-4 (Arity preservation). A slot for an entity Characteristic binds one subject. A slot for a relation Characteristic binds the exact ordered or unordered subject/input tuple required by that Characteristic. Direction and symmetry belong to this signature. In either case the Coordinate remains one value on the declared Scale; the participant tuple never substitutes for it.
A19-CS-5 (No hidden normalization, preference, or aggregation). A CharacteristicSpace carries no implicit normalization, polarity preference, threshold, formula, or aggregation. A CharacteristicSpacePredicate may declare polarity, operator semantics, and a cut or band over that space. Normalizing, indicatorizing, scoring, folding, comparing, and selecting remain explicit operations under their subject patterns. A.19.UNM governs normalization semantics and admissibility; C.16 governs relied-on measurement and calibration claims.
A19-CS-6 (Value and absence discipline). Each slot declares its admissible Scale domain. Missing, censored, unknown, and inapplicable input states stay with the observation, record, or evaluation use rather than entering the ontic Scale value set. not-applicable is a Scale value only when that domain explicitly gives it a subject-side meaning.
A19-CS-7 (Space-versus-consumer boundary). A CharacteristicSpace declaration contains only its basis, optional overlays, and typing hooks. A consumer separately declares references to the space, relation positions, source use, views, publication details, applicability, partial-input handling, and evaluation results.

A.19:5.1.3 - Minimal structure hooks (optional overlays)

A CharacteristicSpace has no default order, topology, or distance. Declare only the structure that a real use needs:

Order overlay. OrderOverlay = (D, preceq, laws, applicability), where D is a stated subset of CS, preceq is a typed binary relation on D, and laws say whether it is a preorder, partial order, or another named order. The declaration explains how the relation respects each participating Scale.
Topology overlay. TopologyOverlay = (D, tau, construction, applicability), where tau is a topology on D. The construction may cite a product topology or give another basis; the name alone supplies no continuity claim.
Distance overlay. DistanceOverlay = (D, d, distanceLaws, parameters, applicability), where d : D x D -> nonnegative values. distanceLaws states exactly which separation, symmetry, direction, and triangle conditions hold; parameters include any weights, units, normalization basis, and validity conditions.

The declaration of every overlay is optional. Once a consumer relies on one, however, it names the exact overlay and stays within its domain and applicability conditions; any claimed order preservation, continuity, convergence, sensitivity, robustness, or stability must satisfy the laws of that overlay. An overlay adds analysis structure and cannot redefine a slot’s Characteristic, Scale, admissible operations, or Coordinate meaning.

Here distance means a mathematical distance function, not a performance measure or a C.16 measurement method. Use U.DHCMethod for the measurement definition and U.DHCMethodRef to refer to it.

A.19:5.1.4 - Dynamics hook (typing only)

A U.Dynamics.stateSpace SHALL refer to a CharacteristicSpace that types its state values. The dynamics model declares the subset admitted by its constraints; when these depend on time or external conditions, that dependence remains part of the model. States and trajectories use points of the CharacteristicSpace satisfying those applicable constraints. Thus the product supplies coordinate meanings and the model supplies compatibility and change. A.3.3.CC constructs the configuration description, including implicit constraints or a parametrization. A.3.3 determines the additional information and transition law required for the prediction. A.19 supplies the space and applicable overlays without choosing that law or time base.

A.19:5.1.5 - Lexical discipline (Normative)

Use Characteristic, Scale, Level, Coordinate, CharacteristicSpace, slot, and basis for the objects defined here. Use “slot” or “basis element” for one component of the declared basis, and “Characteristic” for the measured or evaluated aspect. An explanatory alias must preserve that meaning. Mathematical uses of “axis” or “dimension” remain available when they denote their own declared mathematical objects rather than substitute ambiguously for a Characteristic or slot. A point is a tuple of Coordinates, not an alias for one Coordinate.

A.19:5.1.6 - Normalized values, classes and representative choice

Subject-pattern note. A.19.UNM governs the directed transformation, optional equality-of-output relation ≡_UNM and NormalizationFix. Cite the selected method instance, actual domain, target, preservation/loss basis and validity conditions when state-space reasoning uses that result.

For an equality, join, acceptance predicate or comparison, state which distinctions its answer requires. A directed normalization suffices when its declared preservation basis supports that answer. A many-to-one normalization requires the receiving query to be constant on its classes; otherwise retain the original distinction, refine the normalization or return the missing basis. Forming the set of classes does not prove an operation on them well defined.

If a state-space operation is inherited by classes, require compatible outputs and, for a partial operation, representative-independent availability under A.19.UNM. Cite a NormalizationFix only when an established class use needs a representative; choosing one does not restore the actual original state. Keep equality of labels separate from the claimed state or value equality.

A.19:5.1.7 - Overlay use, sensitivity, and calibration (Normative)

Use the weakest declared overlay that the argument needs. Declaring an order or distance does not make every predicate monotone, every map non-expansive, or either property necessary or sufficient for acceptance. Bands, target regions, and Boolean cuts are valid even when they are not isotone or continuous.

When a consumer makes a sensitivity, robustness, continuity, stability, or prediction-use claim, that consumer states:

the exact function, predicate evaluation, or transition map and the overlay it uses;
the domain, codomain, applicability conditions, and claimed property;
any bound, margin, approximation, uncertainty, or error allowance required by the consumer’s policy; and
the evidence or argument needed for that use.

A useful bound need not be Lipschitz <= 1; its admissible value comes from the named use and policy. Claim isotonicity only when the use depends on order preservation. Claim commutation with normalization only when that exact composition matters. C.16 governs relied-on measurement and calibration claims. A.3.3 governs prediction error, horizon, and model applicability; A.20, A.21, G.4, and the direct authority pattern govern their own constraint, gate, criterion, and decision consequences. Non-expansiveness or commutation alone grants no gate, release, assurance, or work authority.

A.19:5.1.8 - `CharacteristicSpacePredicate` (by-value)

A CharacteristicSpacePredicate is a typed unary predicate over one declared space:

P : D_P -> Boolean, where D_P is a declared subset of CS.

Its input variable denotes one state. The predicate declares which coordinates it reads and any projection used to obtain them. Its complete by-value meaning contains:

the exact CharacteristicSpace, input variable, domain, and coordinate projection;
each read Coordinate’s Scale and value interpretation;
any exact coordinate projection or A.19.UNM normalization instance used to obtain those inputs;
the operators, cuts, bands, regions, or unary subpredicates used in its Boolean expression; and
the polarity that says which outcome satisfies the predicate.

Conditions defined by thresholds, bands, and regions are unary predicates of this kind. Compose predicates with logical operators only after their input bindings and domains are aligned; otherwise give the composition an explicit binding that makes the conversion visible. A dominance or other comparison between two states is instead a typed binary comparison relation such as R : D_left x D_right -> Boolean, governed by A.19.CPM or another direct comparison pattern. Its comparator application and result are not components of a unary CharacteristicSpacePredicate. Use a genuinely n-ary predicate only when its full variable roles, domains, projections, and result type are declared.

An arbitrary condition relation is not automatically a state or Coordinate. A use binds either a direct characteristic assignment or an explicit governed projection from its subject/input tuple to the predicate input. When the affected entity differs from the condition participants, the consumer also states that direct relation. An F.9 Bridge relates two exact local senses; it is not this subject-to-input binding.

The predicate carries no applicability, assessment, observation, evidence, or evaluation window. A consumer separately binds the exact U.ClaimScope, relevant U.ContextSlice membership, effective reference scheme and plane, application or evaluation window, available input, and evaluation operation. An evaluation may return unknown, not-applicable, or error when input or applicability is unresolved; those consumer results do not enlarge the predicate’s Boolean codomain or the space’s Scale value sets. When asserting a particular performed evaluation as U.Work, establish its A.13 basis and then its independent A.15.1 admission; keep its operation application and result separate from the predicate.

Predicate identity changes when one of these semantic components changes. Wording, notation, carrier, publication, identifier, or description-edition changes alone do not create another predicate. A consumer may evaluate the same predicate in another scope or window, but may not silently change its space, projection, Scale, normalization, expression, cut, band, composition, or polarity. An obtaining semantic Bridge or plane relation may be cited by one consumer use without becoming part of predicate identity.

Minimally viable case. In a pump space with batteryVoltage on the volt Scale, batteryReady(x) := x.batteryVoltage >= 24 V is a unary predicate with Boolean result. A maintenance check separately binds Pump #37, its current measured input and window, and the evaluation result. Comparing two pumps by voltage would be a separate binary comparison relation, not a second reading of batteryReady.