#Role Description (RCS + RoleStateGraph + Checklists)

F.4 · 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. Role-description episteme.

#Keywords

• role template
• status template
• invariants
• RoleStateGraph (RSG)
• Role Characterisation Space (RCS).

#Relations

#Content

#Use This When

Plain name. Role-description episteme.

Use this pattern when a project needs a short, reusable description that makes one work-facing U.Role recognizable, teachable, and checkable inside one U.BoundedContext.

Typical moments:

• a project has a role name such as ReviewerRole, OperatorRole, InspectorRole, TransformerRole, ShipyardCoordinatorRole, or ModelCardReviewerRole, but the bounded context, admissible holder kind, role invariants, capability expectations, or work-facing boundary are unclear;
• a method description names required roles, but readers cannot tell what role value is required before a U.RoleAssignment can be checked;
• a role name is starting to carry method, capability, work, permission, evidence, publication, or status claims that belong to neighboring patterns;
• a former source phrase says that a report, standard, dataset, theorem, dashboard, publication, or requirement has a "role" and the text must decide whether that phrase is a real work-facing role description or a direct episteme-use relation.

Primary EntityOfConcern. The EntityOfConcern is the role-description episteme: a U.Episteme that describes one U.Role value in one bounded context. It is not the role value itself, not the holder, not a role assignment, not a capability, not a method description, not performed work, not a status-use relation, and not a publication form.

Primary working reader. The first reader is an engineer-manager, analyst, method author, or pattern author who must let people recognize a role while keeping role value, holder, assignment, capability, method, work, evidence use, status use, and publication use distinct.

First useful move. Name the role value being described, the bounded context that gives it meaning, the kind of holder admitted for role assignment, and the smallest set of role invariants that matters for the next assignment, method, work, naming, or bridge claim.

What goes wrong if missed. A role-description card becomes a hidden method, access policy, permission badge, evidence relation, status assertion, staffing plan, or work log. Then FPF grows one role ontology for acting holons and a second role-like ontology for epistemes, publications, statuses, and relation positions.

What this buys. A project can publish a compact, human-readable role description while keeping operational claims in their direct patterns. The role remains recognizable; the assignment remains checkable; capability, method, work, evidence, status, and publication claims stay inspectable instead of being smuggled into the role name.

Not this pattern when.

• If the current claim is the role value itself or role taxonomy, use A.2.
• If the current claim is which holder bears which role in which context and window, use A.2.1.
• If the current claim is role state or enactable-state admission, use A.2.5.
• If the current claim is role-requirement substitution, role incompatibility, role-factor qualification, or bundle expression, use A.2.7.
• If the current claim is capability, use A.2.2.
• If the current claim is method, method description, work plan, or performed work, use A.15 and its neighbors.
• If the current claim is evidence use, status use, source use, standard use, requirement use, publication use, assurance use, gate use, or decision use of an episteme, use the direct pattern for that relation. Do not call that episteme a role holder.
• If the current issue is only a durable name, use F.18.
• If the current issue is cross-context sameness or translation, use F.9.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.

#Problem Frame

Role descriptions are useful because a role value needs a recognizable description before people can assign it, name it, compare it, or use it in a method requirement. A role such as InspectorRole is not self-explanatory. The project needs to know which bounded context gives it meaning, what kind of holder can bear it, which role invariants matter, and which neighboring checks may become current.

The recurring failure is to make the role description carry too much. A compact card is tempting: put role, status, permission, evidence, capability, method, assignment, work, and publication cues into one "assignable" template. That looks convenient but creates duplicate ontology. A standard used as a requirement source becomes a "standard role"; a report used as evidence becomes an "evidence role"; an access-control label becomes a behavioral role; a role name becomes proof of capability or proof that work occurred.

F.4 therefore treats a role description as a description episteme about a work-facing U.Role. It may mention neighboring relations, but it does not absorb them.

#Problem

Without this pattern:

1. Role description and role value collapse. The description is treated as if it were the U.Role value.
2. Role description and assignment collapse. A role name or card is treated as proof that a holder has the role.
3. Role description and capability collapse. A role name is treated as evidence that the holder can do the work.
4. Role description and method collapse. Role invariants become a hidden procedure or method description.
5. Role description and performed work collapse. A role card is treated as evidence that work happened.
6. Status and evidence uses become roles. Epistemes, publications, standards, datasets, and claims are put into role language because they are used in project reasoning.
7. Relation positions become roles. Slot positions in signatures, interfaces, evidence relations, or status-use relations are called roles.
8. Cross-context labels overreach. The same role-like word in two contexts is treated as one role description without a bridge.

#Forces

#Solution

Use a role-description episteme to describe one U.Role in one bounded context. The description gives readers enough to recognize and check the role, while sending neighboring claims to their governing patterns.

RoleDescriptionCore:
  DescribedRoleSlot:
  BoundedContextSlot:
  HolderAdmissionSlot:
  RecognitionTextSlot:
  RoleInvariantSetSlot:
  RoleStateRequirementRefs:
  CapabilityRequirementRefs:
  MethodRequirementRefs:
  WorkUseBoundarySlot:
  NamingRefs:
  BridgeRefs:
  NonRoleUseBoundarySlot:

This is a description episteme shape, not a new assignment relation. Its publication may be a card, table row, method appendix, standard clause, or pattern section. The publication form is not the role description by default; it publishes or carries the description episteme.

#Core Slot Meanings

The slot list is an open-world discipline. A quick local description may fill only the role, context, recognition text, holder admission, and non-role boundary. A safety-critical work-admission use may need role-state, capability, method, assignment-window, and evidence references through neighboring patterns.

#Role Description vs Neighboring Values

Keep these distinctions:

F.4 may point to these patterns; it does not copy their ontology.

#Positive Construction Rule

Write a role description in this order:

1. Name the described U.Role and bounded context.
2. State the admitted holder kind for role assignment.
3. Give one short recognition paragraph.
4. List the role invariants that make the role different from neighboring roles.
5. State the non-role boundary: what this description does not say about assignment, capability, method, work, evidence, status, permission, publication, or slot positions.
6. Add neighboring references only when the current use depends on them.
7. If the name is durable, public, cross-context, or Core-facing, settle it through F.18; if the sense crosses contexts, use F.9.

#Invariants

1. One described role. A role description describes exactly one U.Role value in the current application.
2. One bounded context. The role description is local to one U.BoundedContext; cross-context reuse needs F.9.
3. Description boundary. The role description is a U.Episteme; it is not the role value, assignment relation, holder, capability, method, work, or status-use relation.
4. Work-facing holder boundary. The holder admitted by a role assignment is a system or acting holon admitted by the governing work or method pattern. An episteme is not a role holder because it is used as evidence, source, standard, requirement, definition, explanation, status bearer, publication, or assurance input.
5. No hidden capability. Capability requirements may be referenced, but the role description does not prove capability.
6. No hidden method. Method requirements may be referenced, but the role description is not a method description.
7. No hidden work. A role description may enable work attribution checks, but it is not evidence that work occurred.
8. No status-template fusion. Status-use and evidence-use relations are direct relations, not a second branch of role description.
9. Slot discipline. If a source says "role" for a relation position, recover SlotKind, ValueKind, and RefKind through A.6.5.
10. Name after meaning. Durable naming follows F.18 only after role value, context, and local sense are recovered.

#Reasoning Primitives

Use these judgement schemas as thinking checks.

RoleDescription RD describes Role R in Context C
  -> RD is a description episteme about R, not R itself.

RoleDescription RD admits holder kind HK for Role R
  -> A RoleAssignment may use a holder of HK only if A.2.1 and neighboring checks admit it.

RoleDescription RD lists capability requirement CapReq
  -> capability claim is governed by A.2.2, not by RD.

RoleDescription RD lists method requirement MReq
  -> method or method-description claim is governed by A.15, A.3.1, or A.3.2.

Source says "X has role Y" and X is an episteme
  -> recover direct episteme-use relation before considering U.Role.

#Worked Cases

#Pump Inspector Role

RoleDescription:
  DescribedRoleSlot: PumpInspectorRole
  BoundedContextSlot: PlantMaintenance_2026
  HolderAdmissionSlot: maintenance technician, inspection robot, or service team admitted as acting holon by the maintenance context
  RecognitionTextSlot: the role used for inspecting pump condition before maintenance work is admitted
  RoleInvariantSetSlot:
    - concerns inspection of pump condition in PlantMaintenance_2026
    - does not perform repair work by itself
    - requires current assignment before work attribution
  CapabilityRequirementRefs: PumpInspectionCapability when the work claim depends on ability
  MethodRequirementRefs: PumpInspectionMethodDescription when the work claim depends on method
  NonRoleUseBoundarySlot: inspection report is evidence use, not a role holder

The description makes PumpInspectorRole recognizable. It does not say that Robot-7 holds the role, can inspect, followed the method, or performed work. Those claims go to [A.2.1](/generated/patterns/A.2.1), [A.2.2](/generated/patterns/A.2.2), [A.15](/generated/patterns/A.15), and evidence patterns.

#Reviewer Role and Review Report

ReviewerRole in PatternReview_2026 may have a role description with invariants about checking a pattern against declared scales. A review report produced by a reviewer is an episteme used as evidence or source for a pattern-quality claim. The report is not the role holder and does not hold an evidence role.

Use:

• A.2 for ReviewerRole;
• F.4 for the role-description episteme;
• A.2.1 for Alice#ReviewerRole:PatternReview_2026@Window;
• A.15.1 for the review work occurrence;
• A.10, B.3, G.6, or a direct evidence-use pattern for the review report as evidence.

#Standard Used as Requirement Source

The sentence "ISO 42010 has the architecture-standard role in this work" is unsafe if it makes the standard a role holder.

Repair it as:

ISO/IEC/IEEE 42010 is used as a standard-use or requirement-use episteme
for architecture-description claims in this bounded context.

Only a system or acting holon can hold a work-facing role. The standard may constrain, evidence, or source a claim through direct episteme-use relations.

#Access Role Is Not Automatically Work-Facing Role

RBAC "role" often names a permission grouping. If the current claim is permission or access standing, use the status, policy, or deontic governing pattern. Do not describe it as U.Role unless the bounded context explicitly introduces a work-facing role value and the holder, assignment, method, and work claims are current.

#Anti-Patterns and Repairs

#Consequences

Benefits.

• Role descriptions become short enough for practical use while preserving ontology.
• Part F naming and bridge patterns can rely on role descriptions without inheriting assignment, capability, method, work, evidence, or status claims.
• Episteme-use relations stay direct and do not become a parallel role ontology.
• Method and work checks can cite role descriptions without treating them as work evidence.

Costs.

• Former "role-or-status template" material must move to F.10, A.2.4, B.3, A.10, E.17, G.6, or direct use patterns.
• A stronger claim may require several neighboring patterns instead of one overloaded role card.
• Durable names require F.18 when the role name is public, Core-facing, or cross-context.

#SoTA-Echoing and Source-Use

Current best-known pressure for this problem is not a larger universal role taxonomy. It is explicit separation of local role value, assignment, attributes or capability, permission or policy standing, performed work, and evidence or status use. RBAC, ABAC, zero-trust authorization, safety independence practice, method engineering, and FPF slot discipline all push in that direction, while F.4 keeps only the role-description episteme and hands the neighboring claims to direct patterns.

Currentness and reopen condition: reopen this pattern when A.2, A.2.1, A.2.5, A.2.7, A.15, A.6.5, C.2.1, F.9, F.10, F.18, or the accepted episteme-use and status-use discipline changes enough that role-description, holder admission, or non-role-use boundaries would be stated differently.

#Relations

Builds on. A.2, A.2.1, A.6.5, A.7, C.2.1, E.10.D2, and E.24.

Coordinates with. A.2.2, A.2.5, A.2.7, A.15, A.15.1, A.15.2, F.9, F.10, F.14, F.15, F.18, evidence-use, status-use, source-use, publication-use, requirement-use, and assurance patterns.

Constrains.

• F.5 must name role descriptions after the described U.Role, bounded context, and local sense are recovered.
• F.8 must decide durable role-name minting or reuse without turning status-use or episteme-use relations into role descriptions.
• F.14 must treat bundles and separation-of-duties as role relation structure or neighboring role-description claims, not as hybrid role descriptions.
• F.15 must check role-description single-role and non-role-use boundaries.

#Conformance Checklist

#Phrasebook

Prefer:

• "role-description episteme describing ReviewerRole in PatternReview_2026";
• "holder admission for ReviewerRole is governed by A.2.1";
• "capability requirement referenced by the role description";
• "method requirement referenced by the role description";
• "review report used as evidence for the claim";
• "standard used as requirement source";
• "relation position governed by SlotSpec discipline".

Avoid as live vocabulary:

• "evidence role" for an episteme;
• "status role" for a badge or status-use relation;
• "standard role" for a standard used as source;
• "holder" for a publication, report, standard, dataset, or theorem unless a direct pattern admits an acting holon holder;
• "role" for a SlotKind;
• "role description" for a method, capability, work record, access policy, or status-use relation.

#Didactic Memory

A role description is the readable episteme that tells people what a role value means in a bounded context. It helps someone assign, check, name, or compare the role. It does not assign the role, prove capability, define the method, perform the work, grant permission, carry evidence, publish itself, or turn every useful episteme into a role holder.

#F.4:End

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