@memoarchitect/ontology 0.11.2 → 0.12.1

package/examples/sysml-diagram-samples/model/catalog/viewpoints/unassigned/views/sequence_view.sysml

@@ -0,0 +1,97 @@
+package diagram_samples {
+    // Sequence sample (sequence view kind, `seq` diagram type). A FunctionalFlow
+    // owns an ordered chain of FunctionalFlowSteps; each step is `allocate`d to
+    // the lifeline (an actor or component) that performs it, and the sequence
+    // template lays lifelines out as columns with one row per step in
+    // declaration order.
+    private import ScalarValues::*;
+
+    private import memo_architecture_operational_context_actors::*;
+    private import memo_architecture_logical_structure::*;
+    private import memo_architecture_functional_functions::*;
+    private import memo_core_relationships::*;
+    private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_functional_functional_viewpoint::*;
+    private import memo_core_enumerations::*;
+
+    private import memo_core_common::*;
+    private import memo_core_common::MemoIdentity;
+
+    // Lifelines — the actor and components each step is allocated to.
+    part clinician : User { attribute :>> name = "Clinician"; }
+    part pumpController : LogicalComponent { attribute :>> name = "Pump Controller"; }
+    part pumpMechanism : LogicalComponent { attribute :>> name = "Pump Mechanism"; }
+
+    // Combined fragment definitions — referenced by steps' `fragment` attribute.
+    part monitorLoop {
+        attribute :>> name = "Monitor Loop";
+        attribute fragmentType = "loop";
+        attribute guard = "vitals abnormal";
+    }
+    part errorHandling {
+        attribute :>> name = "Error Handling";
+        attribute fragmentType = "alt";
+        attribute fragmentGuards = "[error recoverable]|[else]";
+    }
+
+    action startInfusion : FunctionalFlow {
+        attribute :>> name = "Start Infusion";
+
+        action stepRequestStart : FunctionalFlowStep { attribute :>> name = "Request start infusion"; }
+        action stepValidate : FunctionalFlowStep { attribute :>> name = "Validate prescribed rate"; }
+        action stepCommandMotor : FunctionalFlowStep { attribute :>> name = "Command motor drive"; }
+        action stepConfirm : FunctionalFlowStep { attribute :>> name = "Confirm delivery started"; }
+
+        // Steps inside the monitoring loop fragment
+        action stepReadSensor : FunctionalFlowStep { attribute :>> name = "Read sensor data"; attribute stepOrder = "5"; attribute fragment = "monitorLoop"; }
+        action stepCheckVitals : FunctionalFlowStep { attribute :>> name = "Check vital signs"; attribute stepOrder = "6"; attribute fragment = "monitorLoop"; }
+
+        // Steps inside the alt (error-handling) fragment
+        action stepRetryDelivery : FunctionalFlowStep { attribute :>> name = "Retry delivery"; attribute stepOrder = "7"; attribute fragment = "errorHandling"; attribute fragmentOperand = "1"; }
+        action stepAlertUser : FunctionalFlowStep { attribute :>> name = "Alert user"; attribute stepOrder = "8"; attribute fragment = "errorHandling"; attribute fragmentOperand = "2"; }
+
+        action stepNotify : FunctionalFlowStep { attribute :>> name = "Notify delivery started"; attribute stepOrder = "9"; }
+
+        first start then stepRequestStart;
+        first stepRequestStart then stepValidate;
+        first stepValidate then stepCommandMotor;
+        first stepCommandMotor then stepConfirm;
+        first stepConfirm then stepReadSensor;
+        first stepReadSensor then stepCheckVitals;
+        first stepCheckVitals then stepRetryDelivery;
+        first stepCheckVitals then stepAlertUser;
+        first stepRetryDelivery then stepNotify;
+        first stepAlertUser then stepNotify;
+        first stepNotify then done;
+    }
+
+    // Lane assignment — which lifeline performs each step, in the order the
+    // sequence reads top to bottom: clinician requests, controller validates,
+    // mechanism drives, controller confirms, clinician is notified.
+    allocate startInfusion.stepRequestStart to clinician;
+    allocate startInfusion.stepValidate to pumpController;
+    allocate startInfusion.stepCommandMotor to pumpMechanism;
+    allocate startInfusion.stepConfirm to pumpController;
+    allocate startInfusion.stepReadSensor to pumpMechanism;
+    allocate startInfusion.stepCheckVitals to pumpController;
+    allocate startInfusion.stepRetryDelivery to pumpController;
+    allocate startInfusion.stepAlertUser to clinician;
+    allocate startInfusion.stepNotify to clinician;
+
+    view startInfusionSequence : MemoDiagramView {
+        expose startInfusion::**;
+        expose clinician::**;
+        expose pumpController::**;
+        expose pumpMechanism::**;
+        expose monitorLoop::**;
+        expose errorHandling::**;
+        attribute depth = 2;
+        @MemoIdentity { :>> shortDescription = "Start-infusion sequence with combined fragments — loop for sensor monitoring and alt for error handling."; }
+        attribute :>> viewKind = DiagramViewKind::sequence;
+        attribute :>> diagramType = "seq";
+        ref :>> viewpointDefinition = sequenceViewpoint;
+        part :>> selectionQuery {
+            attribute :>> includeElementKinds = ("FunctionalFlowStep", "User", "LogicalComponent", "Part");
+        }
+    }
+}

package/examples/sysml-diagram-samples/model/catalog/viewpoints/unassigned/views/standard_activity_view.sysml

@@ -1,17 +1,17 @@
-// Standard SysML v2 activity sample (actionflow view kind, `afd` diagram type).
-//
-// The view over `activity_example::CustomerProcess`, the standard-SysML activity
-// fixture in `model/sysml_v2_activity_example.sysml`. It exists because the
-// fixture's whole point is the node types `action_flow_view.sysml` does not
-// have — decision, merge, fork, join, accept, send, terminate, and guarded
-// successions. Without a view exposing it the fixture parses into the model and
-// is never drawn, which is indistinguishable from a renderer that cannot draw
-// decisions.
-//
-// Nothing here specializes a MEMO kind: the fixture is plain standard SysML,
-// and that is the property under test. The renderer classifies its nodes from
-// the metamodel (`activity-notation.ts`), not from an ontology kind.
-package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_standard_activity_view {
+package diagram_samples {
+    // Standard SysML v2 activity sample (actionflow view kind, `afd` diagram type).
+    //
+    // The view over `activity_example::CustomerProcess`, the standard-SysML activity
+    // fixture in `model/sysml_v2_activity_example.sysml`. It exists because the
+    // fixture's whole point is the node types `action_flow_view.sysml` does not
+    // have — decision, merge, fork, join, accept, send, terminate, and guarded
+    // successions. Without a view exposing it the fixture parses into the model and
+    // is never drawn, which is indistinguishable from a renderer that cannot draw
+    // decisions.
+    //
+    // Nothing here specializes a MEMO kind: the fixture is plain standard SysML,
+    // and that is the property under test. The renderer classifies its nodes from
+    // the metamodel (`activity-notation.ts`), not from an ontology kind.
     private import ScalarValues::*;
 
     private import memo_core_relationships::*;
@@ -23,12 +23,12 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_standard
 
     private import memo_core_common::*;
     private import memo_core_common::MemoIdentity;
-    view standardActivityView : MemoDiagramView {
-        expose CustomerProcess::**;
+    view orderFulfillmentActivity : MemoDiagramView {
+        expose FulfillOrder::**;
         attribute depth = 2;
-        @MemoIdentity { :>> shortDescription = "Customer login, guarded validation, shopping loop, checkout, credit approval, and explicit completion outcomes."; }
+        @MemoIdentity { :>> shortDescription = "Order fulfilment — accept, validate, decide, fork into parallel shipment and invoice, join, notify, send receipt, and terminate."; }
         attribute :>> viewKind = DiagramViewKind::actionflow;
         attribute :>> diagramType = "afd";
-        ref :>> viewpointDefinition = functionalViewpoint;
+        ref :>> viewpointDefinition = actionFlowViewpoint;
     }
 }

package/examples/sysml-diagram-samples/model/catalog/viewpoints/unassigned/views/state_transition_view.sysml

@@ -1,7 +1,7 @@
-// State transition sample (statetransition view kind, `stm` diagram type). A
-// behaviour machine owns its mode states by containing them, and each native
-// transition lives inside the state whose substates it connects.
-package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_state_transition_view {
+package diagram_samples {
+    // State transition sample (statetransition view kind, `stm` diagram type). A
+    // behaviour machine owns its mode states by containing them, and each native
+    // transition lives inside the state whose substates it connects.
     private import ScalarValues::*;
 
     private import memo_architecture_functional_behavior::*;
@@ -62,18 +62,30 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_state_tr
         }
     }
 
-    view sampleStateTransitionView : MemoDiagramView {
+    view pumpModeStateMachine : MemoDiagramView {
         expose pumpModes::**;
         attribute depth = 2;
         @MemoIdentity { :>> shortDescription = "A pump-mode state machine — Idle, Infusing, Paused, Alarm — where Infusing is a composite state nesting Priming, Delivering and Holding."; }
         attribute :>> viewKind = DiagramViewKind::statetransition;
         attribute :>> diagramType = "stm";
-        ref :>> viewpointDefinition = functionalViewpoint;
+        ref :>> viewpointDefinition = stateMachineViewpoint;
         part :>> selectionQuery {
             attribute :>> includeElementKinds = ("StateMachine", "MemoState");
         }
     }
 
+    view infusingSubStates : MemoDiagramView {
+        expose pumpModes.infusing::**;
+        attribute depth = 2;
+        @MemoIdentity { :>> shortDescription = "Sub-states of the Infusing composite state — Priming, Delivering, and Holding with their internal transitions."; }
+        attribute :>> viewKind = DiagramViewKind::statetransition;
+        attribute :>> diagramType = "stm";
+        ref :>> viewpointDefinition = stateMachineViewpoint;
+        part :>> selectionQuery {
+            attribute :>> includeElementKinds = ("MemoState");
+        }
+    }
+
     // The machine is one containment tree, so exposing its root reaches every
     // state and transition; the former per-element IncludedIn list restated
     // that tree a second time and is gone with it.

package/examples/sysml-diagram-samples/model/catalog/viewpoints/unassigned/views/tree_view.sysml

@@ -1,4 +1,4 @@
-package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_tree_view {
+package diagram_samples {
     private import ScalarValues::*;
     private import memo_architecture_implementation_hardware_structure::*;
 
@@ -16,7 +16,7 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_tree_vie
             attribute :>> name = "Branch A.1";
             part leafA11 : HardwareAssembly {
                 attribute :>> name = "Leaf A.1.1";
-                attribute :>> partNumber = "PN-001";
+                attribute :>> partNumber = "PN-1";
             }
             part leafA12 : HardwareAssembly { attribute :>> name = "Leaf A.1.2"; }
         }
@@ -33,13 +33,13 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_tree_vie
         }
     }
 
-    view sampleTreeView : MemoDiagramView {
+    view blockDecomposition : MemoDiagramView {
         expose rootA::**;
         attribute depth = 2;
-        @MemoIdentity { :>> shortDescription = "One connected dummy hierarchy with varied branch depths for tree layout development."; }
+        @MemoIdentity { :>> shortDescription = "Block decomposition tree — hardware assemblies with varied branch depths."; }
         attribute :>> viewKind = DiagramViewKind::general;
         attribute :>> diagramType = "bdd";
-        ref :>> viewpointDefinition = physicalViewpoint;
+        ref :>> viewpointDefinition = treeViewpoint;
         attribute :>> layoutHint = "tree";
         attribute :>> styleHint = "expanded:rootA,rootB,branchA1,branchB1";
         part :>> selectionQuery {

package/examples/sysml-diagram-samples/model/catalog/viewpoints/unassigned/views/use_case_view.sysml

@@ -1,4 +1,4 @@
-package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case_view {
+package diagram_samples {
     private import ScalarValues::*;
     private import memo_architecture_operational_context_actors::*;
     private import memo_architecture_operational_use_cases::*;
@@ -9,6 +9,15 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case
 
     private import memo_core_common::*;
     private import memo_core_common::MemoIdentity;
+
+    // Generalization (specialization) relation for UML-style use-case diagrams.
+    // Source is the specific element, target the general one; the UCD renderer
+    // draws a solid line with a hollow triangle pointing at the general end.
+    connection def Specialization :> MemoRelationship {
+        end specialized :>> source;
+        end general :>> target;
+    }
+
     // Product-neutral fixture for the UML-style use-case presentation.
     part patient : User {
         attribute :>> actorKind = ActorKind::patient;
@@ -22,9 +31,13 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case
         attribute :>> actorKind = ActorKind::technician;
         attribute :>> name = "Service Technician";
     }
+    part nursingStaff : User {
+        attribute :>> actorKind = ActorKind::clinician;
+        attribute :>> name = "Nursing Staff";
+    }
 
     use case reviewStatus : UseCase {
-        @MemoIdentity { :>> providedId = "UC-SAMPLE-001"; }
+        @MemoIdentity { :>> providedId = "UC-SAMPLE-1"; }
         attribute :>> name = "Review Device Status";
         attribute :>> useCaseKind = UseCaseKind::clinical;
         include validateTherapySettings;
@@ -32,7 +45,7 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case
         actor patientActor = patient;
     }
     use case configureTherapy : UseCase {
-        @MemoIdentity { :>> providedId = "UC-SAMPLE-002"; }
+        @MemoIdentity { :>> providedId = "UC-SAMPLE-2"; }
         attribute :>> name = "Configure Therapy";
         attribute :>> useCaseKind = UseCaseKind::clinical;
         include reviewStatus;
@@ -41,7 +54,7 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case
         actor patientActor = patient;
     }
     use case maintainDevice : UseCase {
-        @MemoIdentity { :>> providedId = "UC-SAMPLE-003"; }
+        @MemoIdentity { :>> providedId = "UC-SAMPLE-3"; }
         attribute :>> name = "Maintain Device";
         attribute :>> useCaseKind = UseCaseKind::service;
         subject supportingSystem;
@@ -49,14 +62,14 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case
     }
 
     use case documentTreatment : UseCase {
-        @MemoIdentity { :>> providedId = "UC-SAMPLE-004"; }
+        @MemoIdentity { :>> providedId = "UC-SAMPLE-4"; }
         attribute :>> name = "Document Treatment";
         attribute :>> useCaseKind = UseCaseKind::clinical;
     }
 
     // L2 child of Review Device Status: makes L0 → L1 → L2 selectable.
     use case validateTherapySettings : UseCase {
-        @MemoIdentity { :>> providedId = "UC-SAMPLE-005"; }
+        @MemoIdentity { :>> providedId = "UC-SAMPLE-5"; }
         attribute :>> name = "Validate Therapy Settings";
         attribute :>> useCaseKind = UseCaseKind::clinical;
         subject supportingSystem;
@@ -67,24 +80,34 @@ package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case
     // specialization, and `:>` inherits the base's subject and actors.
     dependency from documentTreatment to reviewStatus;
 
-    view sampleUseCaseView : MemoDiagramView {
+    // Actor generalization: Nursing Staff is a specialization of Clinician.
+    // UML draws this as a solid line with a hollow triangle arrowhead pointing
+    // at the general actor.
+    connection : Specialization connect nursingStaff to clinician;
+
+    // Use-case generalization: Configure Therapy specializes Review Device
+    // Status — the general case is browsing status; configuring therapy is a
+    // more specific variant.
+    connection : Specialization connect configureTherapy to reviewStatus;
+
+    view deviceUseCases : MemoDiagramView {
         expose patient;
         expose clinician;
         expose serviceTechnician;
+        expose nursingStaff;
         expose reviewStatus;
         expose configureTherapy;
         expose maintainDevice;
         expose documentTreatment;
         expose validateTherapySettings;
-        @MemoIdentity { :>> shortDescription = "Actors outside a device boundary with include, extend, hierarchy-level, and orthogonal-routing presentation."; }
+        @MemoIdentity { :>> shortDescription = "Actors outside a device boundary with include, extend, generalization, hierarchy-level, and orthogonal-routing presentation."; }
         attribute :>> viewKind = DiagramViewKind::general;
         attribute :>> diagramType = "ucd";
-        ref :>> viewpointDefinition = operationalViewpoint;
+        ref :>> viewpointDefinition = useCaseViewpoint;
         part :>> selectionQuery {
             attribute :>> includeElementKinds = ("User", "UseCase");
-            attribute :>> includeRelationshipKinds = ("ParticipatesIn", "IncludesStep", "Extends");
+            attribute :>> includeRelationshipKinds = ("ParticipatesIn", "IncludesStep", "Extends", "Specialization");
         }
-        // Presentation is owned by the model view, rather than a canvas control.
         attribute :>> layoutHint = "usecase:level=all;edge=rounded";
     }
 }

package/extensions/aadl/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/extension-aadl'
-version: 0.11.2
+version: 0.12.1
 description: AADL (SAE AS5506) correspondence profile and runtime component families
 license: MIT
 tags:

package/extensions/cloud/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/extension-cloud'
-version: 0.11.2
+version: 0.12.1
 description: Networked services and managed data stores
 license: MIT
 tags:

package/extensions/container/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/extension-container'
-version: 0.11.2
+version: 0.12.1
 description: OCI container images and container runtimes as deployment content
 license: MIT
 tags:

package/extensions/messaging/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/extension-messaging'
-version: 0.11.2
+version: 0.12.1
 description: Publish/subscribe messaging — topics, brokers, and delivery semantics
 license: MIT
 tags:

package/extensions/ros/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/extension-ros'
-version: 0.11.2
+version: 0.12.1
 description: ROS 2 nodes, messages, topic/service/action interfaces, QoS, and containerized deployment
 license: MIT
 tags:

package/methodologies/default/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/methodology-default'
-version: 0.11.2
+version: 0.12.1
 description: "MEMO default medical-device methodology \u2014 selects viewpoints/views/DHF documents from @memoarchitect/ontology and adds rules, gates, patterns, profiles, and workflow."
 license: MIT
 tags:

package/methodologies/gpca/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/methodology-gpca'
-version: 0.11.2
+version: 0.12.1
 description: "GPCA infusion pump methodology \u2014 subtraction-based tailoring of @memoarchitect/methodology-default for the non-networked prototype variant. Excludes cybersecurity and SOUP."
 license: MIT
 tags:

package/ontology/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/ontology'
-version: 0.11.2
+version: 0.12.1
 description: "MEMO \u2014 the single canonical medical-device ontology: core semantics, the Arcadia-inspired architecture layers (context, requirements, behavior, structure, interfaces, risk, cybersecurity,\
   \ assurance, \u2026), compliance, viewpoints, views, and invariant rules. One namespace (memo::), one src/ tree."
 license: MIT

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@memoarchitect/ontology",
-  "version": "0.11.2",
+  "version": "0.12.1",
   "packageManager": "pnpm@9.15.0",
   "description": "MEMO — Medical Engineering Modelling Ontology. Pure SysML v2 medical-device ontology with native constraints, portable to any conformant SysML v2 tool (SysIDE, SysON, sysand).",
   "scripts": {

package/profile/memo.package.yaml

@@ -7,7 +7,7 @@
 # (`type`, `extends`, `usage`, `ontologies`, `methodology`, `modules`) were
 # removed at the native semantic flip and are now rejected if present.
 name: '@memoarchitect/medical-modeling-profile'
-version: 0.11.2
+version: 0.12.1
 description: Closure rules and viewpoints for medical device modeling
 license: MIT
 tags:

package/src/architecture/functional/behavior/memo_behavior.sysml

@@ -88,7 +88,14 @@ package memo_architecture_functional_behavior {
         attribute constraintKind : TimingConstraintKind;
         attribute minMs : String;
         attribute maxMs : String;
-        ref referenceElement : MemoPart[1];
+        // Untyped, the way `InteractsInContext::systemOfInterest` is: what a
+        // latency or period is measured against is a behaviour at least as
+        // often as it is a structure — a functional flow, an action, a port.
+        // `MemoPart[1]` said otherwise and could only ever have held the
+        // structural half, which is the same A0 residue that kept
+        // `FunctionalFlow` a part def. MEMO has no root above the metaclasses
+        // by design, so spanning them means naming none.
+        ref referenceElement[1];
         attribute verificationMethod : MemoVerificationMethodKind;
     }
 }

package/src/architecture/functional/functions/memo_functions.sysml

@@ -17,7 +17,9 @@
 // ZERO example files. The ends are metaclass-neutral now (CR-ONT-060..073), so
 // the split has no cause and is gone: OperativeAction is merged into the function
 // family, and its `actionKind` moved onto MemoFunction where it was always
-// describing the function anyway.
+// describing the function anyway. `FunctionalFlow` was the one element A0 left
+// behind on the part side; it is an `action def` now, for the same reason and
+// on the same evidence.
 //
 // `functionCategory` and `actionKind` are NOT two spellings of one axis, and
 // merging them would lose information. `actionKind` is the verb — sense,
@@ -112,7 +114,19 @@ package memo_architecture_functional_functions {
 
     // A reusable functional route through system responsibilities. Functional
     // flows are part of functional architecture, never logical structure.
-    part def FunctionalFlow specializes MemoPart {
+    //
+    // An `action def`, like every other behaviour in MEMO. It was
+    // `part def ... specializes MemoPart` for the Track A0 reason described at
+    // the top of this file — relation ends typed on part-based types, and
+    // KerML forbids a behaviour from specializing one — and it was the single
+    // element A0 did not carry across when that reason went away. A route
+    // through responsibilities is the same shape as the `OperationalWorkflow`
+    // and `OperativeScenario` it sits beside: the scenarios package calls a
+    // scenario "a selected path through a workflow (or functional flow)",
+    // naming the two as one kind of thing, and its steps are `action def`s
+    // already. A structure whose whole body is `perform` is a behaviour that
+    // has not been allowed to say so.
+    action def FunctionalFlow specializes MemoAction {
         attribute flowCategory : FunctionalFlowKind;
         attribute endToEndLatencyBudgetMs : String;
         attribute safetyRelevant : Boolean;

package/src/architecture/implementation/ui/memo_ui.sysml

@@ -115,21 +115,15 @@ package memo_architecture_implementation_ui {
         attribute uiTechnology : String;
     }
 
-    // What a rendered control and a physical one genuinely share: a label, an
-    // accessibility story, and — when they annunciate — an alarm character.
-    // The base exists so that the §18 traceability relations can type against
-    // "something the user interacts with" rather than against software
-    // specifically. Without it a use error on a knob would be unmodellable,
-    // because ErrorAtElement would only accept a UIElement.
-    abstract part def InteractionElement specializes MemoPart {
-        attribute labelText : String;
-        attribute accessibilitySummary : String;
-        // alarm annunciation (optional; IEC 60601-1-8)
-        attribute alarmPriority : NotificationPriorityKind[0..1];
-        attribute annunciationModality : String;
-        attribute silenceable : Boolean;
-    }
-
+    // `InteractionElement` was an abstract base over UIElement and
+    // OperatorInterfaceElement, existing so the §18 relations could type
+    // against "something the user interacts with". It was both redundant and
+    // too narrow: the nearest real common ancestor is already `MemoPart`, and
+    // IEC 62366-1 puts the whole means of interaction in scope — a mis-keyed
+    // connector, a moulded marking on a housing, a tube routed backwards are
+    // use errors at parts that were never interaction elements and so could
+    // not be named. `ErrorAtElement` and `ElementTriggersAction` now take
+    // `MemoPart`; the attributes moved to whichever type actually set them.
 
     // One UIElement — the single UI part type. The widget form — holding
     // (screen/panel/dialog), acting (button/knob/slider), presenting
@@ -153,8 +147,20 @@ package memo_architecture_implementation_ui {
     // CODE, and a screen is not a source module. Runtime processes are
     // SoftwareComponent, code is SoftwareModule, and the UI is a third view of
     // the same software — a sibling of those, not a kind of either.
-    part def UIElement specializes SoftwareElement, InteractionElement {
+    part def UIElement specializes SoftwareElement {
         attribute formKind : UIElementFormKind;
+        // The visible label. Held here rather than on a shared interaction
+        // base: a physical control's label is moulded or printed, and is
+        // `legendText` on OperatorInterfaceElement.
+        attribute labelText : String;
+        // ── alarm annunciation (optional; IEC 60601-1-8) ──
+        // On the rendered element, because that is where every modelled
+        // annunciation lives. A physical annunciator that needs a priority
+        // wants an alarm concept of its own, not three attributes copied onto
+        // every front-panel part.
+        attribute alarmPriority : NotificationPriorityKind[0..1];
+        attribute annunciationModality : String;
+        attribute silenceable : Boolean;
         // ── screen layout (optional; set for elements that are laid out) ──
         // Bounds are relative to the parent element in the Composes tree; a
         // root screen's bounds are the full frame.
@@ -222,7 +228,7 @@ package memo_architecture_implementation_ui {
         enum printedMarking;
     }
 
-    part def OperatorInterfaceElement specializes PhysicalComponent, InteractionElement {
+    part def OperatorInterfaceElement specializes PhysicalComponent {
         attribute formKind : OperatorInterfaceFormKind;
         // actuation (optional; set for actuated forms)
         attribute actuationForce : String;
@@ -267,7 +273,17 @@ package memo_architecture_implementation_ui {
         attribute intent : InteractionIntentKind;
     }
 
-    action def UIAction specializes MemoAction {
+    // Clicking a button IS an operative action: it has a trigger, a
+    // precondition, a criticality, a potential harm and a frequency of use,
+    // exactly as turning a knob does. Specializing MemoAction directly made
+    // UIAction a SIBLING of OperativeAction, which cost two things — a UI
+    // action could carry none of those ten attributes, and `CommitsUseError`
+    // (source end: OperativeAction) would not accept it, so a use error
+    // committed by a click was unmodellable.
+    //
+    // The three attributes here are what a UI action adds on top: what the
+    // user meant by it, what came back, and whether it asks first.
+    action def UIAction specializes OperativeAction {
         attribute intent : InteractionIntentKind;
         attribute feedbackProvided : String;
         attribute confirmationRequired : Boolean;
@@ -310,8 +326,13 @@ package memo_architecture_implementation_ui {
     // from here, and only this relation says so.
 
     // ── §18 traceability ─────────────────────────────────────────
+    // Source is `MemoPart`, not a UI-specific base: a foot pedal and a
+    // rendered button trigger the same kind of action, and the two are a
+    // PhysicalComponent and a SoftwareElement whose only common ancestor is
+    // MemoPart. CR-MED-111 still holds rendered controls to it, and it is
+    // scoped to UIElement, so the wider end does not weaken the rule.
     connection def ElementTriggersAction :> MemoRelationship {
-        end element : InteractionElement :>> source;
+        end element : MemoPart :>> source;
         end triggeredAction : UIAction :>> target;
     }
     abstract connection elementTriggersActionLinks : ElementTriggersAction[*];
@@ -334,9 +355,14 @@ package memo_architecture_implementation_ui {
     }
     // A UI scenario realizes a functional scenario one layer up: each is a
     // OperativeScenario selected by scenarioKind rather than a separate definition.
+    // Target is `MemoPart`. IEC 62366-1 scopes the user interface to every
+    // means of interaction, so a use error lands wherever the user got it
+    // wrong — a mis-keyed connector, a moulded marking, a tube routed
+    // backwards — not only on a control. Narrowing this to an interaction
+    // base made those unmodellable.
     connection def ErrorAtElement :> MemoRelationship {
         end useError : UseError :>> source;
-        end element : InteractionElement :>> target;
+        end element : MemoPart :>> target;
     }
     abstract connection errorAtElementLinks : ErrorAtElement[*];
     metadata def <errorAtElement> ErrorAtElementMetadata :> SemanticMetadata {