#RoleAssignment and Performed-Work Attribution Check

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. Check who performed this work under which role assignment.

#Keywords

• actual performing U.System
• exact U.RoleAssignment
• performedUnderAssignment
• assignment coverage
• world-side attribution
• separate assertion and evidence.

#Relations

#Content

#Use This When

Plain name. Check who performed this work under which role assignment.

Use this pattern when deciding whether one exact dated Work individual W : U.Work was performed under one exact obtaining assignment occurrence RA : U.RoleAssignment. When it was, the direct world-side relation performedUnderAssignment(W, RA) obtains. A separate attribution assertion or record may designate W and RA and state that the relation obtains.

Typical moments include:

• a work record says "Alice reviewed", "Robot-7 inspected", or "the operations team approved", but the exact assignment episode is missing;
• a method description names a work-facing role and the project must connect performed work to the system that held that role;
• source wording says RoleEnactment, "played the role", or Holder#Role:Context@Window, and the direct work-to-assignment relation must be recovered;
• a report, standard, dashboard, access label, or other episteme is described with role language even though it did not perform the work;
• a role label is reused under another role taxonomy or reference scheme and local attribution would be unsafe without an explicit bridge.

Primary EntityOfConcern. One obtaining direct performedUnderAssignment relation occurrence between one exact U.Work occurrence and one exact U.RoleAssignment occurrence.

Primary working reader. An engineer, operator, method author, manager, or FPF author deciding whether a performed-work attribution is grounded strongly enough for the next use.

First useful move. Name the Work occurrence and the assignment occurrence that may participate in the attribution relation. Recover the assignment's holder system, role value, role-taxonomy episteme, effective reference scheme, and assignment window before deciding whether performedUnderAssignment(W, RA) obtains.

What goes wrong if missed. Assignment is treated as proof that work happened; a work log names a person but not the assignment episode; a context-like word hides the role taxonomy and interpretation scheme; or an episteme is made the performer because it described, constrained, or evidenced the work.

What this buys. Work attribution becomes a direct, inspectable relation: the admitted holder system remains the actor, the dated Work separately enacts one exact U.Method, and role value, assignment, capability, method, method description, evidence, source use, result, publication, and cross-scheme correspondence remain with their own governing patterns.

Not this pattern when. Use A.2 for the role value, A.2.1 for the assignment occurrence, A.2.5 for a current role-state predicate, A.2.2 for capability, and A.15.1 for the work occurrence. Use A.10, A.15.4, E.17, or another direct pattern when the current claim is evidence use, source reliance, publication, status, gate, or decision. Use A.6.5 when "role" means a relation position rather than a work-facing U.Role.

#Problem Frame

U.RoleAssignment admits assignment-relation occurrences; U.Work admits Work individuals. One exact RA : U.RoleAssignment is a world-side assignment-relation occurrence that relates an admitted holder System to one role value, one role-taxonomy episteme, and one effective reference scheme and obtains throughout one assignment episode. One exact W : U.Work is a dated world-side Work occurrence. The existence of RA and W does not by itself establish the additional world-side attribution between them: performedUnderAssignment(W, RA) must separately obtain. A distinct assertion or record may designate RA and W, state that RA obtains, state that W occurred, or state that the attribution relation obtains.

F.6 governs the missing direct relation. The assignment is one participant and the work occurrence is the other. A roster row may assert the assignment; a work log may assert the work and attribution; evidence may support either assertion. Those epistemes help a system know or use the relation, but they do not become relation participants and do not make the world-side relation obtain merely by being recorded.

This separation matters because assignment, state, ability, performance, evidence, and acceptance can vary independently. A system can hold a role and do no work. It can perform poor work under a valid assignment. A report can accurately describe the work without performing it. One compact "enactment" label hides these distinctions.

#Problem

Without the direct attribution relation, recurring engineering failures appear:

1. Assignment-as-work. Current role holding is treated as evidence that the assigned system performed a particular occurrence.
2. Performer by label. A name such as Reviewer or Operator is used without the assignment episode that fixes holder, role interpretation, and time.
3. Assignment-episode mismatch. The assignment interval does not cover the work interval, yet attribution is accepted.
4. Support-as-constitution. A log, report, standard, dashboard, or decision is treated as what makes the attribution obtain rather than as an assertion or support relation.
5. Duplicate enactment ontology. RoleEnactment or RoleEnactmentFact becomes a second object beside the dated work and its direct performedUnderAssignment relation.
6. Hidden locality. A generic context field replaces the role-taxonomy episteme, effective reference scheme, assignment window, or an independently selected model-use structure.

#Forces

#Solution

Govern performed-work attribution as one direct relation species under U.Relation.

#Direct Relation Declaration

performedUnderAssignment : U.Relation
  WorkOccurrenceSlot: U.Work, U.EntityRef
  RoleAssignmentSlot: U.RoleAssignment, U.EntityRef

when performedUnderAssignment(W, RA) obtains:
  actualPerformerSystem(W, RA) := RA.HolderSystemSlot

WorkOccurrenceSlot names the dated performed occurrence governed by [A.15.1](/generated/patterns/A.15.1). RoleAssignmentSlot names the obtaining assignment occurrence governed by [A.2.1](/generated/patterns/A.2.1).

For an obtaining attribution, the readable actual-performer cue is S = actualPerformerSystem(W, RA) = RA.HolderSystemSlot: S is the admitted U.System that acts, while RA is the assignment under which that action is attributed. The projection exposes the actor already carried by the assignment participant; it does not assert attribution when the relation fails to obtain and is not another relation kind or occurrence.

performedBy(W, RA) is a deprecated compatibility spelling of performedUnderAssignment(W, RA). Existing claims or records may be read through that alias only after resolving S = RA.HolderSystemSlot. New practitioner-facing claims, examples, and conformance statements MUST use S performed W under RA or performedUnderAssignment(W, RA), never wording that makes RA the performer.

No evidence, log, status, method description, result, publication, context record, or role-state assertion is a generic participant in this relation.

performedUnderAssignment also has no method participant. Because W is an admitted Work occurrence, an assertion or description about it must separately make recoverable the actual enactsMethod(W, M) relation governed by [A.15.1](/generated/patterns/A.15.1), for one exact M : U.Method. The holder system acts and performs W; neither RA, its role value, a capability or algorithm-possession phrase, M, nor a method-description episteme D thereby acts or performs the work. Citing D may identify, constrain, or justify M for a receiving use, but it neither enacts D nor establishes that D : U.MethodDescription; apply [A.3.2](/generated/patterns/A.3.2) to that membership question independently.

#Obtaining and Occurrence Identity

The relation performedUnderAssignment(W, RA) obtains when:

1. W is one exact dated U.Work occurrence governed by A.15.1;
2. RA is one obtaining U.RoleAssignment occurrence;
3. the holder system in RA.HolderSystemSlot actually performed W under RA.RoleValueSlot;
4. the assignment predicate for RA obtains throughout the temporal extent of W.

If the performer attribution concerns only a temporal, episode, or operational part of a larger work whole, first identify that part as the U.Work occurrence under A.15.1 and use it in WorkOccurrenceSlot. Do not hide an unidentified work portion inside the attribution relation.

When a receiving use needs an explicit relation-occurrence reference, use:

PerformedUnderAssignmentOccurrenceKey = <WorkOccurrenceSlot, RoleAssignmentSlot>

The temporal extent is inherited from WorkOccurrenceSlot. Extending an open work interval or later recording its end does not create another attribution occurrence while both participants remain the same. A separately identified work occurrence, including a separately identified work part, or a different assignment episode yields a different relation occurrence.

An evidence gap leaves a relied-on attribution assertion unresolved. It does not demonstrate that performedUnderAssignment failed to obtain. A demonstrated different performer or non-covering assignment episode can support the stronger negative claim.

#Recover the Exact Assignment

Before relying on the attribution, recover the four direct participants of the exact assignment occurrence RA that fills RoleAssignmentSlot:

RoleAssignmentRelationSignature:
  HolderSystemSlot: U.System, U.EntityRef
  RoleValueSlot: U.Role, ByValue
  RoleTaxonomyEpistemeSlot: U.Episteme, U.EpistemeRef
  EffectiveReferenceSchemeSlot: U.ReferenceScheme, ByValue

One assignment occurrence is the maximal continuous period during which the assignment predicate obtains for those fixed four participants. A supporting assertion or occurrence description may state assignmentInterval, including an open end, but that field is not a participant and does not establish temporal coverage. Verify coverage for performedUnderAssignment from the actual obtaining history of the exact assignment occurrence and the exact work extent.

Do not replace these participants with one Context value. If source notation contains Context, recover what that token denotes and send it to its direct pattern. It may denote an actual system or work locus, a claim scope, or an independently selected BoundedModelUseStructure; those objects have different kinds and relations. A selected model-use structure can qualify the receiving attribution assertion, but it is not an optional participant of generic U.RoleAssignment.

#Attribution Check Sequence

Use this short sequence for the current attribution claim:

1. Name the exact U.Work occurrence whose performer is being asserted.
2. Name or recover the exact U.RoleAssignment occurrence through its four fixed participants and uninterrupted obtaining extent.
3. Check that the holder system named by the assignment is the system claimed to have performed the work.
4. Check that the assignment episode covers the attributed work interval.
5. State the direct performedUnderAssignment(WorkOccurrenceSlot, RoleAssignmentSlot) relation, or keep the attribution assertion unresolved when support is insufficient.
6. Send role state, capability, method fit, evidence, source use, result, acceptance, publication, and bridge questions to their direct governing patterns.

The sequence is application guidance, not a new check record, work plan, or workflow object. Its useful result is the repaired direct relation or an explicit stop at the missing relation participant or support claim.

#Direct Neighboring Relations

#Source Shorthand and RoleEnactment

Holder#Role:Context@Window is readable source notation only. Before reliance-bearing use, recover the assignment's holder system, role value, role-taxonomy episteme, effective reference scheme, and assignment window. Recover the object denoted by Context separately.

When source wording says RoleEnactment or RoleEnactmentFact, recover the dated U.Work occurrence and the direct performedUnderAssignment relation. Do not retain a second enactment kind, fact object, or relation occurrence.

#Lightweight Use

Ordinary use can stop at a readable assertion:

InspectionWork-17 was performed by Robot-7 under RoleAssignment-17.

Expose the relation declaration and occurrence key only when a receiving use must distinguish attribution occurrences, cite one as a participant, compare assertions, or preserve provenance. If the assignment cannot be recovered, lower the claim to "Robot-7 is named as performer in record R" and route that reliance through [A.15.4](/generated/patterns/A.15.4) or the direct source and evidence patterns.

#Invariants

1. Every performed-work attribution relates one exact U.Work occurrence to one exact U.RoleAssignment occurrence.
2. The assignment occurrence RA in RoleAssignmentSlot keeps exactly four fixed participants and one maximal continuous obtaining extent; no mandatory U.BoundedContext, generic context slot, or optional model-use participant is added.
3. The actual maximal continuous extent of the assignment occurrence covers the attributed portion of the work interval; a declared or recorded window alone does not establish coverage.
4. Assignment does not prove performance, and performance attribution does not prove capability, state, method validity, result quality, or acceptance.
5. RoleEnactment wording is repaired to dated work plus direct performedUnderAssignment; no duplicate enactment object is retained.
6. Assertions, logs, rosters, evidence, identifiers, and publications remain epistemic or representational objects distinct from world-side relation obtaining.
7. An evidence gap yields unresolved reliance, not an inferred non-attribution interval.
8. An episteme does not fill HolderSystemSlot merely because it describes, constrains, or supports the work claim.
9. Cross-scheme role correspondence uses a direct bridge relation and does not change either assignment identity.
10. Reduced prose remains admissible until a receiving use needs explicit relation-occurrence identity.
11. For admitted Work W, actual enactsMethod(W, M) remains a separately obtaining relation to one exact U.Method; only the admitted holder system acts, while assignment, role value, capability, method, and method description do not perform the work.

#Reasoning Primitives

RA : U.RoleAssignment is one exact obtaining assignment-relation occurrence
  and W : U.Work is one exact dated Work occurrence
  and RA.HolderSystemSlot actually performs W under RA.RoleValueSlot
  and the assignment predicate for RA obtains throughout the attributed work interval
  -> performedUnderAssignment(W, RA) obtains.

An attribution assertion lacks adequate current support
  -> reliance on the assertion is unresolved;
  -> do not infer that performedUnderAssignment(W, RA) is false.

A source episteme names a performer or role
  -> do not claim that performedUnderAssignment obtains until exact W and RA are recovered.

#Archetypal Grounding

#Robot Inspection

RoleAssignmentAssertion@RoleAssignment17:
  participantDesignations:
    HolderSystemSlot: Robot-7
    RoleValueSlot: InspectorRole
    RoleTaxonomyEpistemeSlot: MaintenanceRoles-2026
    EffectiveReferenceSchemeSlot: Maintenance-Scheme-A
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

performedUnderAssignment:
  WorkOccurrenceSlot: InspectionWork-17
  RoleAssignmentSlot: RoleAssignment-17

The assertion interval describes the known extent of RoleAssignment-17; the direct assignment predicate must actually obtain throughout InspectionWork-17 before performedUnderAssignment obtains. The relation attributes the inspection occurrence to Robot-7 under that assignment. Separately, enactsMethod(InspectionWork-17, TurbineInspection@Maintenance-2026) names the exact enacted method, while TurbineInspectionProcedure-v3 may be cited as a distinct description episteme only if the receiving use needs it. Robot-7 is the actor; InspectorRole, a sensor capability or statement that Robot-7 possesses an inspection algorithm, the method, and the procedure do not perform the inspection. Algorithm-possession wording alone establishes neither the work attribution nor TurbineInspectionProcedure-v3 : U.MethodDescription. Calibration state, inspection-method adequacy, report quality, and acceptance remain separate claims.

#Reviewer and Review Report

Engineer Alice is identified as the exact holder and satisfies the A.1 U.System criterion. ReviewAssignment-82 assigns her ReviewerRole under ReviewRoles-v5 and Review-Scheme-A for one uninterrupted review assignment episode. ReviewWork-82 performedUnderAssignment ReviewAssignment-82 attributes the dated work.

ReviewReport-82 is a separately identified U.Episteme. When ReviewWork-82 first constitutes that exact episteme and the inception claim matters, A.15.PROD recovers the local work/change/identity claim. A later evidence relation may use the report for a decision. The report never fills HolderSystemSlot and never becomes the attribution relation.

#Standard Used During Safety Work

A safety method description cites a standard, and source prose says that the standard has a "normative role". F.6 does not create a work-facing assignment for the standard. The standard is an episteme used through the exact external-rule, source-use, specification-use, or evidence relation selected by the claim.

A safety engineer or tool system may separately hold SafetyAnalystRole and perform dated safety work. That attribution names the engineer's or tool system's assignment; it does not use the standard as performer.

#Access Label and Approval Work

An access directory says Alice has DB-Admin. That entry describes an access or policy relation under its own scheme. It is not automatically a work-facing ApproverRole assignment.

If Alice performs ApprovalWork-481, recover a separate U.RoleAssignment under the role taxonomy used by the approval method and relate the work through performedUnderAssignment. The directory entry may support authorization or gate reasoning through its direct pattern; it does not substitute for the work assignment.

#Bias Annotation

#Conformance Checklist

1. WorkOccurrenceSlot names one admitted dated U.Work occurrence.
2. RoleAssignmentSlot names one obtaining U.RoleAssignment occurrence.
3. The assignment exposes holder system, role value, role-taxonomy episteme, and effective reference scheme as participants; its maximal continuous assignment extent is checked separately.
4. The assignment holder is the system claimed to have performed the work.
5. The assignment episode covers the selected work occurrence's interval; attribution to only one part first selects that part as U.Work.
6. The attribution uses direct performedUnderAssignment wording and introduces no RoleEnactmentFact.
7. Role state, capability, method, result, evidence, source reliance, publication, gate, and decision claims use their direct patterns.
8. Any selected model-use structure is designated by the receiving attribution assertion or use, not by an optional slot in generic U.RoleAssignment.
9. Missing evidence leaves the relied-on assertion unresolved rather than proving non-attribution.
10. Compact source notation is unfolded before a receiving use depends on hidden assignment positions.
11. The work assertion makes a separately obtaining actual enactsMethod(W, M) relation to one exact U.Method recoverable; it does not make the role value, assignment, capability, method, or method description the actor, and it does not infer U.MethodDescription membership from a label or algorithm-possession phrase.

#Common Anti-Patterns and Repairs

#Consequences

Benefits. Assignment and performed work remain independently identifiable, while attribution becomes a direct relation that can be cited, compared, supported, corrected, or left unresolved. The pattern works for people, organizations, machines, and software systems because the holder is always an admitted U.System, not a domain-specific performer category.

Costs. Reliance-bearing use must recover the exact assignment episode rather than stopping at a familiar role label. A compact source sentence may split into an assignment assertion, a work occurrence, the direct attribution relation, an exact change or production claim, an operation-result binding or result episteme, and any evidence relation current for the use.

Limits. F.6 does not determine capability, readiness, method validity, work success, result acceptance, authorization, or evidence sufficiency. It only governs the relation by which one performed work occurrence is attributed to one role assignment.

#Rationale

The direct relation is needed because U.RoleAssignment and U.Work admit different kinds of world-side occurrence. One obtaining assignment occurrence RA relates its holder System to a role value under one interpretation and throughout one episode; one Work individual W : U.Work is the dated Work occurrence. performedUnderAssignment(W, RA) either obtains or does not obtain as the additional world-side attribution between them. A distinct assertion or record may designate RA and W, state that RA obtains, state that W occurred, or state that the attribution relation obtains.

Making a log, status, decision, or evidence item a relation participant would confuse world-side attribution with knowledge of attribution. Creating RoleEnactmentFact would duplicate the same pair under a second identity. The two-participant relation preserves realism and keeps correction local: changing an evidence use does not rewrite work or assignment; discovering a different performer changes the attribution assertion and, when demonstrated, the selected relation occurrence.

#SoTA-Echoing and Source Use

These lines discipline the examples rather than supply a foreign ontology. FPF takes the useful separation pressure and retains its own constructive relation, work, role-assignment, episteme, and evidence distinctions.

#Relations

Builds on: A.6.REL for relation obtaining and occurrence identity; A.2 for U.Role; A.2.1 for U.RoleAssignment; and A.15.1 for dated U.Work.

Uses when current: A.2.5 for role state; A.2.2 for capability; A.3.1, A.3.2, and A.15 for method and work alignment; A.10 for evidence; A.15.4 for reliance on encountered project material; F.9 for cross-scheme correspondence; and A.1.1 only when an independently selected model-use structure changes assignment interpretation.

Coordinates with: F.4 for role-description epistemes; F.5 and F.18 for durable names; E.17 for publication; and E.10 for source-word precision repair.

#Completion Conditions

F.6 use is complete when the reader has either:

• one direct performedUnderAssignment relation between an exact work occurrence and an exact assignment occurrence;
• an unresolved attribution assertion with the missing assignment, interval, or support relation named;
• or a corrected exit to the direct pattern because the encountered claim concerns assignment, state, capability, method, evidence, source reliance, result, publication, gate, or decision rather than performed-work attribution.

#F.6:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)