#Naming Discipline for U.Types & Roles

F.5 · Stable · Definitional (D) · Normative unless marked informative · Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

#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 Normativity: Normative unless marked informative

Plain name. Meaning-first naming discipline.

#Keywords

• naming conventions
• lexical rules
• morphology
• twin registers
• U.Type naming.

#Relations

#Content

#Use This When

Plain name. Meaning-first naming discipline.

Use this pattern when a project needs a durable name for either:

• a U.Type or other cross-context concept admitted through a Concept-Set row; or
• a label used by a role-description episteme for one work-facing U.Role in one U.BoundedContext.

Typical moments:

• a Concept-Set row has enough witnesses to admit a reusable FPF name, but the candidate names import one source tradition too strongly;
• a role-description episteme names a role such as ReviewerRole, OperatorRole, InspectorRole, or TransformerRole, and the label must stay faithful to the bounded context without smuggling capability, permission, method, work, evidence, or status;
• a role-like external phrase must be named for local use, but the project has not yet decided whether it is a work-facing U.Role, a status-use relation, an access or policy term, a relation slot, or only a local phrase;
• two similar names threaten to make a U.Type, a U.Role, a status value, a method, and a work occurrence look like one object.

Primary EntityOfConcern. The EntityOfConcern is the naming discipline for these two name families. It governs the relation between a recovered meaning and its Tech and Plain labels. It does not define the named U.Type, does not define the described U.Role, does not assign a holder to a role, does not assert status, does not provide evidence, and does not make a publication form authoritative.

Primary working reader. The first reader is an engineer-manager, analyst, pattern author, or terminology steward who already has a candidate meaning and must choose a name that remains usable by readers without creating a second ontology.

First useful move. Before choosing the label, recover the named value kind and its source of meaning: Concept-Set row for a U.Type; role-description episteme, described U.Role, bounded context, and local sense for a role label. Then choose Tech and Plain labels whose morphology matches that kind and whose scope does not exceed the recovered meaning.

What goes wrong if missed. Names become arguments. A role label starts implying permission or capability. A status phrase becomes a role. A U.Type name imports one context's private ontology. A pretty global word hides that the Concept-Set witnesses do not agree. Downstream patterns then repair "semantics" that were actually broken at naming time.

What this buys. Readers can use short names without guessing the ontology. U.Type names stay neutral across their witnesses. RoleDescription labels stay local to their bounded context and point to work-facing roles. Status, evidence, access, requirement, source, publication, assurance, and gate names remain governed by their direct patterns instead of becoming "roles" by naming accident.

Not this pattern when.

• If the current problem is ordinary phrase repair rather than a durable name, use E.10, E.10.ARCH, A.6.P, or the direct governing pattern.
• If the current issue is the broader local-first naming protocol, Name Cards, candidate fronts, lineage, or public naming governance, use F.18.
• If the current issue is a role-description episteme itself, use F.4.
• If the current issue is role assignment, holder, context, window, or performed-work attribution, use A.2.1.
• If the current issue is status classification, use F.10 or the direct status-use pattern.
• If the current issue is evidence, source, standard, requirement, publication, assurance, gate, or decision use of an episteme, use the direct pattern for that relation.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.
• If cross-context sameness or translation is current, use F.9.

#Problem Frame

FPF needs names that humans can use without dragging the wrong ontology behind them. A good name is short enough to be used in documents and conversations, but it is not free-floating. It belongs to a recovered meaning.

This pattern keeps two recurrent naming families separate.

First, a U.Type or similar cross-context concept gets its name from a Concept-Set row. The name should be neutral with respect to the witnesses and should name the least shared kind that the row actually admits.

Second, a role-description episteme labels one work-facing U.Role in one bounded context. The label should fit the local idiom and make the role recognizable. It should not make a holder assignment, capability, method, work occurrence, status, evidence relation, permission, publication, or relation slot look like part of the role value.

The tempting shortcut is to make "Role Description" cover both roles and statuses because both need labels. That is convenient wording, but it creates duplicate ontology. Statuses and evidence uses need names too; they do not become roles because they are named.

#Problem

Without this pattern:

1. Context-local terms look global. A name such as Observation, Activity, or Process is promoted to a U.Type name even though it carries one witness tradition's private commitments.
2. Role names become hidden assignments. A label such as ReviewerRole is treated as proof that someone holds the role.
3. Role names become capability claims. A holder is assumed able because the role label sounds competent.
4. Role names become methods. A noun label hides a method or method family.
5. Status names become roles. Approved, AccessRole, ModelFitEvidenceRole, or RequirementRole becomes a role-name family instead of a status-use, evidence-use, access-policy, requirement-use, or source-use relation.
6. Relation positions become roles. Signature or interface slot names borrow role morphology and collide with U.Role.
7. Names carry editions or contexts. Labels such as Task-IEC61131 or Participant-BPMN fossilize provenance inside the label instead of using Context, SenseCell, or Concept-Set evidence.
8. Aliases become silent renames. Several labels circulate for one meaning without lineage or bridge discipline.

#Forces

#Solution

Name after meaning. For each candidate name, first recover the named value, its meaning source, and its intended use. Then choose labels that preserve that meaning.

NamingDisciplineRecord:
  NamedValueSlot:
  NamedValueKindSlot:
  MeaningSourceSlot:
  BoundedContextSlot:
  TechLabelSlot:
  PlainLabelSlot:
  AliasRefs:
  MorphologyCheckSlot:
  NeutralityCheckSlot:
  MinimalGeneralityCheckSlot:
  NeighboringUseBoundarySlot:

This record is not a registry requirement. It is the smallest relation a reader should be able to reconstruct from the pattern text, a Name Card, a table row, or a role-description episteme when the name is used.

#Name Families Governed Here

#Tech and Plain Labels

Use two human-facing labels when the name is durable enough to be reused:

For a role-description label, the Tech label may be an agentive noun, local role term, or role phrase such as ReviewerRole, PumpInspectorRole, Participant, or Approver. The suffix Role is a disambiguator, not a universal law. Use it when it prevents confusion with a status, method, work occurrence, organization unit, publication, or access-policy term. Do not add it merely to make the name look formal.

For a coupled role-method label, recover the role expression and the method value or work value separately before naming. RoboticsEngineerRole may be a durable Tech label for a robotics-qualified engineering role value. RobotEngineeringMethod names a method or method family. The ordinary label "engineer-roboticist" can be useful when the context makes the coupled role-method meaning recoverable, but it must not replace the method record or work record.

For a U.Type, the Tech label should be neutral enough that no witness context wins by vocabulary alone. If witnesses disagree between Observation, Reading, and MeasurementResult, the admitted name may be Result, Reading, or another head only if the Concept-Set row admits it by value.

#Positive Naming Rules

Use these rules when choosing or checking a name.

1. Recover kind first. State whether the named value is a U.Type, U.Role, role-description episteme, role-relation expression, method, work, status-use value, evidence-use relation, relation slot, lens description, or another named kind.
2. Recover meaning source. Use Concept-Set row for U.Type; role-description episteme and bounded context for role labels; A.2.7 for role-relation expressions; A.3.1, A.3.2, A.15, G.5, or a direct method-composition pattern for method, method-family, method relation structure, or work names; direct governing pattern for statuses, evidence, source, requirement, publication, assurance, gate, decision, and relation slots.
3. Use minimal generality. The name's scope stays no wider than the admitted invariants.
4. Keep context out of the label string. Context, edition, source, and witness provenance belong in Context, SenseCell, Concept-Set row, or Name Card fields, not inside the main label.
5. Make morphology kind-sensitive. Agentive role names fit work-facing roles. State or level forms fit statuses. Verbal or gerund forms fit methods only when the method pattern admits them. Slot names should say Slot, Argument, Endpoint, or another declared slot or position head when current.
6. Keep coupled role-method names typed. A phrase like "engineer-roboticist" may be the ordinary label for a qualified role expression; "robot engineering" may be a method or work name. Do not make one label carry holder assignment, role value, method, work, and capability at once.
7. Do not encode thresholds or windows in the name. Put time, state, threshold, capability envelope, or admission window in the governing pattern.
8. Use aliases only with lineage. A source term, previous term, symbol, or translation can be an alias; it does not create a second Tech label.
9. Escalate when reuse becomes public or cross-context. Use F.18, F.17, and F.9 when the name crosses local use, public publication, or context boundary.

#Neighboring Use Boundary

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

The name is admitted only after this recovery. A cleaner string is not a repair if it hides the same kind error.

#Archetypal Grounding

#Cross-Context Type Name

A Concept-Set row compares:

• SOSA Observation;
• metrology measurement result;
• ML practice metric reading;
• a dashboard value exported for subsequent comparison.

The row does not justify naming the U.Type Observation merely because one source tradition uses that word. It also does not justify DashboardValue if the dashboard is only one publication form. A name such as Reading or Result is admissible only if the row shows the shared invariant: produced value or record admitted for comparison in the declared context.

#Work-Facing Role Label

In PlantMaintenance_2026, the role-description episteme describes PumpInspectorRole.

NamedValueSlot: PumpInspectorRole
NamedValueKindSlot: U.Role
MeaningSourceSlot: RoleDescription for PlantMaintenance_2026
TechLabelSlot: PumpInspectorRole
PlainLabelSlot: pump inspector role
NeighboringUseBoundarySlot: inspection report is evidence use; inspection method is method; assigned technician is RoleAssignment holder.

The label helps readers identify the role. It does not say Robot-7 holds the role, can inspect pumps, followed the inspection method, or produced an admissible report.

#Evidence Use Is Not a Role Name

Source text may say ModelFitEvidenceRole. The repair is not to invent a prettier role name. The project first recovers the current claim: a dataset, report, or model-output episteme is being used as evidence for a target claim under a scope, polarity, relevance window, assurance use, weight model, and provenance constraints.

The durable name, if needed, is a name for that evidence-use relation or status-use value under the direct governing pattern. It is not a work-facing U.Role and not a RoleDescription label.

#Relation Position Is Not a Role Name

In a relation signature, "provider role" may mean "the provider argument position". F.5 does not make ProviderRole a U.Role name. Use A.6.5 to recover ProviderSlot, its admitted ValueKind, and its reference mode. If a provider system also has a work-facing role in a method, that is a separate U.Role/U.RoleAssignment claim.

#Bias-Annotation

This pattern protects against four naming biases.

1. Semio-bias. A name, card, table row, publication, or source label is mistaken for the named value or for authority to use it.
2. Role-bias. Useful relation words such as evidence, status, access, source, requirement, or argument position are put into Role language because role words sound familiar.
3. Source-vocabulary capture. One source context's term becomes the FPF Tech label without proving cross-context fit.
4. Suffix formalism. Adding Role, Status, Record, Graph, or Map makes a label look precise while leaving the kind unresolved.

The repair is always kind recovery first, label second.

#Conformance Checklist

Use this checklist on each durable name governed by F.5.

| CC-F5-10 | Public or cross-context reuse invokes F.18, F.17, or F.9 as needed. |

#Common Anti-Patterns and How to Avoid Them

#Consequences

Good consequences:

• durable names become shorter because the ontology is carried by the right pattern, not by compound labels;

• role-description labels stay usable without becoming assignment, capability, method, or evidence claims;

• U.Type names become easier to bridge because their Concept-Set row is explicit;

• E.10 repair cases that uncover durable naming issues use the direct F.5 or F.18 naming discipline instead of inventing ad hoc word replacements.

Costs:

• authors must recover kind and meaning source before naming;
• some familiar source labels cannot be promoted as FPF Tech labels;
• public or cross-context names may require F.18, F.17, and F.9 even when the local name looks obvious;
• source text that used Role for status, evidence, access, or relation position must be repaired by ontology, not by suffix editing.

Reopen F.5 when role-description label morphology, U.Type neutrality rules, Tech and Plain label relation, alias lineage, or cross-context naming boundaries change. Reopen neighboring patterns when the dispute is about the named object itself.

#Rationale

Naming is late ontology, not early decoration. FPF can tolerate many local phrases, but durable names become references used in reasoning, search, publications, and pattern relations. If a name is wrong, subsequent users inherit a false kind claim.

The key design choice is to split naming by meaning source rather than by source spelling. Role in a source phrase may refer to a work-facing role, a policy term, a status label, an evidence-use relation, a relation position, or ordinary English. F.5 does not decide by suffix. It recovers the current value and then applies naming discipline.

This also keeps F.5 smaller than F.18. F.18 governs the fuller local-first naming protocol, Name Cards, candidate fronts, lineage, and public naming. F.5 supplies the special discipline needed by U.Type names and RoleDescription labels so that Part F does not preserve role and status fusion.

#SoTA-Echoing and Source-Use

Source-use boundary: external labels are evidence for local meaning or common practice, not automatic FPF Tech labels. A source term becomes the selected label only after the governing Concept-Set row, role-description episteme, or direct relation pattern admits it.

#Relations

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

Coordinates with. A.2.1 for role assignment; A.2.2 for capability; A.2.5 for role state; A.2.7 for role relation structure and role-algebra lens use; A.6.5 for relation-slot names; A.15 for role-method-work alignment; F.8 for mint-or-reuse; F.9 for cross-context bridges; F.10 for status mapping; F.13 for aliases and continuity; F.14 for anti-explosion; F.15 for harness checks; F.17 for public term-sheet use.

Used by. Part F unification patterns, role-description authors, Concept-Set authors, E.10 repairs that uncover naming rather than only phrase-use issues, and any FPF pattern that creates a durable local name for a U.Type or work-facing role label.

Does not replace. Direct evidence-use, status-use, requirement-use, source-use, publication-use, assurance, gate, decision, relation-signature, method, work, or architecture patterns.

#Footer Marker

#F.5:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)