@memoarchitect/ontology 0.7.0 → 0.8.22

package/extensions/ros/src/ros_extension.sysml

@@ -0,0 +1,200 @@
+// ROS 2 (Robot Operating System 2).
+//
+// The acceptance test for MEMO's extension point (plan §10.3): a whole
+// technology stack — nodes, messages, topics, quality of service, services,
+// actions, and
+// containerized deployment — landing without a single change to a base
+// relation. `BuildsInto`, `DeploysTo`, and `ProvidesEnvironment` are reused
+// exactly as the base declares them.
+//
+// Composition is by MODULE LIST, not by chaining. `baseMethodology` is [0..1],
+// but `includedModule` is [0..*], so this extension's methodology names
+// `memo_extension_messaging` and `memo_extension_container` alongside its own
+// module. ROS communication specializes native MEMO item, port, and interface
+// families; it does not invent publish/subscribe relations.
+package memo_extension_ros {
+    private import ScalarValues::*;
+
+    private import memo_core_common::*;
+    private import memo_architecture_functional_behavior::*;
+    private import memo_architecture_logical_interfaces::*;
+    private import memo_architecture_implementation_software_structure::*;
+    private import memo_architecture_implementation_software_runtime::*;
+    private import memo_extension_messaging::*;
+    private import memo_extension_container::*;
+
+    // ── Quality of service ──────────────────────────────────────────────
+    //
+    // QoS is the first real customer for "where do per-technology properties
+    // live" (plan C3, open question §14.6). The answer is a typed
+    // `attribute def` on the extension's own types — NOT the base's
+    // `PropertySet` stub, which was one String field and could not say what a
+    // reliability setting is. A typed profile can be validated, compared
+    // between a publisher and a subscriber, and read by a tool; a property bag
+    // cannot. `PropertySet` is deleted in this session for that reason.
+
+    // ROS 2 RELIABLE resends until delivery; BEST_EFFORT does not. This is
+    // the delivery guarantee, so it maps onto MessagingDeliveryKind:
+    // bestEffort is atMostOnce, reliable is atLeastOnce.
+    enum def RosReliabilityKind {
+        enum bestEffort;
+        enum reliable;
+    }
+    // TRANSIENT_LOCAL replays the last samples to a late-joining subscriber;
+    // VOLATILE does not. The difference decides whether a node that restarts
+    // sees the current state or waits for the next publication — which is a
+    // safety-relevant fact when the topic carries a latched mode or setpoint.
+    enum def RosDurabilityKind {
+        enum volatile;
+        enum transientLocal;
+    }
+
+    attribute def RosQosProfile {
+        attribute reliability : RosReliabilityKind;
+        attribute durability : RosDurabilityKind;
+        // The QoS contract: a sample is expected at least this often.
+        attribute deadlineMs : Real;
+        // How long a publisher may be silent before subscribers treat it as
+        // lost — ROS 2 liveliness lease duration.
+        attribute livelinessLeaseMs : Real;
+        // Depth of the history buffer, KEEP_LAST(n) / KEEP_ALL.
+        attribute historyDepth : Integer;
+    }
+
+    // ── Nodes, messages, topics, and endpoint roles ────────────────────
+
+    // A ROS node. `runtimeKind` is deliberately NOT bound: a node may run as
+    // its own process or be composed with others into a single container
+    // process, and which one it is is a design decision the model should
+    // record rather than a fact the type can assert.
+    part def RosNode specializes SoftwareComponent {
+        attribute nodeNamespace : String;
+        // Whether the node implements the managed-node lifecycle
+        // (unconfigured / inactive / active / finalized). A lifecycle-managed
+        // node can be brought up in a defined order and held inactive until
+        // its preconditions hold, which is how a robot reaches a safe state.
+        attribute lifecycleManaged : Boolean;
+        attribute executorModel : String;
+    }
+
+    // A definition is the ROS message contract (`LaserScan`, `Twist`, ...).
+    // A named item usage of that definition is a deployed topic (`/scan`).
+    // Individual deliveries are native flows/messages between ports that
+    // reference the same topic usage.
+    abstract item def RosMessage specializes MessagingMessage {
+        attribute rosTypeName : String;
+    }
+
+    port def RosPublisher specializes MessagingPublisher {
+        attribute offeredQos : RosQosProfile;
+    }
+
+    port def RosSubscriber specializes MessagingSubscriber {
+        attribute requestedQos : RosQosProfile;
+    }
+
+    interface def RosTopicInterface specializes MessagingTopicInterface {
+        end rosPublisher : RosPublisher :>> publisher;
+        end rosSubscriber : RosSubscriber :>> subscriber;
+    }
+
+    // ── Services: one correlated request/reply contract ────────────────
+    abstract item def RosServiceRequest specializes RosMessage;
+    abstract item def RosServiceResponse specializes RosMessage;
+
+    port def RosServiceClient specializes SoftwarePort {
+        out item request : RosServiceRequest;
+        in item response : RosServiceResponse;
+        attribute serviceName : String;
+        attribute timeoutMs : Real;
+    }
+
+    port def RosServiceServer specializes SoftwarePort {
+        in item request : RosServiceRequest;
+        out item response : RosServiceResponse;
+        attribute serviceName : String;
+    }
+
+    interface def RosServiceInterface specializes SoftwareInterface {
+        end client : RosServiceClient :>> source;
+        end server : RosServiceServer :>> target;
+        flow of RosServiceRequest from client.request to server.request;
+        flow of RosServiceResponse from server.response to client.response;
+    }
+
+    // ── Actions: long-running goal protocol ─────────────────────────────
+    // ROS 2 realizes an action through goal/result/cancel services plus
+    // feedback/status topics. The port exposes those distinct native message
+    // features, so an action cannot be mistaken for a two-message service.
+    abstract item def RosActionGoal specializes RosMessage;
+    abstract item def RosActionAcceptance specializes RosMessage;
+    abstract item def RosActionFeedback specializes RosMessage;
+    abstract item def RosActionResult specializes RosMessage;
+    abstract item def RosActionCancel specializes RosMessage;
+    abstract item def RosActionStatus specializes RosMessage;
+
+    port def RosActionClient specializes SoftwarePort {
+        out item goal : RosActionGoal;
+        in item acceptance : RosActionAcceptance;
+        in item feedback : RosActionFeedback;
+        in item result : RosActionResult;
+        out item cancel : RosActionCancel;
+        in item actionStatus : RosActionStatus;
+        attribute actionName : String;
+    }
+
+    port def RosActionServer specializes SoftwarePort {
+        in item goal : RosActionGoal;
+        out item acceptance : RosActionAcceptance;
+        out item feedback : RosActionFeedback;
+        out item result : RosActionResult;
+        in item cancel : RosActionCancel;
+        out item actionStatus : RosActionStatus;
+        attribute actionName : String;
+    }
+
+    interface def RosActionInterface specializes SoftwareInterface {
+        end client : RosActionClient :>> source;
+        end server : RosActionServer :>> target;
+        flow of RosActionGoal from client.goal to server.goal;
+        flow of RosActionAcceptance from server.acceptance to client.acceptance;
+        flow of RosActionFeedback from server.feedback to client.feedback;
+        flow of RosActionCancel from client.cancel to server.cancel;
+        flow of RosActionResult from server.result to client.result;
+        flow of RosActionStatus from server.actionStatus to client.actionStatus;
+    }
+
+    abstract state def RosActionExecution specializes MemoState;
+    state def RosActionAccepted specializes RosActionExecution;
+    state def RosActionExecuting specializes RosActionExecution;
+    state def RosActionCanceling specializes RosActionExecution;
+    state def RosActionSucceeded specializes RosActionExecution;
+    state def RosActionCanceled specializes RosActionExecution;
+    state def RosActionAborted specializes RosActionExecution;
+
+    // ── Deployment ──────────────────────────────────────────────────────
+    //
+    // Nothing below declares a relation. The base's three deployment
+    // relations already say everything a ROS deployment needs:
+    //   BuildsInto          SoftwareModule -> RosContainerImage
+    //   DeploysTo           RosContainerImage -> ProcessingNode
+    //   ProvidesEnvironment ProcessingNode -> RosContainerRuntime
+    // That is the proof the base is factored correctly.
+    part def RosContainerImage specializes ContainerImage {
+        // humble, iron, jazzy, rolling.
+        attribute rosDistribution : String;
+        // The workspace overlay the image was built from.
+        attribute workspaceOverlay : String;
+    }
+
+    part def RosContainerRuntime specializes ContainerRuntime {
+        attribute rosDistribution : String;
+        // The RMW implementation below ROS 2 — rmw_fastrtps_cpp,
+        // rmw_cyclonedds_cpp. QoS is enforced here, so it is part of any
+        // argument that a QoS profile is actually honoured.
+        attribute rmwImplementation : String;
+        // ROS_DOMAIN_ID. Two robots sharing a domain see each other's topics,
+        // which is a hazard on a shared network and not visible in any node.
+        attribute rosDomainId : Integer;
+    }
+}

package/extensions/template/src/extension.sysml

@@ -0,0 +1,37 @@
+// Skeleton for a new MEMO extension. Copy the directory, rename the packages,
+// and replace the prefix.
+//
+// Two conventions this file follows and every extension must (extensions/README.md):
+//
+//   1. Every definition an extension declares is prefixed with the PascalCase
+//      form of the extension's directory name — `template/` gives `Template`.
+//      Extension names share one flat namespace with the base and with each
+//      other, so the prefix is what keeps two independent extensions from both
+//      declaring `Node`.
+//   2. A relation an extension declares specializes a base relation. It never
+//      roots independently.
+//
+// This package used to bind `baseMethodName = "MedicalDeviceLightDefault"` — a
+// pre-flip spelling that resolves to nothing. It went unnoticed for as long as
+// extensions lived under `examples/`, where the build did not check them; the
+// build checks `extensions/` now, and reported it on the first run.
+package memo_extension_template {
+    private import ScalarValues::*;
+    private import memo_core_enumerations::*;
+    private import memo_methodology_core::*;
+    private import memo_methodology_profiles::*;
+
+    part extensionMethod : MethodologyDefinition {
+        attribute :>> id = "EXT-METH-001";
+        attribute :>> name = "ExtensionMethod";
+        attribute :>> version = "0.1.0";
+        attribute :>> domain = "project extension";
+        attribute :>> description = "Adds a project or domain package to the selected MEMO methodology.";
+        // The base is a typed SysML reference, not a name held in sync by hand.
+        ref :>> baseMethodology = mdDefaultDefinition;
+        // An extension adds its own module to whatever its base selected;
+        // saying so explicitly is required now that an empty list means empty.
+        attribute :>> scopeMode = ScopeModeKind::explicit;
+        attribute :>> includedModule = "replace_with_extension_package";
+    }
+}

package/memo.manifest.yaml

@@ -19,5 +19,16 @@ examples:
   standard-sysml-diagrams: ./examples/sysml-diagram-samples
   ui-screen-regions: ./examples/ui-screen-regions
   nested-architecture-dsm: ./examples/nested-architecture-dsm
-  extension-template: ./examples/extensions/template
-  clinical-extension: ./examples/extensions/clinical
+  ros-mobile-robot: ./examples/ros-mobile-robot
+# Extensions are a way to MODEL, not a thing to copy. They are reusable
+# ontology packages that specialize the base, selected by a methodology or a
+# project binding — so they sit beside the ontology, not under examples/.
+# `examples/ros-mobile-robot` demonstrates using one; it is not the extension.
+extensions:
+  template: ./extensions/template
+  clinical: ./extensions/clinical
+  aadl: ./extensions/aadl
+  cloud: ./extensions/cloud
+  container: ./extensions/container
+  messaging: ./extensions/messaging
+  ros: ./extensions/ros

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.7.0
+version: 0.8.22
 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.7.0
+version: 0.8.22
 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.7.0
+version: 0.8.22
 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,11 +1,12 @@
 {
   "name": "@memoarchitect/ontology",
-  "version": "0.7.0",
+  "version": "0.8.22",
   "packageManager": "pnpm@9.15.0",
   "description": "MEMO \u2014 Medical Engineering Modelling Ontology. Pure SysML v2 medical-device ontology with native constraints, portable to any conformant SysML v2 tool (SysIDE, SysON, sysand).",
   "scripts": {
     "build": "bash scripts/build-kpar.sh",
-    "check": "bash scripts/build-kpar.sh",
+    "check": "bash scripts/build-kpar.sh && npm run lint",
+    "lint": "node ../memo-tools/packages/tools/lib/bin/memo.js dhf lint",
     "test": "node --test test/package.test.mjs",
     "docs:api": "node scripts/generate-sysml-api.mjs",
     "docs:diagrams": "node scripts/generate-reference-diagrams.mjs",
@@ -69,6 +70,7 @@
     "src/viewpoints/",
     "src/memo_namespaces.sysml",
     "templates/",
-    "examples/"
+    "examples/",
+    "extensions/"
   ]
 }

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.7.0
+version: 0.8.22
 description: Closure rules and viewpoints for medical device modeling
 license: MIT
 tags:

package/src/architecture/decisions/memo_decisions.sysml

@@ -1,4 +1,5 @@
 package memo_architecture_decisions {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -13,7 +14,27 @@ package memo_architecture_decisions {
     }
 
     connection def DecisionRecordedInADR :> MemoRelationship {
-        end decision : DesignDecision;
-        end adr : ADRArtifact;
+        end decision : DesignDecision :>> source;
+        end adr : ADRArtifact :>> target;
+    }
+    abstract connection decisionRecordedInADRLinks : DecisionRecordedInADR[*];
+    metadata def <decisionRecordedInADR> DecisionRecordedInADRMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = decisionRecordedInADRLinks meta SysML::Usage;
+    }
+
+    // ── 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 Decides :> MemoRelationship {
+        end decision : DesignDecision :>> source;
+        end affectedElement : MemoPart :>> target;
+    }
+    abstract connection decidesLinks : Decides[*];
+    metadata def <decides> DecidesMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = decidesLinks meta SysML::Usage;
     }
 }

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

@@ -3,29 +3,50 @@ package memo_architecture_functional_behavior {
 
     private import memo_core_common::*;
     private import memo_core_enumerations::*;
+
+    // Typed functional execution step. Project-specific action definitions
+    // specialize this rather than bypassing MemoAction; ActivityFlow remains
+    // the composite route that sequences such steps.
+    abstract action def FunctionalAction specializes MemoAction;
     // State machines and their mode states are SysML v2 states (behaviours), so
     // they derive from the MemoState foundation, not the part-based
     // ArchitectureElement. Transitions stay part-based (below) to keep their
     // traceable safety attributes.
-    // State-machine vocabulary. ModeState denotes a state owned by this model.
+    // State machines retain their own execution semantics; individual modes
+    // are MemoState usages selected by stateKind.
     state def StateMachine :> MemoState {
         attribute machineKind : String;
         attribute executionSemantics : String;
     }
-    state def ModeState :> MemoState {
-        attribute modeKind : String;
-        attribute entryCondition : String;
-        attribute exitCondition : String;
+    // A configuration is the concrete selection made at a `variation` choice
+    // point. It remains separate from a mode state: it says which mode and
+    // elements are active in one selectable arrangement.
+    // The reference is typed to the shared native state family so a consumer
+    // can navigate from the selected configuration to its governing mode.
+    part def ModeConfiguration specializes ArchitectureElement {
+        ref activeMode : MemoState[1];
+        ref activeElement : MemoPart[0..*];
     }
-    part def Transition specializes ArchitectureElement {
+    // Transitions are native SysML v2 `transition` usages inside the owning
+    // state — there is no `part def Transition`, and its `transition` keyword
+    // collision is why. A transition usage's definition is always implicit, so
+    // it has no MEMO supertype to carry the identification core; this record
+    // carries it instead, applied with `@TransitionRecord`.
+    //
+    // `trigger`, `guardSummary`, and `effectSummary` are prose summaries, not
+    // executable semantics: a guard reading "none in source (MEMO extension
+    // REQ-X-02 additionally gates therapy on POST)" is a citation. Formal
+    // triggers and guards belong in native `accept` and `if`; these stay
+    // records so the two are not confused.
+    metadata def TransitionRecord {
+        attribute id : String;
+        attribute name : String;
         attribute trigger : String;
         attribute guardSummary : String;
         attribute effectSummary : String;
-        attribute priority : Integer;
-        attribute sameStepCritical : Boolean;
-        attribute sourceState : String;
-        attribute targetState : String;
+        attribute sourceReference : String;
     }
+
     // A verifiable behavioural constraint, such as an invariant, transition
     // rule, temporal claim, assumption, or guarantee.
     part def BehaviorProperty specializes VerifiableElement {
@@ -34,7 +55,21 @@ package memo_architecture_functional_behavior {
         attribute formalExpression : String;
     }
     part def Contract specializes VerifiableElement { attribute contractScope : String; }
-    part def PropertySet specializes VerifiableElement { attribute propertySetScope : String; }
+    // `part def PropertySet specializes VerifiableElement { attribute
+    // propertySetScope : String; }` stood here and is DELETED (plan C3,
+    // open question §14.6). It was AADL's property-set idea imported as a
+    // name: one String field, no typed content, no binding to whatever it
+    // annotated, and zero usages anywhere in the tree.
+    //
+    // Per-technology properties belong on the extension type that owns them,
+    // typed. ROS QoS was the first real customer and settled it:
+    // `attribute def RosQosProfile` has reliability, durability, deadline,
+    // liveliness and history depth as typed fields, so a publisher's offer and
+    // a subscriber's request can be compared. A `propertySetScope` String
+    // could not have expressed one of them. Where an extension needs to
+    // annotate a BASE element rather than declare its own type, the SysML-
+    // native answer is `metadata def` + `Metaobjects::SemanticMetadata`, which
+    // is what every MEMO relation already carries since A4.
     part def ActivityAction specializes ArchitectureElement {
         attribute actionKind : ActionKind;
         attribute inputSummary : String;
@@ -47,20 +82,13 @@ package memo_architecture_functional_behavior {
         attribute guardCondition : String;
         attribute weight : String;
     }
-    // UIScenario now lives in memo_architecture_implementation_ui (:> MemoScenario).
-    part def InteractionMessage specializes MemoPart {
-        attribute messageKind : MessageKind;
-        attribute sequenceOrder : Integer;
-        attribute senderComponent : String;
-        attribute receiverComponent : String;
-        attribute exchangeItem : String;
-        attribute timingConstraintMs : String;
-    }
+    // UI scenarios are MemoScenario usages with scenarioKind `ui`.
+
     part def TimingConstraint specializes VerifiableElement {
         attribute constraintKind : TimingConstraintKind;
         attribute minMs : String;
         attribute maxMs : String;
-        attribute referenceElement : String;
+        ref referenceElement : MemoPart[1];
         attribute verificationMethod : VerificationMethodKind;
     }
 }

package/src/architecture/functional/constraints/memo_constraints.sysml

@@ -1,13 +1,14 @@
 package memo_architecture_functional_constraints {
     private import ScalarValues::*;
+    private import memo_core_common::*;
 
     doc /* Reusable quantitative constraint definitions. */
 
-    constraint def MaxResponseTimeConstraint {
+    constraint def MaxResponseTimeConstraint :> MemoConstraint {
         attribute responseTimeMs : Real;
         attribute maxAllowedMs : Real;
     }
-    constraint def LockoutIntervalConstraint {
+    constraint def LockoutIntervalConstraint :> MemoConstraint {
         attribute elapsedMs : Real;
         attribute lockoutMs : Real;
     }

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 ArchitectureElement` until Track A0
+// removed the reason: relation ends were typed on MemoPart/ArchitectureElement,
+// 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 SystemAction` 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: SystemAction 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,31 +59,53 @@ 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.
+    // 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 ArchitectureElement {
         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.
@@ -51,24 +119,13 @@ package memo_architecture_functional_functions {
         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.
 }