@memoarchitect/ontology 0.6.5 → 0.8.22

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

@@ -0,0 +1,93 @@
+---
+id: task-analysis
+title: Task Analysis
+standard: IEC 62366-1:2015+AMD1:2020
+clauses: ["5.4"]
+required_for: ["CE", "MDR"]
+---
+
+{{include:shared/snippets/document-control-header.md}}
+
+{{toc}}
+
+---
+
+## 1. Purpose
+
+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 and task steps currently defined:
+
+```memo-query
+kind: [UserTask, TaskStep]
+display: table
+columns: name, layer, doc
+sort: name
+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)]_
+
+| Task | Critical | Hazardous Situation if Error | Mitigation |
+| --- | --- | --- | --- |
+| | | | |
+
+---
+
+## 4. Task Flow Analysis
+
+The diagram below is rendered from the corresponding model view and reflects the current state of the model:
+
+{{diagram:task-flow}}
+
+_[TODO: Document sequential and parallel task flows with decision points]_
+
+---
+
+{{include:shared/snippets/revision-history-table.md}}

package/src/{compliance/dhf-templates → 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/{compliance/dhf-templates → 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

@@ -0,0 +1,116 @@
+---
+id: fmea
+title: Failure Mode and Effects Analysis
+standard: IEC 60812:2018
+clauses: ["5", "6", "7", "ISO 14971:2019 §7"]
+required_for: ["CE", "FDA_510k", "FDA_PMA"]
+---
+
+{{include:shared/snippets/document-control-header.md}}
+
+{{toc}}
+
+---
+
+## 1. Purpose and Scope
+
+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 components in scope of this analysis:
+
+```memo-query
+kind: [PhysicalAssembly, HardwareAssembly, PhysicalComponent, HardwareComponent, SoftwareSystem, SoftwareComponent, SoftwareModule]
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No components defined. Add hardware or software architecture elements."
+```
+
+---
+
+## 3. FMEA Worksheet
+
+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: [PhysicalAssembly, HardwareAssembly, PhysicalSubassembly, PhysicalComponent, HardwareComponent, ElectricalComponent, ElectronicComponent, ThermalComponent, FluidicComponent]
+traverse: outgoing hasFailureMode
+display: table
+columns: name, effect, severityRating, probability, doc
+sort: name
+empty: "No hardware failure modes defined. Link FailureMode elements to hardware components with HasFailureMode."
+```
+
+### 3.2 Software Failure Modes
+
+Software failures: logic errors, memory exhaustion, data corruption, timing violations.
+
+```memo-query
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
+traverse: outgoing hasFailureMode
+display: table
+columns: name, effect, severityRating, probability, doc
+sort: name
+empty: "No software failure modes defined. Link FailureMode elements to software items with HasFailureMode."
+```
+
+### 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: [InterfaceElement, MemoPort]
+traverse: incoming hasFailureMode
+display: table
+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 or ports defined."
+```
+
+---
+
+## 4. Risk Controls for FMEA Items
+
+Risk control measures defined for **{{project.product}}**. A failure mode with no risk control belongs in §5.
+
+```memo-query
+kind: RiskControlMeasure
+display: table
+columns: name, layer, doc
+sort: name
+empty: "No risk controls defined."
+```
+
+---
+
+## 5. Unmitigated Failures
+
+Complete this section for **{{project.product}}** using the guidance below.
+
+_[TODO: List any failure modes without risk controls and justify residual risk per ISO 14971:2019 §7.4 and §8]_
+
+---
+
+{{include:shared/snippets/revision-history-table.md}}
+
+{{include:shared/snippets/approval-block.md}}

package/src/{compliance/dhf-templates → 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/{compliance/dhf-templates → 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
 ```

package/src/artifacts/templates/dhf/system/sad.md

@@ -0,0 +1,173 @@
+---
+id: sad-system
+title: System Architecture Description
+standard: ISO/IEC/IEEE 42010:2022
+clauses: ["5", "6", "IEC 62304:2006+AMD1:2015 §5.3", "IEC 60601-1:2005+AMD1:2012+AMD2:2020 §4.2"]
+required_for: ["CE", "FDA_510k", "MDR"]
+---
+
+{{include:shared/snippets/document-control-header.md}}
+
+{{toc}}
+
+---
+
+## 1. Purpose
+
+This System Architecture Description (SAD) defines the overall cyber-physical architecture of **{{project.product}}** per ISO/IEC/IEEE 42010:2022 and satisfies architecture requirements across IEC 62304 §5.3 (software) and IEC 60601-1 (hardware).
+
+---
+
+## 2. System Overview
+
+A high-level view of the **{{project.product}}** system, drawn live from the architecture model:
+
+```memo-query
+kind: [SoftwareSystem, HardwareAssembly, PhysicalAssembly]
+display: table
+columns: name, layer, doc
+sort: name
+empty: "No system-level elements defined."
+```
+
+**Total elements:**
+
+```memo-query
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule, HardwareAssembly, PhysicalAssembly, PhysicalSubassembly, HardwareComponent, PhysicalComponent]
+display: count
+label: Total system elements
+```
+
+---
+
+## 3. SEI Viewpoints
+
+This architecture is described using the Software Engineering Institute (SEI) Views and Beyond approach, adapted for cyber-physical systems.
+
+### 3.1 Module View (Implementation Structure)
+
+The static structure of the system's implementation units. Hardware and software are sibling directories in the `implementation` layer, so the two subsections are distinguished by **kind**, not by a layer filter — there is no hardware layer and no software layer.
+
+#### 3.1.1 Software Implementation Units (IEC 62304 §5.3.1)
+
+```memo-query
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
+display: table
+columns: name, layer, doc
+sort: name
+empty: "No software implementation units defined."
+```
+
+#### 3.1.2 Hardware Implementation Units
+
+```memo-query
+kind: [PhysicalAssembly, HardwareAssembly, PhysicalSubassembly, PhysicalComponent, HardwareComponent]
+display: table
+columns: name, layer, doc
+sort: name
+empty: "No hardware implementation units defined."
+```
+
+### 3.2 Component-and-Connector (C&C) View (Runtime Execution)
+
+Runtime behaviour: the components executing in the system and the connectors through which they interact.
+
+#### 3.2.1 Runtime Environments
+
+```memo-query
+kind: [RuntimeEnvironment, DeploymentUnit]
+display: table
+columns: name, layer, doc
+sort: name
+empty: "No runtime environments or deployment units defined."
+```
+
+#### 3.2.2 Interfaces and Data Flows
+
+Cyber-physical interactions and data flows between components:
+
+```memo-query
+kind: [Interface, LogicalInterface, ComponentExchange, InterfaceElement, MemoPort, DataPort, SensorPort, CommandPort, SoftwarePort, PhysicalPort, LogicalPort]
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No interfaces, ports or component exchanges defined."
+```
+
+### 3.3 Allocation View (Environment Mapping)
+
+Software elements mapped to their execution environments.
+
+#### 3.3.1 Deployment Units
+
+```memo-query
+kind: DeploymentUnit
+traverse: outgoing deploysTo
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No deployments defined. Add DeploysTo links from DeploymentUnit to the processing node."
+```
+
+---
+
+## 4. Architecture Decisions & Segregation
+
+Significant architecture decisions, alternatives considered, and rationale — including decisions driven by risk control measures (ISO 14971) or cybersecurity considerations.
+
+### 4.1 Segregation of Safety Classes (IEC 62304 §5.3.5)
+
+_[TODO: Describe how safety-critical items are segregated from non-safety-critical items, and the rationale for the integrity of each boundary]_
+
+---
+
+## 5. SOUP Components
+
+Software of Unknown Provenance used by **{{project.product}}**, derived by traversing `dependsOnSoup` from the software items. MEMO has no `SOUPComponent` kind: SOUP is a *relationship* a project's own software item has to a third-party item, which is why it is traversed rather than typed.
+
+```memo-query
+kind: [SoftwareSystem, SoftwareComponent, SoftwareModule]
+traverse: outgoing dependsOnSoup
+display: table
+columns: name, kind, layer, doc
+sort: name
+empty: "No SOUP identified. Add DependsOnSoup links from software items to the SOUP they depend on."
+```
+
+---
+
+## 6. Standards Compliance and Traceability
+
+Maps architectural elements to the regulatory clauses they claim, for compliance audits. Both tables are relationship tables — rows are `ConformsTo` links, with columns drawn from both endpoints. Each is scoped to one standard by the clause's declaring package, since the standards library is one package per standard; a clause *number* would not do it, because "5" is a clause of seven of the standards MEMO ships.
+
+### 6.1 Compliance with IEC 62304
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.package == "memo_artifacts_standards_iec_62304"
+display: table
+columns: source, source.kind, target.clauseNumber, target.title
+sort: target.clauseNumber
+empty: "No IEC 62304 compliance traces defined."
+```
+
+### 6.2 Compliance with IEC 60601-1
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.package == "memo_artifacts_standards_iec_60601_1"
+display: table
+columns: source, source.kind, target.clauseNumber, target.title
+sort: target.clauseNumber
+empty: "No IEC 60601-1 compliance traces 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/system/standards-checklist.md

@@ -0,0 +1,87 @@
+---
+id: standards-checklist
+title: Standards Conformance Checklist
+standard: ISO 13485:2016
+clauses: ["4.2", "7.3.10"]
+required_for: ["CE", "FDA_510k", "FDA_PMA", "MDR"]
+---
+
+{{include:shared/snippets/document-control-header.md}}
+
+{{toc}}
+
+---
+
+## 1. Purpose
+
+This checklist is the clause-by-clause conformance record for **{{project.product}}**. It lists every clause the project's declared regulatory regimes require, states whether the project claims it, and — where it does — names the element that carries the claim and the evidence behind it.
+
+It replaces a hand-maintained conformance matrix. The difference that matters is that this one **cannot silently go empty**: it is generated from the clause library, so a clause nobody has claimed appears as a row marked *Gap*, not as an absent line.
+
+**How to read this document.**
+
+| Status | Meaning |
+| --- | --- |
+| ✅ Evidenced | Something claims the clause, and that claim reaches verification, a risk control, or an approved controlled document. |
+| 🟡 Claimed | Something claims the clause, but no evidence is linked to it yet. |
+| ❌ Gap | Nothing in the project claims the clause. |
+
+A **Gap** is not a defect in the model. Coverage is profile-dependent — that is why it is a report and not a consistency rule, and why `memo_rules_coverage` is deliberately empty. A gap says the project has not claimed that clause *yet*, which is the normal state of a project in flight.
+
+**Scope.** The clauses below are those of the standards the project's `regulatoryRegime` declaration pulls in. Method and reference standards that no regime mandates — the FMEA method, the architecture-description standard — are listed separately in §4; their clauses are claimable but not required, so they have no gap count.
+
+`memo standards check` prints the same numbers at the command line, from the same computation.
+
+---
+
+## 2. Coverage Summary
+
+```memo-standards
+display: summary
+empty: "No standards are in scope. Declare `regulatoryRegime` on the project's ProjectMethodBinding."
+```
+
+---
+
+## 3. Clause-by-Clause Record
+
+Every required clause, including the ones nothing claims. The unclaimed rows are the point of the document.
+
+```memo-standards
+display: checklist
+status: all
+empty: "No standards are in scope for the declared regimes."
+```
+
+---
+
+## 4. Standards Not Required by the Declared Regimes
+
+Method and reference standards, and packs outside this project's submission targets. A clause claimed here is real traceability; it is simply not something a regime obliges this project to claim, so nothing here is counted as a gap.
+
+```memo-standards
+display: checklist
+scope: unrequired
+status: claimed
+empty: "No clauses are claimed outside the required standards."
+```
+
+---
+
+## 5. Open Gaps
+
+The working list. Each row is a clause a declared regime requires and nothing in the project claims.
+
+```memo-standards
+display: checklist
+status: gaps
+empty: "No open gaps — every required clause is claimed."
+```
+
+---
+
+{{include:shared/snippets/revision-history-table.md}}
+
+{{include:shared/snippets/approval-block.md}}
+
+{{include:shared/snippets/references-section.md}}

package/src/artifacts/templates/dhf/system/standards-traceability.md

@@ -0,0 +1,125 @@
+---
+id: standards-traceability
+title: Standards Traceability Matrix
+standard: ISO 13485:2016
+clauses: ["7.3.9", "IEC 62304:2006+AMD1:2015 §5.1", "IEC 60601-1:2005+AMD1:2012+AMD2:2020 §4.2", "ISO 14971:2019 §4.4"]
+required_for: ["CE", "FDA_510k", "MDR"]
+---
+
+{{include:shared/snippets/document-control-header.md}}
+
+{{toc}}
+
+---
+
+## 1. Purpose
+
+This Standards Traceability Matrix cross-references the requirements and architectural elements of the **{{project.product}}** cyber-physical system against the clauses of applicable regulatory standards. It is the automated compliance checklist an auditor reads.
+
+**How to read this document.** Every table below is *relationship-shaped*: a row is a `ConformsTo` link, with the clause on one end and the conforming element on the other. `select: relationships` makes the link the row, so both ends are addressable as columns.
+
+Each section is scoped to one standard by the clause's declaring package — the standards library is one package per standard, which makes `target.package` an exact per-standard selector. A clause *number* is not one: "5" is a clause of seven of the standards MEMO ships, so a matrix filtered on clause number would silently mix IEC 62304 §5 with ISO 14971 §5.
+
+A clause with no `ConformsTo` link is a gap. Enumerating the gaps is `memo standards check`, not this document — this document shows what the project *does* claim.
+
+---
+
+## 2. IEC 62304 Software Lifecycle Processes
+
+Maps IEC 62304 clauses to the system elements that satisfy them.
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.package == "memo_artifacts_standards_iec_62304"
+display: table
+columns: target.clauseNumber, target.title, source, source.kind
+sort: target.clauseNumber
+empty: "No IEC 62304 compliance traces defined."
+```
+
+### 2.1 Document Traceability (IEC 62304)
+
+```memo-query
+select: relationships
+kind: tracesToDocument
+where: source.package == "memo_artifacts_standards_iec_62304"
+display: table
+columns: source.clauseNumber, source.title, target, sectionReference
+sort: source.clauseNumber
+empty: "No IEC 62304 document traces defined."
+```
+
+---
+
+## 3. IEC 60601-1 Medical Electrical Equipment Safety
+
+Maps IEC 60601-1 clauses to the hardware elements and requirements that satisfy them.
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.package == "memo_artifacts_standards_iec_60601_1"
+display: table
+columns: target.clauseNumber, target.title, source, source.kind
+sort: target.clauseNumber
+empty: "No IEC 60601-1 compliance traces defined."
+```
+
+### 3.1 Document Traceability (IEC 60601-1)
+
+```memo-query
+select: relationships
+kind: tracesToDocument
+where: source.package == "memo_artifacts_standards_iec_60601_1"
+display: table
+columns: source.clauseNumber, source.title, target, sectionReference
+sort: source.clauseNumber
+empty: "No IEC 60601-1 document traces defined."
+```
+
+---
+
+## 4. ISO 14971 Risk Management
+
+Maps ISO 14971 risk management clauses to their conforming elements — the risk management plan, the hazard analysis, the risk controls.
+
+```memo-query
+select: relationships
+kind: conformsTo
+where: target.package == "memo_artifacts_standards_iso_14971"
+display: table
+columns: target.clauseNumber, target.title, source, source.kind
+sort: target.clauseNumber
+empty: "No ISO 14971 compliance traces defined."
+```
+
+---
+
+## 5. Standards and Clauses in Scope
+
+The clause library itself, as element queries — the standards this project's documents cite, and the clauses available to claim.
+
+```memo-query
+kind: RegulatoryStandard
+display: table
+columns: name, designation, edition, issuer
+sort: designation
+empty: "No standards declared. Add RegulatoryStandard instances for the standards this project claims."
+```
+
+```memo-query
+kind: StandardClause
+display: table
+columns: clauseNumber, title, normativeStrength, doc
+sort: clauseNumber
+empty: "No standard clauses declared. Add StandardClause instances for the clauses this project claims."
+```
+
+---
+
+{{include:shared/snippets/revision-history-table.md}}
+
+{{include:shared/snippets/approval-block.md}}
+
+{{include:shared/snippets/references-section.md}}