@memoarchitect/ontology 0.7.0 → 0.8.24

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

@@ -1,10 +1,56 @@
-// Functional architecture (§9). A SystemFunction is a technology-independent
-// responsibility of the system; a SystemAction is executable behavior realizing
-// a function; a FunctionalExchange is a typed transfer between functions. A
-// function may be realized by human action, mechanical design, electrical
-// hardware, software, or a combination — allocation is optional and never
-// assumes software.
+// Functional architecture (§9). A function is a responsibility: what the
+// system, or one of its components, is answerable for. A FunctionalExchange is
+// a typed transfer between functions. A function may be realized by human
+// action, mechanical design, electrical hardware, software, or a combination —
+// allocation to the system's own parts is what ComponentFunction records, and
+// it never assumes software.
+//
+// ─── A function is a behaviour ───────────────────────────────────────────
+//
+// `MemoFunction` and both its specializations are `action def`s. They were
+// `part def SystemFunction specializes MemoPart` until Track A0
+// removed the reason: relation ends were typed on part-based types,
+// KerML forbids a behaviour from specializing a part-based type, and a function
+// has to be satisfiable, verifiable, and allocatable. So a function was declared
+// a part, and a separate `action def OperativeAction` carried the behaviour with a
+// `ref performedFunction` stapling the two back together — a reference used in
+// 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.
+//
+// `functionCategory` and `actionKind` are NOT two spellings of one axis, and
+// merging them would lose information. `actionKind` is the verb — sense,
+// compute, actuate, route. `functionCategory` is the domain grouping the
+// project argues in — therapy, alarm, platform, protection. A function can be
+// `sense` in the `protection` category, and a safety case reasons about both.
+//
+// ─── System function vs. component function ──────────────────────────────
+//
+// ARCADIA's functional chain does not stop at the system boundary: system
+// functions decompose until each piece is the responsibility of exactly one
+// component. MEMO names the two ends of that chain because they obey different
+// rules, not because they carry different attributes:
+//
+//   SystemFunction    — a responsibility of the system as a whole.
+//                       Technology-independent. Allocation is OPTIONAL, and a
+//                       system function may be realized by several components,
+//                       by a human, or by mechanism.
+//   ComponentFunction — a responsibility of ONE component: a flowmeter's
+//                       "measure flow rate", a subsystem's "arbitrate alarms".
+//                       Allocation is MANDATORY and single-valued (CR-ONT-074).
+//
+// That difference is structural, which is why these are two definitions rather
+// than one definition carrying a `functionLevel` enum. An enum member cannot
+// change a multiplicity, and "is answerable to exactly one component" is the
+// whole content of the concept.
+//
+// Decomposition and allocation reuse the existing relations and need no new
+// ones — `Composes` for the function tree, `AllocatedTo` for the component.
+// Both had part-typed ends until A0; both are metaclass-neutral now, which is
+// precisely what makes an action-def function usable at all.
 package memo_architecture_functional_functions {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -13,62 +59,73 @@ package memo_architecture_functional_functions {
     private import memo_architecture_operational_activities::*;
     private import memo_architecture_operational_scenarios::*;
 
-    part def SystemFunction specializes ArchitectureElement {
+    abstract action def MemoFunction specializes MemoAction {
         attribute functionCategory : String;
+        attribute actionKind : ActionKind;
         attribute trigger : String;
         attribute outputSummary : String;
         attribute concernKind : ConcernKind;
         attribute criticality : CriticalityKind;
     }
 
-    // Executable behavior realizing a system function.
-    action def SystemAction specializes MemoAction {
-        attribute actionKind : ActionKind;
-        attribute executionSummary : String;
-        ref performedFunction : SystemFunction[0..1];
-    }
+    // A responsibility of the system as a whole. Allocation is optional: a
+    // system function that no single component owns is a normal intermediate
+    // state of the functional chain, not a defect.
+    action def SystemFunction specializes MemoFunction;
+
+    // A responsibility of exactly one component. `AllocatedTo` names that
+    // component; CR-ONT-074 requires it. A component function that reaches no
+    // component is a responsibility nobody has accepted.
+    action def ComponentFunction specializes MemoFunction;
 
     // Named traceable route between functions. Native `flow of` usages carry
-    // the transported item; this element exists for budgets and assurance
-    // attributes that a flow usage cannot own.
-    part def FunctionalExchange specializes ArchitectureElement {
+    // the transported item; this element exists for the budgets and assurance
+    // attributes below.
+    //
+    // The reason is MEMO's grammar, NOT the language — the earlier wording here
+    // said "attributes that a flow usage cannot own", and that was a false
+    // claim about SysML v2. The standard's `FlowUsage` is
+    // `OccurrenceUsagePrefix 'flow' FlowDeclaration DefinitionBody`
+    // (SysML-textual-bnf.kebnf:829), so a conforming flow usage takes a name
+    // from its `UsageDeclaration` and owns attributes in its body like any
+    // other usage. MEMO's own production is
+    // `'flow' 'of' itemType 'from' … 'to' … ';'` — no name, no body — so a
+    // MEMO flow can carry neither an `id` nor a latency budget, and nothing
+    // can refer to it. Every MEMO element rests on the identification core in
+    // memo_core_common, and an anonymous attribute-less edge cannot join it.
+    //
+    // So this part def is a workaround for a MEMO gap, not a design MEMO is
+    // entitled to. Restoring the two dropped clauses is what would let it
+    // collapse into the flow it stands in for.
+    part def FunctionalExchange specializes MemoPart {
         attribute flowKind : FlowKind;
         attribute latencyBudgetMs : Real;
         attribute staleAfterMs : Real;
         attribute integrityLevel : String;
-        ref sourceFunction : SystemFunction[0..1];
-        ref targetFunction : SystemFunction[0..1];
+        // MemoFunction, not SystemFunction: an exchange between two component
+        // functions is the ordinary case once the chain is decomposed.
+        ref sourceFunction : MemoFunction[0..1];
+        ref targetFunction : MemoFunction[0..1];
     }
 
     // A system function enables operational work; it does not perform it.
 
     // A reusable functional route through system responsibilities. Functional
     // flows are part of functional architecture, never logical structure.
-    part def FunctionalFlow specializes ArchitectureElement {
+    part def FunctionalFlow specializes MemoPart {
         attribute flowCategory : FunctionalFlowKind;
         attribute endToEndLatencyBudgetMs : String;
         attribute safetyRelevant : Boolean;
         attribute securityRelevant : Boolean;
     }
     action def FunctionalFlowStep specializes MemoAction {
-        ref function : SystemFunction[0..1];
+        ref function : MemoFunction[0..1];
         ref exchange : FunctionalExchange[0..1];
-        ref item exchangedItem : MemoExchangeItem[0..1];
+        ref item exchangedItem : MemoItem[0..1];
     }
 
-    // The functional-layer scenario selects one functional route and realizes
-    // an operative scenario. It is the "what the system does" path, not a
-    // logical component interaction.
-    action def FunctionalScenario specializes MemoScenario {
-        ref selectedFlow : FunctionalFlow[0..1];
-    }
-    connection def IncludesStep :> MemoRelationship {
-        end functionalFlow : FunctionalFlow;
-        end step : FunctionalFlowStep;
-    }
-    connection def InvolvesFunction :> MemoRelationship {
-        end functionalFlow : FunctionalFlow;
-        end function : SystemFunction;
-    }
-    // Compatibility spelling used by existing models.
+    // `InvolvesFunction` is native `perform` (R10-S6): a `FunctionalFlow`
+    // already names its functions via its step chain
+    // (`perform <step>;` + the step's own `ref function`), and a flow with no
+    // step chain performs its functions directly.
 }

package/src/architecture/implementation/hardware/common/memo_hardware_common.sysml

@@ -13,7 +13,7 @@ package memo_architecture_implementation_hardware_common {
     private import memo_core_enumerations::*;
     private import memo_core_relationships::*;
 
-    part def PhysicalAssembly specializes ArchitectureElement {
+    part def PhysicalAssembly specializes MemoPart {
         attribute responsibility : String;
         attribute safetyRole : String;
         attribute partNumber : String;
@@ -25,7 +25,7 @@ package memo_architecture_implementation_hardware_common {
     // Retained name from 0.4; an electronics-centred assembly.
     part def HardwareAssembly specializes PhysicalAssembly;
 
-    part def PhysicalComponent specializes ArchitectureElement {
+    part def PhysicalComponent specializes MemoPart {
         attribute partNumber : String;
         attribute materialSummary : String;
         // ISO 10993-1 contact characterization; required when true.

package/src/architecture/implementation/software/runtime/memo_software_runtime.sysml

@@ -1,10 +1,17 @@
-// Software runtime (component-and-connector) view (§11). Runtime structure
-// with concurrency, scheduling, health monitoring, fault containment, and
-// update/rollback semantics. Module structure lives in
+// Software runtime (component-and-connector) view (§11), matching the SEI
+// Views and Beyond distinction between runtime components and implementation
+// modules. Runtime structure carries concurrency, scheduling, health
+// monitoring, fault containment, and update/rollback semantics. Module structure lives in
 // memo_architecture_implementation_software_structure; allocation in
-// memo_architecture_realization_deployment. Detailed AADL categories stay in the AADL
-// correspondence profile (examples/aadl-mapping).
+// memo_architecture_realization_deployment.
+//
+// Detailed AADL categories live in the AADL correspondence profile, which is
+// an extension package: `extensions/aadl` (plan §C5). It carries the process /
+// thread / virtual-processor families and a correspondence rule per mapped
+// name and property. This comment pointed at `examples/aadl-mapping` for a
+// long time and that directory never existed; the pointer above resolves.
 package memo_architecture_implementation_software_runtime {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -25,7 +32,7 @@ package memo_architecture_implementation_software_runtime {
         enum messageBroker;
     }
 
-    part def SoftwareComponent specializes SoftwareItem {
+    part def SoftwareComponent specializes SoftwareElement {
         attribute runtimeKind : RuntimeKind;
         attribute responsibility : String;
         attribute periodMs : Real;
@@ -36,7 +43,10 @@ package memo_architecture_implementation_software_runtime {
         attribute activation : String;
         attribute synchronizationMechanism : String;
         attribute sharedResources : String;
-        attribute memoryBudget : String;
+        // Maximum resident memory allocation in megabytes.  The public name
+        // predates MEMO's unit-suffixed scalar convention, so document the
+        // unit here rather than silently changing the published feature name.
+        attribute memoryBudget : Real;
         attribute healthMonitoring : String;
         attribute restartPolicy : String;
         attribute faultContainment : String;
@@ -45,24 +55,38 @@ package memo_architecture_implementation_software_runtime {
         attribute auditable : Boolean;
         attribute updatePolicy : String;
         attribute rollbackPolicy : String;
-        // runtime-kind-specific detail (set only for the relevant runtimeKind)
-        attribute addressSpaceIsolated : Boolean[0..1];
-        attribute owningProcessName : String[0..1];
-        attribute serviceContract : String[0..1];
-        attribute discoveryMechanism : String[0..1];
-        attribute imageReference : String[0..1];
-        attribute orchestrationPlatform : String[0..1];
-        attribute partitionBudget : String[0..1];
-        attribute isolationMechanism : String[0..1];
-        attribute storageKind : String[0..1];
-        attribute retentionPolicy : String[0..1];
-        attribute deliverySemantics : String[0..1];
-        attribute topicStructure : String[0..1];
+        // Twelve runtime-kind-conditional attributes used to follow, each
+        // documented "set only for the relevant runtimeKind" — which is a
+        // subtype family in disguise, and a technology the base ontology had
+        // no business asserting. They are gone; every one of them now lives on
+        // a type in an extension, where it is unconditional and therefore
+        // checkable (plan §10.3 D3, extensions/README.md):
+        //
+        //   addressSpaceIsolated, owningProcessName,
+        //   partitionBudget, isolationMechanism          -> extensions/aadl
+        //   serviceContract, discoveryMechanism,
+        //   storageKind, retentionPolicy                 -> extensions/cloud
+        //   imageReference, orchestrationPlatform        -> extensions/container
+        //   deliverySemantics, topicStructure            -> extensions/messaging
+        //
+        // The last two were also on the wrong metaclass: a component does not
+        // have a topic, a publication does.
+        //
+        // What stays is what is true of EVERY runtime component in every
+        // regulated project — the AADL thread properties above and the
+        // assurance ones — plus `runtimeKind` itself, which says which family
+        // a component belongs to without claiming to describe it.
     }
 
     connection def ComponentConnects :> MemoRelationship {
         attribute protocolSummary : String;
-        end sourceComponent : SoftwareComponent;
-        end targetComponent : SoftwareComponent;
+        end sourceComponent : SoftwareComponent :>> source;
+        end targetComponent : SoftwareComponent :>> target;
+    }
+    abstract connection componentConnectsLinks : ComponentConnects[*];
+    metadata def <componentConnects> ComponentConnectsMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = componentConnectsLinks meta SysML::Usage;
     }
 }

package/src/architecture/implementation/software/structure/memo_software_structure.sysml

@@ -1,7 +1,10 @@
-// Software module view (§11; IEC 62304 5.3-5.4). Code/module structure only:
-// runtime structure lives in memo_architecture_implementation_software_runtime and
-// allocation in memo_architecture_realization_deployment.
+// Software module view (§11; IEC 62304 5.3-5.4). Following the SEI Views and
+// Beyond viewtypes, modules are implementation/code units; interacting runtime
+// elements are SoftwareComponents in
+// memo_architecture_implementation_software_runtime, and allocation lives in
+// memo_architecture_realization_deployment.
 package memo_architecture_implementation_software_structure {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -21,12 +24,16 @@ package memo_architecture_implementation_software_structure {
     // software view inherits it rather than re-declaring it: the code view
     // (SoftwareModule), the runtime view (SoftwareComponent), the system, and
     // the user interface (memo_architecture_implementation_ui::UIElement).
-    abstract part def SoftwareItem specializes ArchitectureElement {
+    // Structural software decomposition is part-native. IEC 62304 also uses
+    // the term "software item" for this concept, but reserving SoftwareItem
+    // for the native SysML item family keeps structural parts and exchanged
+    // values unambiguous in the model.
+    abstract part def SoftwareElement specializes MemoPart {
         attribute safetyClass : SafetyClassKind;
         attribute complexity : ComplexityKind;
     }
 
-    part def SoftwareSystem specializes SoftwareItem {
+    part def SoftwareSystem specializes SoftwareElement {
         attribute version : String;
         attribute operatingSystem : String;
     }
@@ -44,7 +51,7 @@ package memo_architecture_implementation_software_structure {
         enum soup;
     }
 
-    part def SoftwareModule specializes SoftwareItem {
+    part def SoftwareModule specializes SoftwareElement {
         attribute moduleKind : ModuleKind;
         attribute responsibility : String;
         // module-kind-specific detail (set only for the relevant moduleKind)
@@ -63,22 +70,30 @@ package memo_architecture_implementation_software_structure {
         attribute soupClassification : SOUPClassificationKind[0..1];
     }
 
-    part def Algorithm specializes ArchitectureElement {
+    part def Algorithm specializes MemoPart {
         attribute algorithmKind : String;
         attribute inputSummary : String;
         attribute outputSummary : String;
         attribute clinicalPerformanceClaim : String;
     }
-    part def DataModel specializes ArchitectureElement {
+    part def DataModel specializes MemoPart {
         attribute schemaReference : String;
         attribute persistenceScope : String;
     }
-    part def ConfigurationArtifact specializes ArchitectureElement {
+    part def ConfigurationArtifact specializes MemoPart {
         attribute configurationScope : String;
         attribute version : String;
     }
 
-    item def SBOMEntry specializes MemoExchangeItem {
+    // Software data/content that may be stored or exchanged through ports.
+    abstract item def SoftwareItem specializes MemoItem {
+        attribute schemaIdentifier : String;
+        attribute schemaVersion : String;
+        attribute :>> encoding : String;
+        attribute :>> timestampRequired : Boolean;
+    }
+
+    item def SBOMEntry specializes SoftwareItem {
         attribute componentName : String;
         attribute version : String;
         attribute supplier : String;
@@ -86,8 +101,20 @@ package memo_architecture_implementation_software_structure {
         attribute hash : String;
     }
 
-    connection def ModuleUses :> MemoRelationship {
-        end usingModule : SoftwareModule;
-        end usedModule : SoftwareModule;
+    // `ModuleUses` is native `dependency` (R10-S6): write
+    // `dependency <usingModule> to <usedModule>;` instead of a connection.
+
+    // ── Relations owned by this package ─────────────────────────────
+    // Moved out of memo_core_relationships: their ends are typed against
+    // types declared here, and core must not depend on a domain package.
+    connection def DependsOnSoup :> MemoRelationship {
+        end component : MemoPart :>> source;
+        end soupItem : SoftwareElement :>> target;
+    }
+    abstract connection dependsOnSoupLinks : DependsOnSoup[*];
+    metadata def <dependsOnSoup> DependsOnSoupMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = dependsOnSoupLinks meta SysML::Usage;
     }
 }

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

@@ -5,10 +5,12 @@
 // UI is an implementation concern (rendered UI is software; physical controls
 // are hardware), so it lives in the implementation layer, not operational.
 package memo_architecture_implementation_ui {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
     private import memo_core_enumerations::*;
+    private import memo_assurance_safety_risk::*;   // RiskControlMeasure
     private import memo_core_relationships::*;
     private import memo_architecture_operational_activities::*;
     private import memo_architecture_operational_scenarios::*;
@@ -108,7 +110,7 @@ package memo_architecture_implementation_ui {
         enum recovery;
     }
 
-    part def UserInterface specializes ArchitectureElement {
+    part def UserInterface specializes MemoPart {
         attribute modality : String;
         attribute uiTechnology : String;
     }
@@ -119,7 +121,7 @@ package memo_architecture_implementation_ui {
     // "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 ArchitectureElement {
+    abstract part def InteractionElement specializes MemoPart {
         attribute labelText : String;
         attribute accessibilitySummary : String;
         // alarm annunciation (optional; IEC 60601-1-8)
@@ -143,15 +145,15 @@ package memo_architecture_implementation_ui {
     // errors, and risk controls already trace to it. Screen layout adds four
     // numbers to that tree — it does not add a tree.
     //
-    // A UIElement IS a SOFTWARE ITEM (IEC 62304 §3.25) and specializes the
-    // SoftwareItem base, inheriting safetyClass and complexity, so the
+    // A UIElement IS a structural SOFTWARE ITEM (IEC 62304 §3.25) and
+    // specializes SoftwareElement, inheriting safetyClass and complexity, so the
     // interface is classified and decomposed like the software it is.
     //
-    // It specializes SoftwareItem and NOT SoftwareModule: the module view is
+    // It specializes SoftwareElement and NOT SoftwareModule: the module view is
     // 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 SoftwareItem, InteractionElement {
+    part def UIElement specializes SoftwareElement, InteractionElement {
         attribute formKind : UIElementFormKind;
         // ── screen layout (optional; set for elements that are laid out) ──
         // Bounds are relative to the parent element in the Composes tree; a
@@ -169,6 +171,11 @@ package memo_architecture_implementation_ui {
         // Capture-relative fill transparency for region review overlays. A
         // modelled value keeps interactive review and exported figures aligned.
         attribute boundaryOpacity : Real[0..1];
+        // Stroke width of the same box, in pixels. Colour and opacity are
+        // modelled so a review print, an exported figure, and the workbench
+        // agree on which box is which; a width chosen per renderer breaks that
+        // agreement for exactly the same reason.
+        attribute boundaryWidth : Real[0..1];
         attribute detectionMethod : BoundsDetectionKind[0..1];
         attribute detectionConfidence : Real[0..1];
         attribute confirmedBy : String;
@@ -228,7 +235,7 @@ package memo_architecture_implementation_ui {
     }
 
     // ─── Captured evidence ───────────────────────────────────────
-    // One image of one screen. MemoEvidence, not ArchitectureElement: it
+    // One image of one screen. MemoEvidence, not a design element: it
     // records what a specific build actually displayed at a specific time,
     // which is the provenance a design review or a usability engineering file
     // needs before it can rely on the picture. The screen it depicts is an
@@ -251,11 +258,11 @@ package memo_architecture_implementation_ui {
     }
 
     // UI state is presentation state — distinct from system/device state.
-    part def UIState specializes ArchitectureElement {
+    part def UIState specializes MemoPart {
         attribute displayedInformation : String;
         attribute availableActions : String;
     }
-    part def UIEvent specializes ArchitectureElement {
+    part def UIEvent specializes MemoPart {
         attribute eventSource : String;
         attribute intent : InteractionIntentKind;
     }
@@ -267,38 +274,44 @@ package memo_architecture_implementation_ui {
     }
 
     // A reusable dialogue structure through the UI; a selected path through
-    // it is an UIScenario.
+    // it is a OperativeScenario with scenarioKind `ui`.
     action def InteractionFlow specializes MemoAction {
         attribute entryPoint : String;
         attribute exitPoint : String;
     }
 
-    action def UIScenario specializes MemoScenario {
-        ref parentFlow : InteractionFlow[0..1];
-    }
-
-    connection def UITransition :> MemoRelationship {
-        attribute triggeringEvent : String;
-        attribute guardCondition : String;
-        end sourceState : UIState;
-        end targetState : UIState;
-    }
     connection def DataBinding :> MemoRelationship {
         attribute bindingExpression : String;
         attribute refreshPolicy : String;
-        end boundElement : InteractionElement;
-        end dataSource : MemoPart;
+        end boundElement : InteractionElement :>> source;
+        end dataSource : MemoItem :>> target;
     }
-    connection def PresentsState :> MemoRelationship {
-        end userInterface : UserInterface;
-        end uiState : UIState;
+    abstract connection dataBindingLinks : DataBinding[*];
+    metadata def <dataBinding> DataBindingMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = dataBindingLinks meta SysML::Usage;
     }
+    // `PresentsState` had zero usages anywhere in the tree (R10-S6). Its
+    // audited native form, `exhibit state`, does not actually fit: `UIState`
+    // is a `part def` with plain string attributes, not a `state def`, and
+    // SysIDE rejects `exhibit` referencing anything that does not conform to
+    // `States::StateAction` ("An exhibit state must reference another
+    // state"). Free deletion rather than a migration — nothing referenced
+    // it, so nothing to preserve. If `UIState` is ever restructured onto a
+    // real state machine, `exhibit state` becomes available then.
 
     // ── Screen layout relations ──────────────────────────────────
     // Which modelled screen an image is a rendering of.
     connection def CapturesScreen :> MemoRelationship {
-        end capture : ScreenCapture;
-        end screen : UIElement;
+        end capture : ScreenCapture :>> source;
+        end screen : UIElement :>> target;
+    }
+    abstract connection capturesScreenLinks : CapturesScreen[*];
+    metadata def <capturesScreen> CapturesScreenMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = capturesScreenLinks meta SysML::Usage;
     }
 
     // Activating this element opens another screen. This is NAVIGATION, not
@@ -309,34 +322,61 @@ package memo_architecture_implementation_ui {
     // from here, and only this relation says so.
     connection def NavigatesTo :> MemoRelationship {
         attribute triggerGesture : String;
-        end sourceElement : UIElement;
-        end targetScreen : UIElement;
+        end sourceElement : UIElement :>> source;
+        end targetScreen : UIElement :>> target;
+    }
+    abstract connection navigatesToLinks : NavigatesTo[*];
+    metadata def <navigatesTo> NavigatesToMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = navigatesToLinks meta SysML::Usage;
     }
 
     // ── §18 traceability ─────────────────────────────────────────
     connection def ElementTriggersAction :> MemoRelationship {
-        end element : InteractionElement;
-        end triggeredAction : UIAction;
+        end element : InteractionElement :>> source;
+        end triggeredAction : UIAction :>> target;
     }
-    connection def ActionInvokesFunction :> MemoRelationship {
-        end uiAction : UIAction;
-        end systemFunction : SystemFunction;
+    abstract connection elementTriggersActionLinks : ElementTriggersAction[*];
+    metadata def <elementTriggersAction> ElementTriggersActionMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = elementTriggersActionLinks meta SysML::Usage;
     }
+    // `ActionInvokesFunction` is native `perform` (R10-S6): write
+    // `perform <systemFunction>;` inside the `UIAction` usage instead.
     connection def FlowServesUseCase :> MemoRelationship {
-        end interactionFlow : InteractionFlow;
-        end useCase : UseCase;
+        end interactionFlow : InteractionFlow :>> source;
+        end useCase : UseCase :>> target;
+    }
+    abstract connection flowServesUseCaseLinks : FlowServesUseCase[*];
+    metadata def <flowServesUseCase> FlowServesUseCaseMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = flowServesUseCaseLinks meta SysML::Usage;
     }
-    // The UI-layer scenario realizes exactly one FunctionalScenario one layer
-    // up (the interaction sequence that carries out the function sequence),
-    // completing the OperativeScenario → FunctionalScenario → UIScenario chain.
+    // A UI scenario realizes a functional scenario one layer up: each is a
+    // OperativeScenario selected by scenarioKind rather than a separate definition.
     connection def ErrorAtElement :> MemoRelationship {
-        end useError : UseError;
-        end element : InteractionElement;
+        end useError : UseError :>> source;
+        end element : InteractionElement :>> target;
+    }
+    abstract connection errorAtElementLinks : ErrorAtElement[*];
+    metadata def <errorAtElement> ErrorAtElementMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = errorAtElementLinks meta SysML::Usage;
     }
     // A risk control implemented by a UI element or by task design
     // (confirmation dialog, lockout, guarded control).
     connection def ControlImplementedBy :> MemoRelationship {
-        end riskControl : VerifiableElement;
-        end implementingElement : ArchitectureElement;
+        end riskControl : RiskControlMeasure :>> source;
+        end implementingElement :>> target;
+    }
+    abstract connection controlImplementedByLinks : ControlImplementedBy[*];
+    metadata def <controlImplementedBy> ControlImplementedByMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = controlImplementedByLinks meta SysML::Usage;
     }
 }