@memoarchitect/ontology 0.6.4 → 0.7.0

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

@@ -0,0 +1,94 @@
+format: memo.viewlayout/v1
+viewSource: model/catalog/viewpoints/unassigned/views/interconnection_view.sysml
+layouts:
+  diag-sample-sampleInterconnectionView:
+    nodes:
+      coffeeMachine:
+        x: 301.2
+        y: 0
+        ports:
+          mainsWaterIn:
+            x: -12
+            y: 95
+            side: left
+          beverageOut:
+            x: 536
+            y: 375
+            side: right
+          serviceInterface:
+            x: 536
+            y: 217
+            side: right
+          diagnostics:
+            x: 536
+            y: 247
+            side: right
+        width: 768
+        height: 422
+      waterTank:
+        x: 118.75
+        y: 48
+        ports:
+          tankWaterOut:
+            x: 299.5
+            y: 47
+            side: right
+          tankWaterIn:
+            x: -12
+            y: 47
+            side: left
+      heaterAssembly:
+        x: 78.80000000000001
+        y: 220
+        ports:
+          heaterWaterIn:
+            x: -12
+            y: 47
+            side: left
+          heatedWaterOut:
+            x: 352
+            y: 47
+            side: right
+      brewGroup:
+        x: 134
+        y: 328
+        ports:
+          brewWaterIn:
+            x: -12
+            y: 47
+            side: left
+          brewedCoffeeOut:
+            x: 268
+            y: 47
+            side: right
+      waterSupply:
+        x: 0
+        y: 170
+        ports:
+          supplyWaterOut:
+            x: 198.8
+            y: 47
+            side: right
+      cup:
+        x: 1000
+        y: 320
+        ports:
+          cupBeverageIn:
+            x: -12
+            y: 50
+            side: left
+    edges:
+      rel-66: {}
+      rel-67: {}
+      rel-68: {}
+      rel-69: {}
+      rel-70: {}
+      rel-71: {}
+    annotations: {}
+    canvas:
+      autoLayout: false
+      zoom: 0.83251321227496
+      pan:
+        x: -129.43112026011397
+        y: -3.900376690780462
+      coordinateSpace: context-child-v1

package/examples/sysml-diagram-samples/model/{samples → catalog/viewpoints/unassigned/views}/operational_behaviour_view.sysml

@@ -1,10 +1,12 @@
-package memo_examples_sysml_diagram_samples_model_samples_operational_behaviour_view {
+package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_operational_behaviour_view {
     private import ScalarValues::*;
     private import memo_architecture_operational_context_actors::*;
     private import memo_core_relationships::*;
     private import memo_architecture_logical_interfaces::*;
     private import memo_architecture_operational_structure::*;
+    private import memo_architecture_operational_activities::*;
     private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_operational_operational_viewpoint::*;
     private import memo_core_enumerations::*;
 
     // Operational activity across clinical roles. The fixture is intentionally
@@ -16,17 +18,17 @@ package memo_examples_sysml_diagram_samples_model_samples_operational_behaviour_
         attribute :>> itemKind = InterfaceItemKind::signal;
     }
 
-    action def OpPrescribeTherapy { out prescription : OpPrescription; }
-    action def OpVerifyPrescription { in prescription : OpPrescription; }
-    action def OpRequestBolus { out bolusRequest : OpBolusRequest; }
-    action def OpCheckLockout { in bolusRequest : OpBolusRequest; }
+    action def OpPrescribeTherapy specializes OperationalActivity { out item prescription : OpPrescription; }
+    action def OpVerifyPrescription specializes OperationalActivity { in item prescription : OpPrescription; }
+    action def OpRequestBolus specializes OperationalActivity { out item bolusRequest : OpBolusRequest; }
+    action def OpCheckLockout specializes OperationalActivity { in item bolusRequest : OpBolusRequest; }
 
     // Use the canonical MEMO operational system type—never a sample-local
     // placeholder—so ontology-driven Explorer grouping remains authoritative.
     part opCareSystem : OperationalEntity {
         attribute :>> name = "PCA Care System";
         attribute :>> entityKind = OperationalEntityKind::device;
-        attribute :>> contextRole = "systemOfInterest";
+        attribute :>> responsibility = "System of interest for this context view.";
     }
     part opClinicalTeam : User {
         attribute :>> actorKind = ActorKind::clinician; attribute :>> name = "Clinical Team"; }
@@ -48,22 +50,22 @@ package memo_examples_sysml_diagram_samples_model_samples_operational_behaviour_
     connection : Composes connect parent ::> opClinicalTeam to child ::> opRoleBiomed;
     connection : Composes connect parent ::> opPatientGroup to child ::> opRolePatient;
 
-    action opSetupFlow {
-        action opPrescribe : OpPrescribeTherapy { attribute name = "Prescribe Therapy"; }
-        action opVerify : OpVerifyPrescription { attribute name = "Verify Prescription"; }
+    action opSetupFlow : OperationalActivity {
+        action opPrescribe : OpPrescribeTherapy { attribute :>> name = "Prescribe Therapy"; }
+        action opVerify : OpVerifyPrescription { attribute :>> name = "Verify Prescription"; }
         fork opForkPrep;
-        action opPrime { attribute name = "Prime Pump & Load Reservoir"; }
-        action opSelfTest { attribute name = "Run Device Self-Test"; }
+        action opPrime : OperationalActivity { attribute :>> name = "Prime Pump & Load Reservoir"; }
+        action opSelfTest : OperationalActivity { attribute :>> name = "Run Device Self-Test"; }
         join opJoinPrep;
-        action opProgram { attribute name = "Program Pump Parameters"; }
-        action opConnect { attribute name = "Connect to Patient"; }
-        action opStart { attribute name = "Start Infusion"; }
-        action opAdminister {
-            attribute name = "Administer PCA Therapy";
-            action opRequestBolus : OpRequestBolus { attribute name = "Request Bolus"; }
-            action opCheckLockout : OpCheckLockout { attribute name = "Check Lockout"; }
-            action opDeliverDose { attribute name = "Deliver Dose"; }
-            action opLogEvent { attribute name = "Log Dose Event"; }
+        action opProgram : OperationalActivity { attribute :>> name = "Program Pump Parameters"; }
+        action opConnect : OperationalActivity { attribute :>> name = "Connect to Patient"; }
+        action opStart : OperationalActivity { attribute :>> name = "Start Infusion"; }
+        action opAdminister : OperationalActivity {
+            attribute :>> name = "Administer PCA Therapy";
+            action opRequestBolus : OpRequestBolus { attribute :>> name = "Request Bolus"; }
+            action opCheckLockout : OpCheckLockout { attribute :>> name = "Check Lockout"; }
+            action opDeliverDose : OperationalActivity { attribute :>> name = "Deliver Dose"; }
+            action opLogEvent : OperationalActivity { attribute :>> name = "Log Dose Event"; }
             flow of OpBolusRequest from opRequestBolus.bolusRequest to opCheckLockout.bolusRequest;
             first start then opRequestBolus;
             first opRequestBolus then opCheckLockout;
@@ -109,6 +111,7 @@ package memo_examples_sysml_diagram_samples_model_samples_operational_behaviour_
         attribute :>> shortDescription = "Operational activity across clinical roles with concurrent preparation and a composite therapy step.";
         attribute :>> viewKind = DiagramViewKind::actionflow;
         attribute :>> diagramType = "ofd";
+        part :>> viewpointDefinition = operationalViewpoint;
     }
 
     connection : IncludedIn connect sourceElement ::> opSetupFlow.opPrescribe to targetView ::> opSetupView;

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

@@ -0,0 +1,13 @@
+format: memo.viewlayout/v1
+viewSource: model/catalog/viewpoints/unassigned/views/operational_behaviour_view.sysml
+layouts:
+  diag-sample-opSetupView:
+    nodes: {}
+    edges: {}
+    canvas:
+      autoLayout: true
+      zoom: 0.3666153460391409
+      pan:
+        x: 359.78478424853927
+        y: 41.19938625300375
+      coordinateSpace: context-child-v1

package/examples/sysml-diagram-samples/model/{samples → catalog/viewpoints/unassigned/views}/requirements_view.sysml

@@ -1,13 +1,14 @@
 // Requirements sample (general view kind, `req` diagram type). Stakeholder needs
 // on the left derive into system requirements; `DerivesFrom` edges render as the
 // requirements-diagram trace lines.
-package memo_examples_sysml_diagram_samples_model_samples_requirements_view {
+package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_requirements_view {
     private import ScalarValues::*;
 
     private import memo_assurance_requirements_needs::*;
     private import memo_assurance_requirements::*;
     private import memo_core_relationships::*;
     private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_requirements_requirements_viewpoint::*;
     private import memo_core_enumerations::*;
 
     requirement needSafeTherapy : Need {
@@ -50,6 +51,7 @@ package memo_examples_sysml_diagram_samples_model_samples_requirements_view {
         attribute :>> shortDescription = "Stakeholder needs deriving into system requirements, wired by DerivesFrom trace edges.";
         attribute :>> viewKind = DiagramViewKind::general;
         attribute :>> diagramType = "req";
+        part :>> viewpointDefinition = requirementsViewpoint;
         part :>> selectionQuery {
             attribute :>> includeRelationshipKinds = ("DerivesFrom");
         }

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

@@ -0,0 +1,51 @@
+// Standard SysML v2 activity sample (actionflow view kind, `afd` diagram type).
+//
+// The view over `activity_example::CustomerProcess`, the standard-SysML activity
+// fixture in `model/sysml_v2_activity_example.sysml`. It exists because the
+// fixture's whole point is the node types `action_flow_view.sysml` does not
+// have — decision, merge, fork, join, accept, send, terminate, and guarded
+// successions. Without a view exposing it the fixture parses into the model and
+// is never drawn, which is indistinguishable from a renderer that cannot draw
+// decisions.
+//
+// Nothing here specializes a MEMO kind: the fixture is plain standard SysML,
+// and that is the property under test. The renderer classifies its nodes from
+// the metamodel (`activity-notation.ts`), not from an ontology kind.
+package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_standard_activity_view {
+    private import ScalarValues::*;
+
+    private import memo_core_relationships::*;
+    private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_functional_functional_viewpoint::*;
+    private import memo_core_enumerations::*;
+
+    private import activity_example::*;
+
+    view standardActivityView : MemoDiagramView {
+        expose CustomerProcess::**;
+        attribute depth = 2;
+        attribute :>> title = "Sample · Customer Purchase Process";
+        attribute :>> shortDescription = "Customer login, guarded validation, shopping loop, checkout, credit approval, and explicit completion outcomes.";
+        attribute :>> viewKind = DiagramViewKind::actionflow;
+        attribute :>> diagramType = "afd";
+        part :>> viewpointDefinition = functionalViewpoint;
+    }
+
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::customerLogsIn to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::validUserDecision to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::rejected to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::browseCatalog to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::viewBookStore to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::selectBookForPurchase to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::addToShoppingBasket to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::viewShoppingBasket to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::shoppingDecision to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::commitOrder to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::supplyCreditCardDetails to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::creditDecision to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::rejectCreditCard to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::closeOrder to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::confirmPurchase to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::itemsDelivered to targetView ::> standardActivityView;
+    connection : IncludedIn connect sourceElement ::> CustomerProcess::orderComplete to targetView ::> standardActivityView;
+}

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

@@ -1,12 +1,13 @@
 // State transition sample (statetransition view kind, `stm` diagram type). A
 // behaviour machine owns its mode states; each Transition carries `sourceState`
 // / `targetState` naming the states it connects, and renders as a labelled edge.
-package memo_examples_sysml_diagram_samples_model_samples_state_transition_view {
+package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_state_transition_view {
     private import ScalarValues::*;
 
     private import memo_architecture_functional_behavior::*;
     private import memo_core_relationships::*;
     private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_functional_functional_viewpoint::*;
     private import memo_core_enumerations::*;
 
     state pumpModes : StateMachine { attribute :>> name = "Pump Operating Modes"; }
@@ -84,6 +85,7 @@ package memo_examples_sysml_diagram_samples_model_samples_state_transition_view
         attribute :>> shortDescription = "A pump-mode state machine — Idle, Infusing, Paused, Alarm — where Infusing is a composite state nesting Priming, Delivering and Holding.";
         attribute :>> viewKind = DiagramViewKind::statetransition;
         attribute :>> diagramType = "stm";
+        part :>> viewpointDefinition = functionalViewpoint;
         part :>> selectionQuery {
             attribute :>> includeElementKinds = ("StateMachine", "ModeState", "Transition");
         }

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

@@ -1,10 +1,11 @@
-package memo_examples_sysml_diagram_samples_model_samples_tree_view {
+package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_tree_view {
     private import ScalarValues::*;
     private import memo_architecture_implementation_hardware_structure::*;
 
     private import memo_architecture_realization_physical::*;
     private import memo_core_relationships::*;
     private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_physical_physical_viewpoint::*;
     private import memo_core_enumerations::*;
 
     part rootA : HardwareAssembly { attribute :>> name = "Root A"; }
@@ -37,6 +38,7 @@ package memo_examples_sysml_diagram_samples_model_samples_tree_view {
         attribute :>> shortDescription = "One connected dummy hierarchy with varied branch depths for tree layout development.";
         attribute :>> viewKind = DiagramViewKind::general;
         attribute :>> diagramType = "bdd";
+        part :>> viewpointDefinition = physicalViewpoint;
         attribute :>> layoutHint = "tree";
         attribute :>> styleHint = "expanded:rootA,rootB,branchA1,branchB1";
         part :>> selectionQuery {

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

@@ -1,9 +1,10 @@
-package memo_examples_sysml_diagram_samples_model_samples_use_case_view {
+package memo_examples_sysml_diagram_samples_viewpoints_unassigned_views_use_case_view {
     private import ScalarValues::*;
     private import memo_architecture_operational_context_actors::*;
     private import memo_architecture_operational_use_cases::*;
     private import memo_core_relationships::*;
     private import memo_viewpoints_definitions::*;
+    private import memo_viewpoints_operational_operational_viewpoint::*;
     private import memo_core_enumerations::*;
 
     // Product-neutral fixture for the UML-style use-case presentation.
@@ -71,6 +72,7 @@ package memo_examples_sysml_diagram_samples_model_samples_use_case_view {
         attribute :>> shortDescription = "Actors outside a device boundary with include, extend, hierarchy-level, and orthogonal-routing presentation.";
         attribute :>> viewKind = DiagramViewKind::general;
         attribute :>> diagramType = "ucd";
+        part :>> viewpointDefinition = operationalViewpoint;
         part :>> selectionQuery {
             attribute :>> includeElementKinds = ("User", "UseCase");
             attribute :>> includeRelationshipKinds = ("Initiates", "ParticipatesIn", "Includes", "Extends");

package/examples/sysml-diagram-samples/model/sysml_v2_activity_example.sysml

@@ -0,0 +1,93 @@
+// Runnable standard SysML v2 action-flow sample.
+package activity_example {
+    private import ScalarValues::*;
+
+    item def Order;
+    item def Receipt;
+    part def Customer;
+    action def ProcessOrder;
+
+    action def FulfillOrder {
+        part customer : Customer;
+        action receiveOrder accept order : Order;
+        action validateOrder { in order : Order; }
+        decide routeOrder;
+        action processOrder : ProcessOrder;
+        action rejectOrder;
+        merge afterDecision;
+        fork parallelWork;
+        action prepareShipment;
+        action createInvoice;
+        join readyToNotify;
+        action notifyCustomer { out receipt : Receipt; }
+        then action sendReceipt send notifyCustomer.receipt to customer;
+        then terminate;
+
+        succession first start then receiveOrder;
+        succession first receiveOrder then validateOrder;
+        flow of Order from receiveOrder.order to validateOrder.order;
+        succession first validateOrder then routeOrder;
+        succession first routeOrder if true then processOrder;
+        succession first routeOrder if false then rejectOrder;
+        succession first processOrder then afterDecision;
+        succession first rejectOrder then afterDecision;
+        succession first afterDecision then parallelWork;
+        succession first parallelWork then prepareShipment;
+        succession first parallelWork then createInvoice;
+        succession first prepareShipment then readyToNotify;
+        succession first createInvoice then readyToNotify;
+        succession first readyToNotify then notifyCustomer;
+    }
+
+    // Customer purchase behavior encoded from the reference activity diagram.
+    // The source picture draws two outgoing paths directly from
+    // viewShoppingBasket. In the semantic model that choice is made explicit
+    // with shoppingDecision; browseCatalog is the merge required to re-enter
+    // the browsing loop without making viewBookStore wait for both inputs.
+    action def CustomerProcess {
+        attribute validUser : Boolean;
+        attribute continueShopping : Boolean;
+        attribute creditOK : Boolean;
+
+        action customerLogsIn;
+        decide validUserDecision;
+        action rejected terminate;
+
+        merge browseCatalog;
+        action viewBookStore;
+        action selectBookForPurchase;
+        action addToShoppingBasket;
+        action viewShoppingBasket;
+        decide shoppingDecision;
+
+        action commitOrder;
+        action supplyCreditCardDetails;
+        decide creditDecision;
+        action rejectCreditCard;
+        action closeOrder terminate;
+        action confirmPurchase;
+        action itemsDelivered;
+        action orderComplete terminate;
+
+        succession first start then customerLogsIn;
+        succession first customerLogsIn then validUserDecision;
+        succession first validUserDecision if validUser == true then browseCatalog;
+        succession first validUserDecision if validUser == false then rejected;
+
+        succession first browseCatalog then viewBookStore;
+        succession first viewBookStore then selectBookForPurchase;
+        succession first selectBookForPurchase then addToShoppingBasket;
+        succession first addToShoppingBasket then viewShoppingBasket;
+        succession first viewShoppingBasket then shoppingDecision;
+        succession first shoppingDecision if continueShopping == true then browseCatalog;
+        succession first shoppingDecision if continueShopping == false then commitOrder;
+
+        succession first commitOrder then supplyCreditCardDetails;
+        succession first supplyCreditCardDetails then creditDecision;
+        succession first creditDecision if creditOK == false then rejectCreditCard;
+        succession first rejectCreditCard then closeOrder;
+        succession first creditDecision if creditOK == true then confirmPurchase;
+        succession first confirmPurchase then itemsDelivered;
+        succession first itemsDelivered then orderComplete;
+    }
+}

package/examples/temperature-alarm/model/catalog/project.sysml

@@ -0,0 +1,24 @@
+// Temperature Alarm — project identity and method binding.
+//
+// The native entrypoint. The imports name what this project contains and the
+// binding names the methodology it is governed by. No YAML file participates.
+package memo_examples_temperature_alarm_project {
+    private import ScalarValues::*;
+
+    private import memo_core_enumerations::*;
+    private import memo_methodology_core::*;
+    private import memo_methodology_profiles::*;
+
+    // The project's own content, imported so the catalog is one reachable
+    // closure from a single entrypoint.
+    private import memo_examples_temperature_alarm_viewpoints_unassigned::*;
+    private import memo_examples_temperature_alarm_viewpoints_unassigned_views_temperature_alarm_overview::*;
+
+    part projectBinding : ProjectMethodBinding {
+        attribute :>> id = "PMB-TEMPERATURE-ALARM-001";
+        attribute :>> name = "TemperatureAlarmProjectMethodBinding";
+        attribute :>> projectName = "Temperature Alarm";
+        ref :>> selectedMethodology = mdDefaultDefinition;
+        attribute :>> scopeMode = ScopeModeKind::explicit;
+    }
+}

package/examples/temperature-alarm/model/catalog/temperature_alarm.sysml

@@ -13,6 +13,7 @@ package memo_examples_temperature_alarm {
     private import memo_assurance_requirements_needs::*;
     private import memo_architecture_operational_use_cases::*;
     private import memo_architecture_operational_activities::*;
+    private import memo_architecture_operational_workflows::*;
     private import memo_architecture_operational_scenarios::*;
     private import memo_architecture_functional_functions::*;
     private import memo_architecture_logical_structure::*;
@@ -111,7 +112,7 @@ package memo_examples_temperature_alarm {
     connection : ControlImplementedBy connect riskControl ::> rcReAnnunciate to implementingElement ::> elAlarmBanner;
 
     // ── Verification, validation, evidence ──────────────────────
-    part vsAlarmLatency : VerificationScenario {
+    action vsAlarmLatency : VerificationScenario {
         attribute :>> id = "TA-VS-001"; attribute :>> name = "AlarmLatencyScenario";
         attribute :>> variantKind = ScenarioVariantKind::nominal;
         attribute :>> operationalCondition = OperationalConditionKind::normal;

package/examples/temperature-alarm/model/catalog/viewpoints/unassigned/viewpoint.sysml

@@ -0,0 +1,9 @@
+// unassigned viewpoint.
+//
+// This project does not define its own viewpoint here; it binds the reusable
+// MEMO viewpoint that frames these concerns. The views it governs sit beneath
+// `views/`.
+package memo_examples_temperature_alarm_viewpoints_unassigned {
+    // The reusable package declaring unassigned could not be resolved during
+    // conversion. Import it here so the views beneath this viewpoint resolve.
+}

package/examples/temperature-alarm/model/{viewpoints → catalog/viewpoints/unassigned/views}/temperature_alarm_overview.sysml

@@ -1,4 +1,4 @@
-package memo_examples_temperature_alarm_viewpoints {
+package memo_examples_temperature_alarm_viewpoints_unassigned_views_temperature_alarm_overview {
     private import memo_examples_temperature_alarm::*;
     private import memo_viewpoints_definitions::*;
     private import memo_core_enumerations::*;

package/examples/ui-screen-regions/README.md

@@ -0,0 +1,117 @@
+# UI screen regions
+
+A focused MEMO example for marking up a screenshot so that every functional
+area of the interface is traceable to a function, a specification, and a risk
+control — using the part tree MEMO already has, not a parallel one.
+
+- `model/ui_screen_regions.sysml` is the public parent package.
+- `model/catalog/` holds the canonical model elements.
+- `model/viewpoints/` holds the geometry view and a trace graph of that catalog.
+
+## What it demonstrates
+
+One infusion-pump screen, modelled as an **ordinary part tree**. A screen is a
+`UIElement` that contains `UIElement`s; each carries `bounds` (x, y, width,
+height). There is no separate "region" type: one tree carries both the geometry
+and the design record.
+
+Because the elements carrying geometry are the same elements carrying the
+design record, every trace MEMO already supported applies unchanged:
+
+```
+elRateValue                     a part, with bounds, inside elRatePanel
+  -ElementTriggersAction->  uiaEditRate
+     -ActionInvokesFunction->  fnSetInfusionRate     FUNCTION
+  <-SatisfiedBy-  reqRateEntry                       SPEC
+  <-ErrorAtElement-  ueMisreadRate                   RISK (use error)
+  <-ControlImplementedBy-  rcRateConfirm             RISK (control)
+```
+
+Layout adds four numbers and two invariants over them — nothing else.
+
+## Containment vs navigation
+
+These are different, and conflating them is the trap this example is built to
+show:
+
+| Element | Relation | Meaning |
+| --- | --- | --- |
+| `elRateValue` inside `elRatePanel` | `Composes` | laid out **within** the parent's box |
+| `elSettingsRow` → `elSettingsScreen` | `NavigatesTo` | activation **replaces** the view |
+
+`elSettingsScreen` is a sibling root with its own capture and its own
+coordinate frame. It is not a child of anything, so no geometric rule relates
+it to the main screen.
+
+## The dropdown, and why `disclosureKind` exists
+
+`elDrugMenu` is why geometry alone is not enough. Open, it extends past the
+bottom of the rate panel (`y + height` = 1.35 > 1.0) **and** overlaps
+`elRateValue` outright. For an `inline` element both would be layout defects;
+for a dropdown both are correct. The four numbers cannot tell those cases apart,
+so `disclosureKind = overlay` states the intent — and a renderer reads it to know
+not to clip.
+
+Layout correctness is **not** asserted as a consistency rule. Geometric
+invariants (child within parent, inline siblings disjoint) cannot be written as
+KerML constraint bodies — the evaluator has no Real literal, and it binds one
+implicit subject per quantifier, so pairwise sibling comparison is impossible by
+construction. Rather than declare rules no engine can evaluate, layout is checked
+where it is drawn.
+
+`elStatusBar` is the negative case that IS checked: it is chrome, and it passes
+**CR-MED-110** only because it is declared `formKind = decoration`. An element
+left unclassified fails. Declaring chrome as chrome is a modelling act, not an
+omission.
+
+## Bounds
+
+`RegionBounds` are normalized to the **parent element**, each value in 0..1.
+`elRateValue` occupies the lower 65 % of the rate panel, not 65 % of the screen,
+so a renderer accumulates transforms down the `Composes` tree. Two things
+follow: an element survives re-capture at a different resolution, and a child's
+box is stated against its parent, which is exactly what the containment tree
+already asserts. Absolute pixels stay recoverable from the capture's
+`pixelWidth` / `pixelHeight`.
+
+## Commentary
+
+`ModelComment` elements carry review conversation — author, timestamp,
+disposition — attached with `CommentsOn` and threaded with `Composes`.
+They are kept separate from `description` on purpose: `description` is what an
+element *is*, a comment is what someone *said about it*, and only the former
+belongs in a generated DHF section.
+
+## Validation
+
+The example is written to pass the four UI layout rules:
+
+| Rule | Severity | What it enforces |
+| --- | --- | --- |
+| CR-MED-110 | error | Every non-`decoration` element has a design record (requirement or action) |
+| CR-MED-111 | warning | Interactive elements trigger an action that invokes a function |
+| CR-MED-112 | warning | Automatically detected bounds are confirmed by a reviewer |
+| CR-MED-113 | error | Screen captures identify their build and hash their bytes |
+
+See the caveat in `memo-ui-region-spec.md` §5 about rule evaluation generally —
+no ontology rule body currently evaluates.
+
+## Where the images live
+
+Screenshots live in the project repo beside the model, in a folder named for the
+layout view that renders them:
+
+```
+model/
+  assets/
+    mainScreenLayout/main-screen-2.4.1.png
+    settingsScreenLayout/settings-screen-2.4.1.png
+```
+
+`imageUri` is relative to the model root. One layout view per captured screen,
+and the view's name is its folder — so it is always obvious which images belong
+to which layout.
+
+The image files themselves are **not committed**; this example ships as model
+content only, and the `imageHash` values are illustrative. Drop your own
+screenshots at those paths to see the geometry view render.