F.18:7.2 - Engineer-Roboticist and Musician

A lab says: “Vasya is an engineer, does robot engineering, is therefore an engineer-roboticist. These are musical robots, and Vasya is also a musician, performs music, and teaches robots music.”

Recovered values:

Vasya as an admitted system; MusicalRobotLab_2026 is the lab and Work locus in its direct relations, not a generic assignment participant;
RoboticsEngineerSystemRole, one local system-role kind whose admitted-system candidates count when they satisfy the current robotics-engineering condition, boundary probes, and continuity rule; MusicalRobotLab provenance locates the definition but does not identify the kind;
robotics as the qualification that distinguishes this local engineering kind, with any non-monotonic restriction retained as a separate A.2.7 relation;
MusicianSystemRole as another exact local kind when its own music-performance condition and boundary matter separately;
any current engineering or musician assignments as occurrences of their declared A.2.1 species;
robot-engineering Method or Work, music-performance Work, and robot-music-teaching Method or Work under their direct patterns;
an optional algebraic, graph, matrix, embedding, or neural representation only if the project actually uses that lens to describe the selected system-role-kind relation structure.

If the exact robotics-qualified local kind has been admitted, its local naming settlement is:

NameCard:
  NameCardId: NameCard.RoboticsEngineerSystemRole.MusicalRobotLab.2026
  GovernedValueRef: RoboticsEngineerSystemRole
  GovernedValueKindRef: U.Kind
  SubjectPatternLocator: A.2 with C.3 and A.2.7 for the separately current qualification relation
  ReferenceScheme: MusicalRobotLab-Scheme
  ClaimContent: NameCard.RoboticsEngineerSystemRole.MusicalRobotLab.2026.ClaimGraph
  LocalSenseRef: local expression `engineer-roboticist`; sense claim: the C.3 kind whose admitted-system candidates satisfy the current robotics-engineering condition, member/non-member boundary, and continuity rule; MusicalRobotLab provenance locates this settlement but does not identify the kind
  LocalSenseBasisRelationRef: absent; no separate source-bearing basis relation is current for this use
  TechLabel: RoboticsEngineerSystemRole
  PlainLabel: engineer-roboticist
  CandidateSet: RoboticsEngineerSystemRole; RoboticsEngineerRole; engineer-roboticist; robotics engineer; engineer and roboticist; RobotEngineeringMethod; engineer-roboticist-musician
  CandidateCoverage: system-role-kind head; ambiguous role head; two ordinary expressions; method neighbour; compressed multi-kind neighbour
  RejectedCandidates: RoboticsEngineerRole; engineer and roboticist; engineer-roboticist-musician; RobotEngineeringMethod
  SelectionRationale: the Tech label exposes one local system-role kind; the Plain label preserves recognizable lab speech; musician classification or assignment, Method, and Work remain separate
  BridgeRefs: absent; the card makes no semantic-correspondence claim
  PublicRowStatus: localOnly
  UnifiedTermRowRef: absent
  LineageEntries: `RoboticsEngineerRole` is predecessor wording only; ordinary `robotics engineer` remains available in local prose when no stable technical reference is needed
  RefreshCondition: reopen if the local kind or A.2.7 qualification changes, or readers merge musician classification or assignment, Method, or Work into this name

If no durable qualified kind is admitted, keep engineer-roboticist as local ordinary wording rather than filling the card. Ordinary project communication may say “Vasya is our engineer-roboticist and musician” when the separate claims about his engineering and musicianship remain recoverable; any assignment is another claim. Name a current Method, MethodDescription, or performed Work through A.3.1, A.3.2, or A.15.1. If public reuse becomes current, apply section 4.4; do not infer an F.17 row from this local card.