@memoarchitect/ontology 0.7.0 → 0.8.24

package/src/artifacts/standards/memo_artifacts_standards_traceability.sysml

@@ -0,0 +1,132 @@
+// Clause-level traceability: the project-facing half of the regulatory axis.
+//
+// MEMO carries standards in two mechanisms, and this file is one of them:
+//
+//   @StandardReference metadata (core/semantics)  — provenance INSIDE the MEMO
+//     library: "this ontology type exists because ISO 14971 §5.4 says so".
+//     Library-internal, not project data.
+//   ConformsTo (here)                             — PROJECT traceability:
+//     "this requirement in this project satisfies IEC 62304 §5.2.2".
+//     Queryable, reportable, auditable.
+//
+// Do not add a third. A standard is data in the ontology, not a code path:
+// adding ISO 13485 must be one new file of RegulatoryStandard/StandardClause
+// instances and zero TypeScript changes.
+//
+// Nothing here is abstract. An abstract def cannot be instantiated, so a
+// traceability matrix over abstract clause types is empty by construction —
+// which is the failure mode this whole area exists to prevent.
+//
+// ─── The clause library and how a document cites it ──────────────────────
+//
+// The concrete instances live one file per standard beside this one
+// (iec_62304.sysml, iec_60601_1.sysml, …). A DHF template cites them from its
+// frontmatter, in one of two shapes:
+//
+//   clauses: ["5.4"]                              relative — the clause number
+//                                                 belongs to this document's
+//                                                 own `standard:`
+//   clauses: ["ISO 14971:2019 §7"]                qualified — the designation
+//                                                 before the section sign, the
+//                                                 clause number after it
+//
+// An entry containing "§" is qualified and nothing else is: that is the whole
+// grammar. The designation must match a RegulatoryStandard's `designation`
+// exactly, amendments included, and the clause number must match a
+// StandardClause's `clauseNumber` exactly. Both are checked by
+// standards-library.test.ts in memo-tools, which is what makes "adding a
+// standard is one file" true rather than aspirational.
+package memo_artifacts_standards_traceability {
+    private import Metaobjects::SemanticMetadata;
+    private import ScalarValues::*;
+    private import memo_core_common::*;
+    private import memo_core_enumerations::*;
+    private import memo_core_relationships::*;
+    private import memo_artifacts_core::*;
+
+    // =========================================================================
+    // Standards and clauses
+    // =========================================================================
+
+    item def RegulatoryStandard :> MemoArtifactItem {
+        doc /* A regulatory or consensus standard a project claims conformance
+             * to, identified by its full designation including edition and
+             * amendments (e.g. "IEC 62366-1:2015+AMD1:2020"). Dropping the
+             * amendment is a CE/MDR regression, so it is carried explicitly
+             * rather than folded into the designation by convention. */
+        attribute designation : String;
+        attribute edition : String[0..1];
+        attribute issuer : String[0..1];
+        attribute amendments : String[0..*];
+        // Which submission regimes this standard has standing in. Empty is a
+        // MEANINGFUL value, not an unset one: it says no regime mandates this
+        // standard, which is true of the method and reference standards MEMO
+        // carries (IEC 60812's FMEA method, ISO/IEC/IEEE 42010's architecture
+        // description). A regime-free standard never contributes to
+        // `required(project)` — its clauses are claimable but not required.
+        //
+        // Because empty means something, it cannot also mean "the pack author
+        // forgot". `memo standards check` prints regime-free standards in their
+        // own section rather than dropping them, and standards-library.test.ts
+        // names the exact set — the same way Phase 2 named the four document
+        // types that derive no standards. A forgotten regime is a red test.
+        attribute appliesToRegime : RegulatoryRegimeKind[0..*];
+    }
+
+    item def StandardClause :> MemoArtifactItem {
+        doc /* One normative clause of a RegulatoryStandard, at the depth at
+             * which the standard makes a distinct requirement a MEMO document
+             * actually claims. `title` is a MEMO-authored scope phrase — a
+             * representative synonym for what the clause governs ("§17" →
+             * "electromagnetic compatibility") — never the standard's own
+             * normative wording, which is copyrighted. The scope phrase is a
+             * label: queries traverse ConformsTo to the clause instance, they
+             * never match on its text.
+             *
+             * Clause containment uses the existing Composes relation
+             * (standard as parent, clause as child; clause as parent,
+             * sub-clause as child). There is no clause-specific composition
+             * type, because whole/part decomposition is already one relation
+             * in MEMO. */
+        attribute clauseNumber : String;
+        attribute title : String[0..1];
+        attribute normativeStrength : String[0..1];
+    }
+
+    // =========================================================================
+    // Relationships
+    // =========================================================================
+
+    connection def ConformsTo :> MemoRelationship {
+        doc /* Any model element claims conformance to a standard clause.
+             * This is the edge the standards traceability matrix and the
+             * clause coverage report are computed over. */
+        end conformingElement : MemoPart :>> source;
+        end clause : StandardClause :>> target;
+    }
+    abstract connection conformsToLinks : ConformsTo[*];
+    metadata def <conformsTo> ConformsToMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = conformsToLinks meta SysML::Usage;
+    }
+
+    connection def TracesToDocument :> MemoRelationship {
+        doc /* Where the evidence for a clause claim is written down. The target
+             * is the existing controlled-artifact type — MEMO does not model a
+             * separate Document/DocumentSection family, because
+             * ControlledArtifact / ModelOwnedArtifact / MarkdownDocumentSource
+             * already carry version, owner and approval status. Section
+             * granularity rides on the link as a reference string rather than
+             * as a duplicate element type. */
+        attribute sectionReference : String[0..1];
+        end tracedElement : MemoPart :>> source;
+        end artifact : ControlledArtifact :>> target;
+    }
+    abstract connection tracesToDocumentLinks : TracesToDocument[*];
+    metadata def <tracesToDocument> TracesToDocumentMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = tracesToDocumentLinks meta SysML::Usage;
+    }
+}

package/src/artifacts/templates/dhf/21cfr820/design-input.md

@@ -33,7 +33,7 @@ empty: "No system requirements defined."
 ### 2.2 Design Inputs from User Needs
 
 ```memo-query
-kind: [DesignInput, Need]
+kind: [Requirement, Need]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/21cfr820/design-output.md

@@ -23,8 +23,8 @@ Defines design outputs for **{{project.product}}** per 21 CFR 820.30(d). Design
 ### 2.1 Hardware Design Outputs
 
 ```memo-query
-kind: [Component, Subsystem, DesignOutput]
-where: layer == "physical"
+kind: [HardwareComponent, HardwareAssembly, SoftwareComponent, SoftwareSystem]
+where: layer == "implementation"
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -34,8 +34,8 @@ empty: "No hardware design outputs defined."
 ### 2.2 Software Design Outputs
 
 ```memo-query
-kind: [SoftwareItem, SoftwareUnit, DesignOutput]
-where: layer == "software"
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
+where: layer == "implementation"
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -45,7 +45,7 @@ empty: "No software design outputs defined."
 ### 2.3 All Design Outputs
 
 ```memo-query
-kind: DesignOutput
+kind: [HardwareComponent, HardwareAssembly, SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/21cfr820/design-review.md

@@ -41,7 +41,7 @@ _[TODO: Track all open action items from design reviews]_
 Snapshot of the design state at the time of review, computed from the model:
 
 ```memo-query
-kind: [Requirement, Requirement, DesignInput, DesignOutput]
+kind: [Requirement, HardwareComponent, HardwareAssembly, SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: count
 label: Total design elements at last review
 ```

package/src/artifacts/templates/dhf/21cfr820/design-validation.md

@@ -29,7 +29,7 @@ _[TODO: Reference V&V Plan]_
 Describe clinical or bench validation activities demonstrating conformity with user needs under actual or simulated use conditions.
 
 ```memo-query
-kind: ValidationActivity
+kind: ValidationCase
 display: table
 columns: name, layer, doc
 sort: name
@@ -43,7 +43,7 @@ empty: "No validation activities defined."
 Coverage of user needs by validation activities, computed live from the model:
 
 ```memo-query
-kind: [Need, Requirement]
+kind: [Requirement, Need]
 display: table
 columns: name, layer, doc
 empty: "No user needs defined."

package/src/artifacts/templates/dhf/21cfr820/design-verification.md

@@ -21,7 +21,7 @@ Documents design verification that design outputs meet design inputs for **{{pro
 The verification traceability below is generated live from the model — every requirement should be covered by at least one verification activity:
 
 ```memo-query
-kind: VerificationActivity
+kind: VerificationCase
 display: table
 columns: name, layer, doc
 sort: name
@@ -35,7 +35,7 @@ empty: "No verification activities defined."
 Test executions and their outcomes are summarized below from the model:
 
 ```memo-query
-kind: TestCase
+kind: VerificationCase
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/21cfr820/dhf-index.md

@@ -79,7 +79,7 @@ Key characteristics of **{{project.product}}**, drawn from the model:
 Summary statistics of the system model at the time this document was generated:
 
 ```memo-query
-kind: [Requirement, Requirement]
+kind: Requirement
 display: count
 label: Total requirements
 ```
@@ -91,7 +91,7 @@ label: Total hazards
 ```
 
 ```memo-query
-kind: [TestCase, VerificationActivity]
+kind: VerificationCase
 display: count
 label: Total test cases
 ```

package/src/artifacts/templates/dhf/21cfr820/transfer-plan.md

@@ -36,7 +36,7 @@ Checklist of items required before design transfer to production is complete:
 Production specifications derived from the design outputs:
 
 ```memo-query
-kind: DesignOutput
+kind: [HardwareComponent, HardwareAssembly, SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/21cfr820/user-needs.md

@@ -31,7 +31,7 @@ _[TODO: Describe all intended user groups with their roles, training levels, and
 User needs captured for **{{project.product}}** are listed below from the model. Each user need should trace forward to at least one design input:
 
 ```memo-query
-kind: [Need, Requirement]
+kind: [Requirement, Need]
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/21cfr820/vv-plan.md

@@ -33,7 +33,7 @@ This plan covers:
 ### 3.1 Requirements to Verify
 
 ```memo-query
-kind: [Requirement, Requirement]
+kind: Requirement
 display: table
 columns: name, layer, doc
 sort: name
@@ -43,7 +43,7 @@ empty: "No requirements defined."
 ### 3.2 Verification Test Cases
 
 ```memo-query
-kind: [TestCase, VerificationActivity]
+kind: VerificationCase
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -57,7 +57,7 @@ empty: "No verification test cases defined."
 Validation activities demonstrating that **{{project.product}}** meets user needs and intended uses:
 
 ```memo-query
-kind: ValidationActivity
+kind: ValidationCase
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/21cfr820/vv-report.md

@@ -23,13 +23,13 @@ This V&V Report documents the results of all verification and validation activit
 Summary metrics computed live from the model:
 
 ```memo-query
-kind: TestCase
+kind: VerificationCase
 display: count
 label: Total test cases
 ```
 
 ```memo-query
-kind: [VerificationActivity, ValidationActivity]
+kind: [VerificationCase, ValidationCase]
 display: count
 label: V&V activities
 ```
@@ -41,7 +41,7 @@ label: V&V activities
 ### 3.1 Test Results by Requirement
 
 ```memo-query
-kind: [TestCase, VerificationActivity]
+kind: VerificationCase
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -55,7 +55,7 @@ empty: "No verification activities defined."
 Results of the validation activities are summarized below:
 
 ```memo-query
-kind: ValidationActivity
+kind: ValidationCase
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/fda-cybersecurity/incident-response.md

@@ -2,7 +2,7 @@
 id: incident-response
 title: Cybersecurity Incident Response Plan
 standard: FDA Cybersecurity Guidance 2023
-clauses: ["5.2"]
+clauses: ["VI"]
 required_for: ["FDA_510k", "FDA_PMA"]
 ---
 

package/src/artifacts/templates/dhf/fda-cybersecurity/postmarket-surveillance.md

@@ -2,7 +2,7 @@
 id: postmarket-surveillance
 title: Post-Market Cybersecurity Surveillance Plan
 standard: FDA Cybersecurity Guidance 2023
-clauses: ["5"]
+clauses: ["VI"]
 required_for: ["FDA_510k", "FDA_PMA"]
 ---
 
@@ -30,7 +30,8 @@ Defines ongoing cybersecurity surveillance for **{{project.product}}** in the po
 Describe the process for ongoing monitoring of SOUP components for newly published vulnerabilities.
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, doc
 sort: name

package/src/artifacts/templates/dhf/fda-cybersecurity/security-arch.md

@@ -2,7 +2,7 @@
 id: security-arch
 title: Cybersecurity Architecture Description
 standard: FDA Cybersecurity Guidance 2023
-clauses: ["3.3"]
+clauses: ["V.B"]
 required_for: ["FDA_510k", "FDA_PMA"]
 ---
 
@@ -45,7 +45,7 @@ empty: "No interfaces defined."
 Security controls implemented in **{{project.product}}** are listed below from the model. Each control should trace to at least one identified threat:
 
 ```memo-query
-kind: SecurityControl
+kind: RiskControlMeasure
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/fda-cybersecurity/threat-model.md

@@ -2,7 +2,7 @@
 id: threat-model
 title: Cybersecurity Threat Model
 standard: FDA Cybersecurity Guidance 2023
-clauses: ["3.2"]
+clauses: ["V.A"]
 required_for: ["FDA_510k", "FDA_PMA"]
 ---
 
@@ -23,7 +23,7 @@ This threat model documents cybersecurity threats for **{{project.product}}** pe
 Assets requiring protection (data, functions, interfaces), drawn from the model:
 
 ```memo-query
-kind: [SoftwareSystem, Interface, SOUPComponent]
+kind: [SoftwareSystem, InterfaceElement, SoftwareModule]
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -51,7 +51,7 @@ empty: "No interfaces defined."
 The threat catalog below is generated from the model. Each threat should be assessed for likelihood and impact and trace to mitigating security controls:
 
 ```memo-query
-kind: ThreatModel
+kind: [FMEAWorksheet, FaultTree, HAZOPStudy]
 display: table
 columns: name, layer, doc
 sort: name
@@ -76,7 +76,7 @@ empty: "No threat model elements defined. Add ThreatModel elements."
 Security controls implemented in **{{project.product}}** are listed below from the model. Each control should trace to at least one identified threat:
 
 ```memo-query
-kind: SecurityControl
+kind: RiskControlMeasure
 display: table
 columns: name, layer, doc
 sort: name

package/src/artifacts/templates/dhf/fda-cybersecurity/vuln-assessment.md

@@ -2,7 +2,7 @@
 id: vuln-assessment
 title: Vulnerability Assessment and Penetration Testing Report
 standard: FDA Cybersecurity Guidance 2023
-clauses: ["3.4"]
+clauses: ["V.C"]
 required_for: ["FDA_510k", "FDA_PMA"]
 ---
 
@@ -23,7 +23,7 @@ Documents cybersecurity vulnerability assessment and testing for **{{project.pro
 Define the boundaries of this assessment: components, interfaces, and threat classes in and out of scope.
 
 ```memo-query
-kind: [SoftwareSystem, SoftwareItem, Interface]
+kind: [HardwareComponent, HardwareAssembly, SoftwareSystem, SoftwareComponent, SoftwareModule, InterfaceElement, MemoPort]
 display: table
 columns: name, kind, layer
 sort: name
@@ -37,7 +37,8 @@ empty: "No software assets defined."
 Known vulnerabilities in SOUP and third-party components (e.g. from CVE/NVD monitoring) and their disposition:
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, doc
 sort: name

package/src/artifacts/templates/dhf/iec-60601/hrs.md

@@ -0,0 +1,170 @@
+---
+id: hrs
+title: Hardware Requirements Specification
+standard: IEC 60601-1:2005+AMD1:2012+AMD2:2020
+clauses: ["8", "9", "11", "15", "IEC 60601-1-2:2014+AMD1:2020 §7"]
+required_for: ["CE", "FDA_510k", "MDR"]
+---
+
+{{include:shared/snippets/document-control-header.md}}
+
+{{toc}}
+
+---
+
+## 1. Purpose
+
+This Hardware Requirements Specification (HRS) defines the safety, construction, and performance requirements for the **{{project.product}}** physical equipment, ensuring compliance with IEC 60601-1 (general safety) and applicable collateral standards (IEC 60601-1-2 for electromagnetic compatibility).
+
+Hardware requirements are identified by the model's `requirementKind` attribute. Per-topic sections — construction, electrical, EMC, mechanical — are **not** name filters: each is the set of elements claiming the clause that governs that topic, selected by traversing `ConformsTo` to that clause. A clause is named by its element id rather than by its number, because a clause number is not unique across standards: "8" is a clause of IEC 60601-1, of IEC 60601-1-2 and of IEC 62304.
+
+---
+
+## 2. Hardware Requirements Summary
+
+Summary metrics for the hardware requirements captured in the model:
+
+```memo-query
+kind: Requirement
+where: requirementKind == "RequirementKind::hardware"
+display: count
+label: Total hardware requirements
+```
+
+### All Hardware Requirements
+
+```memo-query
+kind: Requirement
+where: requirementKind == "RequirementKind::hardware"
+display: table
+columns: name, requirementKind, electricalSafetyRelevant, doc
+sort: name
+empty: "No hardware requirements defined. Add Requirement elements with requirementKind = hardware."
+```
+
+---
+
+## 3. Physical & Construction Requirements (IEC 60601-1 §15)
+
+The physical elements these requirements govern:
+
+```memo-query
+kind: [PhysicalAssembly, HardwareAssembly, PhysicalSubassembly, PhysicalComponent, HardwareComponent, PhysicalConnectorPart]
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No physical assemblies or components defined."
+```
+
+The elements claiming IEC 60601-1 §15 are a `ConformsTo` table:
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.id == "iec60601_1Clause15"
+display: table
+columns: source, source.kind, target.clauseNumber, target.title
+sort: source
+empty: "No elements claim IEC 60601-1 §15."
+```
+
+---
+
+## 4. Electrical Safety Requirements (IEC 60601-1 §8)
+
+Protection against electric shock, isolation, and medical-grade power supplies. The electrical elements in scope:
+
+```memo-query
+kind: [ElectricalComponent, ElectronicComponent, PhysicalConnectorPart]
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No electrical or electronic components defined."
+```
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.id == "iec60601_1Clause8"
+display: table
+columns: source, source.kind, target.clauseNumber, target.title
+sort: source
+empty: "No elements claim IEC 60601-1 §8."
+```
+
+---
+
+## 5. Electromagnetic Compatibility (IEC 60601-1-2 §7)
+
+Immunity from electromagnetic disturbances and limits on emissions.
+
+This section is the one that pays for clause-level traceability: once a requirement carries `ConformsTo → IEC 60601-1-2 §7`, "EMC Requirements" stops being a filter over names and becomes *the set of requirements claiming that clause*. The section heading and the standard then come from one source.
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.id == "iec60601_1_2Clause7"
+display: table
+columns: source, source.kind, target.clauseNumber, target.title
+sort: source
+empty: "No elements claim IEC 60601-1-2 §7."
+```
+
+---
+
+## 6. Mechanical, Thermal, and Environmental Requirements (IEC 60601-1 §9, §11)
+
+Mechanical strength and impact resistance (§9), excessive temperatures and ingress (§11). The elements in scope:
+
+```memo-query
+kind: [ThermalComponent, AcousticComponent, FluidicComponent, PneumaticComponent, OpticalComponent]
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No mechanical, thermal, fluidic or optical components defined."
+```
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.id == "iec60601_1Clause9"
+display: table
+columns: source, source.kind, target.clauseNumber, target.title
+sort: source
+empty: "No elements claim IEC 60601-1 §9."
+```
+
+---
+
+## 7. Hardware Traceability
+
+Hardware requirements traced to the elements that satisfy them:
+
+```memo-query
+kind: Requirement
+where: requirementKind == "RequirementKind::hardware"
+traverse: outgoing satisfiedBy
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No hardware requirements are linked to a satisfying element. Add SatisfiedBy links."
+```
+
+The allocation table proper — *which* element allocates to *which* — is relationship-shaped. It is not filtered to hardware: `AllocatedTo` joins two architecture elements and carries no layer of its own, so the receiving element's kind and layer are shown as columns instead of guessed at by a filter.
+
+```memo-query
+select: relationships
+kind: allocatedTo
+display: table
+columns: source, target, target.kind, target.layer
+sort: target
+empty: "No allocations defined."
+```
+
+---
+
+{{include:shared/snippets/revision-history-table.md}}
+
+{{include:shared/snippets/approval-block.md}}
+
+{{include:shared/snippets/references-section.md}}

package/src/artifacts/templates/dhf/iec-62304/detailed-design.md

@@ -23,7 +23,7 @@ This document provides detailed design specifications for **{{project.product}}*
 The software units — the lowest level of decomposition per IEC 62304 — are listed below from the model:
 
 ```memo-query
-kind: SoftwareUnit
+kind: SoftwareModule
 display: table
 columns: name, layer, doc
 sort: name

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

@@ -23,7 +23,7 @@ This Integration Test Plan defines the approach for integration testing of **{{p
 The software items in scope for this test plan, drawn from the model:
 
 ```memo-query
-kind: [SoftwareItem, SoftwareUnit]
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, kind, layer, doc
 sort: name
@@ -37,8 +37,8 @@ empty: "No software items defined."
 Integration test cases are listed below from the model:
 
 ```memo-query
-kind: TestCase
-where: layer == "verification"
+kind: VerificationCase
+where: layer == "verification_validation"
 display: table
 columns: name, layer, doc
 sort: name

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

@@ -33,7 +33,7 @@ empty: "No SoftwareSystem defined."
 **Total elements:**
 
 ```memo-query
-kind: [SoftwareSystem, SoftwareItem, SoftwareUnit, SOUPComponent]
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: count
 label: Total software elements
 ```
@@ -49,17 +49,17 @@ This section describes the decomposition of the software into software items per
 ### 3.1 Software Items
 
 ```memo-query
-kind: SoftwareItem
+kind: [HardwareComponent, HardwareAssembly, SoftwareSystem, SoftwareComponent, SoftwareModule]
 display: table
 columns: name, layer, doc
 sort: name
-empty: "No SoftwareItem elements defined."
+empty: "No SoftwareElement elements defined."
 ```
 
 ### 3.2 Software Units
 
 ```memo-query
-kind: SoftwareUnit
+kind: SoftwareModule
 display: table
 columns: name, layer, doc
 sort: name
@@ -83,7 +83,8 @@ empty: "No Interface elements defined."
 Software of Unknown Provenance (SOUP) used by **{{project.product}}** is listed below per IEC 62304 §5.3.3–5.3.4. For each SOUP item, functional/performance requirements and required hardware/software must be specified:
 
 ```memo-query
-kind: SOUPComponent
+kind: SoftwareModule
+where: moduleKind == "SoftwareModuleKind::soup"
 display: table
 columns: name, doc, layer
 sort: name