#Evaluation CharacteristicSpace Construction

A.19.ECS · Stable · Method pattern · Normative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Method pattern Status: Stable Normativity: Normative

Use A.19.ECS when an object version is to be improved or judged, but the evaluation that says what "better" means is not yet available, not yet explicit, or not yet adequate for the object.

#Relations

#Content

#Problem frame

Use A.19.ECS when an object version is to be improved or judged, but the evaluation that says what "better" means is not yet available, not yet explicit, or not yet adequate for the object.

A.19 says how a CharacteristicSpace is structured: declared characteristics, declared scales, slots, value sets, optional overlays, and no hidden normalization or aggregation. A.19.ECS says how to make such a CharacteristicSpace for the evaluated object, so that an evaluation can later read that object and E.23 can run an improvement loop without inventing values.

The ordinary output is an evaluation characteristic-space specification: a grouped set of characteristics, scales, value meanings, evidence rules, missingness rules, protected trade-offs, status meanings, and stop or reopen conditions for one evaluated object kind and use scope.

Not this pattern when. If a suitable evaluation already exists, cite it and use E.22 for question framing or E.23 for repeated improvement. Use A.17, A.18, and C.16 when the live problem is one characteristic, one scale, or measurement legality. Use C.16.P first when candidate coordinate wording still hides whether the live object is a characteristic, scale, coordinate, score, metric label, quality-term repair, or another receiving object. Use A.19 when the live problem is the structure of CharacteristicSpace itself. Use C.25 when the evaluated object is a composite engineering quality family that already fits Q-Bundle form. Use F.18 when the live problem is durable naming. Use E.21, E.9.DA, or E.2.DA when the object is respectively one FPF pattern version, one DRR, or one FPF-level Pillar-adequacy evaluated object.

First useful move. State the sentence: "good as what kind of object, for which use, against which contrast cases?" Then name the evaluated object kind, the use scope, and at least three contrast cases: one admissible evaluated object, one below-floor evaluated object, and one not-applicable object.

Cheap stop. If the answer is "use this existing evaluation" and the evaluated object kind, use scope, floor, protected trade-offs, and stop meanings are already recoverable, do not construct a new CharacteristicSpace.

What goes wrong if missed. A team says "improve this" and then chooses convenient scores. A scale set appears from nowhere. Chairs, coal plants, nuclear plants, and FPF patterns all get compared on coordinates that do not distinguish the evaluated object kind. One visible value improves while the intended use gets worse. A review can say "better" but cannot say which object property changed, what trade-off was protected, or why improvement may stop.

What this buys. A.19.ECS gives improvement work a way to create the missing evaluation before the loop starts. It keeps E.23 universal and simple: E.23 changes the object and asks an evaluation to re-read it; A.19.ECS helps build that evaluation when none is yet adequate.

Governed object in plain terms. The governed object is the construction of one evaluation CharacteristicSpace for one evaluated object kind and declared use.

Primary working reader. The first reader is the engineer, analyst, pattern author, reviewer, steward, or method designer who must define what counts as improvement for an evaluated object before running an improvement loop.

#Problem

FPF already has exact machinery for single characteristics, scales, coordinate readings, Q-Bundles, and repeated improvement. The gap is the construction of a useful grouped scale set for an evaluated object kind.

Recurring failures:

1. Scale set from air. An evaluation lists coordinates because they are familiar, not because they discriminate the evaluated object kind or use.
2. Wrong-kind comparison. Objects outside the declared kind are scored as if they were weak objects under improvement instead of being marked not applicable.
3. One-score collapse. Several independent characteristics are averaged into one score, hiding hard blockers and trade-offs.
4. Unstated polarity. Readers cannot tell which direction is preferred or when a value has no preferred direction.
5. No floor or exceptional meaning. Values are recorded, but nobody can say what is viable, exceptional, or still inadmissible for the declared use.
6. No evidence or missingness rule. A coordinate value is asserted without saying what observation, content locus, test, example, source, or judgment can justify it, or what absence means.
7. No protected trade-off. The evaluation encourages improvement on visible coordinates while damaging safety, usability, affordability, source preservation, entry cost, neighbour fit, or another value that should constrain the change.
8. No stop or reopen condition. Improvement continues forever or stops after a convenient checklist closure, not because the evaluation says the evaluated object has reached the declared aim.
9. Specification underdeclaration. A new evaluation is mentioned in prose, table, rule, or local rubric, but its declared specification does not make evaluated object kind, coordinate set, value meanings, status meanings, relations, and non-use boundaries recoverable.

#Forces

#Solution

Construct an evaluation CharacteristicSpace by declaring the evaluated object kind, use scope, contrast cases, characteristic slots, scale bindings, value meanings, evidence rules, protected trade-offs, status meanings, and stop or reopen conditions.

EvaluationCharacteristicSpaceSpec := <EvaluatedObjectKindRef, ObjectVersionUnderImprovementRef?, DeclaredUseScope, WorkingReaderScope, QualificationWindow, DiscriminatingCaseSet, ApplicabilityRule, CharacteristicSlotSet, ScaleBindingSet, PolarityAndPreferredMovement, FloorAndExceptionalMeaningSet, EvidenceAndMissingnessRule, ProtectedTradeoffSet, DominanceOrComparisonRule?, StatusValueSet, StopOrReopenCondition, NeighborPatternExitSet, E22QuestionFrameUse?, E23StartCondition>

#Local names and kind settlement

These names are local to this pattern. They do not mint kernel U.* kinds, measurement templates, gate states, evidence kinds, or release states.

#Construction moves

Use these moves when constructing or repairing an evaluation. They are not a mandatory work sequence; each move is a required content question whose answer must be recoverable before the evaluation is used for improvement.

1. Name the evaluated object kind and use. Say what object kind is being read and for which declared use. If the evaluated object kind is not recoverable, stop before choosing coordinates.
2. Build the discriminating cases. Include at least one evaluated object that should pass, one object of the same general family that should fail the floor, and one different object kind that should be not applicable rather than scored.
3. Choose candidate characteristics. Draw candidates from the object kind's real failure modes, first-principles structure, user or operator harms, domain tradition, current SoTA, existing evaluations, and exact FPF neighbours.
4. Bind each slot. For each candidate, state the characteristic, chosen scale, value set, admissible domain, missingness semantics, and whether the value is a measurement claim or an ordinal content reading.
5. Remove false coordinates. Drop coordinates that do not change admissible action, do not discriminate the evaluated object, duplicate another coordinate without a different repair move, or belong to another exact evaluation.
6. Split compound coordinates. If a coordinate mixes two repair moves, two object kinds, or two incompatible scales, split it or assign one part to the exact neighbouring pattern that governs it.
7. State preferred movement and trade-offs. For each active coordinate, state the preferred direction or explain why no simple direction exists. Name the protected trade-offs that must be checked when the coordinate improves.
8. Define floor, exceptional, status, and stop. State the viable-for-use floor, exceptional-for-use meaning, status values, and local stop or reopen condition.
9. Record neighbour exits. Name the exact FPF pattern that governs evidence, assurance, gate, work, decision, publication, naming, quality-bundle, measurement, OEE/NQD, or mathematical-lens claims when those become live.
10. Start E.23 only after evaluation values exist. A repeated improvement loop can start only when the evaluated object version and evaluation are recoverable enough for re-read.

#Evaluation specification minimum

A.19.ECS does not prescribe a publication or record form. It states which intensional objects must be recoverable before an evaluation characteristic space is reusable for judgement or improvement. The selected publication or record form may be an FPF pattern, local engineering standard, rubric, table, review form, model card section, protocol note, or project rule, but that form is not governed here. The evaluation characteristic-space specification must make these items recoverable by value:

This minimum is a content requirement, not a file-format requirement. For an FPF pattern publication form, E.8 still governs the authoring form. A.19.ECS only states what the evaluation must make recoverable so that E.22 can frame an improvement-oriented quality read and E.23 can run a repeated improvement loop.

#Discriminating-case test

An evaluation is not ready if it cannot distinguish these three outcomes:

1. Admissible evaluated object. The object is of the evaluated object kind and can meet or exceed the floor under the declared use.
2. Below-floor evaluated object. The object is of the evaluated object kind or a declared comparable family, but fails one or more floors.
3. Not-applicable object. The object is not of the evaluated object kind for this use and should not receive coordinate values except an explicit not-applicable status.

Example: for a nuclear-plant adequacy evaluation, a nuclear plant can vary along safety, output, maintenance, regulatory, thermal, waste-handling, grid, and resilience coordinates. A coal plant may be a power-generation alternative, but it is not a nuclear plant unless the declared use explicitly compares power-generation options across plant kinds. A chair or FPF pattern is not applicable as a nuclear plant; scoring it as "low nuclear plant quality" would show that the applicability rule is wrong.

#Scale-set improvement

The evaluation characteristic space itself can be improved. In that case, the evaluated object is the current EvaluationCharacteristicSpaceSpec version, not the original evaluated object.

Use E.23 for the repeated improvement method over the scale set when the improvement aim is live. The evaluation for that meta-level improvement may be:

• this pattern's conformance checklist for whether the scale set is constructible and usable;
• E.21 when the evaluation characteristic-space specification is itself an FPF pattern version;
• E.9.DA when the decision record selecting the scale set is the DRR decision-adequacy object being evaluated;
• E.2.DA when the scale set changes FPF-level Pillar adequacy;
• F.18 when the live problem is name choice for the scale-set heads;
• C.16, A.17, A.18, or A.19 when the live problem is measurement or characteristic-space legality.

Do not improve an evaluated object by silently changing its evaluation. If the evaluation changes, the loop record names the changed evaluation version and states whether earlier object-version readings remain comparable, need a bridge, or must be retired for the new use.

#Worked slices

Show, FPF pattern quality. The evaluated object kind is one FPF pattern version. The existing evaluation is E.21, so A.19.ECS stays closed unless E.21 itself is being redesigned. E.23 may improve the pattern version under E.21.

Show, DRR adequacy. The evaluated object kind is one DRR version for a declared campaign-decision use. The existing evaluation is E.9.DA. If a campaign needs a different DRR adequacy coordinate, A.19.ECS can test whether that coordinate belongs inside E.9.DA, another evaluation, or no current FPF pattern.

Show, FPF Pillar adequacy. The evaluated object is FPF as a corpus or release candidate. E.2 gives the Pillars; E.2.DA is the evaluation. A.19.ECS explains why E.2.DA needs evaluated object, use, eligibility, coordinates, evidence loci, stop meanings, and neighbour exits rather than a Pillar essay.

Show, name improvement. The evaluated object is a durable term candidate. F.18 already supplies a grouped lexical quality vector: SemanticFidelity, CognitiveErgonomics, MorphologicalActionFit, and AliasRisk, plus NQD discipline over candidate names. A.19.ECS treats F.18 as an existing local evaluation for naming, not as a reason to build another one.

Show, no evaluation yet. A team says "make this onboarding method better" but cannot say better for whom, by what values, or with what stop. A.19.ECS opens before E.23: it names evaluated object kind, user, use, contrast cases, candidate characteristics, scales, floors, missingness, protected trade-offs, and neighbour exits. Only then can E.22 frame an improvement-oriented quality read and E.23 improve the method.

#Conformance checklist

#Common anti-patterns

#Relations

#Consequences

A conforming A.19.ECS result lets E.22 ask a useful improvement-oriented quality-read question and lets E.23 run a repeated improvement loop without inventing values during the loop. It also gives object-specific evaluation patterns such as E.21, E.9.DA, E.2.DA, and F.18 a common construction shape: evaluated object kind, use, contrast cases, coordinates, value meanings, evidence and missingness rules, protected trade-offs, status meanings, and local stop or reopen condition.

The cost is intentional. A reusable evaluation is heavier than a local checklist, because it must prevent wrong-kind use, hidden value drift, proxy-for-value substitution, neighbour theft, and false stop claims. When a local rubric is enough, keep the rubric local. When reuse is needed, carry the evaluation by value.

#SoTA-Echoing

#Rationale

Improvement cannot be better than its evaluation. A loop that changes an object version without a declared characteristic space can only produce activity, persuasion, or reviewer preference. An evaluation that lists scales without evaluated-object-kind discrimination, floor, evidence, missingness, trade-offs, and stop meanings cannot guide improvement safely.

Placing this method under A.19 keeps the ontology clean. A.19 governs the structure of CharacteristicSpace; A.19.ECS governs the construction method for evaluations of declared object kinds and uses. A.19.ECS governs the intensional content of the evaluation characteristic space, not its publication or record form. An FPF pattern is only one possible publication form when the evaluation belongs in FPF; a local rubric, standard, table, or project rule is enough when the use is local. E.23 stays a universal loop method because it does not need to know how every domain chooses its scales. Domain and FPF-specific evaluations such as E.21, E.9.DA, E.2.DA, and F.18 keep coordinate choices inside those evaluations.

#A.19.ECS:End

---

Last Updated: 2026-05-29 — this section last modified in upstream FPF commit 2e112078 (github.com/ailev/FPF)