FPF Reference

    A.19:5.2.2.1 Coordinatewise comparability (≼_coord)

    Preface node heading:a-19-5-2-2-1-coordinatewise-comparability-coord:23063

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    Two states can be compared coordinatewise only under strict conditions. Essentially, we require the states to be expressed in the same measurement space, with the same units and scales, and using the same state definitions. Formally, coordinatewise comparison is allowed only if all of the following hold:

    • Same space. The two holders’ state snapshots lie in the same CharacteristicSpace by value (and, if relevant, the same RCS attached to a Role in a given Context). It’s not enough that they have similarly named characteristics; they must share the actual defined space (same slots with same definitions).

    • Scale congruence. For each slot being compared, the scale type, unit, and polarity orientation are identical. For example, if comparing temperature readings, both must be on the same scale (say, °C on a ratio scale with “higher = hotter” orientation). No unit mismatches or differing interpretations can be present.

    • State-definition congruence. The states or status labels themselves must be defined in terms of the same checklist criteria applied in the same space. In other words, if we are comparing whether one system is “Ready” and another is “Ready”, both instances of “Ready” must derive from the same formal definition (same thresholds, same checklist logic) over those coordinates. If one context’s "Ready" means something different, you cannot assume they correspond.

    When these conditions are met, one can define a coordinatewise preorder over states. Common patterns include:

    • Dominance: For a given set of “higher is better” slots, we say state x ≼coord state y if and only if for every relevant slot a, the coordinate $a(x) \le a(y)$ (after orienting all slots to the declared polarity for that slot). In other words, y is as good or better on all enforced criteria. This defines a Pareto-like ordering (often partial, not total).

    • Threshold band inclusion: If states are defined by meeting certain thresholds (e.g. State Y means all metrics above specific levels), then we might say x ≼coord y if x meets every threshold that defines y’s state. For instance, if state y = “High Performance” requires speed > 100 and accuracy > 90%, then x is “no less than y” if x also exceeds those thresholds.

    By default, no comparability is assumed unless proven. If any of the above congruence conditions fails, one must not fall back to ad-hoc comparisons (like matching by name or normalizing without declaration). Either switch to a normalization-based regime or declare the states incomparable.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)