#Mint or Reuse? (U.Type vs Concept-Set vs Role Description vs Alias)

F.8 · Stable · Architectural pattern · 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: Architectural pattern Status: Stable Normativity: Normative unless marked informative

Plain name. Name admission decision.

#Keywords

• decision lattice
• type explosion
• reuse
• minting new types
• parsimony.

#Relations

#Content

#Use This When

Plain name. Name admission decision.

Use this pattern when a project has a candidate expression and must decide whether it should stay local, reuse an existing name, become an alias, reuse a Concept-Set row, name a role-description episteme, introduce a new Concept-Set row, introduce a policy id, or become a rare U.Type candidate.

Typical moments:

• a role-like expression such as ReviewerRole, AccessRole, EvidenceRole, RequirementRole, ProviderRole, or "actor" appears and the project must decide whether it names a work-facing U.Role, a status-use relation, an evidence-use relation, an access or policy term, a relation position, or only a local phrase;
• a source tradition uses a convenient name, but the name would import one context's ontology if promoted as an FPF name;
• a Concept-Set row seems reusable, but its scope may be only naming, not substitution, role assignment, measurement, or structural inference;
• a project wants a new U.Type, policy id, role-description label, or public term because no existing name feels comfortable;
• an E.10 repair discovers that a smoother word would still hide the current kind or relation.

Primary EntityOfConcern. The EntityOfConcern is one mint-or-reuse decision for one candidate expression or proposed durable name. The pattern governs the decision relation. It does not define the named U.Type, does not describe the U.Role, does not assign a holder, does not assert status, does not provide evidence, and does not make a publication authoritative.

Primary working reader. The first reader is an engineer-manager, analyst, method author, pattern author, or terminology steward deciding whether a candidate expression deserves durable FPF treatment.

First useful move. Recover what the candidate expression is trying to name in the current bounded context. Then choose the smallest admissible decision: local phrase, alias, local name reuse, Concept-Set row reuse, RoleDescription label, direct-pattern name, policy id, new row, or rare U.Type candidate.

What goes wrong if missed. A convenient label becomes a new ontology. A source word becomes global. A status, evidence, access, requirement, source, publication, or relation-position use gets named as a role. A Concept-Set row is used beyond the scope admitted by its bridge evidence. FPF then accumulates duplicate kinds where it needed a smaller decision.

What this buys. Teams can reuse names without growing FPF by accident. Durable names become harder to mint, but easier to trust. Role expressions become work-facing role names only when the role ontology is actually current; other expressions go to their direct patterns before any durable naming.

Not this pattern when.

• If the issue is ordinary phrase repair with no durable name, use E.10, E.10.ARCH, A.6.P, or the direct governing pattern.
• If the issue is choosing a good label after the mint-or-reuse decision is already made, use F.5 for the local name family and F.18 for the fuller public naming protocol.
• If the issue is describing one work-facing role, use F.4.
• If the issue is assigning a holder to a role or attributing performed work, use A.2.1, F.6, and A.15.1.
• If the issue is cross-context sameness, use F.9 and F.7.
• If the issue is status, evidence, source, standard, requirement, publication, assurance, gate, or decision use, use the direct pattern before naming.

#Problem Frame

Name pressure is often a sign of unresolved ontology. A project wants one short expression, but the expression may stand for several different values: a local sense, a reusable row, a role-description label, a status value, a method name, a work occurrence label, a policy id, or a new U.Type candidate.

The dangerous shortcut is to decide by word form. If the word contains Role, it is treated as a role. If the word appears in two contexts, it is treated as the same concept. If a source standard uses the name, the name is promoted. If the expression is short and readable, it becomes public vocabulary.

F.8 delays naming until the current kind and use are recovered. It is the gate between local expression and durable name, not the naming style guide itself.

#Problem

Without this pattern:

1. Local phrases become durable names. A temporary phrase outlives its context and looks like FPF vocabulary.
2. Source names capture FPF. One tradition's word becomes the selected FPF name before cross-context fit is shown.
3. Role expressions become role ontology. EvidenceRole, RequirementRole, AccessRole, or ProviderRole is promoted without checking whether a work-facing U.Role exists.
4. Role names hide assignments. A RoleDescription label is treated as proof that a holder has the role.
5. Concept-Set rows overreach. A row admitted for naming is reused for assignment, measurement, or structural inference.
6. Aliases change meaning. A prettier label is introduced but silently changes kind, scope, or use.
7. Kernel inflation follows comfort. A new U.Type is proposed because existing names feel awkward.
8. Policy ids appear as strings. A policy identifier is reused or introduced without a resolvable policy specification and decision trace.

#Forces

#Solution

Treat mint-or-reuse as a typed decision over a recovered candidate, not as a vote on wording. Use this compact relation:

MintReuseDecision:
  CandidateExpressionSlot:
  BoundedContextSlot:
  RecoveredKindOrRelationSlot:
  LocalSenseRefSlot:
  ProposedUseSlot:
  ReuseCandidateRefSlot:
  DecisionKindSlot:
  DirectPatternRefs:
  NameDisciplineRefs:
  NonAdmissibleOverreadSlot:
  ReopenConditionSlot:

DecisionKindSlot is a local field for the result of this pattern. It does not create a new U.* kind.

Admissible decision kinds:

• localPhraseOnly;
• reuseLocalSenseLabel;
• aliasOnly;
• reuseConceptSetRow;
• nameRoleDescription;
• nameDirectPatternValue;
• introducePolicyId;
• proposeConceptSetRow;
• proposeUTypeCandidate;
• blockOrLowerUse.

#Decision Targets

#Decision Sequence

Use this order. Stop at the first result that fits the recovered kind and use.

1. Recover the current claim. Name the bounded context, local sense if known, and the kind or relation being claimed.
2. Split mixed candidates. If one expression covers role, status, evidence, work, method, measurement, or structure at once, split it before deciding.
3. Check local reuse. If one bounded context already has the needed local sense, reuse its label inside that context.
4. Check role expression. If the candidate describes one work-facing U.Role, use F.4 and F.5. If it asserts assignment or performed work, use A.2.1, F.6, or A.15.1. If it is evidence, status, access, requirement, source, publication, assurance, gate, decision, or relation-position use, use the direct pattern.
5. Check cross-context reuse. If more than one context is current, use F.9 bridge discipline and F.7 Concept-Set row discipline. Reuse a row only for the row's admitted use.
6. Check alias. If the meaning is the same and only wording changes, use alias discipline. Do not let an alias change kind or scope.
7. Check policy id. If the candidate is a policy identifier, require PolicyIdRef discipline in F.8:8.1.
8. Propose new row. If the need recurs across contexts and bridges admit the intended use but no row exists, propose a small Concept-Set row.
9. Propose new U.Type only rarely. Use this only when the candidate is cross-family, irreducible to existing FPF values, and governed by an accepted decision record.
10. Block or lower. If none of the above is true, keep the expression local, quote it as source wording, or lower the claim.

#Role Expression Boundary

A role expression becomes a durable role name only when it names one work-facing U.Role or the role-description episteme for that role in one bounded context.

#Row Scope Consumption

F.8 consumes row scope; it does not define bridge strength. F.9 declares bridges and F.7 declares Concept-Set rows. F.8 asks whether the row's declared use is enough for the proposed name.

If the row does not admit the intended use, lower the name's use or open the direct bridge or row repair. Do not strengthen a name because the wording is attractive.

#Invariants

1. Kind before name. The candidate's recovered kind or relation comes before the label decision.
2. One decision, one current use. Mixed uses are split into separate decisions.
3. Local before cross-context. Reuse local sense labels before proposing cross-context rows or new U.Types.
4. Aliases are meaning-preserving. An alias cannot change kind, scope, use, or authority.
5. Role names are work-facing. A role name or RoleDescription label must point to a work-facing U.Role; status, evidence, access, source, publication, requirement, assurance, gate, decision, and relation-position uses are direct-pattern names.
6. Role assignment is not naming. A name does not assign a holder or prove performed work.
7. Rows do not exceed their admitted use. F.8 may reuse a row only at the use declared by F.7 and admitted by F.9.
8. New U.Type candidates are rare. Cross-family recurrence and irreducibility are necessary; an accepted decision record governs the change.
9. Policy ids are resolvable. A policy id needs a policy specification reference and, when introduced, a mint decision reference.
10. Source labels are not semantic authority. A source term can be evidence for a local sense or alias, not automatic FPF vocabulary.

#Reasoning Primitives

Candidate expression E has no recovered kind or relation
  -> do not mint; run E.10 or direct precision restoration first.

E names one local sense in context C
  -> reuse local label in C unless durable public use is current.

E names one work-facing Role R in context C
  -> use F.4 and F.5 for RoleDescription naming; use A.2.1 for assignment.

E names an episteme-use, status-use, policy-use, source-use, or relation-position case
  -> recover the direct pattern before any durable name is selected.

E needs cross-context reuse
  -> use F.9 bridge plus F.7 row; F.8 only consumes the admitted row use.

E is a proposed new U.Type
  -> require irreducibility, cross-family recurrence, and an accepted decision record.

#Worked Cases

#Reviewer Role vs Review Report

The expression ReviewerRole in PatternReview_2026 names a work-facing role value. F.8 admits nameRoleDescription: use F.4 for the role-description episteme and F.5 or F.18 for the label.

The expression "review report has reviewer role" is different. The report is an episteme. It may be used as evidence or source for an adequacy claim about the reviewed pattern; it does not hold the work-facing role. F.8 does not mint a role name for the report. It sends the case to evidence-use, source-use, or publication-use patterns.

#Actor Across BPMN and PROV

A manager wants one word, "actor", for BPMN participant and PROV agent in a diagram. F.8 asks for the intended use. If the Bridge Card and Concept-Set row admit only naming use, the result is reuseConceptSetRow for prose and diagram labels only.

No role assignment follows. If the project subsequently needs a work-facing role in one context, it creates or reuses the local role-description episteme for that context.

#Access Role

An access-control source says ApproverRole. In that source, the expression may name a permission grouping. F.8 first recovers the access or policy relation. Only if the project also defines a work-facing U.Role for approval work in a bounded context does a RoleDescription label become current.

Otherwise the durable name, if needed, belongs to the access, policy, status, or gate pattern, not to role ontology.

#Policy Id

A gate profile introduces Aut-Guard-2026. F.8 treats this as a policy-id decision. Reuse requires a resolvable PolicySpecRef. New introduction also needs a MintDecisionRef or equivalent accepted decision record.

The policy id is not a role, method, gate result, evidence value, or source authority by itself. It is a reference to a policy specification used by the pattern that governs the policy claim.

#New U.Type Candidate

A team proposes U.InfluenceEdge because many documents use "influence". F.8 blocks immediate minting. The team must show the candidate is not an existing relation, causal claim, evidence relation, characteristic, method relation, or bridge relation under current patterns. If it is still cross-family, irreducible, and needed by several domain families, the proposal goes to A.8, C.3, E.9, and F.18.

#Filled Decision Records

MintReuseDecision:
  CandidateExpressionSlot: ReviewerRole
  BoundedContextSlot: PatternReview_2026
  RecoveredKindOrRelationSlot: U.Role described by one RoleDescription episteme
  LocalSenseRefSlot: review-work role in PatternReview_2026
  ProposedUseSlot: durable local RoleDescription label
  ReuseCandidateRefSlot: no existing local role-description label fits
  DecisionKindSlot: nameRoleDescription
  DirectPatternRefs: F.4, F.5; F.18 if public reuse becomes current
  NameDisciplineRefs: role label must not encode assignment, capability, method, work, evidence, or status
  NonAdmissibleOverreadSlot: this decision does not assign Alice, prove review work, or make a review report evidence
  ReopenConditionSlot: reopen if the label is used for evidence, status, access, source, publication, or cross-context row claims

MintReuseDecision:
  CandidateExpressionSlot: EvidenceRole
  BoundedContextSlot: PatternReview_2026
  RecoveredKindOrRelationSlot: evidence-use relation around a review-report episteme
  LocalSenseRefSlot: review report used as evidence for an adequacy claim about the reviewed pattern
  ProposedUseSlot: durable name requested for repeated evidence-use wording
  ReuseCandidateRefSlot: no U.Role candidate, because the episteme is not a role holder
  DecisionKindSlot: nameDirectPatternValue or blockOrLowerUse
  DirectPatternRefs: A.10, B.3, G.6, or direct evidence-use pattern
  NameDisciplineRefs: F.5 or F.18 only after the evidence-use relation is recovered
  NonAdmissibleOverreadSlot: do not mint EvidenceRole as RoleDescription or U.Role
  ReopenConditionSlot: reopen if the evidence-use relation changes target claim, polarity, provenance, assurance use, or validity window

#Conformance Checklist

#Policy-Id Mint-or-Reuse Discipline

FPF treats policy ids such as Phi(CL), Phi_plane, Psi(CL^k), Aut-Guard, EmitterPolicyRef, insertion-policy ids, and acceptance-clause ids as versioned identifiers whose meaning must be recoverable. They are not "just strings", role names, or gate decisions.

PolicyIdRef:
  PolicyId:
  PolicySpecRef:
  MintDecisionRef?:
  ScopeOrNamespaceRef:

PolicySpecRef is a resolvable reference to the policy definition. It identifies the policy id, pins an edition or equivalent digest when needed, and can be found from the same publication family or cited source relation.

MintDecisionRef is a resolvable reference to the decision that introduced the policy id in the declared namespace. For FPF normative policy ids this is usually an accepted [E.9](/generated/patterns/E.9) decision record. For local non-exported policy ids, the governing gate, decision, or publication pattern may admit a smaller decision record when the local scope is explicit.

Rules:

1. No silent policy-id introduction. A newly introduced policy id carries both PolicySpecRef and MintDecisionRef.
2. Reuse is reference use. Reusing an existing policy id cites PolicySpecRef; it does not restate policy semantics as if a new policy had been introduced.
3. Gate checkability. A gate, crossing, bridge, assurance, or publication claim that depends on policy ids includes PolicyIdRef or an equivalent resolvable structure admitted by its governing pattern.
4. Policy authority stays with the governing pattern. F.8 decides introduction or reuse of the identifier; it does not decide whether the policy permits work, passes a gate, or gives evidence.

#Common Anti-Patterns and Repairs

#Consequences

Good consequences:

• durable vocabulary grows more slowly and with clearer justification;
• role, status, evidence, access, source, requirement, publication, and slot-position cases stop forming duplicate role ontology;
• Concept-Set rows keep their declared scope;
• F.5 and F.18 are used with better naming inputs because mint-or-reuse has already settled the decision kind;
• policy identifiers become checkable references instead of decorative strings.

Costs:

• authors must do kind recovery before naming;
• some attractive names remain local phrases or aliases;
• public and cross-context names may require bridge, row, naming, and decision records;
• a new U.Type becomes harder to justify.

Reopen F.8 when A.2, A.2.1, F.4, F.5, F.6, F.7, F.9, F.18, A.6.5, E.10, E.9, A.8, or policy-id publication discipline changes enough that the decision kinds or boundaries would change.

#Rationale

F.8 is placed before naming style because a naming mistake is often a kind mistake. A project should not ask "what name should we use?" until it has asked "what kind of value or relation is this, and does it deserve durable naming?"

The pattern is intentionally narrower than F.18. F.18 can run a full candidate search, Name Card, public term sheet, lineage, and bridge-facing naming protocol. F.8 supplies the prior admission decision: should this expression become a durable name at all, and if so, under which direct governing pattern?

The strict role decision is central. A role expression names a work-facing role only when U.Role is recovered. Epistemes, publications, standards, requirements, evidence, statuses, permissions, gates, decisions, methods, work, and relation positions may need names, but they do not become roles because a source phrase used "role".

#SoTA-Echoing and Source-Use

Source-use boundary: a source tradition may supply candidate words and current practice pressure. It does not select the FPF decision kind. The decision kind follows the recovered value or relation and the direct governing pattern.

#Relations

Builds on. A.7, A.8, A.11, E.10, E.10.ARCH, F.1, F.2, F.3, F.5, F.7, F.9, and F.18.

Coordinates with. A.2, A.2.1, A.2.5, A.2.7, A.6.5, A.15, A.15.1, F.4, F.6, F.10, F.13, F.14, F.15, F.17, C.3, E.9, and direct status-use, evidence-use, source-use, publication-use, requirement-use, assurance, gate, decision, method, work, characteristic, and architecture patterns.

Constrains.

• F.5 names only after F.8 has decided what kind of naming case is current.
• F.4 governs only work-facing role-description naming cases.
• F.9 and F.7 govern cross-context row admission before F.8 reuses the row label.
• F.18 expands durable public naming after F.8 has admitted the name decision.
• F.14 and F.15 use F.8 to avoid role, status, row, and alias explosion.

Does not replace. Direct governing patterns for the named value, role assignment, performed work, status, evidence, source, publication, requirement, assurance, gate, decision, method, work, relation-slot, characteristic, architecture, or mathematical-lens claims.

#Didactic Memory

Do not ask for a better name first. Ask what the expression is trying to name, whether that value already exists locally, whether any cross-context row admits the intended use, and whether the expression is really a role, status, evidence, policy, source, slot, method, work, or type case. Mint only after reuse, alias, direct-pattern naming, and row options have failed.

#Footer Marker

#F.8:End

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