A.6.5:4.2 - Declare one complete SlotSpec for each relation-participant meaning needed by typed reuse

The following code block is a compact representation of a declaration. Its assignment mark, angle brackets, order, and alternatives are notation elements.

SlotSpec := <SlotKind, ValueKind, refMode>
refMode := ByValue | RefKind

SlotKind is the declaration-local kind by which one exact RelationSignature distinguishes one relation-participant meaning. HolderSystemSlot and AssignedSystemRoleKindSlot are different SlotKinds inside the InspectionShiftAssignment declaration even when a receiving assertion designates the holder by reference and the assigned system-role kind by value. A receiving semantic field is covered by an explicit declaration against one exact SlotSpec. An external or independently named representation field keeps its source name and requires an explicit correspondence to the declared SlotSpec; use C.29 when that correspondence is part of a declared mathematical-lens use. Neither route makes the field a SlotSpec or the designation an actual participant. A mathematical operand or numbered argument belongs to its mathematical representation, not to the relation declaration.

ValueKind is the exact world-side kind admitted for the actual participant corresponding to the declared participant meaning. Recover it from the accepted declaration that defines that kind. The declaration may settle a durable U-kind, a current C.3 kind, a Concept-Set entry, or an imported sort whose bridge states the corresponding FPF kind. If one proposed ValueKind hides several kinds for which the predicate has different meaning, recover their real common kind or split the relation kind. A prose list of alternatives does neither.

RefKind is the kind of reference used when a named-use assertion or relation-occurrence description episteme carries a relation-participant designation by reference. A system applying the declared resolution Method obtains a participant of the declared ValueKind as referent. U.EntityRef, U.HolonRef, U.EpistemeRef, and U.StructureRef are examples only where their exact RefKind declarations and admission predicates apply. The shorthand byRef is usable in a compact local sketch only when the exact RefKind is declared next to that sketch; it is not a complete refMode by itself.

ByValue means that an assertion or relation-occurrence description episteme carries a value as its relation-participant designation. By reference means that it carries a reference value of the declared RefKind as that designation. In both cases, the designation denotes the world-side actual participant. The reference value retains its RefKind, its referent retains the declared ValueKind, the SlotSpec remains declaration content, and the relation occurrence retains its direct identity.

Naming and source-token repair. Use ...Slot only for one declaration-local SlotKind inside one exact RelationSignature. Use ...Ref only for an admitted RefKind or for a reference value or designator of that kind; never use it for the actual participant or the SlotKind. Keep the participant’s ValueKind name free of both suffixes. Thus HolderSystemSlot is the SlotKind, U.System is the participant ValueKind, and Robot_7_Ref : U.EntityRef is a reference designation whose referent is Robot_7 : U.System. If a source token such as holder conflates those objects, split them rather than cosmetically renaming the token. A concrete source field keeps its source name and is related to the SlotSpec identified by HolderSystemSlot only through an explicit declaration or representation correspondence.