A.6.5:5.1 - System-role assignment: first minute, substitution, and repeated occurrence

First minute. Assume the case facts explicitly: Robot_7 is an admitted U.System; InspectorSystemRole is a local system-role kind; and InspectionShiftAssignment <: U.SystemRoleAssignment declares only two participant positions, holder System and assigned system-role kind. InspectionShiftAssignment-17 is the occurrence with those values that obtains without interruption from 09:00 to 17:00 on 13 July. A.2.1 supplies the family and continuity discipline; it does not inspect this robot or warrant the assertion. The species predicate, applicability, and InspectorSystemRoleKindDomain must come from the independent InspectionShiftAssignment definition, which is assumed but not supplied here. The directClaimFamilyRef below is a placeholder for that source. The stated case facts satisfy that predicate, and the SystemRoleAssignmentAssertion records affirmative polarity. Any evidence and reliance posture remain separately established. The following field block represents that assertion episteme:

SystemRoleAssignmentAssertion:
  directClaimFamilyRef: <independent InspectionShiftAssignment definition>
  participantDesignations:
    HolderSystemSlot: Robot_7_Ref
    AssignedSystemRoleKindSlot: InspectorSystemRole
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

The two labels inside participantDesignations are convenient source-side labels in this compact representation. An explicit representation correspondence relates each label to the SlotSpec identified by the matching SlotKind in the InspectionShiftAssignmentRelationSignature; equal spelling does not identify field and SlotKind, and another source field keeps its own name. assignmentInterval is a different assertion field and corresponds to no relation-participant SlotSpec. Robot_7_Ref : U.EntityRef resolves to Robot_7 : U.System; InspectorSystemRole is carried by value under the declaration-local InspectorSystemRoleKindDomain. The assertion does not create the assignment, and neither the system-role kind, assertion, nor assignment performs inspection Work.

If inspection admission also needs InspectionReady, A.2.5 tests InspectionShiftAssignment-17 against that exact SystemRoleAssignmentStatePredicate. The resulting SystemRoleAssignmentStateRelation is separate from the assignment and has its own maximal continuous truth interval. The assignment may continue while that state relation ceases to obtain.

Substitution. Assume Robot_8_Ref : U.EntityRef resolves to another admitted Robot_8 : U.System. Replacing only the HolderSystemSlot designation with Robot_8_Ref passes the declared ValueKind check, but it does not create an assignment for Robot_8. Current case facts must separately satisfy the direct InspectionShiftAssignment predicate before an affirmative assertion is warranted. The proposed designation can therefore be type-correct while the direct claim remains negative or unresolved.

Repeated occurrence. If the same two participants enter another inspection shift after a demonstrated non-assignment period, the A.2.1 continuity rule ends the first occurrence and starts another. A copied field block or reused row key does not merge them. Conversely, closing an open assignmentInterval for one uninterrupted assignment refines the same occurrence; an evidence gap alone does not split it. Under that continuing assignment, true → false → true for one fixed A.2.5 predicate creates two assignment-state-relation occurrences without creating another assignment.