FPF Reference

    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

    A.19.ECSbuilds onA.CHR-NORM — Canonical “Characteristic” & rename (Dimension/Axis → Characteristic)
    A.19.ECSbuilds onCharacteristicSpace & Dynamics Hook (A.CHR-SPACE)
    A.19.ECSbuilds onMM-CHR — Measurement & Metrics Characterization
    A.19.ECSbuilds onLocal-First Unification Naming Protocol
    A.19.ECScoordinates withImprovement-Oriented Quality Evaluation Question Framing
    A.19.ECScoordinates withQuality Improvement Loop Method
    A.19.ECScoordinates withQ-Bundle: Authoring "-ilities" as Structured Quality Bundles
    A.19.ECScoordinates withFPF Pattern-Quality Evaluation CharacteristicSpace
    A.19.ECScoordinates withDRR Decision-Adequacy Evaluation CharacteristicSpace
    A.19.ECScoordinates withFPF Pillar-Adequacy Evaluation CharacteristicSpace
    A.19.ECScoordinates withEvaluation CharacteristicSpace FPF Pattern Publication Form
    A.19.ECScoordinates withOntology-First Plain Technical Rewriting
    A.19.ECSoutline parentCharacteristicSpace & Dynamics Hook (A.CHR-SPACE)
    A.19.ECSoutline next siblingState-Family Precision Restoration
    A.19.ECSexplicit referenceQuality Improvement Loop Method
    A.19.ECSexplicit referenceImprovement-Oriented Quality Evaluation Question Framing
    A.19.ECSexplicit referenceA.CHR-NORM — Canonical “Characteristic” & rename (Dimension/Axis → Characteristic)
    A.19.ECSexplicit referenceA.CSLC-KERNEL — Minimal CSLC in Kernel (Characteristic/Scale/Level/Coordinate)
    A.19.ECSexplicit referenceMM-CHR — Measurement & Metrics Characterization
    A.19.ECSexplicit referenceFPF Pattern-Quality Evaluation CharacteristicSpace
    A.19.ECSexplicit referenceDRR Decision-Adequacy Evaluation CharacteristicSpace
    A.19.ECSexplicit referenceFPF Pillar-Adequacy Evaluation CharacteristicSpace
    A.19.ECSexplicit referenceLocal-First Unification Naming Protocol
    A.19.ECSexplicit referenceCharacteristicSpace & Dynamics Hook (A.CHR-SPACE)
    A.19.ECSexplicit referenceThe Eleven Pillars
    A.19.ECSexplicit referenceCharacteristic and Scale Precision Restoration
    A.19.ECSexplicit referenceQuality-Term Precision Restoration
    A.19.ECSexplicit referenceUnified Lexical Rules for FPF
    A.19.ECSexplicit referenceRelational Precision Restoration (RPR) — Kind-Explicit Qualified Relation Discipline
    A.19.ECSexplicit referenceEpistemic Precision Restoration
    A.19.ECSexplicit referenceNQD‑CAL — Open‑Ended Search Calculus
    A.19.ECSexplicit referenceExplore–Exploit Governor (E/E‑LOG)
    A.19.ECSexplicit referenceMulti‑Method Dispatcher & MethodFamily Registry
    A.19.ECSexplicit referenceParity / Benchmark Harness
    A.19.ECSexplicit referenceTelemetry-Driven Refresh & Decay Orchestrator
    A.19.ECSexplicit referenceEvidence Graph Referring (C-4)
    A.19.ECSexplicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
    A.19.ECSexplicit referenceU.Flow.ConstraintValidity — Eulerian
    A.19.ECSexplicit referenceGateProfilization: OperationalGate(profile) (GateFit core)
    A.19.ECSexplicit referenceRole-Method-Work Alignment (Contextual Enactment)
    A.19.ECSexplicit referenceCreativity‑CHR — Characterising Generative Novelty & Value

    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, declared coordinate groups, 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 evaluate 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-basis rules, missingness rules, result-row shape, calibration points, coordinate-specific evidence payloads, 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 use under repair is a characteristic, scale, coordinate, score, metric label, quality-term repair, or governing-pattern relation. Use A.19 when the live problem is the structure of CharacteristicSpace itself. Use C.25 when the evaluated EntityOfConcern 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 evaluated EntityOfConcern is respectively one FPF pattern version, one DRR, or one FPF-level Pillar-adequacy evaluated EntityOfConcern.

    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 outside-declared-object-kind boundary case that should return to evaluation selection before the evaluation is opened or receive an explicit object-kind-fit defect/value when that evaluation has already been invoked.

    Existing-evaluation boundary. 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-evaluate it; A.19.ECS helps build that evaluation when none is yet adequate.

    Primary EntityOfConcern in plain terms. The primary EntityOfConcern 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 named patterns for single characteristics, scales, coordinate values, 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, or are silently skipped, instead of being returned to evaluation selection before opening or handled by an explicit object-kind-fit defect/value after opening.
    3. One-score collapse. Several independent characteristics are averaged into one score, hiding object-kind-fit defects 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.
    10. Result-form underdeclaration. The evaluation has coordinates, but the returned result can be a prose impression, a two-column value table, or a checklist count without evidence basis, adjacent-value rationale, calibration discipline, or coordinate-specific payload.
    11. Evidence-basis leakage. Evidence needed to justify the evaluation result, corpus projection, currentness, retrieval, or parity is written as if it were the evaluated object's own method or user action.

    Forces

    ForceTension
    evaluated-object-kind discrimination vs broad reuseThe evaluation must fit the evaluated object kind, but it should reuse existing FPF characteristic and scale discipline where possible.
    Small first version vs enough coordinatesA useful first evaluation can be compact, but it needs enough coordinates to block false improvement and wrong-kind comparison.
    Measurement legality vs ordinal judgmentSome coordinates are measured through C.16; others are evidence-backed ordinal content values. The evaluation must say which is which.
    Improvement direction vs trade-off protectionPreferred movement must be visible without turning every coordinate into an optimization command.
    Contrast cases vs overfittingContrast cases are needed to test the scale set, but the evaluation must not become a list of examples only.
    Reusable specification vs local useA reusable evaluation must make the same evaluation characteristic-space elements recoverable across uses. A local project can use a smaller specification when the use is bounded and non-reusable.
    Local stop vs open-ended improvementA loop may stop for the declared use while the object and the scale set remain improvable under new use, source, or comparison pressure.

    Solution

    Construct an evaluation CharacteristicSpace by declaring the evaluated object kind, use scope, contrast cases, characteristic slots, scale bindings, value meanings, evidence-basis and missingness rules, result-row shape, calibration points, coordinate-specific evidence payloads, protected trade-offs, status meanings, and stop or reopen conditions.

    EvaluationCharacteristicSpaceSpec := <EvaluatedObjectKindRef, ObjectVersionUnderImprovementRef?, DeclaredUseScope, WorkingReaderScope, QualificationWindow, DiscriminatingCaseSet, ObjectKindFitRule, CharacteristicSlotSet, ScaleBindingSet, PolarityAndPreferredMovement, FloorAndExceptionalMeaningSet, EvaluationEvidenceBasisRule, EvidenceAndMissingnessRule, ResultRowShape, AdjacentValueRationaleRule, CalibrationPointSet, CoordinateSpecificEvidencePayloadRule?, ProtectedTradeoffSet, DominanceOrComparisonRule?, StatusValueSet, StopOrReopenCondition, NeighborPatternExitSet, E22QuestionFrameUse?, E23StartCondition>

    Local names and kind settlement

    Local nameRoleNon-use boundary
    EvaluationCharacteristicSpaceSpecLocal specification for constructing one evaluation CharacteristicSpace.Not a score sheet, review packet, work plan, gate, evidence record, or project approval.
    EvaluatedObjectKindRefExact kind of object the evaluation evaluates.Not a vague artifact, file bundle, campaign, chat, or source collection.
    DeclaredUseScopeUse for which the evaluated object is being judged or improved.Not all possible uses.
    DiscriminatingCaseSetPositive, below-floor, and outside-declared-object-kind boundary cases used to test whether the characteristic space distinguishes the evaluated object kind and use.Not a substitute for the coordinate set.
    ObjectKindFitRuleRule for admissible evaluated object, below-floor evaluated object, and outside-declared-object-kind boundary case.Not permission to omit declared coordinates after an evaluation has been invoked.
    CharacteristicSlotSetThe grouped slots, each binding one characteristic to one scale.Not an arbitrary checklist and not hidden aggregation.
    ScaleBindingSetThe chosen scale and value meaning for each characteristic slot.Not a metric dashboard unless a distance or measurement claim is explicitly declared by the neighbour.
    PolarityAndPreferredMovementDirection of preferred movement for each coordinate, or a statement that the coordinate has no simple preferred direction.Not permission to optimize one coordinate while damaging protected trade-offs.
    FloorAndExceptionalMeaningSetViable-for-use and exceptional-for-use value meanings for declared coordinates.Not a maturity ladder and not proof that future improvement is impossible.
    EvaluationEvidenceBasisRuleThe checked evidence loci required for the result: object version, corpus/projection loci when corpus-facing, source-currentness loci when currentness is valued, comparator loci when parity is valued, worked-case loci when case coverage is valued, and missing or unchecked loci when they affect values.Not a separate "not evaluated" alternative, not permission to infer values from reputation, review state, or absence of visible defects, and not the evaluated object's own method or user action.
    EvidenceAndMissingnessRuleWhat justifies a value and how missing, censored, unknown, object-kind-fit, or boundary-return cases are handled.Not project evidence, assurance, or gate proof by itself.
    ResultRowShapeRequired result row fields for the evaluation, including coordinate, value, and a short rationale; some evaluations may add evidence-locus or payload fields.Not a free-form review paragraph and not a two-column coordinate/value table.
    AdjacentValueRationaleRuleRule that each result rationale says why the lower adjacent value would understate the evidence and why the higher adjacent value would overstate it, or for the top value what would lower or reopen the claim.Not verbosity for its own sake.
    CalibrationPointSetReusable 3/4/5 or equivalent adjacent-value calibration points for common evaluator disagreements.Not a second score system and not a shortcut around the declared scale.
    CoordinateSpecificEvidencePayloadRuleExtra payload that a coordinate needs when a category label can fake discharge: comparator plus selected ingredient plus current locus, source plus adopted payload plus currentness window, projection locus plus retrieval cue, or another payload named by value.Not administrative burden, not the evaluated object's method, and not live evaluated-object text unless the evaluated object itself is an evaluation result or projection carrier.
    ProtectedTradeoffSetQualities or neighbour claims that must be checked when visible coordinates improve.Not a hidden veto without a declared evaluation pattern or value meaning.
    PrecisionRepairKindRuleRule for checking pre-repair and post-repair evaluated object kind, characteristic kind, relation or claim kind, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope when coordinate wording or evaluation wording is repaired, with a governing-pattern reference when another pattern governs the kind under repair, relation, claim, or position.Not a lexical substitution table and not permission to change object kind or slot, relation position, use relation, or claim kind by cleaner wording.
    StatusValueSetLocal admissible-use result values for the evaluation.Not release state, gate status, or reviewer praise.
    E23StartConditionMinimum condition for using this evaluation inside E.23.Not the improvement loop itself.

    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 evaluated 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 return to evaluation selection before opening or receive an explicit object-kind-fit defect/value if this evaluation has already been invoked.
    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 FPF neighbouring patterns named by value.
    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 evaluation.
    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 neighboring pattern governing the claim that governs it.
    7. State preferred movement and trade-offs. For each declared 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 result form, evidence basis, and calibration. State the required result row shape, evidence basis, adjacent-value rationale rule, calibration points for common disagreements, and any coordinate-specific payload needed for high or floor-reaching values.
    9. Define floor, exceptional, status, and stop. State the viable-for-use floor, exceptional-for-use meaning, status values, and local stop or reopen condition.
    10. Record governing-neighbour relations. Name the FPF pattern that governs evidence, assurance, gate, work, decision, publication, naming, quality-bundle, measurement, OEE/NQD, or mathematical-lens claims when those become live. This is a declarative relation after the coordinate/value/evidence content, not route, receiver, owner, host, home, handoff, exit prose, "go there/not here" reference boilerplate, or architecture-placement rationale.
    11. Start E.23 only after evaluation values exist. A repeated improvement loop can start only when the evaluated object version, evidence basis, result form, and evaluation are recoverable enough for re-evaluation.

    Evaluation specification minimum

    A.19.ECS does not prescribe a publication or record form. It states which evaluation characteristic-space elements 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:

    Specification itemRequired content
    Evaluation problem frameEvaluated object kind, declared use, first useful move, existing-evaluation boundary, and what goes wrong if no evaluation exists.
    Non-use boundaryBoundaries to single-characteristic, measurement, Q-Bundle, naming, evidence, assurance, gate, work, decision, publication, and loop-method patterns.
    Local names and kind settlementLocal field names, role named by values, and non-use boundaries.
    Evaluation record shapeThe local record or bundle shape used by the evaluation.
    Object-kind fit ruleAdmissible evaluated object, below-floor evaluated object, and outside-declared-object-kind boundary handling before and after invocation.
    Evaluation evidence basisLoci named by value that must be checked or named when a value depends on object version, corpus projection, source currentness, mature comparator, worked case, retrieval, or other external evidence.
    Result-row shapeRequired result row fields, at minimum coordinate, value, and short rationale; any required evidence-locus or coordinate-specific payload fields are declared here.
    Coordinate setCoordinate heads, properties of the evaluated object, evaluated-object properties and use conditions, scale/value meanings, evidence loci, and protected trade-offs.
    Calibration and payload rulesAdjacent-value calibration points and coordinate-specific payloads that prevent impressionistic 3/4/5 assignment or category-list discharge.
    Status and stop conditionAdmissible-use statuses, local stop meanings, and reopen conditions.
    Worked slicesAt least one passing evaluated object, one below-floor evaluated object, and one outside-declared-object-kind boundary case.
    Common anti-patternsThe false interpretations or values the evaluation must block.
    Neighbouring-pattern claim assignmentNeighbouring FPF patterns named by value and the claims being made that each pattern governs.

    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 evaluation and E.23 can run a repeated improvement loop.

    When construction or repair changes coordinate wording or evaluation wording, the evaluation characteristic-space specification records PrecisionRepairKindRule or an equivalent result-row requirement. The check compares the pre-repair and post-repair evaluated object kind, characteristic kind, relation or claim kind, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope, and names the governing pattern when another pattern governs the kind under repair, relation, claim, or position. A cleaner phrase that changes those items, treats a coordinate position as an object kind, or loses the value's slot, relation position, use relation, or claim kind is a changed evaluation decision, not a wording repair.

    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. Outside-declared-object-kind boundary case. Before the evaluation is opened, the object should return to evaluation selection or construction rather than be treated as the evaluated object kind. If the evaluation has already been invoked for that object, the result is an explicit object-kind-fit defect/value or repair status, not omitted coordinates.

    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 only when the declared use explicitly compares power-generation options across plant kinds. A chair or FPF pattern is outside the nuclear-plant evaluated-object kind: before opening the evaluation it returns to a suitable evaluation; after a forced invocation, the record shows an object-kind-fit defect/value rather than pretending the chair has weak nuclear-plant quality or silently skipping coordinates.

    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 values 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 governing relations 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 governing relations. Only then can E.22 frame an improvement-oriented quality evaluation and E.23 improve the method.

    Conformance checklist

    CheckRequirementWhy
    CC-A19ECS-1An evaluation characteristic-space specification SHALL name evaluated object kind, use scope, reader scope, and qualification window.Prevents context-free quality claims.
    CC-A19ECS-2It SHALL include admissible, below-floor, and outside-declared-object-kind boundary contrast cases.Tests evaluated-object-kind discrimination.
    CC-A19ECS-3Each coordinate SHALL bind one characteristic to one scale or state why it is an ordinal content evaluation rather than a measurement claim.Preserves A.17/A.18/C.16/A.19 discipline.
    CC-A19ECS-4Each coordinate SHALL state value meanings, polarity or no-simple-direction value rule, evidence rule, and missingness rule.Makes values replayable.
    CC-A19ECS-5The specification SHALL state floor, exceptional, status, stop, and reopen meanings for the declared use.Lets improvement stop locally without claiming final perfection.
    CC-A19ECS-6Protected trade-offs SHALL be named when improving visible coordinates can harm another live value.Blocks Goodhart-style improvement.
    CC-A19ECS-7The specification SHALL not average ordinal coordinates or turn undeclared coordinates into hidden pass, waiver, or failure.Preserves non-scalar comparison.
    CC-A19ECS-8Wrong-kind objects SHALL return to evaluation selection before opening, or receive an explicit object-kind-fit defect/value when the evaluation has already been invoked.Keeps the declared coordinate table complete after invocation and prevents false low scores before the suitable evaluation is selected.
    CC-A19ECS-9If made reusable beyond one local use, the evaluation characteristic-space specification SHALL make the minimum items in A.19.ECS:4.3 recoverable by value. If the selected publication form is an FPF pattern, E.8 also applies to that publication form.Prevents underspecified evaluations.
    CC-A19ECS-10If the evaluation itself changes during improvement, the loop record SHALL name the changed evaluation version and the comparability effect on earlier object-version evaluations.Prevents silent value drift.
    CC-A19ECS-11The evaluation characteristic-space specification SHALL state any evidence, assurance, gate, work, decision, publication, naming, measurement, Q-Bundle, OEE/NQD, mathematical-lens, or related claim as a direct governing-pattern application or named relation by value when that claim is being made. The coordinate Solution carries the evaluation construction itself; reference apparatus, architecture-placement rationale, and coordination with another governing pattern stay in relations, rationale, source-basis, or decision-rationale material unless they change a coordinate.Prevents an evaluation from becoming a second ontology or reference apparatus.
    CC-A19ECS-12A reusable evaluation characteristic-space specification SHALL state what would lower, reopen, or retire the evaluation: missing contrast case, changed use, changed source-use relation or source-currentness status, hidden trade-off loss, or corrected neighbouring-pattern claim assignment.Makes high-value evaluation claims falsifiable instead of permanent praise.
    CC-A19ECS-13A reusable evaluation characteristic-space specification SHALL define the result-row shape and require a short rationale for every coordinate value.Prevents prose impressions and two-column tables from being mistaken for evaluation results.
    CC-A19ECS-14It SHALL define the evaluation evidence basis and any coordinate-specific evidence payload needed for source-currentness, comparator, corpus-projection, worked-case, retrieval, or external-currentness claims. Missing or unchecked evidence lowers the coordinate that needs it.Makes values replayable without creating an "inactive" or "not evaluated" escape route.
    CC-A19ECS-15It SHALL publish calibration points for common adjacent-value disagreements whenever the evaluation is expected to be reused by different evaluators.Keeps 3, 4, and 5 from drifting into reviewer temperament.
    CC-A19ECS-16It SHALL declare where result evidence, corpus-projection evidence, retrieval evidence, comparator evidence, currentness evidence, and quality-status evidence live. These payloads SHALL stay in the evaluation result, evidence basis, projection carrier, or selected publication carrier unless the evaluated object itself is that carrier. If the payload implies a user move for another evaluated object, publish that move or boundary, not the carrier proof. This is a role-based placement rule, not a lexical ban: evidence-role payloads do not enter live evaluated-object text merely because they are true or useful to developers, reviewers, or evaluators.Prevents evaluation evidence from leaking into the evaluated object's method or live text.
    CC-A19ECS-17If construction or repair changes coordinate wording or evaluation wording, the specification SHALL require a pre/post kind-restoration check for evaluated object kind, characteristic kind, relation or claim kind, current ontic slot, relation position, use relation, or claim kind when live, admissible use, and scope, plus the governing pattern when another pattern governs the kind under repair, relation, claim, or position.Prevents coordinate cleanup from changing what the evaluation evaluates.

    Common anti-patterns

    Anti-patternSymptomRepair
    Scale set from air.Coordinates appear because they are familiar.Rebuild from evaluated object kind, use, contrast cases, failure modes, domain tradition, first principles, and current source-use relation.
    Wrong-kind object forced through the table.Objects outside the declared kind are either scored as weak members of that kind or silently exempted from declared coordinates.Add an object-kind-fit rule and boundary cases: before opening, return to a suitable evaluation; after invocation, record an explicit object-kind-fit defect/value or repair status.
    Checklist masquerading as characteristic space.A list of tasks is treated as coordinates.Convert each task row to an evaluated EntityOfConcern property with a characteristic, scale, value meaning, and evidence rule, or move it to work planning.
    One total quality score.Several ordinal values are averaged.Use coordinates, statuses, dominance or comparison rule, and protected trade-offs; do not scalarize unless an neighboring pattern governing the claim explicitly declares the operation.
    Improvement without floor.A loop continues because more change is possible.State floor, exceptional meaning, stop condition, and reopen condition.
    Hidden value drift.The evaluation changes while old evaluations are compared as if nothing changed.Version the evaluation and state comparability, bridge, or retirement.
    Evaluation theft.The new evaluation starts governing evidence, assurance, gate, work, decision, or publication truth.Return each claim to the neighboring pattern governing the claim and leave only the value evaluation here.
    Result prose as evaluation.A reviewer returns a narrative, two-column table, checklist count, or value list without evidence basis and short rationales.Define the result-row shape, require short rationales and evidence basis, and lower any coordinate whose needed evidence is missing or unchecked.
    Evidence basis as evaluated-object method.Corpus projection, retrieval, currentness, comparator, monolith-parity, quality-status evidence, or role-turn correspondence is written in the evaluated object as if it were what the evaluated-object user does.Move the evidence to the evaluation result, evidence basis, projection carrier, or selected publication carrier; keep only the user action or boundary that the evidence justifies.
    Coordinate wording as ontology change.A coordinate or repair name sounds cleaner, but changes the evaluated object kind, characteristic kind, relation or claim kind, admissible use, or scope.Treat it as a changed evaluation decision, recover the pre/post kind relation, and repair or reopen the evaluation rather than accepting lexical cleanup.

    Relations

    PatternRelation
    A.19Defines CharacteristicSpace. A.19.ECS gives the method for constructing one evaluation CharacteristicSpace for an evaluated object.
    A.17, A.18, C.16Govern characteristics, scales, scale values, coordinates, measures, units, and measurement legality. A.19.ECS uses them by reference for each slot.
    C.25Governs Q-Bundle normal form for composite engineering quality families. A.19.ECS may select or repair the characteristic-space part before a Q-Bundle endpoint is used.
    E.22Frames one improvement-oriented quality-evaluation question after an evaluation is declared. A.19.ECS constructs the missing or inadequate evaluation.
    E.23Governs repeated improvement after evaluated object version and evaluation are declared. A.19.ECS provides the evaluation when it is missing or underdesigned.
    E.21Existing evaluation for one FPF pattern version. A.19.ECS explains the construction shape but does not replace E.21.
    E.9.DAExisting evaluation for one DRR decision-adequacy claim. A.19.ECS does not replace it.
    E.2.DAExisting evaluation for FPF-level Pillar adequacy. A.19.ECS explains why it must publish evaluated object, coordinates, values, evidence loci, status, and stop meanings.
    F.18Existing naming discipline with a grouped lexical quality vector. Use F.18 for durable term and name improvement.
    C.16.P, C.16.Q, E.10, A.6.P, C.2.PRepair overloaded characteristic/scale/score, quality, lexical, relation, and source-use wording before it becomes a coordinate or status value.
    C.18, C.19, G.5, G.9, G.11Govern OEE/NQD novelty, diversity, archive, pool, selected-set, parity, and refresh semantics. An evaluation may supply Q values, but it does not govern the rest of OEE/NQD.
    C.29Governs mathematical-lens use when a mathematical structure is used to define or justify coordinates.
    A.10, B.3, A.20, A.21, A.15Govern evidence, assurance, local CV, gates, and work when an evaluation result is reused for those claims.

    Consequences

    A conforming A.19.ECS result lets E.22 ask a useful improvement-oriented quality-evaluation 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 basis, result-row shape, calibration points, coordinate-specific payloads, 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

    ClaimCurrent practice lineAdoption in A.19.ECSBoundary
    Evaluation artifacts must declare intended use, object, criteria, and missingness before their values are useful.Current reporting anchors: BenchmarkCards/EvalCards practice for evaluation-card structure, model-card lineage for intended-use and performance-characteristic reporting, and HELM/VHELM/AHELM-style evaluation suites for scenario, metric, raw-result, and modality-extension transparency.A.19.ECS starts from evaluated object kind, use scope, contrast cases, coordinate meanings, evidence rule, and missingness rule.It is not a benchmark harness, automated judge, or publication format by itself.
    Multicriteria evaluation needs preserved dimensions and protected trade-offs.Current QD overview: A survey on Quality-Diversity optimization: Approaches, applications, and challenges, Swarm and Evolutionary Computation 100:102240 (2026); retained design lineage: MCDA and value-focused thinking for criterion separation and trade-off visibility.The pattern requires coordinate values, polarity or no-simple-direction value rule, protected trade-offs, status meanings, and stop or reopen conditions.Scalarization belongs only to an neighboring pattern governing the claim or explicitly declared local method.
    Improvement pressure can damage the intended value when the evaluation is a weak proxy.Current proxy-risk anchors: Goodhart's Law in Reinforcement Learning (ICLR 2024) and current catastrophic-Goodhart reward-misspecification work (NeurIPS 2024); retained lineage: Goodhart taxonomy.A.19.ECS requires evidence rules, missingness rules, protected trade-offs, and lowering/reopen conditions before a loop can treat a value as improved.It is not an anti-measurement rule; it makes the measurement or ordinal evaluation explicit enough to be challenged.
    OEE/NQD separates the quality side from novelty, diversity, archive, pool, and selected-set semantics.Current QD and OEE/NQD neighbour basis: QD uses quality pressure with novelty/diversity and archive/front practice, while current FPF C.17, C.18, C.19, G.5, G.9, and G.11 keep archive, pool, selected-set, parity, and refresh semantics named by value.The evaluation may supply Q values, while novelty, diversity, archive, front, pool, selected-set publication, parity, and refresh remain with neighboring pattern governing the claims.A.19.ECS does not govern OEE/NQD generation, selection, archive, parity, or refresh.

    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 EntityOfConcern kinds and uses. A.19.ECS governs the selected characteristics, scales, coordinate construction, and evaluation-use boundaries 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)