#A.CHR-NORM — Canonical “Characteristic” & rename (Dimension/Axis → Characteristic)

Pattern A.17 · Stable Part A - Kernel Architecture Cluster

To have reproducibility and explainability there is a need to measure various aspects of systems or knowledge artifacts. A dedicated measurement backbone (see C.MM‑CHR, Measurement & Metrics Characterization) already exists, prescribing the CSLC discipline – i.e. define a Characteristic, choose a Scale (with a Unit if applicable), record a Level/Value, and thus obtain a Coordinate on that scale, optionally mapping to a Score via a ScoringMethod (USCM). However, historically multiple near-synonyms (“axis”, “dimension”, “property”, “feature”, "metric") have been used interchangeably for “what is being measured,” and often the aspect itself gets conflated with how it is expressed (units, ranges, labels). This pattern enters the FPF Kernel lexicon to canonize a single term for the measured aspect and enforce a clear separation between what is measured and how it is measured.

#Keywords

• characteristic
• measurement
• property
• attribute
• dimension
• axis.

#Relations

#Content

#Context

To have reproducibility and explainability there is a need to measure various aspects of systems or knowledge artifacts. A dedicated measurement backbone (see C.MM‑CHR, Measurement & Metrics Characterization) already exists, prescribing the CSLC discipline – i.e. define a Characteristic, choose a Scale (with a Unit if applicable), record a Level/Value, and thus obtain a Coordinate on that scale, optionally mapping to a Score via a ScoringMethod (USCM). However, historically multiple near-synonyms (“axis”, “dimension”, “property”, “feature”, "metric") have been used interchangeably for “what is being measured,” and often the aspect itself gets conflated with how it is expressed (units, ranges, labels). This pattern enters the FPF Kernel lexicon to canonize a single term for the measured aspect and enforce a clear separation between what is measured and how it is measured.

#Problem

When measurement concepts are not kept rigorously distinct, several issues arise:

• Polysemy at the anchor. Teams say “dimension” or “feature” but mean slightly different things, so the very trait being measured is ambiguous.

• Arity mistakes. A relational quality (e.g. similarity between two items) might be treated as if it were an intrinsic property of one item, or vice versa, leading to logical errors.

• Expression conflation. The aspect being measured is often mixed up with its expression – for example, using “scale” or “axis” to mean both the quality and its unit or range. This leads to unsafe arithmetic (averaging ordinal ranks, comparing raw numbers from incompatible scales, etc.) because values get interpreted out of context.

In summary, projects lacking a canonical terminology for metrics risk miscommunication and pseudo-quantitative operations. Measurements of physical quantities, architectural attributes, or performance scores end up on incommensurate rails due to inconsistent naming and handling.

#Forces

• F1 – Single anchor of meaning. Any numeric value is meaningless unless one can ask “value of what?”. The measurement’s meaning must be anchored in a single clearly named aspect.

• F2 – Arity clarity. Some characteristics apply to a single entity (e.g. its mass or length), while others inherently relate multiple entities (e.g. distance between two points, coupling between modules, agreement between judges). If arity isn’t explicit, claims and calculations become corrupted.

• F3 – Scale integrity. Different kinds of scales permit different operations – e.g. you can average temperatures (ratio scale) but not ranks or grades (ordinal scale) without losing meaning. If one mixes values without regard to scale type or units, the result is nonsense (pseudo-arithmetic).

• F4 – Composition discipline. In complex evaluations, multiple measurements may need to be combined. Without a disciplined approach, people might perform ad-hoc math on apples and oranges (adding scores from unrelated characteristics, etc.). A proper pattern must require any combination to go through a defined monotonic ScoringMethod (e.g. a weighted formula) instead of arbitrary aggregation.

• F5 – Transdisciplinarity. The measurement framework should work for any domain. The same conceptual scaffold must serve physical science (e.g. lab temperature readings), software engineering (e.g. module cohesion ratings), and even subjective assessments (e.g. figure-skating scores) without bias. One vocabulary, many CG‑frames.

• F6 – Open-endedness. As systems evolve, their performance or quality metrics also evolve. Rigid life-cycle stage labels (“Phase 1, Phase 2…”) don’t capture iterative improvement. The pattern should favor an open-ended state-space view (revisiting states via checklists, as in an RSG – RoleStateGraph with re-entry) over any fixed lifecycle with “terminal” stages.

#Solution

Establish “Characteristic” as the one canonical construct for “what is measured.” In every FPF context, the aspect or trait being measured MUST be referred to as a Characteristic. This term replaces “axis” or “dimension” in normative usage (those may appear only as explanatory aliases in Plain register). By fixing a single name and schema, we cleanly separate a Characteristic from its Scale (and Unit), and from any observed Value/Level on that scale. The solution also differentiates single-entity vs multi-entity cases and binds all measurements to the standard CSLC sequence.

To enforce this solution, the following rules apply:

• A17-R1 (Canonical term). In all normative models and specifications, the measured aspect SHALL be referred to as a Characteristic. (Legacy terms “Axis” or “Dimension” are retired from technical vocabulary – see Part J Lexicon Update.)

• A17-R2 (Entity vs. relation subtype). Each Characteristic MUST declare its intended arity. An Entity-Characteristic applies to exactly one bearer (e.g. Temperature of a reactor, Evolvability of a software module), whereas a Relation-Characteristic applies to an ordered tuple of two or more bearers (e.g. Distance between two sensors, Coupling between modules, Agreement among reviewers). The arity is part of the definition and must be explicit wherever it’s not obvious from naming.

• A17-R3 (Characteristic space). Any set of defined Characteristics spans a multi-dimensional CharacteristicSpace. Movement or evolution is then described as trajectories through this space (with states revisited or refined over time), rather than as a linear lifecycle through preset phases. This ensures measurements feed into open-ended state modeling rather than locking into “end states.”

• A17-R4 (Lexical guardrails). Normative text SHALL use only the canonical measurement terms: Characteristic, Scale, Level, Value, Coordinate, Score, Normalization, Unit. Synonyms like axis, dimension, metric, grade, property, etc., are forbidden in formal usage. (They may appear in narrative explanations or user-facing documentation only if clearly defined as aliases for the canonical terms.) Authors MUST not use deprecated terms in identifiers or formal statements, and any didactic alias should be introduced with an explicit mapping to the official term. These lexical rules uphold clarity and are further detailed in E.10 LEX‑BUNDLE.

• A17-R5 (Symbol policy). Γ reserved for holonic composition; 𝒢 : Coordinate→Score for metric‑level ScoringMethod; MUST NOT be conflated; documents SHALL NOT reuse Γ for ScoringMethod. If an ordered Scale is declared, polarity SHALL be fixed; 𝒢 MUST be monotone w.r.t. that polarity.

• A17-R6 (Declared polarity). Every ordered Scale SHALL declare one of: ↑‑better, ↓‑better, or non‑applicable (for purely nominal scales). For interval/ratio scales, polarity fixes the intended order of comparison.

• A17-R7 (Monotonicity against polarity). If a template declares an ordering polarity on its Scale (↑ better / ↓ better), then 𝒢 MUST be monotone w.r.t. that polarity: higher‑is‑better (resp. lower‑is‑better) in coordinates implies ≥ (resp. ≤) in scores.

• A17-R8 (Arity declaration). Authors SHALL mark a Characteristic as U.EntityCharacteristic (applies to exactly one bearer) or U.RelationCharacteristic (applies to a relation of cardinality ≥ 2). Examples: Cohesion → entity‑level; Coupling → relation‑level.

• A17-R9 (Relational scale anchors). For relation‑level cases, the Scale’s admissible values SHALL be defined over the tuple domain (e.g., distances, similarities, inter‑role latencies). Ambiguity that re‑reads a relational Characteristic as unary is forbidden.

• A17-R10 (Intension vs Description). The Characteristic remains the intensional object; any rubric, catalogue of levels, or examples are descriptions. Keep the intensional Characteristic distinct from its descriptive episteme (cf. U.Episteme roles: Object–Concept–Symbol).

#CharacteristicSpace & Change Reasoning (Normative/Clarifying)

R17 — CharacteristicSpace declaration. When an agent reasons about change, it SHALL name the CharacteristicSpace (the set of Characteristics, with Scales, units, and topology assumptions) in which motion is considered.

R18 — RSG framing, not lifecycle. Change narratives SHALL be framed as movement on a reachable‑states graph (RSG) with checklists that certify state acquisition; “lifecycle” staging is deprecated. (A.17 conforms to the open‑ended evolution stance of the Kernel.)

I7 — Vector interpretation. A U.Coordinate vector may collect multiple coordinates for multi‑Characteristic reasoning; composition into a single Score, if desired, is an explicit new 𝒢 on that vector.

#Archetypal Grounding (System & Episteme Examples)

In a physical system (U.System): Consider a Distance Characteristic defined for a pair of physical objects. For example, two machines in a factory have a Distance of 3.5 meters between them. Here Distance is a Relation-Characteristic (applies to the pair), with an associated Scale (e.g. a ratio scale in meters), and the measured 3.5 m is a Coordinate on that scale. If we instead look at an Engine Temperature Characteristic (unary), a particular engine might have a Temperature of 350 K at some moment – Temperature (the Characteristic) is clearly separated from how it’s measured (Scale in Kelvin) and the reading (350, a Coordinate on that scale).

In an epistemic context (U.Episteme): Consider a Formality Characteristic to rate a documentation artifact’s rigor. We might define an ordinal Scale with named Levels such as Informal, Semi-formal, Formal. A given specification document can then be said to have High Formality – meaning it occupies the “Formal” Level on the Formality Scale. Here Formality (Characteristic) captures what we measure about the document, while the tiered Scale (with qualitative levels) expresses how we categorize it. Because we use an ordinal scale, we can rank documents by Formality, but we would not average “Semi-formal” and “Formal” (avoiding meaningless arithmetic on an ordinal metric). In another knowledge context example, one could define a Characteristic Reliability for a knowledge source with a percentage Scale from 0 to 100%. An article’s reliability might be 85% – which is only interpretable by knowing it refers to “Reliability” on a 0–100% Scale (i.e. a specific Coordinate on that Characteristic’s scale).

#Bias-Annotation

This pattern is deliberately domain-neutral and introduces no bias toward any particular discipline or measurement type. By enforcing a uniform lexicon, A.17 actually mitigates bias: it prevents disciplinary jargon from creeping into core definitions (ensuring, for instance, that a software metric isn’t given a vague custom term when it’s fundamentally a Characteristic). The Didactic lens is strongly served: using one precise name per concept improves clarity for all audiences. There is a slight initial cost in re-labeling legacy terms (e.g. renaming “dimensions” to Characteristics), but this is offset by the long-term Cognitive Elegance (P‑1) – the framework becomes easier to learn and less prone to misinterpretation. No single domain’s terminology dominates, and the pattern explicitly supports both quantitative (physics-like) and qualitative (judgment-based) measurements, reflecting Pragmatic neutrality. The requirement of open-ended state-space thinking aligns with P‑10 (Open-Ended Evolution), ensuring we don’t bake in lifecycle biases that assume development must terminate at a final stage. In summary, A.17 imposes a disciplined vocabulary that is broad enough for all fields and free of hidden assumptions, thereby avoiding subtle ontological or cultural biases in the measurement model.

#Conformance Checklist

When authoring or reviewing FPF-compliant metrics, use the following checklist to ensure Characteristic normalization is applied:

1. Declared Characteristic: Have you explicitly named a Characteristic for each aspect being measured, instead of using generic terms? (e.g. use “Reliability” as a Characteristic name rather than saying “this dimension”).

2. Arity Explicit: Is it clear whether the Characteristic is unary or relational? If a metric involves a relationship, are the participating entities (pair, tuple, etc.) identified in its definition?

3. Separate Scale/Unit: For each Characteristic, have you defined the Scale (and Unit, if applicable) separately, rather than embedding units or ordinal terms in the name of the Characteristic? (e.g. “Length (m)” should be captured as Characteristic = Length, Unit = meter).

4. Scale-appropriate operations: Are you only performing comparisons or calculations that make sense for the declared scale type? (No averaging of ranks, no mixing of units – ensure ordinal Characteristics aren’t treated like numbers, and interval/ratio values respect zero and units.)

5. No implicit aggregation: If multiple measurement readings are combined, is there a defined ScoringMethod (with monotonic logic) that produces a Score? Avoid any ad-hoc “overall score” that simply adds or averages raw values from different Characteristics.

6. Canonical terminology in use: Are you using the terms Characteristic, Scale, Level/Value, Coordinate, Score, ScoringMethod, Unit in all formal descriptions? Confirm that no deprecated synonyms (axis, dimension, etc.) appear in technical content or identifiers (they can appear in Plain explanations only with proper reference to the canonical term).

7. Open-ended progression: (If applicable) When modeling progress or change using metrics, have you considered using a state-space of Characteristics rather than a fixed sequence of phases? This check is to encourage leveraging the open-ended nature of CharacteristicSpaces, especially in evolutionary or iterative processes.

(Failure to satisfy the above indicates a violation of this pattern’s intent. The LEX-BUNDLE rules in E.10 provide automated checks for term usage, and MM-CHR templates enforce explicit Characteristic/Scale definitions.)

#Consequences

By instituting Characteristic as the single term and enforcing the CSLC structure, this pattern yields several positive outcomes:

• Unambiguous metrics: Every measurement has a single, well-defined anchor of meaning – the Characteristic – eliminating guesswork about “what is this number about?”.

• Separation of concerns: We cleanly separate what is measured from how it’s represented. The Characteristic names the quality of interest, while the Scale/Unit defines the expression. A raw value now means nothing by itself – it must be read as “X units on the Y scale of Z Characteristic,” which greatly reduces misinterpretation.

• Unary vs. relational clarity: The explicit distinction between Entity-Characteristic and Relation-Characteristic ensures that relational properties (like “distance between A and B” or “consistency among experts”) aren’t mistakenly treated as inherent properties of a single object. This guards against logical errors and data modeling mistakes.

• Cross-domain comparability: All measurements, regardless of domain, follow the same CSLC rails. This means a temperature in Kelvin and a reliability score in percent can each be traced through Characteristic → Scale → Coordinate. They can’t be directly compared unless designed to be, which is good: any composite scoring must be done via an explicit SCP mapping to a common Score scale. The pattern thus enables interoperability (through well-defined Score bridges) while preventing illegitimate comparisons.

• Consistent evolution framing: By retiring the idea of a bespoke “lifecycle” for every process and instead viewing changes as movement in a CharacteristicSpace, the pattern aligns metric thinking with state-based reasoning (e.g. as used in dynamic models). There is no artificial “final state” for improvement – a system can always evolve to a new coordinate without violating a lifecycle Standard. This open-ended view encourages continuous improvement and refinement, echoing FPF’s emphasis on evolutionary development.

There are few downsides. One consequence is that modelers must learn the canonical terms and possibly refactor existing documentation (a short-term effort). Also, enforcing scale integrity means quick-and-dirty aggregate scores are not allowed unless justified via a SCP – this introduces a healthy “pause” to ensure composite metrics are well-founded. Overall, the benefits in clarity and correctness far outweigh the overhead. Teams gain a lingua franca for metrics, and the risk of metric abuse (mixing apples and oranges) is significantly reduced.

#Rationale

The Canonical Characteristic pattern is a direct response to recurring measurement pitfalls. By insisting on “one precise name per concept”, it upholds Strict Distinction (A.7), ensuring that the framework never treats two different ideas as one. For instance, earlier practice might label both a requirement category and its score as “dimension,” causing confusion; with A.17, the aspect is a Characteristic and its score is separate, so each idea has its place. This clarity is pedagogically vital (P‑2 Didactic Primacy): readers and contributors immediately know what a term means and how to interpret any value associated with it.

The solution also draws on fundamentals of measurement theory (Stevens’ levels of measurement) to prevent misuse. By encoding scale types and unit handling into our patterns, we avoid the “pseudo-quantitative” fallacies – no more averaging things like risk levels or adding up grades as if they were true numbers. In effect, A.17 puts a safeguard around P‑1 Cognitive Elegance and P‑7 Ontological Parsimony: we use a minimal, universal set of measurement constructs, and we avoid bloating the conceptual space with domain-specific or redundant terms. One canonical set of terms also makes the framework more teachable and composable across contexts, since patterns and projects aren’t inventing new synonyms that others must decipher.

Importantly, distinguishing Entity vs Relation Characteristics future-proofs the reasoning model. It enforces a modeling rigor seen in domains like physics (where properties vs. relations are carefully distinguished) and brings it to architecture and knowledge domains. This rigor supports advanced reasoning in FPF – for example, A.3.3 (Dynamics) can treat system state variables as a well-defined set of Characteristics, and assurance patterns can trace evidence metrics unambiguously to the exact aspect measured. It also means any attempt to compare or combine metrics has to be explicit (via ScoringMethods), which inherently improves transparency and auditability (a key FPF goal).

Finally, retiring the “lifecycle” vocabulary in favor of state-space trajectories aligns with FPF’s open-ended evolution principle. It acknowledges that improvement is not a predefined path but a navigable space. This shift in mindset (from lifecycle stages to checklisted state transitions) removes an implicit bias that systems ought to reach a “final” maturity stage – instead, it keeps the door open for perpetual refinement, which is philosophically aligned with continuous learning and adaptation.

In summary, A.17 is the linchpin that turns a loose collection of measurement practices into a coherent, principle-driven system. It rationalizes the language, thereby rationalizing thought: by speaking in one clear voice about measurements, FPF ensures that every number in the system can be trusted to answer “value of what, on what scale, relative to what context.” This rationale is reflected in improved model integrity and cross-domain trust in the meaning of metrics.

#Relations

• Builds on / Elaborates: FPF Core Measurement Schema (as outlined in C.16). A.17 lifts the metric template concepts from C.16 into a kernel-level rule. It also reinforces A.7 Strict Distinction, by giving each measurement concept a unique name and forbidding overloaded terms.

• Constrains: All other patterns that define or use metrics. For example, A.3.3 U.Dynamics (system dynamics) must name its state variables as Characteristics with proper scales (it cannot refer to them loosely as “KPIs” without context). Similarly, any service-level targets / SLO clauses (A.2.3 U.PromiseContent.acceptanceSpec) or assurance calculations (B.3, D.3 patterns) that involve measurements are governed by this canonical terminology (no unwarranted synonyms or unit confusion per ISO/IEC 80000, ISO/IEC 25024, QUDT, SOSA/SSN best practices). The pattern’s lexical rules are part of the LEX-BUNDLE (E.10) – any FPF-conformant context must adhere to these naming conventions.

• Coordinates with: A.18 (CSLC-KERNEL), which defines the minimal Characteristic/Scale/Level/Coordinate Standard in detail. A.17 provides the vocabulary and basic distinctions (what is a Characteristic, and its arity), while A.18 applies this to ensure each measurement template is well-formed. Also coordinates with C.KD-CAL and C.CHR-CAL (Knowledge Dynamics Calculus, Characterization Calculus) – those patterns use the Characteristic/Scale constructs to build domain-specific metrics (e.g. knowledge quality scores) and rely on A.17’s canon for consistency.

• Anticipates: E.10 Lexical Discipline rules – A.17’s enforcement of a single term and controlled aliases is a concrete instance of the lexical uniformity mandated in E.10. It also paves the way for F.7 Concept-Set Bridges in Unification patterns, since external ontologies for quantities (ISO 80000, QUDT, etc.) can be mapped cleanly onto FPF Characteristics now that the term is fixed. In short, A.17 is a foundational lexicon pattern that a) ensures internal consistency and b) simplifies alignment with external standards for measurable properties.

#A.17:End