@memoarchitect/ontology 0.7.0 → 0.8.22

package/src/artifacts/templates/dhf/iec-62304/sbom.md

@@ -23,7 +23,7 @@ This Software Bill of Materials (SBOM) provides a complete inventory of software
 Software developed in-house for this system is listed below from the model:
 
 ```memo-query
-kind: [SoftwareSystem, SoftwareItem, SoftwareUnit]
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -37,7 +37,8 @@ empty: "No first-party software items defined."
 All third-party and SOUP components with their versions and origins, generated from the model:
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, doc, layer
 sort: name

package/src/artifacts/templates/dhf/iec-62304/sdp.md

@@ -27,11 +27,11 @@ This Software Development Plan (SDP) defines the processes, activities, and task
 | {{project.product}} Software System | Class B | |
 
 ```memo-query
-kind: [SoftwareSystem, SoftwareItem]
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, kind, layer, doc
 sort: name
-empty: "No software items defined. Add SoftwareSystem or SoftwareItem elements."
+empty: "No structural software elements defined. Add SoftwareSystem or SoftwareElement elements."
 ```
 
 ---
@@ -57,7 +57,8 @@ Identify the coding standards, review procedures, and quality gates applied duri
 ### 4.1 Software Items of Unknown Provenance (SOUP)
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, doc, layer
 sort: name
@@ -68,7 +69,7 @@ empty: "No SOUP components defined."
 
 ```memo-query
 kind: Hazard
-where: layer == "software"
+where: layer == "implementation"
 display: table
 columns: name, doc, layer
 sort: name

package/src/artifacts/templates/dhf/iec-62304/soup.md

@@ -23,7 +23,8 @@ This document lists all Software of Unknown Provenance (SOUP) components used in
 The complete inventory of SOUP and third-party components in **{{project.product}}**, generated from the model:
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, layer, doc
 sort: name
@@ -37,7 +38,8 @@ empty: "No SOUP components defined. Add SOUPComponent elements to the model."
 For each SOUP component, the potential impact on device safety must be evaluated.
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, doc
 sort: name

package/src/artifacts/templates/dhf/iec-62304/srs.md

@@ -2,7 +2,7 @@
 id: srs
 title: Software Requirements Specification
 standard: IEC 62304:2006+AMD1:2015
-clauses: ["5.2"]
+clauses: ["5.2", "5.2.2", "5.2.3", "5.2.6"]
 required_for: ["CE", "FDA_510k", "MDR"]
 ---
 
@@ -14,7 +14,9 @@ required_for: ["CE", "FDA_510k", "MDR"]
 
 ## 1. Purpose
 
-This Software Requirements Specification (SRS) defines the software requirements for **{{project.product}}** in accordance with IEC 62304:2006 §5.2.
+This Software Requirements Specification (SRS) defines the software requirements for **{{project.product}}** in accordance with IEC 62304:2006+AMD1:2015 §5.2.
+
+Software, hardware and system requirements are distinguished by the model's own `requirementKind` attribute, never by which layer directory a file sits in and never by what a requirement is called. There is no "software layer": hardware and software are sibling directories inside `implementation`.
 
 ---
 
@@ -24,12 +26,14 @@ Summary metrics for the requirements captured in the model:
 
 ```memo-query
 kind: Requirement
+where: requirementKind == "RequirementKind::software"
 display: count
 label: Total software requirements
 ```
 
 ```memo-query
 kind: Requirement
+where: requirementKind == "RequirementKind::system"
 display: count
 label: System requirements
 ```
@@ -38,25 +42,51 @@ label: System requirements
 
 ## 3. Functional Requirements
 
-Functional requirements are listed below from the model:
+Requirements carrying a `shall` obligation — the binding ones:
 
 ```memo-query
 kind: Requirement
-where: doc contains "shall"
+where: obligation == "ObligationKind::shall"
 display: table
-columns: name, layer, doc
+columns: name, requirementKind, safetyClass, doc
 sort: name
-empty: "No functional software requirements defined."
+empty: "No requirements carry a `shall` obligation. Set `obligation` on Requirement elements."
 ```
 
 ### All Software Requirements
 
 ```memo-query
 kind: Requirement
+where: requirementKind == "RequirementKind::software"
+display: table
+columns: name, requirementKind, safetyClass, doc
+sort: name
+empty: "No software requirements defined. Add Requirement elements with requirementKind = software."
+```
+
+---
+
+## 3.1 Hardware-Software Interface Requirements
+
+The hardware/software boundary is a modelled element, not a naming convention. The interfaces and ports below are the boundary this software crosses; requirements are traced to them through the model rather than selected by having "interface" in their name.
+
+```memo-query
+kind: [InterfaceElement, MemoPort]
 display: table
 columns: name, kind, layer, doc
 sort: name
-empty: "No software requirements defined. Add Requirement elements to model/requirements/*.sysml."
+empty: "No interfaces or ports defined."
+```
+
+Requirements satisfied by elements on that boundary:
+
+```memo-query
+kind: [InterfaceElement, MemoPort]
+traverse: incoming satisfiedBy
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No software requirements are linked to a satisfying architecture element. Add SatisfiedBy links."
 ```
 
 ---
@@ -67,8 +97,9 @@ System requirements allocated to software per IEC 62304 §5.2, drawn from the mo
 
 ```memo-query
 kind: Requirement
+where: requirementKind == "RequirementKind::system"
 display: table
-columns: name, layer, doc
+columns: name, requirementKind, safetyClass, doc
 sort: name
 empty: "No system requirements defined."
 ```
@@ -83,21 +114,23 @@ _[TODO: Define performance requirements (response time, throughput, memory)]_
 
 ### 5.2 Safety Requirements
 
+Software safety requirements are those whose `safetyClass` is set. The hazards they derive from:
+
 ```memo-query
 kind: Hazard
-where: layer == "software"
 display: table
-columns: name, doc
+columns: name, layer, doc
 sort: name
-empty: "No software safety requirements derived from hazard analysis."
+empty: "No hazards defined in the risk model."
 ```
 
 ### 5.3 Security Requirements
 
 ```memo-query
-kind: [SecurityControl, ThreatModel]
+kind: SecurityRequirement
 display: table
 columns: name, layer, doc
+sort: name
 empty: "No security requirements defined."
 ```
 
@@ -105,28 +138,29 @@ empty: "No security requirements defined."
 
 ## 6. SOUP Requirements
 
-This section is generated from the system model. The table below lists the **SOUP Requirements** elements currently defined:
+Software of Unknown Provenance depended on by **{{project.product}}**, derived by traversing `dependsOnSoup` from the software items:
 
 ```memo-query
-kind: SOUPComponent
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
+traverse: outgoing dependsOnSoup
 display: table
-columns: name, doc
+columns: name, kind, layer, doc
 sort: name
-empty: "No SOUP components identified."
+empty: "No SOUP identified. Add DependsOnSoup links from software items to the SOUP they depend on."
 ```
 
 ---
 
 ## 7. Requirements Traceability
 
-This section is generated from the system model. The table below lists the **Requirements Traceability** elements currently defined:
-
 ```memo-query
 kind: Requirement
+where: requirementKind == "RequirementKind::software"
+traverse: outgoing verifiedBy
 display: table
-columns: name, layer
+columns: name, kind, layer, doc
 sort: name
-empty: "No software requirements to trace."
+empty: "No software requirements are linked to a verification case. Add VerifiedBy links."
 ```
 
 ---

package/src/artifacts/templates/dhf/iec-62304/sw-traceability.md

@@ -35,7 +35,7 @@ label: Software requirements
 ```
 
 ```memo-query
-kind: TestCase
+kind: VerificationCase
 display: count
 label: Test cases
 ```
@@ -75,7 +75,7 @@ empty: "No software requirements defined."
 This section is generated from the system model. The table below lists the **Software Requirements → Design Elements** elements currently defined:
 
 ```memo-query
-kind: [SoftwareItem, SoftwareUnit]
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -89,7 +89,7 @@ empty: "No software design elements defined."
 This section is generated from the system model. The table below lists the **Test Cases** elements currently defined:
 
 ```memo-query
-kind: TestCase
+kind: VerificationCase
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/iec-62304/system-test.md

@@ -37,7 +37,7 @@ empty: "No system requirements defined."
 This section is generated from the system model. The table below lists the **System Test Cases** elements currently defined:
 
 ```memo-query
-kind: [TestCase, ValidationActivity]
+kind: [VerificationCase, ValidationCase]
 display: table
 columns: name, kind, layer, doc
 sort: name

package/src/artifacts/templates/dhf/iec-62366/summative-eval.md

@@ -31,7 +31,7 @@ _[TODO: Describe participant demographics, number, and selection criteria]_
 This section is generated from the system model. The table below lists the **Test Scenarios** elements currently defined:
 
 ```memo-query
-kind: [UseCase, ValidationActivity]
+kind: [UseCase, ValidationCase]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/iec-62366/task-analysis.md

@@ -14,26 +14,62 @@ required_for: ["CE", "MDR"]
 
 ## 1. Purpose
 
-Documents task analysis for **{{project.product}}** per IEC 62366-1:2015 §5.4, identifying tasks that could cause hazardous situations if performed incorrectly.
+Documents task analysis for **{{project.product}}** per IEC 62366-1:2015+AMD1:2020 §5.4, identifying the tasks users perform — through software user interfaces and through physical interaction with the equipment — and which of them could cause a hazardous situation if performed incorrectly.
 
 ---
 
 ## 2. User Tasks
 
-This section is generated from the system model. The table below lists the **User Tasks** elements currently defined:
+This section is generated from the system model. The table below lists the user tasks and task steps currently defined:
 
 ```memo-query
-kind: UserActivity
+kind: [UserTask, TaskStep]
 display: table
 columns: name, layer, doc
 sort: name
-empty: "No UserActivity elements defined."
+empty: "No UserTask or TaskStep elements defined."
+```
+
+### 2.1 Task Boundary — What Each Task Acts Through
+
+A task is cyber-physical when the element it is allocated to is a user interface, an operator interface element, or a port. The set below is derived by traversing `allocatedTo` from the tasks above, so it follows the model rather than the wording of a task name.
+
+```memo-query
+kind: [UserTask, TaskStep]
+traverse: outgoing allocatedTo
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No tasks are allocated to an interface element. Add AllocatedTo links from UserTask to the UI, operator interface, or port the task acts through."
+```
+
+### 2.2 Operator-Facing Boundary Elements
+
+The user-facing elements a task can act through, hardware and software alike:
+
+```memo-query
+kind: [UserInterface, OperatorInterfaceElement, Interface, MemoPort, PhysicalPort]
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No user interface or operator interface elements defined."
 ```
 
 ---
 
 ## 3. Critical Tasks
 
+A task is critical when incorrect performance can lead to a hazardous situation. The table below is derived by traversing `causes` from the task set — the `useErrorLeadsToHazard` edge of IEC 62366-1 §5.4:
+
+```memo-query
+kind: [UserTask, TaskStep]
+traverse: outgoing causes
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No hazardous situations linked to user tasks. Add Causes links (causeKind = useErrorLeadsToHazard) from UserTask to HazardousSituation."
+```
+
 Complete this section for **{{project.product}}** using the guidance below.
 
 _[TODO: Identify which tasks are critical (could lead to hazardous situation if performed incorrectly)]_

package/src/artifacts/templates/dhf/iec-62366/ue-plan.md

@@ -39,7 +39,7 @@ _[TODO: Describe all use environments: clinical, home, ambulatory, etc.]_
 This section is generated from the system model. The table below lists the **Use-Related Hazards** elements currently defined:
 
 ```memo-query
-kind: [UseCase, UserActivity]
+kind: [UseCase, UserTask]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/iec-62366/urra.md

@@ -23,7 +23,7 @@ This Use-Related Risk Analysis (URRA) identifies use errors and use-related haza
 This section is generated from the system model. The table below lists the **Use Scenarios** elements currently defined:
 
 ```memo-query
-kind: [UseCase, UserActivity]
+kind: [UseCase, UserTask]
 display: table
 columns: name, layer, doc
 sort: name
@@ -38,7 +38,7 @@ This section is generated from the system model. The table below lists the **Use
 
 ```memo-query
 kind: [Hazard, HazardousSituation]
-where: layer == "ui"
+where: layer == "human-factors"
 display: table
 columns: name, doc, layer
 sort: name
@@ -60,7 +60,7 @@ _[TODO: Identify the critical tasks whose failure could cause a hazardous situat
 This section is generated from the system model. The table below lists the **Mitigation Measures** elements currently defined:
 
 ```memo-query
-kind: [RiskControlMeasure, UsabilityRequirement]
+kind: [RiskControlMeasure, Requirement]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/iso-14971/fmea.md

@@ -2,7 +2,7 @@
 id: fmea
 title: Failure Mode and Effects Analysis
 standard: IEC 60812:2018
-clauses: ["5", "6", "7"]
+clauses: ["5", "6", "7", "ISO 14971:2019 §7"]
 required_for: ["CE", "FDA_510k", "FDA_PMA"]
 ---
 
@@ -14,61 +14,84 @@ required_for: ["CE", "FDA_510k", "FDA_PMA"]
 
 ## 1. Purpose and Scope
 
-This FMEA documents failure modes for **{{project.product}}** components, their effects, severity, and mitigations. Combines hardware, software, and system-level failure analysis.
+This FMEA documents failure modes for **{{project.product}}** components, their effects, severity, and mitigations, across the hardware layer, the software layer, and the boundary between them. IEC 60812 is the analysis method; the results feed the ISO 14971 risk management process.
 
 ---
 
 ## 2. Component Inventory
 
-This section is generated from the system model. The table below lists the **Component Inventory** elements currently defined:
+This section is generated from the system model. The table below lists the components in scope of this analysis:
 
 ```memo-query
-kind: [Component, Subsystem, SoftwareItem]
+kind: [PhysicalAssembly, HardwareAssembly, PhysicalComponent, HardwareComponent, SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, kind, layer, doc
 sort: name
-empty: "No components defined. Add Component, Subsystem, or SoftwareItem elements."
+empty: "No components defined. Add hardware or software architecture elements."
 ```
 
 ---
 
 ## 3. FMEA Worksheet
 
-### 3.1 Hardware Failures
+Each subsection traverses `hasFailureMode` from a set of architecture elements, so a failure mode appears under hardware, software, or the interface according to **what it is attached to in the model** — not according to what it is called.
+
+### 3.1 Hardware Failure Modes
+
+Physical component failures: electrical shorts, mechanical wear, sensor drift, power loss.
 
 ```memo-query
-kind: Component
+kind: [PhysicalAssembly, HardwareAssembly, PhysicalSubassembly, PhysicalComponent, HardwareComponent, ElectricalComponent, ElectronicComponent, ThermalComponent, FluidicComponent]
+traverse: outgoing hasFailureMode
 display: table
-columns: name, layer, doc
+columns: name, effect, severityRating, probability, doc
 sort: name
-empty: "No hardware components defined."
+empty: "No hardware failure modes defined. Link FailureMode elements to hardware components with HasFailureMode."
 ```
 
-### 3.2 Software Failures
+### 3.2 Software Failure Modes
+
+Software failures: logic errors, memory exhaustion, data corruption, timing violations.
 
 ```memo-query
-kind: [SoftwareItem, SoftwareUnit]
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
+traverse: outgoing hasFailureMode
 display: table
-columns: name, kind, layer, doc
+columns: name, effect, severityRating, probability, doc
 sort: name
-empty: "No software items defined."
+empty: "No software failure modes defined. Link FailureMode elements to software items with HasFailureMode."
 ```
 
-### 3.3 Interface Failures
+### 3.3 Hardware-Software Interface Failure Modes
+
+Failures at the boundary between hardware and software — sensor data misinterpreted, actuator commands lost, protocol desynchronisation. The boundary is queried through the interface and port types, never by matching a name.
 
 ```memo-query
-kind: Interface
+kind: [InterfaceElement, MemoPort]
+traverse: incoming hasFailureMode
 display: table
-columns: name, layer, doc
+columns: name, effect, severityRating, probability, doc
+sort: name
+empty: "No interface failure modes defined. Link FailureMode elements to interfaces or ports with HasFailureMode."
+```
+
+### 3.4 Interface Inventory
+
+The boundary elements the section above analyses:
+
+```memo-query
+kind: [InterfaceElement, MemoPort]
+display: table
+columns: name, kind, layer, doc
 sort: name
-empty: "No interfaces defined."
+empty: "No interfaces or ports defined."
 ```
 
 ---
 
 ## 4. Risk Controls for FMEA Items
 
-This section is generated from the system model. The table below lists the **Risk Controls for FMEA Items** elements currently defined:
+Risk control measures defined for **{{project.product}}**. A failure mode with no risk control belongs in §5.
 
 ```memo-query
 kind: RiskControlMeasure
@@ -84,7 +107,7 @@ empty: "No risk controls defined."
 
 Complete this section for **{{project.product}}** using the guidance below.
 
-_[TODO: List any failure modes without risk controls and justify residual risk]_
+_[TODO: List any failure modes without risk controls and justify residual risk per ISO 14971:2019 §7.4 and §8]_
 
 ---
 

package/src/artifacts/templates/dhf/iso-14971/har.md

@@ -50,7 +50,7 @@ All foreseeable hazards arising from the device, its intended use, and reasonabl
 
 ```memo-query
 kind: Hazard
-where: doc contains "energy"
+where: hazardType == "HazardTypeKind::energyExposure"
 display: table
 columns: name, doc, layer
 sort: name
@@ -61,7 +61,7 @@ empty: "No energy hazards identified."
 
 ```memo-query
 kind: Hazard
-where: doc contains "biolog"
+where: hazardType == "HazardTypeKind::biologicalContamination"
 display: table
 columns: name, doc, layer
 empty: "No biological/chemical hazards identified."
@@ -114,7 +114,7 @@ empty: "No harm elements defined. Add Harm elements linked to HazardousSituation
 
 ```memo-query
 kind: RiskControlMeasure
-where: doc contains "design"
+where: controlKind == "RiskControlKind::inherentSafeDesign"
 display: table
 columns: name, doc, layer
 empty: "No inherent safety controls."

package/src/artifacts/templates/dhf/iso-14971/rmp.md

@@ -64,7 +64,7 @@ Complete the table below for **{{project.product}}**:
 ### 4.1 Severity Levels
 
 ```memo-query
-kind: RiskAcceptabilityCriteria
+kind: Requirement
 display: table
 columns: name, doc, layer
 empty: "No risk acceptability criteria defined. Add RiskAcceptabilityCriteria elements to the model."
@@ -83,7 +83,7 @@ Residual risk is acceptable when:
 
 ```memo-query
 kind: Hazard
-where: layer == "risk"
+where: layer == "safety_risk"
 display: count
 label: Total hazards in model
 ```