@memoarchitect/ontology 0.13.2 → 0.15.1

package/src/architecture/logical/interfaces/memo_interfaces.sysml

@@ -1,3 +1,39 @@
+// Logical interfaces: the Interface definition, ports, exchange items, and
+// the component exchange.
+//
+// ─── A component exchange is an interface ────────────────────────────────
+//
+// `ComponentExchange` is an `interface def`: the edge between two ports IS
+// the exchange. It was a `part def` whose `sourceEndpoint`/`targetEndpoint`
+// refs named the ports, beside a separate `flow` or `bind` naming them again,
+// and CR-ONT-076 existed only to keep the two representations in step. It
+// also lost information: the builder stored a dotted ref value as its first
+// segment only, so every endpoint read as the enclosing device, and
+// CR-ONT-072/073 checked the device instead of the port.
+//
+// Its ends are the ports, and they are ports, never components: §6.2 of the
+// architecture plan requires an actual boundary port, and a rule
+// (CR-ONT-072/073) says so because the compiler does not — it accepts a
+// part at an interface end even when the definition types its ends.
+//
+// ─── Transport, delegation, and the choice between them ──────────────────
+//
+// Two ports joined by an interface still need a statement of what moves:
+// the `flow` between the same two ports. The interface is the path, and the
+// flow is the transfer over it.
+//
+// An enclosing part's boundary port and the port of a part inside it are a
+// different case, decided per hop:
+//
+//   flow     when the hop has something of its own to model: a delay, a
+//            queue, a timing or latency budget, a protocol. Write it inside
+//            the enclosing part's body, where the boundary port is a source.
+//   binding  when the boundary port is the inner port exposed and nothing
+//            happens between them: `binding name bind outer = inner { … }`,
+//            carrying the connection's identity and citation in its body.
+//
+// A delegation that is a binding is not a ComponentExchange: nothing
+// interacts, and one feature is seen from both sides.
 package memo_architecture_logical_interfaces {
     private import ScalarValues::*;
 
@@ -15,40 +51,40 @@ package memo_architecture_logical_interfaces {
     // DigitalInterface / SPIInterface / RestInterface … hierarchy: those were
     // 20+ classes that differed only in the value of `protocol`.
 
+    // The common contract of an interface, whatever layer it is on: what
+    // crosses, which way, under what timing, and how much it matters to
+    // safety and security. It is abstract. An interface is a LOGICAL one
+    // (between components, in terms of what is exchanged), a SOFTWARE one
+    // (a contract between software items) or a PHYSICAL one (between
+    // hardware ports), and those are three different things that share
+    // attributes, not one thing with three sets of optional fields. Each
+    // specialization adds only what its layer can state: PhysicalInterface
+    // the signal and the medium, SoftwareInterface the API.
+    //
     // Specializes the standard library interface as well as MEMO's base,
     // rather than shadowing it — see the note on UseCase.
-    interface def Interface specializes MemoInterface, Interfaces::Interface {
-        attribute interfaceKind : InterfaceKind;   // semantic + signaling family
+    abstract interface def Interface specializes MemoInterface, Interfaces::Interface {
+        attribute interfaceKind : InterfaceKind;   // what crosses
         attribute direction : DirectionKind;
         attribute protocol : String;               // "SPI", "CAN", "Ethernet", "REST", "4-20mA"
         attribute protocolSemantics : String;
+        attribute timeoutMs : Real[0..1];
+        attribute retryPolicy : String[0..1];
         attribute interactionPattern : String;     // request-response, pub-sub, streaming…
-        attribute signalKind : String;
         attribute timingSummary : String;
         attribute timingConstraint : String;
         attribute bandwidth : String;
-        attribute schemaReference : String;
         attribute compatibilitySummary : String;
         attribute isolationRequirement : String;
         attribute safetyRelevant : Boolean;
         attribute securityCriticality : CriticalityKind;
         // Applied-part/patient-contact interfaces (IEC 60601-1) must state it.
         attribute patientContactInterface : Boolean;
-        // ── hardware-signal descriptors (optional) ──
-        attribute directionality : DirectionKind[0..1];
-        attribute electricalStandard : String;
-        attribute nominalVoltageV : Real[0..1];
-        attribute nominalCurrentA : Real[0..1];
-        attribute bitRateBps : String;
-        attribute signaling : String;
-        attribute signalRange : String;
-        // ── software-API descriptors (optional) ──
-        attribute apiStyle : String;
     }
 
-    // Software interaction contracts specialize the native MEMO interface
-    // family. Concrete technologies add their protocol roles and message
-    // flows; ports remain the endpoints that components actually own.
+    // Software interaction contracts. Concrete technologies add their
+    // protocol roles and message flows; ports remain the endpoints that
+    // components actually own.
     abstract interface def SoftwareInterface specializes Interface {
         // `default`, not `=`. A bare `=` in a definition BINDS the value, and
         // a binding cannot be overridden by a usage — which asserted that
@@ -56,6 +92,8 @@ package memo_architecture_logical_interfaces {
         // inexpressible. A ROS topic publisher → subscriber is the obvious
         // counterexample, and it is the common case rather than an exotic one.
         attribute :>> direction default DirectionKind::inputOutput;
+        attribute apiStyle : String;
+        attribute schemaReference : String;
     }
 
     // A typed thing exchanged at a boundary. Concrete items such as
@@ -87,48 +125,19 @@ package memo_architecture_logical_interfaces {
     port def SensorPort specializes DataPort { attribute sensorDomain : String; }
     port def CommandPort specializes DataPort { attribute commandDomain : String; }
 
-    part def ComponentExchange specializes MemoPart {
+    // An interaction between two component ports, and the properties of that
+    // connection itself: what kind of thing it carries and its timing
+    // discipline. Authored as a typed named interface between the two ports,
+    // with the transport over it as a `flow` between the same ports:
+    //
+    //     interface ceTlmOutToOutput : ComponentExchange
+    //         connect tlm.portTlmModeOut to outputBus.portOutputTlmModeIn {
+    //         attribute :>> exchangeKind = FlowKind::status;
+    //     }
+    //     flow ceTlmOutToOutputFlow of InterfaceItem
+    //         from tlm.portTlmModeOut to outputBus.portOutputTlmModeIn;
+    interface def ComponentExchange specializes MemoInterface {
         attribute exchangeKind : FlowKind;
-        // Metaclass-neutral endpoints. CR-ONT-002 used to read: "Typed
-        // endpoints. A component or a boundary port may terminate an exchange,
-        // so the ends are MemoPart-typed." That reasoning was circular —
-        // PhysicalPort and SoftwarePort are part defs precisely SO THAT they
-        // could satisfy this typing, and the typing was justified by their
-        // being parts. Track A0 cut the circle at the ends, which is the side
-        // that has to move first: A1 turns those two into `port def`s, and a
-        // port cannot specialize a part-based type.
-        //
-        // The constraint the type was carrying — an endpoint is a component or
-        // a boundary port, never a requirement or a document — is now stated
-        // where it can be checked across metaclasses, as CR-ONT-072/073 in
-        // src/rules/ontology/ontology_invariants.sysml.
-        //
-        // `Base::Anything` rather than no type at all — the only place in this
-        // change that reaches for it. The 36 untyped ends in
-        // memo_core_relationships are `end` declarations, and an untyped `end`
-        // is established practice; an untyped `ref` with a multiplicity is not
-        // something MEMO's own grammar accepts (`Expecting token of type ';'
-        // but found '['`), and the grammar is not in this session's scope.
-        // `Base::Anything` is what the standard's `Allocations::Allocation`
-        // types its own ends with, so it is the conforming spelling of "any
-        // element", not a workaround.
-        ref sourceEndpoint : Base::Anything[0..1];
-        ref targetEndpoint : Base::Anything[0..1];
-        // `sourcePortPath` / `targetPortPath` are GONE. They were String
-        // "descriptive port paths (e.g. TLM.TLM_MODE_OUT) for AADL round-trips;
-        // labels only — never references", which is §13.3's string
-        // pseudo-reference: nothing can follow a string to an element, so
-        // anything built on them produced no traceability.
-        //
-        // Measured across the 92 sites in the GPCA example before removing
-        // them: 23 merely restated the endpoint the ref already named (15 gave
-        // the port's own display name, 8 were prose like "HW-001:
-        // GPCA_HW_Sensors"), and the other 69 named a port ON the endpoint
-        // component, resolving to 49 distinct AADL features. Those 49 are
-        // declared as real ports now and the endpoint refs point straight at
-        // them, which is what Track A1 making SoftwarePort a `port def` is for.
-        // The AADL round-trip is better served by an element than by its name.
-        ref allocatedExchanges : FunctionalExchange[0..*];
         attribute direction : DirectionKind;
         // Connection timing discipline from the source architecture
         // (e.g. AADL Communication_Properties::Timing — immediate

package/src/architecture/logical/memo_architecture_logical.sysml

@@ -0,0 +1,13 @@
+// The logical architecture layer as one package.
+//
+// A layer is a namespace of packages: every package whose name begins
+// `memo_architecture_logical_`. This package publicly imports each of them, so
+// `public import memo_architecture_logical::*;` in a methodology's package selects the whole
+// layer, and the same import in any package makes the layer's definitions
+// visible. It declares nothing of its own. test/package.test.mjs holds the list
+// to exactly the packages in the namespace, so a package added to the layer is
+// selected with it.
+package memo_architecture_logical {
+    public import memo_architecture_logical_interfaces::*;
+    public import memo_architecture_logical_structure::*;
+}

package/src/architecture/logical/structure/memo_logical_structure.sysml

@@ -10,6 +10,7 @@ package memo_architecture_logical_structure {
     private import memo_core_common::*;
     private import memo_core_enumerations::*;
     private import memo_core_relationships::*;
+    private import memo_architecture_logical_interfaces::Interface;
 
     // What a logical connection carries: information and control, but also
     // energy, material, fluid, and mechanical force (§10).
@@ -139,9 +140,8 @@ package memo_architecture_logical_structure {
 
     // Boundary features and contracts.
     port def LogicalPort specializes MemoPort;
-    interface def LogicalInterface specializes MemoInterface {
+    interface def LogicalInterface specializes Interface {
         attribute contentKind : FlowContentKind;
-        attribute interactionPattern : String;
         end providerPort : LogicalPort;
         end consumerPort : ~LogicalPort;
     }
@@ -162,14 +162,33 @@ package memo_architecture_logical_structure {
         :> annotatedElement : SysML::ConnectionUsage;
         :>> baseType = logicalConnectorLinks meta SysML::Usage;
     }
-    // A transfer of a typed item across a connector.
-    part def LogicalExchange specializes MemoPart {
+    // A transfer between two ports, carrying what a reader needs to know about
+    // the transfer itself. Authored as a typed named flow between the item
+    // features the two ports declare, the way `FunctionalExchange` is between
+    // function parameters:
+    //
+    //     part lcMonitor { out port pSpo2Out : LogicalPort { out item spo2 :> spo2Item; } }
+    //     flow exSpo2ToGateway : LogicalExchange
+    //         from lcMonitor.pSpo2Out.spo2 to lcGateway.pSpo2In.spo2 {
+    //         attribute :>> contentKind = FlowContentKind::measurement;
+    //     }
+    //
+    // It was a `part def` holding `sourcePort`, `targetPort` and
+    // `exchangedItem` refs. No example set either port, so no exchange said
+    // what it connected. The flow's ends are those ports now,
+    // and its payload the item feature on them. `direction` is not carried
+    // over: the ports say `in` and `out`, and a second writable direction is
+    // the duplicate §8 of the architecture plan forbids.
+    //
+    // The ends are not restricted to `LogicalPort`. Two of the three examples
+    // move a specimen or a force between hardware parts, and a flow def that
+    // named `LogicalPort` ends would have refused them. `payload` is not
+    // declared either: `of <type>` on a usage of a flow def that declares a
+    // feature is not distinguishable (namespace distinguishability) from the
+    // library's own `payload`, so the payload lives on the ports.
+    abstract flow def LogicalExchange {
         attribute contentKind : FlowContentKind;
-        attribute direction : DirectionKind;
         attribute latencyRequirement : String;
-        ref exchangedItem : LogicalExchangeItem[0..1];
-        ref sourcePort : LogicalPort[0..1];
-        ref targetPort : LogicalPort[0..1];
     }
 
     // States and modes of the logical solution (kept distinct from UI state

package/src/architecture/operational/context/stakeholders/memo_stakeholders.sysml

@@ -33,9 +33,12 @@ package memo_architecture_operational_context_stakeholders {
         enum correspondence;
         enum 'use';
     }
+    // The governor spans metaclasses — a CorrespondenceRule is a part, an
+    // IntendedUse a requirement — so that end stays untyped, as DerivesFrom's
+    // driver does. What is governed is always a structural element.
     connection def Governs :> MemoRelationship {
         attribute governKind : GovernKind;
-        end governor : MemoPart :>> source;
+        end governor :>> source;
         end governedElement : MemoPart :>> target;
     }
     abstract connection governsLinks : Governs[*];

package/src/architecture/operational/memo_architecture_operational.sysml

@@ -0,0 +1,19 @@
+// The operational analysis layer as one package.
+//
+// A layer is a namespace of packages: every package whose name begins
+// `memo_architecture_operational_`. This package publicly imports each of them, so
+// `public import memo_architecture_operational::*;` in a methodology's package selects the whole
+// layer, and the same import in any package makes the layer's definitions
+// visible. It declares nothing of its own. test/package.test.mjs holds the list
+// to exactly the packages in the namespace, so a package added to the layer is
+// selected with it.
+package memo_architecture_operational {
+    public import memo_architecture_operational_activities::*;
+    public import memo_architecture_operational_context_actors::*;
+    public import memo_architecture_operational_context_stakeholders::*;
+    public import memo_architecture_operational_context_use_context::*;
+    public import memo_architecture_operational_scenarios::*;
+    public import memo_architecture_operational_structure::*;
+    public import memo_architecture_operational_use_cases::*;
+    public import memo_architecture_operational_workflows::*;
+}

package/src/architecture/operational/scenarios/memo_scenarios.sysml

@@ -1,8 +1,8 @@
-// Scenario foundation. A scenario is a selected path through a
-// workflow (or functional flow), classified by its kind plus three independent
-// dimensions — variant, operational condition, and purpose. An occurrence is an actual or hypothetical execution
-// of a scenario. Alternate scenarios reference their base scenario and
-// variation point instead of duplicating the workflow.
+// Scenario foundation. A scenario is a selected path through a workflow,
+// classified by its kind (nominal or alternate). It is nested in the workflow
+// it is a path through, so a nominal scenario and its alternates are siblings
+// there. An actual or hypothetical execution is a native usage of the
+// scenario, not a separate element.
 package memo_architecture_operational_scenarios {
     private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
@@ -32,9 +32,10 @@ package memo_architecture_operational_scenarios {
         attribute postCondition : String;
         attribute pathSummary : String;
 
-        // The workflow this scenario belongs to is expressed by the workflow
-        // (HasScenario); a nominal/alternate pair are scenarios of the same
-        // workflow, distinguished by scenarioKind — no baseScenario back-ref.
+        // The workflow this scenario belongs to is the one it is nested in
+        // (a `HasScenario` relation was removed for that reason); a
+        // nominal/alternate pair are scenarios of the same workflow,
+        // distinguished by scenarioKind — no baseScenario back-ref.
         // Actors are derived from `perform` on the nested steps, not listed.
         ref useContext : UseContext[0..1];
         // threat scenario

package/src/architecture/operational/structure/memo_operational.sysml

@@ -11,8 +11,11 @@ package memo_architecture_operational_structure {
     // purpose and the root of the operational spine. A MemoMission, because
     // "mission" has no medical-device meaning — intended use is what a device
     // exists to do. Was in memo_assurance_requirements; moved here as the
-    // operational-world root.
-    part def IntendedUse specializes MemoMission {
+    // operational-world root. It is a `requirement def`: the intended use is
+    // the top obligation the device's design inputs derive from, and ISO 14971
+    // 5.2 asks for it to be documented as the starting point of risk analysis.
+    // It was a `part def`, which made it a structural thing.
+    requirement def IntendedUse :> MemoMission {
         attribute indication : String;
         attribute contraindication : String;
         attribute patientPopulation : String;

package/src/architecture/operational/use_cases/memo_use_cases.sysml

@@ -35,17 +35,24 @@ package memo_architecture_operational_use_cases {
         attribute postCondition : String;
         // clinical / service / manufacturing / development
         attribute useCaseKind : UseCaseKind;
+        // A system use case that no clinical use case includes is a finding (rule CR-ONT-086)
+        // unless it says so: set this for a use case that is deliberately carried out alone,
+        // such as a service procedure. It is not a second kind of use case.
+        attribute standalone : Boolean;
 
         // The device or system under consideration supports the goal. Native
-        // `subject`, not `ref` (R10-S6): SysIDE requires an explicit subject
-        // before a use case can declare `actor` — `case-usage-subject-
-        // parameter-position` — and "the device/system under consideration"
+        // `subject`, not `ref` (R10-S6): a use case needs an explicit subject
+        // before it can declare `actor` (the subject parameter comes first),
+        // and "the device/system under consideration"
         // is exactly what a case's subject means, so this was a duplicate
         // waiting to surface once `actor` needed a subject to attach to.
         subject supportingSystem : MemoPart[0..1];
-        ref primaryUser : User[0..1];
-        ref supportingActors : OperationalParticipant[0..*];
         ref useContext : UseContext[0..1];
+        // Who takes part is native `actor` (`actor <role> = <participant>;`),
+        // inherited from `UseCases::UseCase`. `primaryUser` and
+        // `supportingActors` refs stood here as a second way of saying the
+        // same thing and were removed; which actor initiates is carried by
+        // the actor's name, as the note on `Initiates` below says.
     }
 
     connection def Motivates :> MemoRelationship {
@@ -65,7 +72,8 @@ package memo_architecture_operational_use_cases {
     // named on the use case, not in a relationship type. Write
     // `actor <role> = <existingElement>;` inside the use case instead.
     // UML use-case decomposition (`Includes`) is native `include use case` /
-    // `include` (R10-S6); write that instead of a connection here. `extends`
-    // has 0 hits in the corpus for a use-case `extend` production, so it stays
-    // a MEMO construct: a cross-cutting relationship that is always presented.
+    // `include` (R10-S6); write that instead of a connection here. SysML v2
+    // has no use-case `extend` (the textual BNF defines IncludeUseCaseUsage
+    // and nothing for extend), and MEMO does not add one: an optional path
+    // through a use case is an alternate scenario, not a second use case.
 }

package/src/architecture/realization/deployment/memo_deployment.sysml

@@ -20,7 +20,7 @@ package memo_architecture_realization_deployment {
     private import memo_core_relationships::*;
     private import memo_architecture_implementation_software_structure::*;
     private import memo_architecture_implementation_software_runtime::*;
-    private import memo_architecture_implementation_hardware_electrical::*;   // NetworkMedium
+    private import memo_architecture_implementation_hardware_common::PhysicalComponent;
     private import memo_architecture_realization_physical::*;
     private import memo_architecture_functional_functions::*;
     private import memo_architecture_logical_structure::*;
@@ -52,6 +52,24 @@ package memo_architecture_realization_deployment {
         :> annotatedElement : SysML::AllocationDefinition;
         :> annotatedElement : SysML::AllocationUsage;
         :>> baseType = buildsIntoLinks meta SysML::Usage;
+    }
+    // A logical component is REALIZED BY the hardware or software that implements it. The
+    // logical and the implementation architectures are separate structures and stay
+    // separate: nothing is nested (a logical component never contains software or a
+    // physical part, CR-ONT-078); the two are joined by an allocation, as the language
+    // joins structures across domains (SysML-textual-bnf.kebnf:792-801, AllocationDefinition and AllocationUsage) and as SYSMOD
+    // does with its `logical2product` allocation, logical architecture to product
+    // architecture, logical as the source. The target is any part, as HostedBy's ends are:
+    // a hardware assembly and a software system are both MemoParts.
+    allocation def RealizedBy :> MemoRelationship, Allocations::Allocation {
+        end logicalComponent : LogicalComponent :>> source;
+        end realization : MemoPart :>> target;
+    }
+    abstract connection realizedByLinks : RealizedBy[*];
+    metadata def <realizedBy> RealizedByMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::AllocationDefinition;
+        :> annotatedElement : SysML::AllocationUsage;
+        :>> baseType = realizedByLinks meta SysML::Usage;
     }
         // Every usage of this already writes `allocation x : DeploysTo allocate a
     // to b;` -- the declaration was the only part still saying `connection`.
@@ -92,7 +110,7 @@ package memo_architecture_realization_deployment {
     // language says so. The double specialization keeps MEMO's identification
     // core from `MemoRelationship` while adding the standard's allocation
     // semantics; both root on `Connections::BinaryConnection`, so this is a
-    // diamond and not a conflict. Verified under `syside check` against a
+    // diamond and not a conflict. Verified with a SysML v2 compiler against a
     // negative control (a non-existent supertype is reported), so the clean
     // result is the checker agreeing rather than the checker skipping.
 
@@ -111,17 +129,19 @@ package memo_architecture_realization_deployment {
         :>> baseType = memoryBindingLinks meta SysML::Usage;
     }
 
-    // AADL `actual_connection_binding`. Which physical medium carries a
-    // component exchange. The source is the ComponentExchange rather than the
-    // `ComponentConnects` link, because the exchange is the ELEMENT that owns
-    // the budget (§19.3) and a link instance is not something the graph can
-    // bind to; it is also exactly where the latency the medium contributes has
-    // to be accounted.
+    // AADL `actual_connection_binding`. Which physical thing carries an
+    // interface: a network medium under a component exchange, a cable or
+    // harness under a hardware `Interface`, a connector, a tube. The source is
+    // the interface usage rather than a link, because the interface is the
+    // ELEMENT that owns the budget (§19.3) and a link instance is not
+    // something the graph can bind to; it is also exactly where the latency
+    // the medium contributes has to be accounted. Ends are the two bases
+    // (MemoInterface, PhysicalComponent) so one binding serves every layer.
     allocation def ConnectionBinding :> MemoRelationship, Allocations::Allocation {
         attribute allocatedBandwidth : String;
         attribute mediumLatencyMs : Real;
-        end boundExchange : ComponentExchange :>> source;
-        end medium : NetworkMedium :>> target;
+        end boundExchange : MemoInterface :>> source;
+        end medium : PhysicalComponent :>> target;
     }
     abstract connection connectionBindingLinks : ConnectionBinding[*];
     metadata def <connectionBinding> ConnectionBindingMetadata :> SemanticMetadata {

package/src/architecture/realization/memo_architecture_realization.sysml

@@ -0,0 +1,13 @@
+// The realization (deployment and physical) layer as one package.
+//
+// A layer is a namespace of packages: every package whose name begins
+// `memo_architecture_realization_`. This package publicly imports each of them, so
+// `public import memo_architecture_realization::*;` in a methodology's package selects the whole
+// layer, and the same import in any package makes the layer's definitions
+// visible. It declares nothing of its own. test/package.test.mjs holds the list
+// to exactly the packages in the namespace, so a package added to the layer is
+// selected with it.
+package memo_architecture_realization {
+    public import memo_architecture_realization_deployment::*;
+    public import memo_architecture_realization_physical::*;
+}

package/src/architecture/realization/physical/memo_physical_architecture.sysml

@@ -6,6 +6,7 @@ package memo_architecture_realization_physical {
 
     private import memo_core_common::*;
     private import memo_core_enumerations::*;
+    private import memo_architecture_logical_interfaces::Interface;
     // For PhysicalElement: a processing node and a memory device ARE physical
     // things — a board and a chip — and specialized MemoPart directly only
     // because the physical family had no shared root until CR-ONT-079 needed
@@ -58,4 +59,64 @@ package memo_architecture_realization_physical {
         attribute portCategory : PortCategoryKind;
         attribute connectorType : String;
     }
+
+    // ─── Connecting hardware ─────────────────────────────────────────────
+    //
+    // Hardware is parts with ports. A port on one part is joined to a port on
+    // another by a PhysicalInterface, and what crosses it is a PhysicalFlow.
+    // They are the hardware-layer counterparts of LogicalInterface and
+    // LogicalExchange, and of SoftwareInterface: the same shape, but each
+    // states only what its layer can, so a hardware interface is never
+    // described in terms of a software API or a logical content kind.
+    //
+    // The interface is the CONTRACT (an `interface` usage joins two specific
+    // ports; the def says what kind of link it is). The plug, cable, header
+    // or tube that physically carries it is a part of its own (Cable,
+    // PhysicalConnectorPart, ...), related to the interface by a
+    // ConnectionBinding allocation. PhysicalPort.connectorType names what a
+    // port exposes.
+    //
+    //     part pump {
+    //         out port pMotorDrive : PhysicalPort { out item drive; }
+    //     }
+    //     part driver {
+    //         in port pMotorIn : PhysicalPort { in item drive; }
+    //     }
+    //     part motorHarness : Cable;
+    //     interface cnMotorDrive : PhysicalInterface
+    //         connect pump.pMotorDrive to driver.pMotorIn {
+    //         attribute :>> signalingKind = SignalingKind::pulse;
+    //         attribute :>> nominalVoltageV = 3.3;
+    //     }
+    //     flow flMotorDrive : PhysicalFlow
+    //         from pump.pMotorDrive.drive to driver.pMotorIn.drive {
+    //         attribute :>> quantity = "step pulses";
+    //     }
+    //     allocation cbMotorDrive : ConnectionBinding
+    //         allocate cnMotorDrive to motorHarness;
+    interface def PhysicalInterface specializes Interface {
+        // analog, digital, discrete, pulse or power transfer. Fill in the
+        // descriptors that kind needs: a range for analog, a bit rate and
+        // protocol for digital, a frequency for pulse.
+        attribute signalingKind : SignalingKind;
+        attribute mediumKind : PhysicalMediumKind;
+        attribute electricalStandard : String;
+        attribute nominalVoltageV : Real[0..1];
+        attribute nominalCurrentA : Real[0..1];
+        attribute bitRateBps : String;
+        attribute signalRange : String;
+        attribute connectorStandard : String;
+        end sourcePort : PhysicalPort;
+        end targetPort : PhysicalPort;
+    }
+
+    // What crosses a physical interface, as a quantity: a voltage, a
+    // current, a pressure, a force, a flow of fluid.
+    abstract flow def PhysicalFlow {
+        attribute quantity : String;
+        attribute unit : String;
+        attribute nominalValue : String;
+        attribute minValue : String;
+        attribute maxValue : String;
+    }
 }

package/src/architecture/variability/memo_variability.sysml

@@ -0,0 +1,87 @@
+// Features and design options.
+//
+// A design option is native SysML: a `variation` (a definition or a usage whose
+// body holds only `variant` members; SysML-textual-bnf.kebnf:224 for the definition
+// prefix, :282 for the usage prefix, :254-256 the variant member). MEMO adds
+// nothing to how one is written. What SysML has no word for is WHY a variant exists
+// and WHICH ones go together: that is a product feature.
+//
+//   part featEuMarket : ProductFeature;                    // the market EU releases target
+//   variation part energyOutput : LogicalComponent {
+//       variant part euOutput : LogicalComponent;          // a variant, for the EU
+//       variant part usOutput : LogicalComponent;
+//   }
+//   #RealizesFeature dependency from energyOutput::euOutput to featEuMarket;
+//   connection : RequiresFeature connect ...               // one feature needs another
+//
+// A release selects features (`#SelectsFeature`), and through them the variants it
+// contains; a rule counts one variant per variation point from that. A feature is
+// a usage like any other part, named by the family, and a platform package may
+// declare the family's features once.
+//
+// A variation point cannot own attributes: SysIDE rejects an owned feature in a
+// variation (`usage-variation-owned-feature-membership`). Identity metadata is an
+// annotation and is allowed (measured on E0, 2026-10-13); `status` and anything else
+// a variation point would carry goes on its variants.
+package memo_architecture_variability {
+    private import Metaobjects::SemanticMetadata;
+    private import ScalarValues::*;
+
+    private import memo_core_common::*;
+    private import memo_core_enumerations::*;
+    private import memo_core_relationships::*;
+
+    // Named ProductFeature, not Feature: `Feature` is the KerML metaclass, and the
+    // builder falls back to a metaclass name for a kind it cannot place.
+    //
+    // A feature's page is what is said about it: its prose is the element's `doc`, and
+    // the analysis is these four statements, each optional until someone has an answer.
+    // What the feature shows is curated: `#ShowsView` below names its views.
+    part def ProductFeature specializes MemoPart {
+        /** What the feature gives the people who use the product, in a sentence or two. */
+        attribute valueProposition : String[0..1];
+        /** Who it is for: the roles or segments that gain from it. */
+        attribute targetUsers : String[0..1];
+        /** How anyone will know it worked: the measure, and the level that counts as success. */
+        attribute successMeasure : String[0..1];
+        /** What has to hold for the value to be real, and what is not yet known. */
+        attribute assumptions : String[0..1];
+    }
+
+    // `Requires` is taken by the native `require` relation, so these say what they join.
+    connection def RequiresFeature :> MemoRelationship {
+        doc /* Selecting the source feature needs the target feature selected too. */
+        end dependentFeature : ProductFeature :>> source;
+        end requiredFeature : ProductFeature :>> target;
+    }
+    abstract connection requiresFeatureLinks : RequiresFeature[*];
+    metadata def <requiresFeature> RequiresFeatureMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = requiresFeatureLinks meta SysML::Usage;
+    }
+
+    connection def ExcludesFeature :> MemoRelationship {
+        doc /* The two features cannot be selected together. Symmetric: either end may be written first. */
+        end firstFeature : ProductFeature :>> source;
+        end secondFeature : ProductFeature :>> target;
+    }
+    abstract connection excludesFeatureLinks : ExcludesFeature[*];
+    metadata def <excludesFeature> ExcludesFeatureMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = excludesFeatureLinks meta SysML::Usage;
+    }
+
+    // Typed dependencies (memo_core_relationships::MemoTypedDependency): the variant
+    // is nested in its variation, so it is a dependency's client by qualified name.
+    metadata def RealizesFeature :> MemoTypedDependency {
+        doc /* `#RealizesFeature dependency from <variant> to <feature>;` The variant exists to give the family this feature. */
+    }
+    metadata def SelectsFeature :> MemoTypedDependency {
+        doc /* `#SelectsFeature dependency from <release> to <feature>, <feature>;` The release contains the variants that realize these features. */
+    }
+    metadata def ShowsView :> MemoTypedDependency {
+        doc /* `#ShowsView dependency from <feature> to <view>, <view>;` The views the feature's viewpoint lists: chosen for what the feature demonstrates, not found by a rule. */
+    }
+}