#Role Assignment & Enactment Cycle (Six-Step)

F.6 · Stable · Boundary and use 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: Boundary and use pattern Status: Stable Normativity: Normative unless marked informative

Plain name. Role-assignment and work-attribution check.

#Keywords

• role assignment
• enactment
• conceptual moves
• asserting status.

#Relations

#Content

#Use This When

Plain name. Role-assignment and work-attribution check.

Use this pattern when a project has a role description, role label, assignment notation, or work record and needs to decide whether it can make a work-facing U.RoleAssignment claim or attribute performed work through that assignment.

Typical moments:

• a method description names ReviewerRole, OperatorRole, InspectorRole, TransformerRole, or another required role, and the project must decide which holder bears that role in the bounded context;
• a work record says "Alice reviewed", "Robot-7 inspected", "the operations team approved", or "the CI service deployed", but the holder, role, bounded context, assignment window, or performed-by relation is not explicit;
• a source text uses Holder#Role:Context@Window, RoleEnactment, "assigned role", "played role", or "acted as" and the project must recover the typed assignment relation rather than preserve source notation as ontology;
• a status, evidence, requirement, source, standard, dashboard, model card, publication, or report is being described with role language, and the project must decide that this is not a work-facing role assignment;
• a cross-context role-like word appears, and the project must keep the local role assignment separate from any F.9 bridge or F.5 naming question.

Primary EntityOfConcern. The EntityOfConcern is the role-assignment and performed-work attribution check: a bounded check over a candidate U.RoleAssignment and, when current, a U.Work occurrence that may cite that assignment through Work.performedBy or RoleEnactmentFact. The check is not the role value, not the role description, not the work occurrence, not a status assertion, not evidence, and not a publication form.

Primary working reader. The first reader is an engineer-manager, analyst, method author, or FPF author who must keep a role label, role description, assignment relation, method requirement, work occurrence, status-use relation, and evidence-use relation from becoming one under-typed "enactment" claim.

First useful move. Recover the candidate holder, role value, bounded context, and assignment window or window disposition. Then decide whether the current claim is only assignment admission, performed-work attribution under an assignment, or a status, evidence, source, or publication claim governed outside F.6.

What goes wrong if missed. A role description becomes proof that a holder has a role. A work record names a person or label but not the role assignment that made the work attributable. A report, standard, requirement, or dashboard is made into a role holder because it constrained, evidenced, justified, displayed, or described work. Source U.RoleEnactment wording grows back into a second run-time ontology beside U.Work and U.RoleAssignment.

What this buys. The reader gets one small local check: who or what can bear the role, in which context and window, and whether a specific work occurrence may be attributed through that assignment. Status, evidence, source, publication, method, capability, and bridge claims remain with their direct patterns.

Not this pattern when.

• If the current claim is the role value itself, use A.2.
• If the current claim is the role-description episteme, use F.4.
• If the current claim is durable naming of a role or type label, use F.5 or F.18.
• If the current claim is the U.RoleAssignment relation value itself and its SlotSpecs, use A.2.1.
• If the current claim is role state or enactable-state admission, use A.2.5.
• If the current claim is capability, use A.2.2.
• If the current claim is method, method description, work plan, performed work, or role-method-work alignment beyond the assignment check, use A.15 and its subpatterns.
• If the current claim is status, evidence, source, standard, requirement, publication, assurance, gate, or decision use of an episteme, use the direct pattern for that relation, such as F.10, A.10, B.3, C.28, E.17, or E.10.D2.
• If the current claim is cross-context sameness, translation, or substitution, use F.9.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.

#Problem Frame

Role assignment sits between a role description and performed work. A role description lets a reader recognize InspectorRole or ReviewerRole; it does not assign a holder. A work occurrence may be performed by a holder under a role assignment; it is not the assignment itself. A status value, evidence relation, standard-use relation, requirement-use relation, or publication cue may constrain, evidence, qualify, or display a work-admission relation; it is not a role holder and not performed work.

A common source shape mixes these questions into one "role assignment and enactment cycle" with a status branch. That made the pattern convenient but ontologically noisy. A status assertion and a work-facing role assignment have different subjects, slots, evidence, windows, and direct governing patterns. Putting them into one cycle made status look like a kind of role assignment and made RoleEnactment look like a durable run-time object.

F.6 therefore becomes a check pattern. It asks whether the current local claim can use a recovered U.RoleAssignment, and whether a current U.Work occurrence can cite that assignment. If the current claim is status, evidence, source, publication, bridge, capability, or method, F.6 names the direct governing pattern and stops.

#Problem

Without this pattern:

1. Role-description proof. A role-description episteme or role label is treated as proof that a holder bears the role.
2. Assignment and work collapse. A work occurrence is treated as if it were the assignment, or an assignment is treated as if work already happened.
3. RoleEnactment reification. RoleEnactment becomes a second durable U-kind beside U.Work and U.RoleAssignment.
4. Status branch returns. Status assertions are processed as if they were the same kind of result as role assignment.
5. Episteme-role drift. Standards, reports, datasets, requirements, model cards, dashboards, and publications become "role holders" because they are useful in project reasoning.
6. Window and state loss. A holder-role-context statement is used for current work without saying whether assignment currentness or role-state admission matters.
7. Cross-context overreach. A familiar role-like label from another canon is used to justify local assignment without a bridge.
8. Notation replaces relation. Holder#Role:Context@Window is copied as if the string were the assignment value.

#Forces

#Solution

Use F.6 as a local check over candidate assignment and optional work attribution.

RoleAssignmentAttributionCheck:
  CandidateRoleDescriptionRef:
  CandidateHolderRef:
  CandidateRoleValueRef:
  BoundedContextRef:
  AssignmentWindowDisposition:
  HolderAdmissionDisposition:
  RoleStateAdmissionRef:
  CapabilityRequirementRef:
  MethodOrMethodDescriptionRef:
  WorkOccurrenceRef:
  PerformedByRelation:
  AssignmentJustificationRef:
  EvidenceOrSourceUseRefs:
  BridgeRef:
  NotCarried:
  Result:

This check is not a new root kind. It is an application relation over values governed elsewhere. [A.2.1](/generated/patterns/A.2.1) governs U.RoleAssignment; [A.15.1](/generated/patterns/A.15.1) governs the U.Work occurrence; [F.10](/generated/patterns/F.10), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [E.17](/generated/patterns/E.17), [E.10.D2](/generated/patterns/E.10.D2), and direct governing patterns govern status, evidence, assurance, publication, and source-use relations.

#Slot Meanings

#The Check Sequence

Use these questions in order. They are judgement questions, not a U.WorkPlan, registry procedure, or tool protocol.

1. Role meaning recovered? Does the role label point to a U.Role in one bounded context, usually through F.4 and A.2?
2. Holder admitted? Is the candidate holder a system or acting holon admitted by A.2.1 and by the local role description?
3. Context and window adequate? Is the bounded context explicit, and is the assignment window filled, inherited, unknown, not asserted, or not current for the claim?
4. Related prerequisites current? Does this use need role state, capability, method, method description, work plan, evidence, gate, decision, or source-currentness?
5. Work occurrence current? Is there a U.Work occurrence to attribute? If not, stop at assignment admission or blocker.
6. Performed-by relation admissible? Can the work occurrence cite the assignment by Work.performedBy = RoleAssignment or RoleEnactmentFact?
7. Claim governed outside F.6? If the current claim is status, evidence, source, publication, requirement, assurance, bridge, method, capability, or gate use, apply the direct governing pattern and do not encode that claim as role assignment.

#Assignment Result vs Work-Attribution Result

Keep two local results separate.

AssignmentAdmission:
  CandidateHolderRef bears CandidateRoleValueRef in BoundedContextRef
  with AssignmentWindowDisposition and HolderAdmissionDisposition.

PerformedWorkAttribution:
  WorkOccurrenceRef performedBy RoleAssignmentRef
  with RoleEnactmentFact only when a named fact is useful.

An assignment admission does not prove that work happened. A performed-work attribution does not prove that the method was valid, the capability was sufficient, the evidence is adequate, or the gate passed. Those claims use their governing patterns.

#RoleEnactmentFact

Use RoleEnactmentFact only as a name for the derived fact that a work occurrence was performed under a role assignment.

RoleEnactmentFact:
  workOccurrence: U.Work
  performedBy: U.RoleAssignment
  methodTrace?: U.Method or U.MethodDescription reference when current
  window?: inherited from work occurrence or role assignment when current

Do not write U.RoleEnactment as a durable root kind. If a log, table, database row, or publication stores a role-enactment entry, treat it as a record of this fact unless a direct governing pattern admits record-as-value for that use.

#Status and Evidence Claims Governed Outside F.6

Status and evidence claims often sit next to role assignment. They do not become role assignment.

#Compact Notation and Shortcut Boundary

Holder#Role:Context@Window is allowed as a compact reading aid after the typed relation is recoverable.

Baseline relation:

RoleAssignment:
  HolderSlot:
  RoleValueSlot:
  BoundedContextSlot:
  AssignmentWindowSlot:

Compact notation:

Holder#Role:Context@Window

The compact notation saves reader effort in examples, tables, and short work records. It weakens the representation by hiding SlotSpec names and any current assignment justification, role state, capability, method, evidence, source, or provenance relation. Therefore it is admitted only for local reading, examples, and compact citations after the typed slots are either filled, inherited, or explicitly not current for the claim.

Do not use the compact notation as proof of assignment, proof of performed work, proof of capability, proof of method validity, proof of status, or proof of gate passage. If reliance-bearing use depends on any hidden slot, unfold the notation to the typed relation or lower the claim.

#Invariants

1. Role assignment is local. Every assignment check names one U.Role, one admitted holder, and one U.BoundedContext.
2. Role description is not assignment. A role-description episteme may identify the role value; it does not assign a holder.
3. Assignment is not work. A U.RoleAssignment can be admitted without any U.Work occurrence.
4. Work attribution is direct. Performed work cites the role assignment through Work.performedBy = RoleAssignment; RoleEnactmentFact is only a named fact over that relation.
5. No durable U.RoleEnactment. Source U.RoleEnactment wording is repaired to direct performed-by wording or RoleEnactmentFact.
6. Status is not a role branch. Status-use statements are governed by F.10 or the direct status pattern, not by F.6.
7. Epistemes are not role holders by use. Evidence, source, standard, requirement, definition, explanation, publication, assurance, and gate uses of epistemes go to their direct relations.
8. Window honesty. If a stronger claim depends on assignment currentness, role state, or work time, missing window content lowers or blocks that claim.
9. Bridge restraint. Cross-context role-like labels need F.9; a bridge does not mutate a local assignment.
10. Notation restraint. Holder#Role:Context@Window is source or shorthand notation for a typed assignment relation, not the relation's ontology.

#Reasoning Primitives

RoleDescription RD describes Role R in Context C
  and Holder H is admitted for R in C
  -> candidate RoleAssignment(H, R, C).

RoleAssignment RA is admitted
  and Work W is a current U.Work occurrence
  and W performedBy RA is admitted
  -> RoleEnactmentFact(W, RA) may be named.

Source episteme E is used as evidence, standard, requirement, source, publication, or status bearer
  -> no RoleAssignment holder is recovered from that use alone.

Role-like label L comes from another bounded context
  -> no assignment substitution without F.9 bridge and local A.2.1 check.

#Archetypal Grounding

#Robot Inspection

A maintenance line has a role-description episteme for InspectorRole. A shift note says Robot-7 inspected Pump-12.

F.6 recovers:

CandidateHolderRef: Robot_7
CandidateRoleValueRef: InspectorRole
BoundedContextRef: MaintenanceLine_A
AssignmentWindowDisposition: filled by shift window
WorkOccurrenceRef: InspectionWork_2026-06-15-09
PerformedByRelation: InspectionWork_2026-06-15-09 performedBy Robot_7#InspectorRole:MaintenanceLine_A@shift
Result: workAttributionAdmitted, if A.2.1 and A.15.1 checks pass

This does not prove the robot's sensor capability, the inspection method's adequacy, or the quality of the result. Those claims use capability, method, evidence, and assurance patterns.

#Review Report and Reviewer

A review report is an episteme. The reviewer is a person, service, or team modeled as an acting holon.

The sentence "Report R has reviewer role" is repaired by asking two questions:

• Who or what performed the review work under ReviewerRole?
• How is report R being used now: as evidence, source, publication, or result?

The reviewer holder may be assigned a U.RoleAssignment. The report does not hold the role. Evidence use of the report goes to the evidence-use pattern.

#Standard Used in Safety Work

A safety method description cites ISO 26262. The source phrase says that the standard has the "normative role" in the safety case.

F.6 result:

Result: claimGovernedOutsideF6
NotCarried: no HolderSlot, no U.RoleAssignment, no performed work

The standard is an episteme used through standard-use, source-use, requirement-use, or specification-use relations. A safety engineer or tool service may separately hold SafetyAnalystRole when performing work with that standard.

#Access Label and Actual Approval Work

An RBAC directory says Alice has DB-Admin. That directory state is an access or policy status in its own bounded context. It is not automatically a work-facing ApproverRole.

If Alice approves a database migration, F.6 can check a separate assignment and work attribution:

Alice#ApproverRole:MigrationApprovalContext@approval-window
ApprovalWork_481 performedBy Alice#ApproverRole:MigrationApprovalContext@approval-window

The RBAC status may justify or constrain the approval only through the direct access, policy, evidence, source, or gate pattern that admits that use.

#Bias Annotation

#Conformance Checklist

Use this checklist when applying F.6.

1. The candidate role is a U.Role in one bounded context, not only a source label.
2. The candidate holder is a system or acting holon admitted by A.2.1.
3. The assignment window is filled, inherited, unknown, not asserted, or not current for this claim.
4. If role state matters, an A.2.5 role-state admission or blocker is named.
5. If capability matters, an A.2.2 capability relation or blocker is named.
6. If method or method description matters, A.3.1, A.3.2, or A.15 is named.
7. If actual work is claimed, the U.Work occurrence is named under A.15.1.
8. Performed work uses Work.performedBy = RoleAssignment or RoleEnactmentFact, not U.RoleEnactment.
9. Status, evidence, source, standard, requirement, publication, assurance, gate, and decision uses are not encoded as role assignment.
10. Cross-context role-like reuse is represented by F.9 and does not mutate the local assignment.
11. Compact notation is unfolded to typed assignment slots before reliance-bearing use.
12. NotCarried names the strongest tempting overclaim that this F.6 check does not make.

#Common Anti-Patterns and Repairs

#Consequences

Using F.6 makes role-assignment reasoning narrower and more reliable. A project can still use compact assignment strings and familiar role words, but reliance-bearing claims must expose the holder, role, bounded context, assignment-currentness disposition, and performed-by relation when actual work is claimed.

The cost is one extra split. A source sentence that says "role enacted" may become two or three typed statements: assignment admitted, work performed by that assignment, and evidence or status relation used for downstream reliance. That split is intentional. It prevents duplicate role ontologies and makes audit, bridge, capability, method, and status checks local.

#Rationale

U.RoleAssignment is first-class because work attribution needs a stable holder-role-context relation. RoleEnactmentFact is not first-class because the fact is derived from a work occurrence and its performedBy assignment. Status-use and evidence-use relations are not branches of role assignment because their EntityOfConcern and slot discipline differ: they qualify claims, epistemes, standards, requirements, publications, gates, or decisions rather than assigning acting holders to work-facing roles.

The pattern is deliberately thinner than A.15. It does not rebuild the full role-method-work alignment. It gives Part F a local check that keeps role-description, naming, bridge, status, and work-attribution uses from crossing wires.

#SoTA-Echoing and Source-Use

External traditions such as RBAC, BPMN, PROV, service management, safety standards, and process-notation traditions use "role", "activity", "participant", "status", "approval", and "execution" in different ways. F.6 does not treat any one tradition as semantic authority. The FPF role-assignment ontology recovers the bounded context and local role value first; assigns acting holders only through U.RoleAssignment; represents performed work through U.Work; and represents evidence, status, source, publication, and bridge claims through their own patterns.

When a source tradition is current, cite it through the direct source-use or bridge relation. Do not let source prestige, familiar vocabulary, or a popular notation collapse FPF kinds.

#Relations

Builds on: A.2 for U.Role, A.2.1 for U.RoleAssignment, F.4 for role-description epistemes, and F.5 for role and type naming.

Uses when current: A.2.5 for role-state and enactable-state admission; A.2.2 for capability; A.15, A.15.1, A.3.1, and A.3.2 for method, method description, work plan, and performed work; A.6.5 when role-like words are relation positions.

Direct governing patterns: F.10, A.10, B.3, C.28, E.17, E.17.0, E.17.2, E.10.D2, gate, decision, publication-use, source-use, standard-use, requirement-use, and assurance patterns when the current claim is not work-facing role assignment or performed-work attribution.

Coordinates with: F.9 for cross-context bridge claims; F.18 for durable public names; E.10 and E.10.ARCH for wording-use recovery when source language hides the current kind.

#Footer Marker

F.6 closes when the project knows whether the current local claim is:

• an admitted or blocked U.RoleAssignment;
• an admitted or blocked performed-work attribution through Work.performedBy = RoleAssignment or RoleEnactmentFact;
• a lowered claim with missing holder, role, context, window, role state, capability, method, work, or source-currentness;
• or a non-F.6 status, evidence, source, publication, bridge, method, capability, gate, decision, or assurance claim.

#F.6:End

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