#System-Role Kinds and Assignments

A.2 · Stable · Architectural (A) · Normative unless marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Plain name. Work-facing system classification and assignment.

#Keywords

• system-role kind
• local System classification
• U.SystemRoleAssignment
• holder System
• assignment
• work-facing contribution
• ambiguous role wording.

#Relations

#Content

#Use This When

Plain name. Work-facing system classification and assignment.

Use this pattern when one admitted U.System can contribute to different work or functioning without becoming a different system, and the current claim must say either:

• which exact work-facing kind the system counts under now; or
• which system-role assignment actually obtains.

A system here is any individual independently admitted by A.1. It can be a person, team, organization, service, organism, or non-human technical object. The SystemRole head in a name such as ReviewerSystemRole says that candidates are systems.

Typical moments:

• the same pump counts as a cooling circulator in plant operation and as a test article in qualification work;
• a project must decide whether Alice counts as a reviewer in one review slice;
• a relied-on claim says that a system holds a named system role but leaves the assignment occurrence unclear;
• ordinary wording says that a publication, method, capability, or relation participant “plays a role”, although the direct relation is still hidden;
• a proposed “part of a role” may instead be another kind, a relation among kinds, an assignment-state predicate, a capability condition, a responsibility or commitment relation, or a method or Work structure.

Primary EntityOfConcern. One exact local U.Kind whose candidates are U.System individuals and whose operative membership condition distinguishes a stable, assignable, work-facing contribution. C.3 recovers the kind through that candidate domain and condition, a useful member/non-member boundary, and a continuity rule. A practice or source reference may locate the definition or prompt comparison; it does not identify the kind. Such a kind is called a system-role kind. Assignment is a neighboring direct relation, not part of the kind.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who must keep system identity stable while making classification and assignment inspectable. A later reader must be able to recover the kind's candidate domain, work-facing membership condition, member/non-member boundary, continuity rule, declaration edition, candidate and slice, useful definition provenance, and any separately obtaining assignment and Work attribution.

First useful move. Start with the ordinary conclusion: “Alice counts as a reviewer for this submission” or “PumpUnit-3 is assigned as cooling circulator for this operating episode.” For classification, name the local system-role kind and evaluate the candidate with one KindSignature under C.3.2. Add a U.SystemRoleAssignment occurrence only when holding or assignment identity is actually claimed.

What goes wrong if missed. One label absorbs kind identity, classification, holder, assignment, capability, responsibility, and Work. Or every contribution is forced into a system role even when the real claim concerns evidence use, a relation participant, a declaration slot, or ordinary wording. In both cases readers cannot tell what exists, what merely describes it, and what actually happened.

What this buys. Systems retain their identities while work-facing classifications and assignments change. Membership is testable from the system features named by the membership rule rather than labels or circular hierarchy edges. Practices and sources may reuse one kind or define different kinds; comparing their exact distinctions decides which. Ordinary contribution wording can stay readable without manufacturing an ontology.

Not this pattern when.

• Use A.2.1 when the current object is a U.SystemRoleAssignment species or occurrence and its participant, predicate, or identity law matters.
• Use A.2.2 for capability and A.2.5 for assignment state.
• Use A.2.7 for substitution, incompatibility, bundle, qualification, or another admitted relation among system-role kinds.
• Use A.15 and its neighbors for method admission, planned Work, performed Work, and Work attribution.
• Use E.24.UK when a local system-role kind is proposed as a durable public FPF U-kind.
• Use E.10.ROLE when the source word role is ambiguous. If the recovered meaning is relation participation, a declaration place, an interface place, or a representation position, continue with A.6.RSIR.
• When an episteme rather than a system is current, recover its direct use, evidence, publication, external-rule, currentness, or reliance relation through the relevant subject pattern.

#Problem Frame

One system can contribute in several ways while remaining the same system. PumpUnit-3 remains the same pump when it counts under CoolingCirculatorSystemRole for plant operation and under TestArticleSystemRole for qualification. A person remains the same person while counting under author and verifier kinds in different slices and holding different assignments.

These are local typed distinctions, not durable universal kinds. Each system-role kind has U.System candidates and a condition that distinguishes the stable, assignable contribution in question. C.3 also requires a useful member/non-member boundary and a continuity rule. Practice or source provenance helps readers find and compare the definition but decides neither sameness nor difference. A KindSignature edition states how candidate features are evaluated. A C.3.2 judgment then answers whether one System counts under that kind in one slice. A separate assignment occurrence says that a System is assigned under its declared U.SystemRoleAssignment species.

Ordinary language also uses role to mean contribution or position. A design method can use a standard publication as a source for a constraint; a report can participate in an evidence relation; and a value can fill a relation slot. Those useful claims make neither the episteme nor the slot filler a system-role kind or assignment participant. The current relation must be recovered before the wording carries an FPF technical claim.

#Problem

Without this pattern:

1. one system's changing contributions are modeled as changes of system identity;
2. a familiar label or taxonomy row is treated as a kind and as proof of membership;
3. kind identity and the membership criterion are treated as the same thing;
4. an assignment is used as a family-wide membership rule, or classification is used to manufacture an assignment;
5. the holder, kind, assignment interval, capability, responsibility, and Work are compressed into one record;
6. matching labels across local practices, sources, or editions are treated as identity or permission for reuse;
7. proposed subkind edges or extension rows create their own membership evidence;
8. ordinary role wording turns epistemes, slots, positions, or interfaces into system-held roles.

#Forces

#Solution

Use an exact local U.Kind when U.System candidates need one stable, assignable, work-facing membership distinction. Recover the kind through the candidate domain, operative condition, useful member/non-member boundary, and continuity rule. Keep practice or source provenance as a locator and comparison cue. Give a live technical name the SystemRole head, such as ReviewerSystemRole or CoolingCirculatorSystemRole. Do not introduce U.SystemRole; the concrete value is already a local U.Kind under C.3.

Then keep four moves separate:

1. identify the local system-role kind;
2. declare or select the KindSignature edition used for membership;
3. evaluate one system, kind, signature edition, and slice under C.3.2;
4. add a directly declared U.SystemRoleAssignment species and occurrence only when an assignment actually obtains.

Capability, assignment state, method admission, performed Work, responsibility, commitment, permission, authority, evidence, reliance, and publication remain direct neighboring claims.

#Recognize a System-Role Kind

A local kind is a system-role kind only when all of these conditions hold:

1. its candidate ValueKind is U.System;
2. its operative membership condition states the stable, assignable, work-facing contribution and uses directly governed candidate features;
3. at least one intended member and one relevant non-member or boundary case make the distinction testable;
4. its continuity rule says which changes preserve that distinction and which require another kind; and
5. its KindSignature does not treat a label, taxonomy row, description, assignment record, classification judgment, extension row, or proposed U.SubkindOf edge as the feature by form.

The kind asks what continuing distinction classifies candidate systems. A particular C.3.2 judgment asks whether one system satisfies the current signature now. Practice or source provenance shows where to inspect the definition; it neither creates nor splits the kind. CoolingPumpKind is not thereby a system-role kind. Its identity can be a physical or functional pump distinction rather than an assignable work-facing contribution. ShortAssignmentKind, if declared to classify assignment occurrences by duration, is also not a system-role kind because its candidates are assignments rather than systems.

#Evaluate Membership without a Circular Shortcut

Each membership clause names the candidate feature's subject pattern, predicate or governed feature, applicability, dependencies, and slice. The classification has four explicit inputs:

J(candidateSystem, systemRoleKind, kindSignatureEdition, contextSlice)
  -> true | false | unknown

An assignment may be one feature only when the local KindSignature explicitly uses that independently obtaining assignment predicate. There is no family-wide rule that assignment means membership. The judgment being computed, a broader-kind judgment, an extension row, or the proposed U.SubkindOf occurrence cannot be a premise of the same judgment.

For an admissible candidate and slice, a known failed criterion gives false; missing support for a required feature or an unavailable dependency gives unknown. Evidence supports a claim about the governed feature; it does not create that feature or the membership result.

Every U.SubkindOf proposal evaluates the aligned narrower and broader signatures independently for the same candidate and slice. Admit the order only when the C.3.1 monotonicity condition holds. The edge records an already established implication; it never produces either classification judgment.

#Keep Kind Identity, Declaration, and Extension Separate

The system-role kind is not its KindSignature, taxonomy episteme, reference scheme, classification judgment, or KindExtension. Same-kind continuity across declaration editions requires the C.3.1 comparison of candidate domain, operative membership distinction, member/non-member boundary, and continuity rule. A compatible criterion or scheme edition can preserve the kind while later judgments cite the edition actually used. A changed source or practice triggers that comparison but does not decide it.

An old role taxonomy or scheme can help recover the candidate domain, membership distinction, boundary probes, continuity rule, or provenance of the current definition. Its label or identifier does not decide sameness. A selected BoundedModelUseStructure can qualify one receiving interpretation when that independently established organization matters; it is designated in the receiving assertion or use and is stored neither on the kind nor as an optional participant of a generic assignment or kind relation. A genuinely structure-dependent relation species instead declares the structure as a required participant, uses the stronger predicate, and states the resulting occurrence-identity law.

Use A.1.1 before citing that structure. Select BoundedModelUseStructure only when exact model applicability, actual model use in assigned Work, fixed-content expression coherence, exact applied constraints, and one named selection-use frame jointly change the receiving decision. If the direct kind, relation, assertion, or Bridge already answers the question, stop there; neither a model-use label nor a wish for more background selects the structure.

#Admit Only Exact System-Role-Kind Domains

U.Kind is too broad as the assigned-kind participant domain of an assignment species. Each bounded system-role vocabulary declares one local domain whose candidates are local kinds satisfying the recognition conditions above. For example:

JournalReviewSystemRoleKindDomain : U.Kind
  definitionProvenance: JournalReview-2026 (comparison cue only)
  candidateValueKind: U.Kind
  criterion:
    the candidate kind has U.System candidates, a stable assignable
    work-facing membership condition, useful boundary probes, and
    a continuity rule recovered under C.3

A direct assignment species uses that local domain as the ValueKind of its declaration-local AssignedSystemRoleKindSlot. The slot therefore rejects CoolingPumpKind, ShortAssignmentKind, and arbitrary local kinds. This is local C.3 typed use, not admission of U.Kind as a durable public root.

#Assignment Boundary

A.2.1 defines the U.SystemRoleAssignment family. The family contains directly declared relation species rather than one permissive universal signature. Every species declares:

• HolderSystemSlot : U.System;
• a declaration-local AssignedSystemRoleKindSlot whose ValueKind is one exact local system-role-kind domain;
• any additional real participants needed to distinguish that species; and
• its own obtaining predicate, applicability, and occurrence-identity rule.

A simple species can declare only the holder and assigned-kind participant meanings. A stronger appointment, authorization, or work arrangement can declare another participant meaning when its actual value changes occurrence identity. The specialized occurrence itself remains a U.SystemRoleAssignment; do not keep a second generic occurrence beside it merely for projection.

An assignment occurrence begins when its predicate starts obtaining for the fixed participants, continues over the maximal uninterrupted predicate-true interval, and ends when a participant changes or the predicate ceases to obtain. A taxonomy episteme, reference scheme, KindSignature, assertion, or interval description can interpret or describe the claim without becoming another world-side participant.

Assignment does not prove classification unless the kind's signature uses that independently obtaining relation as a feature. Classification does not create an assignment. Neither one proves capability, agency, responsibility, authority, commitment, permission, functioning, method enactment, or performed Work.

#Relations around the Kind and Assignment

Select only the objects needed by the current claim. None of these values is a “part of the role”.

SystemRoleKindDescription is an F.4 description episteme whose exact EntityOfConcern is one system-role kind. An episteme about an assignment or a relation among kinds has that assignment or relation as its EntityOfConcern instead.

#Recover Contribution Wording before Formalizing It

The phrase “the role of X” often means that X contributes to a use. Apply E.10.ROLE first. If X is an admitted system and the claim needs a work-facing classification, recover the local system-role kind and C.3.2 judgment; add an assignment only when holding is claimed. Otherwise keep X in its actual kind and name the direct relation or declaration place.

Use these recognition probes to identify the relation in the current claim. If no direct relation can yet be named, return the exact missing-governor rather than minting a system-role kind.

#System-Role Vocabularies and Relations among Kinds

A system-role-vocabulary or taxonomy episteme may state local kind names, declarations, and selected relation claims under an effective reference scheme. Each live kind needs the C.3 distinction that lets readers recover it; each judgment cites its actual signature edition. An assignment claim separately requires an obtaining A.2.1 relation.

Use A.2.7 to state one selected SystemRoleKindRelationStructure over exact local system-role kinds and admitted relations among them. A receiving use can cite an assertion about substitution, incompatibility, bundle, qualification, or another residual relation alongside separately stated assignments, state, capability, and Work. Systems and assignments are not participants of the kind-relation structure.

Algebraic, graph, matrix, embedding, or neural representations are mathematical lenses over that selected structure when a project declares the lens use. They neither create the kinds nor make a relation obtain.

#Reduced Use and Stronger Claims

Ordinary “Alice is reviewer” or “this component plays a control role” wording can remain Plain when no decision, attribution, admission, or reliance depends on another technical distinction. Do not materialize a kind, judgment, or assignment merely to decorate the sentence.

When a stronger claim appears, add only the needed object:

• the local kind and judgment when classification matters;
• the assignment occurrence when who holds what and when matters;
• the direct state, capability, method, Work, responsibility, commitment, permission, evidence, reliance, or publication relation when that relation carries the claim;
• the exact C.3.3 kind relation and, when local meanings differ, F.9 relation needed for cross-local use, without merging the kinds or creating assignments.

The earlier Plain sentence is not evidence for a stronger claim.

#Archetypal Grounding

#Reviewer Membership and a Non-Circular Subkind

The JournalReview practice records one local kind under C.3. The source label locates the definition; the kind itself is recovered through its system-candidate domain, substantive-review condition, boundary probes, and continuity rule:

ReviewerSystemRole : U.Kind
  definitionProvenance: JournalReview-2026 (comparison cue only)
  candidateValueKind: U.System
  operativeMembershipDistinction:
    can supply a substantive review judgment that meets the current
    JournalReview acceptance conditions
  intendedBoundary:
    a system that applies those conditions is a member; a report or a
    system that merely comments without applying them is not
  continuityRule:
    continue the kind only while that candidate range and distinction continue
KindSignature@ReviewerSystemRole/e3:
  EntityOfConcern: ReviewerSystemRole
  candidateValueKind: U.System
  membershipCriterion:
    one current A.2.2 capability instance has the candidate system as holder,
    names substantive-review Work or its review-judgment result class,
    and satisfies its declared envelope, measures, and currentness;
    the current JournalReview capability-fit predicate confirms the submission,
    review-phase, and judgment-quality conditions for this slice
  sliceApplicabilityConditions:
    the submission, review phase, and temporal selector
  effectiveReferenceScheme: JournalReview-Scheme-2026/e3
  assumptionsAndDependencies:
    the capability instance, currentness condition, and capability-fit predicate

The capability and fit predicate are governed under A.2.2. They are features used by the criterion, not substitutes for the kind or judgment. One application can therefore state:

J(Alice, ReviewerSystemRole, KindSignature@ReviewerSystemRole/e3, ReviewSlice-17) = true
J(Alice, ReviewerSystemRole, KindSignature@ReviewerSystemRole/e3, LaterSlice-18) = false

The later result follows only from a known failed currentness or fit condition. Ending an assignment alone changes neither judgment because this signature does not use assignment as a feature. If a dependency is unavailable, the result is unknown.

For RoboticsEngineerSystemRole U.SubkindOf EngineerSystemRole, evaluate the two aligned signatures independently for every admitted candidate and slice needed by the declared domain. Only after every defined true narrower judgment implies a true broader judgment may C.3.1 admit the relation. The proposed edge proves neither judgment. An independently obtaining robotics assignment also proves neither judgment unless the relevant signature explicitly uses it as a non-circular feature.

#Pump in a Cooling Loop

CoolingCirculatorSystemRole names a local kind whose candidates are admitted systems. Its membership condition requires the governed circulation features needed for the plant-operation contribution; member/non-member probes and the continuity rule expose the boundary. PlantOperations-2026 locates the current definition but does not identify the kind. PumpUnit-3 is judged against that exact signature edition and slice; the judgment does not change pump identity.

When the plant also claims an assignment, it uses a directly declared species:

PlantCoolingSystemRoleAssignment : U.SystemRoleAssignment
  HolderSystemSlot: U.System
  AssignedSystemRoleKindSlot: PlantOperationsSystemRoleKindDomain
  predicate:
    the holder is selected for the assigned plant-operation contribution
    under the declared operating conditions

PlantCoolingAssignment@PumpUnit3:
  HolderSystemSlot: PumpUnit-3
  AssignedSystemRoleKindSlot: CoolingCirculatorSystemRole
  assignmentInterval: [2026-06-01, open]

The interval is assertion content about the known extent; the occurrence continues only while the species predicate obtains without interruption for the same participants. PlantOperationsSystemRoleVocabulary-2026, its reference scheme, and the relevant signature can be cited as interpretation evidence. They are not extra assignment participants.

Closing the open interval later refines the same occurrence description when uninterrupted identity is preserved; the stated interval neither makes the relation obtain nor becomes another participant.

The assignment proves neither circulation capability over every operating region nor performed circulation or maintenance Work. Those claims use A.2.2, A.15.1, and the applicable Method, transformation, measurement, and evidence relations.

#A Standard Used in Design Work

An engineering team uses RFC 9110 while designing an HTTP service. Keep these claims separate:

1. DesignTeam-2 independently counts under ProtocolDesignerSystemRole in the current slice when its signature criterion is satisfied.
2. For this hypothetical assignment-bound case, suppose the practice has declared ProtocolDesignSystemRoleAssignment under U.SystemRoleAssignment according to A.2.1, and DesignAssignment-1 is one obtaining occurrence with holder DesignTeam-2 and assigned kind ProtocolDesignerSystemRole.
3. The RFC publication is the source episteme in the direct source-use or external-rule relation selected by the design claim.
4. In this hypothetical case, recover DesignTeam-2 as the exact actual performer through A.13 with that same obtaining DesignAssignment-1, then let A.15.1 independently admit the dated design Work. Suppose this Work was performed under DesignAssignment-1; F.6 afterward establishes that relation to this same assignment. F.6 identifies neither assignment nor performer, and failed attribution would leave the Work intact. The Work may separately produce a MethodDescription or SystemDescription only through the applicable production claim.

#The Same Label in Two Local Practices

An editorial-review practice and a safety-assurance practice can each use ReviewerSystemRole. Compare their exact C.3 definitions before deciding whether one kind continues. In this case the safety-assurance condition admits a materially different contribution and member/non-member boundary, so two kinds are present. The practice names help locate those definitions; a shared label, vocabulary source, or reference-scheme spelling establishes neither sameness nor a Bridge.

Suppose a staffing dashboard proposes u-reviewer-display: show assignments from both practices in one Reviewer column. First recover the two exact local kinds and any F.17 cells needed by the displayed expressions; then establish only the C.3.3 kind relation and F.9 local-sense relation that the display actually consumes. State a separate C.2.1 bounded-use assertion with direction d-safety-to-editorial-display, rule r-preserve-reviewer-differences, and tolerance t-shared-label-only, plus polarity and effective scheme. The rule keeps the practices' admission, independence, evidence, and completion fields separate and tolerates only the shared display label.

Current A.10 provenance and RelianceDisposition=pass can support that display use. They do not justify substitution between assignments or merge the two kinds. If an actual named assurance claim about that use is current, only its B.3 result can support that bounded assurance use; a non-positive disposition stops or narrows it. Consequence alone creates no assurance claim. A Bridge Card can package the Bridge, bounded-use assertion, evidence, and disposition, but it grants no assignment, eligibility, capability, use suitability, or performed-Work inference. A selected BoundedModelUseStructure is cited only in the receiving use whose interpretation it changes.

#A Relation Participant Slot Named role

An external notation may call one relation position role. Apply E.10.ROLE and A.6.RSIR to recover the participant meaning and declaration-local SlotKind. Its ValueKind is the participant kind. The external label creates neither a system-role kind nor an assignment. A System participates in the relation as declared; it holds a system-role assignment only through a separate occurrence of a declared assignment species.

#Bias Annotation

#Working Guidance

1. Identify the candidate and confirm its independent A.1 admission as U.System.
2. Recover the local kind by saying which systems can count, which work-facing condition separates members from relevant non-members, and what changes preserve that distinction. Record practice or source provenance only when it helps find or compare the definition.
3. Declare or select the exact KindSignature edition and its direct governed feature criteria.
4. Evaluate the candidate, kind, signature edition, and slice as true, false, or unknown.
5. Add an assignment only when an occurrence of a declared assignment species actually obtains.
6. State each claim about state, capability, Method, Work, responsibility, commitment, permission, authority, evidence, or reliance through the pattern that defines or constrains it.
7. Evaluate every subkind proposal from independently obtained aligned judgments; never use the proposed edge as a membership premise.
8. For cross-local use, compare the C.3 definitions first. Reuse the same kind when its distinction continues; when two kinds are present, keep both kinds distinct and establish only the exact C.3.3 kind relation, any needed F.9 local-sense relation, and bounded-use claim actually consumed. In either branch, establish assignments independently; reusing the kind neither creates assignments nor licenses their substitution or merger.
9. If the source uses role for another object, apply E.10.ROLE and continue with the recovered subject pattern; stop at missing-governor when no relation is yet admitted.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

System-role kinds solve a local classification problem. System-role assignments solve a relation-occurrence problem. The pump does not become another system because its contribution changes, and a kind does not become an assignment because one system currently counts under it.

The architecture therefore keeps these levels separate:

1. the local system-role kind, its candidate domain, work-facing membership distinction, boundary probes, continuity rule, and useful definition provenance;
2. the KindSignature and one C.3.2 judgment over a system and slice;
3. any directly declared U.SystemRoleAssignment occurrence;
4. direct neighboring relations for state, capability, Method, Work, responsibility, commitment, permission, authority, evidence, reliance, description, and publication.

Fields in a SystemRoleKindDescription belong to the description episteme. Proposed “parts” repeatedly resolve into other kinds, relation predicates, assignments, Method or Work structures, or parts of description epistemes. The useful structure for relations among system-role kinds is the exact relation structure governed by A.2.7. Resolve the other proposed “parts” through their subject patterns (§4.6), not role mereology.

Semantic locality needs no universal context participant. C.3's candidate domain, operative membership distinction, boundary probes, and continuity rule recover the kind. A practice or source reference locates the definition and warns where comparison may be needed; it is not an identity participant. An assignment species declares only its real participants. A receiving assertion or use can cite a selected model-use structure when that structure actually changes interpretation.

#SoTA-Echoing

A modeling notation does not decide the identity of a system-role kind, classification judgment, assignment occurrence, participant slot, responsibility relation, or Work.

#Relations

Builds on: A.1 for system admission; A.1.1 for selecting a BoundedModelUseStructure only when its complete decision-relevant relation organization, applied constraints, and named selection-use frame are current; C.3, C.3.1, and C.3.2 for local kind identity, declaration, classification, extension, subkind, and continuity; A.6.0, A.6.5, and A.6.REL for assignment declarations and occurrences; C.2.1 for interpretation and assertion epistemes.

Governs with: A.2.1 for system-role assignments; A.2.2 for capability; A.2.5 for assignment state; A.2.7 for relations among system-role kinds; A.15 and F.6 for Method-Work alignment and attribution; F.4, F.5, and F.18 for description and naming.

Crosses locality through: C.3.3 for exact local kinds, F.9 for relations between exact F.17 cells, and A.6.9 for ambiguous sameness wording across local boundaries, followed by a bounded-use assertion and current reliance when the receiving action needs them. A matching name, Bridge, card, or selected model-use structure creates neither identity nor assignment.

Keeps separate from: responsibility, commitment, permission, authority, state, capability, Method, Work, evidence, reliance, publication, external-rule, and currentness relations. Apply E.10.ROLE to ambiguous wording and A.6.RSIR only when relation participation or its declaration must be recovered.

#A.2:End

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