FPF Reference

    Naming Discipline for U-kind Names and SystemRoleKindDescription Labels

    F.5 · Stable · Definitional (D) · Normative unless marked informative · Part F - The Unification Suite (U-Suite): Concept Sets, SenseCells, and System-Role Kinds and Assignments

    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: Definitional (D) Status: Stable in the current FPF Normativity: Normative unless marked informative

    Plain name. Meaning-first naming discipline.

    Keywords

    • U-kind name
    • system-role-kind name
    • SystemRoleKindDescription label
    • Plain and Tech designations
    • local meaning
    • naming after ontology recovery.

    Relations

    F.5builds onSystem-Role Kinds and Assignments
    F.5builds onKinds, Intent and Extent, and Typed Reasoning
    F.5builds onSystemRoleKindDescription — Describing an Exact System-Role Kind
    F.5builds onLocal-First Unification Naming Protocol
    F.5builds onUnified Lexical Rules for FPF
    F.5builds onRecovering What “Role” Means in the Current Claim
    F.5coordinates withU-kind Admission and Ontic Settlement
    F.5coordinates withMint-or-Reuse Decision
    F.5coordinates withAnti-Explosion Control for System-Role and Status Name Families
    F.5coordinates withUnified Term Sheet
    F.5explicit referenceU-kind Admission and Ontic Settlement
    F.5explicit referenceSystem-Role Kinds and Assignments
    F.5explicit referenceKinds, Intent and Extent, and Typed Reasoning
    F.5explicit referenceSystemRoleKindDescription — Describing an Exact System-Role Kind
    F.5explicit referenceLocal-First Unification Naming Protocol
    F.5explicit referenceUnified Term Sheet
    F.5explicit referenceKindBridge and CL^k — Cross-local Correspondence between Distinct Kinds
    F.5explicit referenceAlignment and Bridge across Contexts
    F.5explicit referenceUnified Lexical Rules for FPF
    F.5explicit referenceRecovering What “Role” Means in the Current Claim
    F.5explicit referenceWording-Use Ontological Precision Restoration Architecture
    F.5explicit referenceRelational Precision Restoration — Recovering Direct Relations from Under-Specified Claims
    F.5explicit referenceRelation, Signature, Interface, Role, and Slot Precision Restoration
    F.5explicit referenceU.SystemRoleAssignment - Contextual System-Role Assignment
    F.5explicit referenceSystemRoleAssignment and Performed-Work Attribution Check
    F.5explicit referenceRelation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline
    F.5explicit referenceTransformer Constitution (Quartet)
    F.5explicit referenceSystem-Role–Method–Work Alignment
    F.5explicit referenceMulti‑Method Dispatcher & MethodFamily Registry
    F.5explicit referenceThe Agential Role & Agency Spectrum
    F.5explicit referenceU.Work: Dated Performed Work Occurrence
    F.5explicit referenceSystemRoleKindRelationStructure - Relations among System-Role Kinds
    F.5explicit referenceU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    F.5explicit referenceEvidence Graph Referring (C-4)
    F.5explicit referenceTrust and Assurance Calculus
    F.5explicit referenceEntityOfConcern, Description Episteme, and Specification-Use Discipline
    F.5explicit referenceCausalUse-CAL: Causal-Use Questions, Identification, and Realizability
    F.5explicit referenceMulti‑View Publication Kit
    F.5explicit referenceU.Capability: System Ability Envelope and Measures
    F.5explicit referenceMathematical Lens Use
    F.5explicit referenceEvidence Graph & Provenance Ledger
    F.5explicit referenceLexical Continuity & Deprecation
    F.5explicit referenceConcept-Set Table Construction
    F.5explicit referenceSystemRoleAssignmentStateRelation - Assignment-State Recognition and Work Admission
    F.5explicit referenceMeasurement & Metrics Characterization (MM‑CHR)
    F.5explicit referenceMint-or-Reuse Decision
    F.5explicit referenceStatus Families Mapping (Evidence • Standard • Requirement)
    F.5explicit referenceAnti-Explosion Control for System-Role and Status Name Families
    F.5explicit referenceStatic and Regression Conformance Harness for Unification

    Content

    Use This When

    Plain name. Meaning-first naming discipline.

    Use F.5 when a project needs a durable name for either:

    • a public U-kind already admitted through E.24.UK, or another durable cross-local value already recovered through the direct rule for that kind of value—for example, episteme constitution or relation obtaining; a Concept-Set row may cite comparison evidence but does not recover the value; or
    • one exact local system-role kind and, when needed, the separate SystemRoleKindDescription episteme that describes it.

    Typical moments:

    • a Concept-Set comparison has enough witnesses for a naming question and the reusable value is already admitted, but candidate names import one source tradition too strongly;
    • an F.4 description names ReviewerSystemRole, OperatorSystemRole, InspectorSystemRole, or TransformerSystemRole, and the label must remain faithful to the exact local kind without smuggling assignment, capability, permission, Method, Work, evidence, status, or responsibility;
    • source wording with role must be named locally, but the project has not yet recovered its use—for example, a system-role kind, assignment, status or access relation, relation position, another object, or ordinary wording; or
    • similar names threaten to collapse independently governed objects—for example, a kind, assignment, status, Method, Work occurrence, and description episteme.

    Primary EntityOfConcern. The EntityOfConcern is the naming discipline for these name families. It relates a recovered meaning to selected Tech and Plain designations. It defines neither the named U-kind nor the local system-role kind, constitutes no description, classifies no candidate, creates no assignment, asserts no status or responsibility, supplies no evidence, and publishes no form.

    Primary working reader. The first reader is a practitioner who already has a candidate meaning and must choose a name that readers can use without creating another ontology—for example, an engineer-manager, analyst, pattern author, or terminology steward.

    First useful move. Recover the exact named value and its direct meaning source before choosing the label. For a U-kind, use its accepted E.24.UK admission result or its direct admission rule. For a local system-role kind, use its A.2 and C.3 identity and criterion; use F.4 for the separate description episteme. Then choose one Tech label and one short Plain explanation whose scope does not exceed the recovered meaning.

    Smallest useful result and stop. Stop with one already identified value, one Tech label, and one Plain explanation as soon as they resolve unambiguously for the named local use. Do not create a NameCard, public row, Bridge, description episteme, or new kind merely to complete a form. If the value or kind is unresolved, apply its direct recovery rule. Use F.18 or F.17 only for the durable or public use they address. Use C.3.3 only for an actual relation between exact local kinds and F.9 only for an actual relation between distinct F.17 cells. If the label starts carrying assignment, Work, result, provenance, assurance, responsibility, or publication claims, stop naming and recover those objects first.

    What goes wrong if missed. Names become arguments. A system-role-kind label smuggles in neighboring claims—for example, assignment, permission, responsibility, or capability. A status phrase becomes a system-role kind. A U-kind name imports one practice's or source's private ontology. A polished global word hides disagreement among witnesses. Downstream patterns then repair semantics that naming already broke.

    What this buys. Readers can use short names without guessing the ontology. U-kind names stay neutral across witnesses. Concrete ...SystemRole designations point to exact local kinds, and ...SystemRoleKindDescription designations point to their separate description epistemes. Names for neighboring claims—for example, status, evidence, access, requirement, source, publication, assurance, gate, and decision claims—remain with their direct relations.

    Not this pattern when.

    • If the problem is ordinary phrase repair, use E.10, E.10.ROLE, E.10.ARCH, A.6.P, A.6.RSIR, or the direct pattern.
    • If the question is whether a U.* spelling or structural name should survive as a durable U-kind, use E.24.UK before F.5.
    • If the broader local-first protocol, NameCards, candidate comparisons, lineage, or public naming is current, use F.18.
    • If the current object is a SystemRoleKindDescription, use F.4 to constitute it before naming it.
    • If the question concerns kind admission, classification, assignment, assignment extent, or performed-Work attribution, use A.2 with C.3, A.2.1, or F.6.
    • If the current object is another governed value rather than a name—for example, a status, evidence use, source use, standard use, requirement use, publication use, assurance claim, gate result, or decision—use its direct pattern.
    • If role denotes a relation position, recover the position under A.6.RSIR and A.6.5.
    • If an actual cross-local relation is current, use C.3.3 for exact local kinds or F.9 for distinct F.17 cells.

    Problem Frame

    FPF needs names that humans can use without dragging the wrong ontology behind them. A good name is short enough for documents and conversation, but it belongs to a recovered meaning.

    This pattern keeps two recurrent naming tasks separate.

    First, a public U-kind gets a name only after E.24.UK admits the exact value. Another durable cross-local value gets a name only after its direct rule has identified or established it; kind membership is only one case. A Concept-Set row may preserve witness comparison and evidence; it neither admits nor identifies the value. The name should be neutral across witnesses and no wider than the recovered invariants.

    Second, one concrete local system-role kind receives a ...SystemRole designation after A.2 and C.3 settle its candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule. A practice or source reference may help readers find or compare that settlement; it does not identify the kind. SystemRole is common morphology, not a universal kind. An F.4 description episteme is another object and may receive a separate ...SystemRoleKindDescription name. Neither label creates the kind, description, classification, or assignment.

    The tempting shortcut is to make system-role descriptions cover statuses and episteme uses because all need labels. That convenience creates duplicate ontology. Another governed value—for example, a status, evidence use, permission, or publication—may need a name; none becomes a system-role kind because it is named.

    Problem

    Without this pattern:

    1. Local terms look global. Observation, Activity, or Process becomes a U-kind name although it carries one practice's or source's private commitments.
    2. System-role names become hidden admissions. A label such as ReviewerSystemRole is treated as if the local kind or candidate classification already exists.
    3. System-role names become hidden assignments. A concrete kind label is treated as if someone is already assigned.
    4. System-role names become capability claims. A candidate is assumed able because the kind label sounds competent.
    5. System-role names become Methods. A noun label hides a Method or Method family.
    6. Description and described kind collapse. PumpInspectorSystemRoleKindDescription is treated as PumpInspectorSystemRole itself.
    7. Status names become system-role kinds. For example, Approved, AccessRole, ModelFitEvidenceRole, or RequirementRole creates a fake work-facing classification instead of the exact direct relation.
    8. Relation positions become system-role kinds. Signature, relation, or argument-position names borrow role morphology even though they name participation or a declaration place.
    9. Names carry interpretation metadata. Task-IEC61131, Participant-BPMN, or ReviewerSystemRole-SchemeA fossilizes an edition, source, local boundary, or scheme in the label.
    10. Aliases become silent renames. Several labels circulate for one meaning without lineage or Bridge discipline.

    Forces

    ForceTension
    Local fit versus cross-local neutralityA local system-role-kind name must fit the named practice or source use; a public U-kind name must not privilege one witness.
    Brevity versus object recoveryA usable name must still let a reader distinguish kind, description, classification, assignment, status, Method, Work, relation, and episteme use.
    Teaching versus wideningA Plain designation should help readers without broadening the Tech designation.
    Stability versus changed meaningNames should survive harmless edition or publication changes, but real sense changes need a split, rename, or lineage record.
    Morphology versus ontologyWord form guides expectations but establishes no kind. SystemRole does not create a universal kind or assignment.
    Open-world use versus name burdenA lightweight local label may be enough; durable public reuse can require F.18 or F.17, and an actual cross-local relation can require C.3.3 or F.9.

    Solution

    Name after meaning. Recover the value, its kind, direct meaning source, and intended use. Then choose designations that preserve them.

    Make these facts recoverable in the prose, direct admission, F.4 description, Concept-Set row, or NameCard. This is a naming checklist, not a relation signature or mandatory record:

    • the exact named value and its admitted kind;
    • the direct source of its meaning;
    • for a local system-role-kind designation, the candidate domain, operative membership condition, intended member/non-member boundary, continuity rule, current KindSignature, and effective scheme, with source or practice provenance kept as a locator or comparison cue;
    • for a description name, the separate F.4 SystemRoleKindDescription and its exact EntityOfConcern;
    • the selected Tech and Plain designations;
    • aliases or predecessor labels with lineage;
    • morphology, neutrality, and minimal-generality checks; and
    • the boundary that prevents the name from absorbing classification, assignment, capability, Method, Work, status, evidence, permission, responsibility, publication, or relation-position claims.

    Name Families Used Here

    Name familyMeaning sourceNaming rule
    Public U-kind or durable cross-local value namePublic U-kind admitted through E.24.UK, or another exact value already recovered through the direct rule for that kind of value; a Concept-Set row may retain witness comparison but supplies neither identity nor admissionUse a neutral Tech head at minimal generality. Do not let one witness's private vocabulary win by spelling alone.
    Concrete local system-role-kind designationExact C.3 kind admitted under A.2, recovered through its candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule; source or practice provenance only locates or helps compare the settlementUse a concrete ...SystemRole Tech designation. SystemRole is morphology, not a universal value; do not add Kind when : U.Kind is already explicit.
    SystemRoleKindDescription designationF.4 description episteme whose exact EntityOfConcern is one local system-role kindName the description separately, for example PumpInspectorSystemRoleKindDescription; never use the description name as the kind or assignment name.
    Relation among system-role kinds or a system-role–Method expressionExact relation under A.2.7 and, when current, a separately recovered Method, MethodDescription, or WorkName the recovered relation or neighboring object. Ordinary phrasing may stay compact but must not hide independent classifications or assignments.
    Method, Method family, Method relation structure, WorkPlan, or Work nameA.3, A.15, G.5, and the exact composition or Work patternName that object directly. Shared words with a system-role-kind label create no relation or identity.
    Mathematical or representation lens nameDescription of a selected system-role-kind relation structure, Method relation structure, transformation-flow structure, or another governed structureName the lens only when the representation is itself the governed value. Otherwise name the underlying structure or relation.
    Status, evidence, requirement, source, standard, publication, assurance, gate, or decision nameExact direct relation or valueDo not treat it as a SystemRoleKindDescription branch. Use F.18 only after the direct object is recovered.
    Relation slot or argument-position nameA.6.RSIR, A.6.5, and the exact relation or signature declarationName the participant meaning, slot, or argument position. Do not use SystemRole morphology unless the value is independently a local system-role kind.

    Keep four things separate: the chosen name, the local system-role kind it names, an optional F.4 description of that kind, and any assignment that the current use actually needs. The name designates the kind; the description describes it. An assignment is a separate A.2.1 occurrence of a directly declared species under U.SystemRoleAssignment. That species says which systems may be holders, which exact local kinds may fill the assigned-kind place, what the assignment predicate means, when it applies, how an uninterrupted occurrence keeps its identity, and whether another real participant matters. The occurrence supplies the actual holder, assigned kind, and any other participant values. If the naming use needs no assignment identity, do not invent an assignment. Spelling, a suffix, a NameCard, a public row, a description, or a citation creates none of these objects, nor any dated Work, result episteme, provenance record, or publication occurrence.

    Tech and Plain Designations

    Use two human-facing designations when a name is durable enough to be reused:

    DesignationJobConstraint
    Tech designationStable label used by the local pattern, table, or description epistemeMust fit the recovered kind and exact meaning source.
    Plain designationShort teaching phrase or sentenceMust point to the same value without widening the sense.
    Symbol or source abbreviationOptional local notation or lineage spellingInformative only; it is not another selected Tech or Plain designation.

    For a concrete local system-role kind, the Tech designation normally ends in ...SystemRole, for example ReviewerSystemRole or PumpInspectorSystemRole. The Plain designation may remain ordinary, for example “reviewer” or “pump inspector”, when the named practice and criterion make the intended kind clear. Add “system role” only when it prevents a live neighboring reading. The compound does not imply non-human technical systems, kind admission, candidate classification, assignment, agency, capability, Method, or Work.

    For the description episteme, name the description rather than the described kind: PumpInspectorSystemRoleKindDescription may have Plain designation “description of the pump-inspector system-role kind”. SystemRoleKindDescription identifies the construction; Kind identifies the EntityOfConcern and Description already identifies the episteme.

    For a coupled system-role–Method phrase, recover the local kind and Method separately before naming either one. Recover and name a MethodDescription, WorkPlan, or dated Work only when that exact object is already admitted and the naming use consumes it; a shared phrase does not require any of them to exist. RoboticsEngineerSystemRole may designate one admitted local kind; RobotEngineeringMethod names a Method or Method family. Ordinary engineer-roboticist may remain the Plain expression when nearby project wording makes the intended kind clear and the C.3 candidate domain, membership distinction, boundary probes, and continuity remain recoverable. The wording helps the reader; it does not identify the kind. It replaces neither a qualifying MethodDescription nor any description of planned or performed Work.

    When a later naming use actually consumes one dated Work identity, that Work must already be constituted before F.5 naming begins. Recover every exact actual performer through A.13, and let A.15.1 independently admit the Work from its semantic Method, time, containing System, and other required direct facts. Add the assignment occurrence, holder equality, and F.6 relation only when the naming record or receiving use expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work identity intact. Otherwise keep the activity in ordinary wording and do not mint a Work identifier merely to support a name.

    For a U-kind, the Tech designation should be neutral enough that no witness wins by vocabulary alone. If witnesses disagree between Observation, Reading, and MeasurementResult, a Concept-Set row preserves the comparison; the exact shared value and invariants must still pass E.24.UK admission or their direct defining rule before an author uses F.5 to choose a name.

    Positive Naming Rules

    1. Recover the object first. State the governed kind or construction of the value—for example, a U-kind, local system-role kind, description episteme, classification judgment, assignment, relation, Method, Work, status, evidence use, slot, lens, or another object.
    2. Recover the meaning source. Use the exact E.24.UK or direct admission for a U-kind; A.2 with C.3 for a local system-role kind; F.4 for its description; A.2.7 for relations among kinds; A.3, A.15, G.5, or the exact composition pattern for Method and Work names; and the direct relation for status, evidence, source, requirement, publication, assurance, gate, decision, and relation-position names.
    3. Use minimal generality. The designation's scope is no wider than the admitted invariants.
    4. Keep interpretation metadata out of the label. Edition, source, witness, local boundary, reference scheme, and threshold belong in the direct declaration, description, relation, or NameCard.
    5. Make morphology object-sensitive. Concrete local system-role kinds use ...SystemRole; description epistemes use ...SystemRoleKindDescription; states use state or level wording; slots say Slot, Argument, Endpoint, or another exact position head.
    6. Keep coupled names typed. A compact phrase may help a reader, but one label must not carry several independently governed objects—for example, kind, assignment, capability, Method, Work, and description—at once.
    7. Do not encode thresholds or windows in the name. Put time, state, threshold, capability envelope, or admission window in the direct claim.
    8. Use aliases only with lineage. A source term, predecessor term, symbol, or translation does not become a second selected Tech label.
    9. Escalate only for actual reuse. Use F.18 and F.17 for durable or public naming. When an actual cross-local relation is consumed, name the exact obtaining C.3.3 relation between local kinds or F.9 Bridge between distinct F.17 cells and keep the separate C.2.1 claim that it suits the named use. Ordinary reliance requires the exact A.10 evidence-provenance relation and RelianceDisposition=pass. Use B.3 only when an actual named assurance claim is current. None of the cross-local relation, use claim, evidence path, assurance result, NameCard, row, designation, or publication establishes assignment, Work, result, provenance, assurance, or publication occurrence.

    Neighboring Use Boundary

    When a candidate contains a tempting word, recover the current claim instead of replacing words mechanically.

    Source wordingFirst ontological questionDirect next locus
    EvidenceRole, ModelFitEvidenceRole, or “evidence role”Is an episteme used as evidence for a target claim with exact scope, polarity, relevance window, and provenance?A.10, B.3, C.2.1, or the exact evidence-use relation
    RequirementRole or “standard role”Is an episteme, standard, or clause used as a requirement, source, or specification?E.10.D2, C.28, E.17, or the exact source or requirement relation
    Access Role in RBACIs this a policy or permission grouping rather than a work-facing kind?Exact access, policy, permission, or status relation; F.18 only if durable naming is needed
    “role of subject, provider, or input”Is this participant meaning, a declaration slot, or a representation position?E.10.ROLE, A.6.RSIR, and A.6.5
    ReviewerSystemRoleIs one exact local C.3 kind with a direct criterion current?A.2 with C.3; F.4 for its description; A.2.1 only when assigned
    robotics engineer or engineer-roboticistIs this a local kind, conjunction, relation, Method, Work, or capability?A.2.7, A.3, A.15, A.2.2, and F.18 when durable naming is current
    Reviewing, ReviewMethod, RobotEngineeringMethod, ReviewWorkflow, or MethodAlgebraIs this a Method, MethodDescription, Method relation structure, WorkPlan, performed Work, or lens?A.3, A.15, G.5, C.29, or the exact composition pattern
    ReviewWork or “review happened”Is one performed Work occurrence current?A.15.1

    Select the name only after recovery. A cleaner string is not a repair if it hides the same ontological error.

    Archetypal Grounding

    Public or Cross-Local Kind Name

    A Concept-Set row compares SOSA Observation, metrology measurement result, ML practice metric reading, and a dashboard value exported for comparison. The row is a comparison and evidence surface, not admission or identity of a common result value.

    Keep the concrete objects at their direct loci. Pump 14 was measured before the reading was recorded, but this naming example does not identify a dated Work occurrence. If a use needs that occurrence, recover its exact actual performer through A.13 and admit it independently under A.15.1. Attribute it under F.6 only when that use also consumes precise assignment-bound attribution.

    C.16 constitutes the measurement result: a value attributed to the measurand together with the Characteristic, Scale, uncertainty, method, model, calibration basis, time stance, and measurement Work needed to interpret it. Pump14PressureReading_2026-07-14T10-42Z is one C.2.1 episteme that states that result; F.5 does not repeat either pattern's schema. The result and its episteme are distinct from raw output, indication, Pump 14's actual state, a later diagnosis, a criterion verdict, evidence, or a dashboard display. Pump14CalibrationTrace_2026-07-14 is a provenance record whose G.6 and A.10 relations make the calibration and source path recoverable. A dashboard publication may cite the reading, and the Concept-Set row may cite the reading and trace; neither is the result, its episteme, provenance, or a generic relation that establishes them.

    Only E.24.UK or the direct result pattern can admit a shared value and its invariants. After admission, use F.5 to select Reading, Result, or another neutral head no wider than that value. The spelling still creates no result or provenance identity.

    Local System-Role Kind and Its Description

    Under Plant-A-Maintenance-Scheme, PumpInspectorSystemRole designates one exact local kind; it is not that kind. PumpInspectorSystemRoleKindDescription-v3 is a separate C.2.1 episteme whose EntityOfConcern is the kind. Its ClaimGraph states which systems are candidates, the reading-and-judgment condition that distinguishes members, useful member and non-member probes, the continuity rule, current KindSignature, and effective scheme. Plant-A maintenance provenance locates that definition; it does not identify the kind. The Tech designation is PumpInspectorSystemRole; the Plain designation is “pump inspector”.

    This worked slice needs an assignment identity, so Robot7-PumpInspector-Assignment-2026Q3 is one occurrence of the directly declared PlantAPumpInspectionAssignment species under U.SystemRoleAssignment. The species' holder slot admits a U.System; its declaration-local assigned-kind slot uses the exact PlantAMaintenanceSystemRoleKindDomain; and its predicate applies within the Plant A maintenance scheme and obtains while the fixed holder is assigned under PumpInspectorSystemRole to supply the pump-inspection contribution. The occurrence identifies Robot-7 as holder and PumpInspectorSystemRole as assigned kind, and spans the maximal uninterrupted interval over which that predicate obtains for those values. This simple species declares no additional identity-bearing participant; a commission, position, or installation locus would become one only in a species whose predicate and identity actually require it.

    This naming example does not identify Robot-7's inspection of Pump 14 as a dated Work occurrence. Pump14InspectionFinding_2026-07-14T11-18Z is a separate claim-bearing result episteme, and Pump14InspectionTrace_2026-07-14 is the exact provenance record connected through G.6 and A.10.

    The kind label helps readers recover the kind; the description episteme describes it. Neither says Robot-7 satisfies the kind, has an assignment, performed the inspection, produced the finding, or supplied its provenance. A suffix, NameCard, row, pattern section, or citation identifies none of those objects or relations.

    Evidence Use Is Not a System-Role Name

    Source text may say ModelFitEvidenceRole. The repair is not a prettier role label. This naming example does not identify the model-fit evaluation as a dated Work occurrence. Recover the exact objects it does consume: ModelFitResult_2026-07-15T09-22Z is a separately constituted domain-local result episteme; ModelFitTargetClaim-v5 is the target claim; and ModelFitRunTrace_2026-07-15 is the provenance record connected through exact G.6 and A.10 relations. Keep any operation-result binding, result-episteme inception claim, evidence use, provenance, and current assurance claim separate, and apply the rule that defines or tests each relation.

    A durable name, if needed, names one recovered evidence-use relation, status value, Work occurrence, result episteme, or provenance value. ModelFitEvidenceRole, a NameCard, row, or citation creates none of them and supplies no generic evidence-result relation. It is neither a local system-role kind nor a SystemRoleKindDescription label.

    Relation Position Is Not a System-Role Name

    In a relation signature, “provider role” may mean the provider argument position. Use E.10.ROLE and A.6.RSIR to recover the participant meaning; use A.6.5 to declare ProviderSlot, its ValueKind, and its reference mode. A provider system's classification under a local ProviderSystemRole kind is a separate C.3 claim. When assignment identity is irrelevant to naming that relation position, say only that any provider assignment remains independently governed by A.2.1; do not invent an occurrence. When it is relevant, recover the assignment occurrence and its declared species rather than asserting that the provider simply “has an assignment”.

    Bias Annotation

    1. Semio-bias. A name, card, row, publication, or source label is mistaken for the named value or authority to use it.
    2. Role-bias. Evidence, status, access, source, requirement, participation, or argument-position wording is forced into SystemRole morphology.
    3. Source-vocabulary capture. One source's term becomes the Tech designation without showing fit to the admitted value or exact local kind.
    4. Suffix formalism. Adding SystemRole, KindDescription, Status, Record, Graph, or Map makes a label look precise while the object remains unresolved.

    The repair is object recovery first, designation second.

    Conformance Checklist

    CheckPass condition
    CC-F5-1The exact named value and kind are explicit.
    CC-F5-2The direct meaning source is explicit: E.24.UK or direct admission for a U-kind, A.2 with C.3 for a local system-role kind, F.4 for its description, or another exact relation. A Concept-Set row, card, or citation is not admission or identity.
    CC-F5-3The Tech designation is no broader than the recovered meaning.
    CC-F5-4The Plain designation points to the same value without widening it.
    CC-F5-5Edition, source, witness provenance, local boundary, scheme, threshold, and window stay outside the main label. A locator may carry such metadata when navigation requires it, but the metadata does not identify the named kind or value unless its own direct recovery rule makes that distinction part of the object.
    CC-F5-6A U-kind name is neutral across the named witness sources or practices. Shared source spelling establishes neither the governed value nor a local kind's identity; the direct admission and identity rules must already have done that work. Treat the term as genuinely shared only when evidence establishes the same referent.
    CC-F5-7The system-role-kind designation, local kind, F.4 description, classification judgment, assignment species, and assignment occurrence remain distinct. For any assignment identity used, recover the occurrence and its declared A.2.1 species. The species defines the participant meanings, assigned-kind domain, predicate, applicability, and occurrence identity; the occurrence supplies the holder, assigned-kind value, case applicability, extent, and any other participant values. Otherwise the text does not invent an occurrence.
    CC-F5-8Status, evidence, requirement, source, publication, assurance, gate, decision, responsibility, and relation-position names remain at their direct objects before durable naming.
    CC-F5-9A source term, symbol, predecessor term, or translation is marked as lineage or alias, not another selected Tech designation.
    CC-F5-10For durable or public reuse, use F.18 and F.17 as needed; actual cross-local use names the exact C.3.3 kind relation or F.9 local-sense relation and the proportionate receiving-use, A.10, or B.3 claims required by rule 9. None substitutes for the receiving Work, result, provenance, assurance, or publication occurrence.
    CC-F5-11A worked case does not mint a dated Work identity merely to support naming. When it consumes an already admitted Work, each exact actual performer has its A.13 basis and A.15.1 independently supplies the Method, time, containing System, and Work identity. A covering assignment and F.6 relation are recoverable only when the naming record or receiving use expressly represents that precise attribution. Result epistemes, provenance values, and their relations remain separate; no label, description, suffix, card, row, or citation substitutes for them.

    Common Anti-Patterns and Repairs

    Anti-patternSymptomRepair
    Interpretation tag in labelParticipant-BPMN, Task-IEC61131, ReviewerSystemRole-SchemeAPut source, edition, local boundary, and scheme in the direct declaration, description, or NameCard.
    Witness captureObservation chosen because one standard uses itRecover the exact value and admission; use comparison evidence only as evidence, then choose a neutral head when witnesses diverge.
    System role and status fusionApprovedReviewerSystemRole or AccessRole treated as a work-facing kindSeparate the local kind from status, policy, permission, and access relations.
    Evidence role revivalEvidenceRole retained as durable ontologyRecover and, if needed, name the evidence-use relation.
    Verbified system roleReviewing used as a kind labelUse a concrete kind noun; use Method or Work patterns for action or occurrence.
    Position roleProviderRole names a relation argumentUse an exact slot or position name under A.6.RSIR and A.6.5.
    Threshold in nameCriticalReviewer0.2mmSystemRolePut threshold, capability envelope, or window in the direct claim.
    Alias spraySeveral Tech labels for one meaningKeep one selected Tech designation; retain other strings as lineage or aliases under F.18 or F.13.
    Decorative precisionCanonicalActionStatus, ValidatedSystemRoleCueRecover the governed object and relation; do not replace one umbrella with another.

    Consequences

    Good consequences:

    • durable names become shorter because the ontology stays at the right object;
    • local system-role-kind names stay usable without becoming assignment, capability, Method, or evidence claims;
    • description names no longer collapse into the kinds they describe;
    • U-kind names are easier to bridge because their comparison evidence remains explicit; and
    • For an E.10 repair that uncovers a durable naming issue, use F.5 or F.18 instead of ad hoc word substitution.

    Costs:

    • authors recover the object and meaning source before naming;
    • some familiar source labels cannot become FPF Tech designations;
    • durable public names may need F.18 and F.17, while actual cross-local relations may need C.3.3 or F.9 even when a local label looks obvious; and
    • source text that uses role for status, evidence, access, participation, or relation position needs ontological recovery, not suffix editing.

    Reopen F.5 when U-kind neutrality, SystemRole or SystemRoleKindDescription morphology, the Tech-Plain relation, lineage, or durable cross-local naming boundaries change. Reopen a neighboring pattern when the dispute is about the named object itself.

    Rationale

    Naming is late ontology, not early decoration. Durable names become references used in reasoning, search, publications, and pattern relations. A wrong name makes later readers inherit a false kind claim.

    The design choice is to split naming by meaning source rather than source spelling. Bare role can point to many different objects or uses—for example, a local system-role kind, assignment, policy term, status, evidence use, relation position, representation position, or ordinary English. Do not decide by suffix. Use E.10.ROLE and the direct patterns to recover the object, then F.5 to name it.

    F.5 remains narrower than F.18. Use F.18 for the full local-first protocol, NameCards, candidate comparison, lineage, and public naming. F.5 supplies the special discipline needed by U-kind names, concrete system-role-kind names, and SystemRoleKindDescription labels.

    SoTA Decision for Precise, Readable Technical Names

    Source use was checked on 2026-08-20. The bounded question is: after the object is recovered, what is the smallest naming result that stays technically precise, readable to a project reader, and honest about morphology and reuse?

    Current lineStrong contributionLimit at comparable one-name effortFPF decision and receiving locus
    ISO 704:2022 and ISO 1087:2019Separate objects, concepts, definitions, and designations; make concept relations and term formation inspectable.Terminology work does not itself admit the FPF object, decide a system-role kind, make an assignment obtain, or state the direct use and publication boundaries.Adopt naming after meaning, minimal generality, and inspectable term formation in sections 4.1-4.3 and checks CC-F5-1 to CC-F5-4. Reject a preferred term or definition as object admission.
    W3C Ontology-Lexica Community Group, OntoLex-Lemon, 2016 Community ReportSeparates lexical entry, written and morphological form, lexical sense, ontology reference, usage conditions, and sense relations.A full lexical graph and syntax-semantics model is excessive for one local Tech/Plain pair, and its reference relation does not establish FPF object identity or reuse authority.Adapt object-sensitive morphology and the separation of name, sense, and referent in sections 4.1-4.4. Reject mandatory full lexicon modeling; use F.18 only when durable naming actually needs a card.
    ISO 24495-1:2023, current published plain-language standardRequires written information that intended readers can find, understand, and use; it explicitly applies to technical writing and controlled languages.Plain-language quality does not settle ontology, reference, or term identity, and a shorter familiar word can still widen the meaning.Adopt one short Plain designation and reader-use check in section 4.2 and CC-F5-4. Reject simplification that changes the recovered value or removes a live distinction.
    W3C SKOS Reference, Recommendation 2009Keeps preferred and alternative labels, notes, concepts, collections, and mapping relations distinct.It is useful lineage for labels and aliases but does not model enough morphology or decide FPF kind, assignment, Work, evidence, or publication claims.Retain as lineage for aliases and cross-local caution in rules 8-9 and CC-F5-6/CC-F5-9; do not treat a shared label or generic mapping as a Bridge or common referent.

    Selected non-dominated contribution. A bare preferred label is cheaper but can hide the wrong object and leaves a cold reader without a safe explanation. A full ontology lexicon is richer but normally costs more than one project naming decision needs. F.5 stops at one already recovered value, one Tech designation, and one short Plain explanation. The word form follows the kind of object, while explicit limits prevent the two labels from creating a second ontology. At that effort, the result is more usable than a formal-only name and more precise than an unexplained familiar word.

    SysML is intentionally not used as a naming, ontology, or lineage authority here. Its notation does not settle the referent, local kind, description, assignment, participation, Method, Work, or readable term choice at issue.

    Source-use boundary: external labels, Concept-Set rows, and citations are evidence for local meaning or common practice, not automatic Tech designations, admission decisions, or Work, result, and provenance identities. A source term becomes selected only after the exact value is admitted and the naming comparison passes; naming changes none of those objects.

    Relations

    Builds on. A.2, C.3, F.4, F.7, F.18, E.10, E.10.ROLE, and E.10.ARCH.

    Coordinates with. E.24.UK for U-kind admission; A.2.1 for system-role assignment; A.2.2 for capability; A.2.5 for assignment state; A.2.7 for relations among system-role kinds; A.6.5 and A.6.RSIR for relation positions; A.15 for system-role–Method–Work alignment and dated Work; C.16 for measurement results; C.2.1 for descriptions and result epistemes; G.6 and A.10 for provenance and ordinary evidence reliance; B.3 for assurance-bearing reliance; F.8 for mint or reuse; C.3.3 for relations between exact local kinds and F.9 for relations between distinct F.17 cells; F.10 for status; F.13 for lineage; F.14 for anti-explosion; F.15 for conformance; and F.17 for public term-sheet use.

    Used by. Part F naming patterns, F.4 description authors, Concept-Set authors, E.10 repairs that uncover naming rather than phrase-use issues, and any pattern use that creates a durable local name for a U-kind, system-role kind, or SystemRoleKindDescription.

    Does not replace. Direct evidence, status, requirement, source, publication, assurance, gate, decision, responsibility, relation-signature, Method, Work, or architecture patterns.

    F.5:End

    Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)