#Anti-Explosion Control for System-Role and Status Name Families

F.14 · Stable · 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.

"Name less; recover the governed values first."

Type. Architectural pattern. Status. Stable. Normativity. Normative. Builds on: A.2 for exact context-local system-role kinds; A.2.1 for U.SystemRoleAssignment; A.2.5 for assignment-state predicates and direct state relations; A.2.7 for exact substitution, incompatibility, qualification, and bundle relations among system-role kinds; A.15.1 for performed Work; F.4 for system-role-kind descriptions; F.5 for local naming discipline; F.8 for one mint-or-reuse decision; F.9 for actual relations between exact local senses; F.10 for status families and windows; F.18 for durable naming; and A.6.5 for relation-slot discipline.

Coordinates with: A.2.2 for capability, A.3.1 and A.3.2 for Method and MethodDescription naming, A.10 and B.3 for evidence and assurance use, E.10.D2 for description use, E.24.PUB for publication occurrence, expression form, and carrier, and F.17 only when a public, Core-facing, durable, or cross-local term row is current.

Plain entry cues (informative). Name explosion guard; system-role-name economy; status-name economy; stop before another card or row.

Use this when. Use F.14 when proposed names, aliases, cards, local-sense cells, or rows begin to multiply faster than the independently governed distinctions. Apply its cheap stop question before minting any NameCard, SchemeSenseCell, Unified Term Sheet row, or durable name family: does an existing designation, alias, local expression, or direct-pattern name already let the practitioner perform the proposed use?

#Keywords

• vocabulary explosion
• system-role names
• status names
• designation
• assignment
• permission
• evidence use
• NameCard
• term row
• reuse.

#Relations

#Content

#Intent and applicability

Use this when. Use F.14 when proposed names, aliases, cards, local-sense cells, or rows begin to multiply faster than the independently governed distinctions. Apply its cheap stop question before minting any NameCard, SchemeSenseCell, Unified Term Sheet row, or durable name family: does an existing designation, alias, local expression, or direct-pattern name already let the practitioner perform the proposed use?

First useful move. For every candidate expression, name the one independently recovered governed value or relation, its exact kind, its direct pattern, the proposed use, and the effective naming U.ReferenceScheme. If no such value or relation is independently recoverable, keep the expression local or keep it with the exact assertion that recovers its subject or value; do not pass a value-less expression to F.8 or manufacture an object so that the name has something to denote. F.8 receives only an unresolved naming disposition for an already recovered value-or-relation and proposed-use pair, with its exact kind and direct pattern.

Intent. Keep system-role-facing, role-like, and status-like vocabularies small without losing real distinctions. F.14 is a control pass over candidate expressions and name families. It defines no system-role kind, status, assignment, sense, card, row, Bridge, or publication. It decides only whether naming pressure can stop at a smaller disposition.

Primary working object. One candidate family and one proposed use, with its recovered values and direct patterns. A durable control record is optional; no generic context object, selected structure, card, or table row identifies the pass.

Primary working reader. A method author or designer, an author of a U.MethodDescription, a terminology steward, architect, manager, or checker who sees names such as NightOperatorSystemRole, EvidenceRole, SeniorReviewer, AtRiskStatus, PreValidated, AccessRole, or RequestApproverSystemRole and must stop vocabulary growth from becoming a second ontology.

What goes wrong if missed. System-role-kind labels become capability models, status labels become system-role families, access-control labels become work-facing kinds, and every local wording difference acquires a card, sense cell, row, or identifier. The corpus then contains many near-duplicate naming objects whose apparent precision hides different kinds and uses.

What this buys. A smaller vocabulary with stronger type separation and a short stopping path: no durable name, an existing designation, an alias, or a local expression whenever one suffices; only then the smallest justified durable naming object.

Not this pattern when. Use F.8 to make the final naming disposition for one candidate expression only after its governed value or relation, exact kind, direct pattern, and proposed use have been recovered; F.14 supplies the preceding anti-explosion stop rather than a second decision record. Assignment claims go to A.2.1. For precise performed Work, A.13 first recovers each exact actual performer and A.15.1 independently admits the dated occurrence; F.6 is added only when the naming case or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. Status, evidence, authorization, publication, and other relation claims require exact predicates in their direct patterns. Add a reader-facing F.17 row only after kind recovery, the F.14 stop, any needed F.8 or F.18 naming decision, and satisfaction of the public-row threshold; treat publication availability as a separate E.24.PUB question.

Recognition versus assurance. Recognition is the visible name-growth pressure plus the first kind-and-use recovery. Assurance is the optional record, invariants, worked countercases, and conformance tests. Neither turns F.14 into naming authority or ontology.

#Problem frame

Name explosion usually begins with a helpful shortcut:

1. Hybrid-system-role shortcut. RequestApproverSystemRole, DevOpsEngineerSystemRole, or IncidentLeadOnCall is minted because several local system-role kinds often appear together.
2. Modifier-as-system-role shortcut. NightOperatorSystemRole, RemoteOperatorSystemRole, or APIApproverSystemRole is minted because a qualifier is visible.
3. Status-as-type shortcut. AtRisk, Grace, PreValidated, or TemporarilyBreached is minted as if time stance or status value were a new essence.
4. Source-suffix shortcut. EvidenceRole, RequirementRole, AccessRole, or ProviderRole is minted because a source tradition uses role-like language.
5. Prestige shortcut. SeniorReviewer or LeadApprover is minted to bypass a separation, capability, or assurance question.
6. Locality shortcut. The same spelling under two local-sense bases is treated as one value, or every difference is answered with a Bridge, card, cell, and row before a receiving use exists.

F.14 prevents those shortcuts from becoming durable ontology or automatic naming infrastructure.

#Forces

#Core idea

Use this sequence before minting a durable name or any supporting naming object:

1. Recover the governed value first. Split candidate expressions into exact local system-role kinds, SystemRoleKindDescription epistemes, direct relation kinds or occurrences, assignments, Work, capability, Method, status, evidence, source, publication, requirement, policy, local-sense, and local-phrase cases. Each retained value keeps its exact kind and direct pattern.
2. Name one proposed use and its interpretation basis. State what the reader will do with the expression and the effective naming U.ReferenceScheme. An independently selected BoundedModelUseStructure appears only when that organization changes this exact naming use; it is never a generic locality field.
3. Try the light dispositions in order. Prefer no durable name, an existing designation, a recorded alias, a local expression, an existing direct-pattern name, or an existing public row. Stop as soon as the proposed use works without hiding a governed distinction.
4. Create only the next object that pays for itself. A local SchemeSenseCell is useful only when the exact local sense needs a stable address; a NameCard only when the naming settlement itself must endure; an F.17 row only for public, Core-facing, durable, or cross-local reuse; E.24.PUB only when the selected row edition must actually be made available. None implies the next.
5. Use exact relations instead of fused names. Bundles and incompatibilities among system-role kinds remain A.2.7 relations; assignment claims remain A.2.1. For precise performed Work, A.13 first recovers each exact actual performer and A.15.1 independently admits the dated occurrence; F.6 follows only when the naming case or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. Status families and windows remain F.10; qualifiers remain with their direct patterns.
6. Treat cross-local wording as a relation question only when one is current. Resolve the exact local senses first. Same spelling proves nothing; different local-sense projections only open F.9. Cite a Bridge only when its predicate obtains, then state the proposed use and reliance separately. A Bridge does not merge governed values or require a public row.

The result is the smallest naming disposition that preserves the exact governed value and supports the named use. It is not a claim that any value, relation, assignment, Work, evidence, status, authority, or publication exists.

#Minimal vocabulary

• Anti-explosion control pass — one bounded review of related candidate expressions before durable naming objects are added.
• Candidate name family — proposed expressions that appear to cover related system-role, status, Work, evidence, source, capability, Method, policy, or local-sense concerns.
• Recovered governed value — the exact typed value or relation the expression is trying to designate, under its direct pattern.
• Naming use — the exact reader or practitioner action for which the expression is being considered.
• Light disposition — no durable name, existing designation, alias, local expression, or existing row reuse.
• System-role-kind relation expression — an expression designating an exact A.2.7 substitution, incompatibility, qualification, or bundle relation rather than another local system-role kind.
• Status-family expression — an expression for a status family, value, window, confidence claim, or status-use relation defined under F.10 or a direct status pattern.
• Blocked minting — the explained result that the candidate remains a light disposition or direct-pattern expression rather than a new durable name or naming object.

#Optional anti-explosion record

Ordinary use needs no record: recover the value, choose the lightest sufficient disposition, and stop. Persist this C.2.1 description episteme only when several related candidates, a contested decision, or later replay makes the family-level reasoning useful.

AntiExplosionControlRecord:
  CandidateNameFamily:
  ProposedNamingUse:
  EffectiveNamingReferenceScheme:
  CandidateExpressionRefs:
  RecoveredGovernedValueRefs:
  GovernedValueKindRefs:
  PatternContributionByClaimOrValue:
    - ClaimOrValueRef:
      PatternRef:
      Contribution: defines | constrains | tests
  ExistingDesignationOrAliasRefs:
  LocalSenseRefsOrCellRefs?:
  LocalSenseBasisRelationRefs?:
  ModelUseStructureRef?: only when an independently selected structure changes this use
  ExactSystemRoleKindRelationRefs?:
  AssignmentOrWorkRefs?:
  StatusFamilyOrWindowRefs?:
  QualifierOrDirectPatternRefs?:
  ActualBridgeRefs?:
  BlockedMinting:
  DurableNamingRefs?:
  RemainingLocalExpressions:
  ReopenTrigger:

The record describes the control result. It creates no governed value, naming decision occurrence, designation, local sense, Bridge, row, publication, evidence, system-role kind, status, assignment, or Work. A field is omitted when its object is not independently current; filling the record is never a completeness goal.

#Levers

#Recover kind before naming

#Reuse before minting

Reuse only when the exact recovered value, kind, direct pattern, proposed use, and admitted naming scope match. Try an existing designation, alias, local expression, or current row before creating a card, cell, row, policy id, or new U-kind candidate. Local-sense reuse does not imply sameness with another local sense; row reuse does not widen the row's admitted use.

#Use relations among system-role kinds before hybrid kinds

If two system-role kinds travel together, recover the exact A.2.7 bundle or qualification relation. If they must stay apart, recover the exact A.2.7 incompatibility. Use A.2.1 and any applicable A.2.5 currentness condition to identify the assignment occurrences. Use F.6 only when the receiving claim separately says that dated Work was performed under one of those assignments. If one kind can satisfy another requirement, recover exact substitution. The relation expression assigns no system and does not become a new kind by name.

#Use a status window before multiplying status families

If the proposed name marks evaluation, active use, grace, archival state, confidence, or presentation, keep the status family and use F.10 windows, values, or direct status-use relations. A new status family needs a recovered governed difference, not another adjective.

#Keep qualifiers with the claims they qualify

Time, location, object type, seniority, permission, Method, capability, evidence, source, and publication are not system-role-kind or status identity by suffix. Keep a qualifier with the claim it qualifies and use the pattern that defines, constrains, or tests that claim. Retain the qualifier in a durable name only when the already governed value and named use genuinely require that designation.

#Stop before a naming-object cascade

A candidate can justify one object without justifying all later objects. A durable local expression needs no cell; a stable local sense may need a cell but no NameCard; a durable naming settlement may need a NameCard but no public row; a row may exist without a current publication occurrence; publication availability creates neither row truth nor governed-value truth. Apply the next gate only when its own use is current.

#Invariants

1. Governed value first. No durable naming object is added until the exact value or relation, kind, proposed use, and the pattern contribution that defines, constrains, or tests each needed claim are recoverable.
2. Lightest sufficient disposition. Prefer the dispositions no durable name, existing designation, alias, or local expression whenever one supports the use without hiding a distinction.
3. No status roles. Status, evidence, requirement, source, publication, and access uses do not become system-role kinds by suffix.
4. No assignment by name. A designation, SystemRoleKindDescription, system-role-kind relation expression, card, cell, or row assigns no system and proves no Work.
5. No hybrid kind by convenience. Exact A.2.7 relations remain relations unless A.2 with C.3 independently admits a different local system-role kind.
6. No capability or authority by label. System-role-kind and status names prove no capability, skill, permission, assurance, evidence use, Method validity, or publication authority.
7. Local senses do not globalize. Same spelling and different local-sense projections establish neither governed-value identity nor an F.9 Bridge.
8. Naming objects remain optional and distinct. Expression, designation, alias, cell, NameCard, row, identifier, publication occurrence, form, and carrier neither imply nor replace one another.
9. Selected structure is conditional. A BoundedModelUseStructure is cited only when its organization changes the exact naming use and never becomes a locality slot or naming identity field.
10. Lineage is not ontology. Historical spelling may be recorded as lineage without carrying its former fused commitments forward.

#Reasoning primitives

candidateExpression(e) and recoveredGovernedValue(e, v) and proposedUse(u)
  -> choose a naming disposition for <v,u>, not an ontology for string e.

existingDesignationOrLocalExpression(v, u) is sufficient
  -> stop; do not mint NameCard, SenseCell, row, or name family.

systemRoleKindBundleRelation(K1, K2) obtains
  -> not(newSystemRoleKind(K1K2)).

statusVariant(S, windowOrValue)
  -> keep status family S unless the pattern that defines the status claim establishes a different family.

differentLocalSenseProjections(c1, c2)
  -> test F.9 only for a named correspondence use; not(Bridge(c1,c2)) by difference alone.

namingObjectPresent(x)
  -> not(governedValueExists) and not(nextNamingObjectRequired).

These are stopping and dispatch rules. They create no values or relation occurrences.

#Worked cases

#Requester and approver

Candidate family: RequesterSystemRole, ApproverSystemRole, RequestApproverSystemRole, SeniorApprover.

Premise: the local practice has already admitted RequesterSystemRole and ApproverSystemRole as exact local system-role kinds under A.2 with C.3. If that independent basis is absent, the case returns two candidates whose kind status is unresolved; the spellings do not admit them.

Result after that premise:

• Reuse the two admitted kinds and keep separate SystemRoleKindDescription epistemes only when descriptions are needed.
• RequestApproverSystemRole is blocked as a fused kind. Use an A.2.7 bundle relation when the two kinds travel together.
• If the same holder must not carry both assignments in the same change window, use the A.2.7 incompatibility relation. Recover the two assignment occurrences through A.2.1 and any applicable A.2.5 currentness condition. Use F.6 only if a separate claim says that dated Work was performed under one of them.
• SeniorApprover is not proof of independence or assurance. Recover the intended local system-role kind, exact assignment-state predicate or relation, capability, assurance, or policy claim before durable naming.

#Operators across shifts

Candidate family: OperatorSystemRole, NightOperatorSystemRole, RemoteOperatorSystemRole, OnCallOperatorSystemRole.

Premise: A.2 with C.3 has independently admitted OperatorSystemRole as an exact local system-role kind. Without that basis, OperatorSystemRole is still a candidate name and the case makes no kind claim.

Result after that premise:

• Reuse the admitted OperatorSystemRole kind.
• night, remote, and on-call are qualifiers in the proposed wording. Recover the claim each qualifies—for example, a schedule, location relation, SystemRoleAssignmentStatePredicate, WorkPlan, or policy condition—and use the pattern that defines, constrains, or tests that claim.
• A new system-role kind is blocked unless A.2 with C.3 independently recovers a distinct local kind through its U.System candidate domain, operative work-facing membership condition, useful member/non-member boundary, and continuity rule. Its criterion may use, for example, a capability, Work, or an assignment established separately, but assignment conditions, a Method, and Work implications are not universal requirements. A practice, source, suffix, or naming ReferenceScheme does not create the kind or its difference.

#SLO compliance labels

Candidate family: Compliant, AtRisk, Grace, Breached, Waived.

Result:

• These are not system-role-kind names.
• F.10 recovers status family, status value, status window, confidence, or deontic or policy use.
• Presentation labels may stay local or be named by the direct status pattern. They do not become a system-role kind, SystemRoleKindDescription, or relation structure among system-role kinds.

#Evidence and requirement suffixes

Candidate family: EvidenceRole, RequirementRole, StandardRole, SourceRole.

Result:

• No work-facing system-role kind is recovered from suffix alone.
• Route each recovered claim separately: bounded evidence reliance goes to A.10; an actual named assurance claim goes to B.3; description-use ambiguity goes to E.10.D2 for recovery only; and publication occurrence, form, or carrier goes to E.24.PUB. A requirement, standard, source, access, or policy use goes to the pattern that directly defines, constrains, or tests that exact claim. If none exists, return missing-governor.
• A durable name may be admitted for the recovered relation, but not as a local system-role kind.

#Same spelling across two local-sense bases

A plant team uses Operator for one local system-role kind. An access-control team uses Operator for one permission grouping. Recover both independently under their direct patterns; neither spelling nor organizational proximity makes them one value.

For local use, keep the existing expressions and stop. If one named cross-local naming use is later proposed, resolve its exact F.17 SchemeSenseCell endpoints and test F.9. Cite a Bridge only when its predicate obtains, then state the use direction, rule, tolerated loss, polarity, and reliance separately. A Bridge, NameCard, cell, or row imports no access permission as U.SystemRoleAssignment, capability, authority, or performed Work. Publish an F.17 row only when the public or durable reuse threshold independently holds.

#Ordinary composite role-like phrases

A project says: "Vasya is an engineer, he works on musical robots, and he is also a musician who teaches robots to play music."

Result:

• Ordinary prose may remain robotics engineer and musician or engineer-musician when the sentence is clear and no FPF claim relies on either noun as an exact classification. Create no Tech kind merely to explain the phrase, and do not require a SystemRole suffix in ordinary prose.
• If the sentence supports a load-bearing FPF claim, apply E.10.ROLE and recover only the supported branch: for example, a local system-role kind and classification, an assignment occurrence, a capability, a participation or contribution relation, a Method or Work claim, or a finding that no pattern yet defines the needed claim. Do not infer two kinds from the two nouns.
• Any claim about an engineering or music-teaching Method, robot-training Work, or performed music Work stays under its direct pattern and remains separate from the ordinary phrase. Such a claim does not by itself justify a system-role-kind name.
• A durable qualified system-role-kind name becomes a candidate only after A.2 with C.3 independently admits that exact local kind through its candidate domain, operative work-facing membership condition, member/non-member boundary, and continuity rule. Differences in, for example, assignment conditions, capability expectations, incompatibilities, or Method or Work implications matter only when the KindSignature or named use actually consumes them. A readable suffix does not perform that admission.

#Anti-patterns and repairs

#Conformance checklist

#Regression checks

Reopen only the affected naming use when candidate expressions grow faster than recovered values; a name starts carrying assignment, capability, method, Work, evidence, status, source, publication, equivalence, or authority; a row is reused beyond its admitted use; local wording is silently globalized; or one naming object begins to imply the next. A changed spelling alone does not require a new governed value or full family replay.

#Relations

• A.2, A.2.1, A.2.5, and A.2.7 define or constrain system-role kinds, assignments, assignment-state predicates and direct state relations, and relations among system-role kinds. For precise performed Work, A.13 first recovers each exact actual performer and A.15.1 independently admits the dated occurrence; F.6 defines only the later assignment-bound attribution when that relation is expressly consumed. F.14 only blocks names that hide these distinctions.
• Use F.8 to make one candidate's smallest mint-or-reuse disposition after the F.14 stop test.
• F.9 defines only an actual relation between exact local senses. Shared spelling and cell presence establish none.
• F.17 defines the public term-row form and its entry threshold; F.18 defines the durable naming-settlement NameCard form; neither defines the governed value.
• Use C.2.1 to identify every persisted NameCard, row, or control-record episteme and its EpistemeEditionRelation; use E.24.PUB to state row publication occurrence, expression form, and carrier bearing.
• Use F.10, A.10, B.3, E.10.D2, and the direct policy, access, and source patterns for the corresponding status, evidence, assurance, description, policy, access, and source claims that often arrive with role-like suffixes.

#SoTA-Echoing

F.14 does not import access-control, terminology, credential, or modeling-language taxonomies as FPF ontology. It uses the sources below only where they change the anti-explosion rule.

SysML is intentionally excluded from the positive SoTA basis and from lineage for this pattern. The official OMG SysML 2.0 specification (September 2025) is recorded only as a rejected-popular comparison: a modeling-language role spelling does not independently establish FPF's local system-role kind, classification, assignment, capability, permission, Method, or Work. Official status and popularity are not evidence for this anti-explosion question. Reopen that rejection only if demonstrated practice supplies a directly relevant, lower-cost kind-admission and assignment boundary that improves the F.14 cases.

#Didactic distillation

When names multiply, do not ask for a better name first. Recover the exact values and the proposed use. Try no durable name, an existing designation, an alias, or a local expression. Keep relations among system-role kinds, status windows, capability, Method, Work, evidence, source, policy, and publication under their direct patterns. Create a cell, NameCard, row, identifier, or publication only when that exact object buys a named use; none requires the next and none makes the governed value real.

#F.14:End

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