F.8:4.3 - Role Expression Boundary
A role expression is not enough to choose the object. For a system-role naming case, keep these four objects distinct:
| Symbol | Object |
|---|---|
L | The candidate or selected designation, interpreted under the effective naming ReferenceScheme. |
K | The local system-role kind recovered through A.2 and C.3, with its work-facing contribution distinction and KindSignature. |
D | An optional F.4 SystemRoleKindDescription episteme whose EntityOfConcern is K. |
A | An optional A.2.1 assignment occurrence in which an admitted system is assigned under K. |
Under the effective naming scheme, L designates K. Needing L does not create or require D; D may receive its own designation when a separate description is justified. Naming either object creates no A. The naming ReferenceScheme interprets the expression; it neither defines the kind nor assigns a system.
After A.2 and C.3 have recovered K, apply the naming ladder. Keep a one-off expression local when that is enough, and reuse an existing designation when it fits. If the kind needs a durable designation, select openDurableNamingSettlement, use F.5 to name K, and use F.18 for the durable settlement. Use nameSystemRoleKindDescription and F.4 only when the governed object is a separately justified description episteme D.
| Source expression | Recovered case | F.8 result |
|---|---|---|
ReviewerRole in a review method | A recovered review-system-role kind needs a durable designation; that naming need requires no description episteme | openDurableNamingSettlement; A.2 and C.3 govern the kind, F.5 its designation, and F.18 the durable settlement; use F.4 only for a separately needed description |
Alice as reviewer | A system is assigned to a local system-role kind for an interval | Not a name decision until A.2.1 recovers the U.SystemRoleAssignment occurrence |
review happened | Dated performed Work | Use A.15.1; open naming only if a Work-kind designation is needed |
EvidenceRole | An episteme used as evidence | Use the evidence-use pattern; only then consider a name for the governed relation |
AccessRole | Permission or policy grouping | Use access, policy, status, or deontic pattern; do not mint a local system-role kind by suffix |
ProviderRole in a signature | Relation position | Use A.6.5 SlotSpec discipline; name a slot only if needed |
RoleEnactment in source prose | Source wording around a U.SystemRoleAssignment plus a Work occurrence | Recover the exact actual performer through A.13 and let A.15.1 independently admit the Work; use F.6 only when the naming case expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment, and do not mint U.RoleEnactment |