mneme-cli 0.4.0__py3-none-any.whl

mneme/profiles/eu-mdr.md

@@ -0,0 +1,196 @@
+---
+name: EU MDR
+description: European Medical Device Regulation (EU 2017/745) documentation profile
+version: 2.0
+tone: formal
+voice: passive-for-procedures
+citation_style: section-reference
+placeholder_for_missing_refs: "[TO ADD REF]"
+trace_types:
+  - derived-from
+  - implemented-by
+  - detailed-in
+  - mitigated-by
+  - verified-by
+  - validated-by
+  - referenced-in
+  - supersedes
+requirement_levels:
+  shall: mandatory requirement - must be fulfilled
+  should: recommended - expected unless justified otherwise
+  may: permitted - optional, at discretion
+vocabulary:
+  - use: medical device
+    reject: [product, unit, item, widget, gadget]
+  - use: intended purpose
+    reject: [intended use, use case, purpose]
+  - use: manufacturer
+    reject: [company, vendor, maker, supplier]
+  - use: clinical evaluation
+    reject: [clinical review, clinical assessment]
+  - use: risk management
+    reject: [risk analysis, risk review]
+  - use: design and development
+    reject: [R&D, engineering]
+  - use: verification
+    reject: [testing, checking]
+  - use: validation
+    reject: [user testing, acceptance testing]
+  - use: notified body
+    reject: [certification body, audit body]
+  - use: technical documentation
+    reject: [tech docs, technical file]
+  - use: post-market surveillance
+    reject: [PMS, market monitoring]
+  - use: unique device identification
+    reject: [UDI, device ID]
+  - use: economic operator
+    reject: [distributor, reseller]
+  - use: conformity assessment
+    reject: [compliance check, certification]
+  - use: essential requirements
+    reject: [basic requirements, core requirements]
+---
+
+# Principles
+
+- Reproducibility: every section must contain enough detail that an independent reviewer with no prior knowledge of the project could in principle reproduce the work. If a reader has to guess, infer, or look elsewhere for critical information, the section is incomplete.
+- Technical, not clinical: validation documents describe technical measurements (e.g. a kinematic signal captured by an accelerometer). They do not describe clinical outcomes, patient experiences, or functional burden. Language must reflect this distinction.
+- Construct validity, not clinical efficacy: when a clinical rating scale (e.g. UPDRS) is used as a reference standard, the algorithm output is a technical proxy that correlates with that scale. Correlation demonstrates construct validity of the technical measurement, not clinical efficacy.
+
+# General Rules
+
+- Be specific, never vague. Replace "adequate statistical power" with the actual power calculation. Replace "diverse populations" with the exact demographic breakdown.
+- Define before you use. Every abbreviation, metric, method, and technical term must be defined at first use.
+- Reference everything. Every dataset, document, standard, or external claim must have an ID, version, and/or citation.
+- If a specific reference cannot be identified at the time of writing, insert the placeholder [TO ADD REF] at the exact point where the citation is needed. Do not omit the claim or leave the gap unmarked.
+- Separate observation from interpretation. State the result first; then in separate sentences state what it means technically.
+- Avoid marketing language. Words like "excellent", "strong", "robust", "high accuracy" are editorial. Let the numbers speak.
+- Use consistent terminology throughout. Pick one term for each concept (e.g. always "algorithm output" or always "tremor metric", not both interchangeably).
+- Never leave a section blank. If a section heading exists, it must contain content or be removed.
+
+# Terminology
+
+| Use | Instead of | Why |
+|---|---|---|
+| Kinematic tremor features | Tremor symptoms | The algorithm detects kinematic signals from accelerometer data, not clinical symptoms. |
+| Accelerometer-derived oscillatory signal | Tremor burden experienced by the patient | Distinguishes the technical signal from the patient experience. |
+| The algorithm output correlates with the reference standard | The algorithm captures the severity of tremor | Correlation framing avoids claiming the algorithm measures clinical severity directly. |
+| Technical proxy for clinician-rated scores | Clinically meaningful measurement | Construct validity language, not clinical efficacy language. |
+| The output shows a monotonic association with [scale] | The measurement reflects the functional burden | Statistical relationship, not clinical interpretation. |
+| Rhythmic oscillations within the target frequency band | Tremor as experienced during daily living | Frequency-domain technical description, not lived experience. |
+| The algorithm quantifies the proportion of time during which target kinematic features are detected | The algorithm measures how tremor affects the patient's activities of daily living | Reports a measurement, not an outcome. |
+
+# Framing: Describing correlation results
+
+**Wrong:**
+
+> The results showcase how tremor affects a patient's activities of daily living. This confirms the algorithm measures a symptom that is directly relevant to the patient's experience.
+
+**Correct:**
+
+> The algorithm's output demonstrates a statistically significant monotonic correlation (Spearman r = 0.399, p < 0.001) with clinician-rated UPDRS Part II Item 16 scores. This supports the construct validity of the accelerometer-derived tremor metric as a technical proxy for the reference standard.
+
+**Why:** the wrong version makes a clinical claim. The correct version reports a statistical relationship with a reference standard and frames it as construct validity of a technical measurement.
+
+# Framing: Describing figures
+
+**Wrong:**
+
+> This correlation validates that the algorithm's measurement is clinically meaningful and accurately reflects the functional burden experienced by the subject.
+
+**Correct:**
+
+> The progressive increase in algorithm-derived tremor percentage across higher reference standard scores supports a consistent monotonic relationship between the technical output and the clinician-rated scale.
+
+**Why:** the wrong version uses "clinically meaningful" and "functional burden" (clinical claims). The correct version describes the relationship between two numerical signals.
+
+# Document Type: risk-management
+
+ISO 14971 compliant risk management file.
+
+# Document Type: clinical-evaluation
+
+MEDDEV 2.7/1 rev 4 clinical evaluation report.
+
+# Document Type: design-history-file
+
+Design and development documentation per Annex II.
+
+# Document Type: software-documentation
+
+IEC 62304 software lifecycle documentation.
+
+# Document Type: post-market-surveillance
+
+Post-market surveillance per Article 83-86.
+
+# Document Type: technical-documentation
+
+Technical documentation per Annex II and III.
+
+# Document Type: design-validation-report
+
+Design Validation Report under the EU MDR CE Marking process. Demonstrates the design output meets the design inputs and the device performs its intended technical function against pre-defined reference standards.
+
+## Section: purpose-and-scope
+
+State the intended use in technical terms (e.g. detection and quantification of kinematic features from triaxial accelerometer data). Be explicit that this report covers design validation against pre-defined reference standards. Avoid clinical claims about patient outcomes.
+
+## Section: context
+
+Write as a technical literature review. Cite peer-reviewed precedent for the chosen modality and the rationale for treating it as a valid technical proxy. This section must never be left blank - if a Context heading exists, it must contain real content.
+
+## Section: referenced-documents
+
+Every referenced document must include document ID, title, version number, and the date of the referenced version. No bare references.
+
+## Section: execution-metadata
+
+State explicitly who executed the validation (name and role), when (date), and any prerequisites (preliminary testing, training, prior knowledge required).
+
+## Section: dataset-descriptions
+
+Describe each dataset with reproducibility in mind. The reader should be able to identify the dataset's source institution, ethics approval reference, GDPR compliance posture, demographic composition (N, sex split, age range, severity distribution, inclusion/exclusion criteria), recording environment, exact device specifications with datasheet links, data characteristics, independence from training data (with split percentage and method when applicable), and storage location within the QMS.
+
+## Section: methodology-explanations
+
+Every method or technique mentioned must be explained in enough detail for an independent reviewer to reproduce it. Define every technical term at first use or remove it. Examples of methods that always need a full explanation: cross-validation schemes (LOSO, k-fold), aggregate metrics (e.g. Mean Daily Tremor %) including bin size, wear-time determination, aggregation, thresholds, filters.
+
+## Section: test-equipment
+
+Specify both software environment (language version, library versions with numbers, algorithm version, git commit hash) and hardware environment (OS, CPU, RAM).
+
+## Section: sample-size-justification
+
+Be specific and quantitative. Give exact sample sizes per dataset and subgroup, the statistical power calculation (target power, expected effect size, alpha, formula or tool used), demographic breakdowns, and inclusion/exclusion criteria. Do not appeal vaguely to "established standards" - cite any standard by name and number.
+
+## Section: acceptance-criteria
+
+Every threshold must have a documented rationale. Cite where the cutoff comes from (literature, regulatory guidance, predicate device comparison). Explain why the specific value was chosen as the minimum acceptable level - not why the achieved result happens to be good.
+
+## Section: test-results
+
+Report numbers, statistical tests, and pass/fail per acceptance criterion. Avoid editorial language ("excellent", "highly effective", "clinically meaningful"). When perfect scores appear (e.g. Precision = 1.00), acknowledge the implication and discuss possible contributing factors such as small sample size or class separability. Keep figure captions descriptive, not interpretive - interpretation belongs in body text.
+
+## Section: conclusion
+
+State pass/fail per metric. Use "validated" only in the technical sense (output meets pre-defined acceptance criteria against specified reference standards). Do not claim "clinically validated" unless a separate clinical validation has been performed.
+
+# Submission Checklist
+
+- Context section is populated with literature references
+- All referenced documents have ID, version, and date
+- Execution metadata (who, when, prerequisites) is stated
+- Each dataset has full documentation (source, ethics, demographics, device specs, independence from training data, QMS location)
+- Hardware and software environments are fully specified
+- All methods explained in reproducible detail
+- Sample size justification includes actual numbers, power calculations, and demographic breakdowns
+- All acceptance criteria thresholds have documented, citable justifications
+- No clinical claims - all language is technical (kinematic, proxy, correlation with reference standard)
+- Perfect scores (1.00) are acknowledged and discussed
+- No undefined terms
+- No vague appeals to "established standards" - specific standards cited by name and number
+- All placeholder values (e.g. ICC = 0.XX) are replaced with actual results
+- Figure captions are descriptive, not interpretive
+- Conclusion says "design validated" not "clinically validated"

mneme/profiles/iso-13485.md

@@ -0,0 +1,182 @@
+---
+name: ISO 13485
+description: ISO 13485:2016 Quality Management System for Medical Devices
+version: 2.0
+tone: formal
+voice: passive-for-procedures
+citation_style: clause-reference
+placeholder_for_missing_refs: "[TO ADD REF]"
+trace_types:
+  - derived-from
+  - implemented-by
+  - detailed-in
+  - mitigated-by
+  - verified-by
+  - validated-by
+  - referenced-in
+  - supersedes
+requirement_levels:
+  shall: mandatory requirement
+  should: recommended
+  may: permitted
+vocabulary:
+  - use: medical device
+    reject: [product, unit, item]
+  - use: quality management system
+    reject: [QMS, quality system]
+  - use: management representative
+    reject: [quality manager, QA lead]
+  - use: documented procedure
+    reject: [SOP, work instruction, procedure]
+  - use: quality objective
+    reject: [quality goal, quality target]
+  - use: nonconformity
+    reject: [defect, bug, issue, problem]
+  - use: corrective action
+    reject: [fix, resolution, remedy]
+  - use: preventive action
+    reject: [prevention, proactive fix]
+  - use: design and development
+    reject: [R&D, engineering, development]
+  - use: purchasing
+    reject: [procurement, sourcing, buying]
+  - use: traceability
+    reject: [tracking, trace]
+  - use: customer complaint
+    reject: [feedback, issue report, bug report]
+  - use: advisory notice
+    reject: [recall notice, safety alert]
+---
+
+# Principles
+
+- Auditable: every claim must be traceable to a documented source - a procedure ID, a record, a controlled form, or a regulatory clause. An ISO 13485 auditor should be able to follow any statement in the document back to its evidence.
+- Procedural, not narrative: this is a quality system document. It describes what is done, by whom, and against what criteria. It does not tell a story.
+- Controlled: every referenced document must be a controlled document with an ID, version, and effective date. Uncontrolled references invalidate the chain.
+
+# General Rules
+
+- Use the controlled vocabulary. ISO 13485 uses specific terms ("nonconformity", "corrective action", "documented procedure", "management representative") with specific meanings - do not substitute synonyms.
+- Reference everything by ID and version. "See SOP-007 v3.2" is acceptable; "see the design control procedure" is not.
+- Define before you use. Every abbreviation, role, metric, and form must be defined at first use.
+- Distinguish "shall" (mandatory), "should" (recommended), and "may" (permitted). Reserve "shall" for actual ISO 13485 mandates.
+- Avoid editorial language. "The supplier was thoroughly evaluated" is unauditable; "The supplier was evaluated against SUP-EVAL-001 v2 with the result documented in record SR-2026-014" is auditable.
+- Never leave a section blank. If a clause requires content, the section must contain content or be removed.
+
+# Terminology
+
+| Use | Instead of | Why |
+|---|---|---|
+| Nonconformity | Defect, Bug, Issue, Problem | ISO 13485 defines "nonconformity" as the failure to meet a requirement. Use the controlled term. |
+| Corrective action | Fix, Resolution, Remedy | Corrective action specifically addresses the cause of a detected nonconformity (clause 8.5.2). |
+| Preventive action | Prevention, Proactive fix | Preventive action addresses potential nonconformities (clause 8.5.3) and is distinct from corrective action. |
+| Documented procedure | SOP, Work instruction | ISO 13485 uses "documented procedure" as the formal term. |
+
+# Framing: Describing a nonconformity
+
+**Wrong:**
+
+> We had an issue with the bonding step where some parts were defective and we fixed it.
+
+**Correct:**
+
+> Nonconformity NCR-2026-018 was raised against the bonding process on 2026-03-12. Root cause analysis (CAPA-2026-022) identified a deviation from BOND-WI-004 v2.1. Corrective action C-2026-022-01 was approved and implemented; effectiveness will be reviewed at the next batch release per CAPA-2026-022.
+
+**Why:** the correct version uses controlled vocabulary, references controlled documents by ID and version, and shows the audit trail. The wrong version is narrative and unauditable.
+
+# Document Type: quality-manual
+
+Quality manual per clause 4.2.2.
+
+## Section: scope
+
+Define the scope of the QMS clearly. State which products, processes, and sites are covered, and explicitly list any exclusions with justification per clause 1.2.
+
+## Section: quality-policy
+
+State the quality policy as approved by top management. Reference the controlling document by ID and version.
+
+## Section: qms-processes
+
+Describe the QMS processes, their sequence, and their interactions. Cross-reference the documented procedures by ID.
+
+# Document Type: management-review
+
+Management review per clause 5.6.
+
+## Section: review-input
+
+List every input topic required by clause 5.6.2 (audits, feedback, complaints, monitoring data, status of CAPA, follow-up from previous reviews, regulatory changes, recommendations for improvement).
+
+## Section: review-output
+
+Document decisions and actions per clause 5.6.3, with owners and target dates.
+
+# Document Type: design-control
+
+Design and development per clause 7.3.
+
+## Section: design-inputs
+
+Capture user needs, intended use, regulatory requirements, applicable standards, and risk management outputs. Each input must be testable and traceable.
+
+## Section: design-outputs
+
+Outputs must satisfy inputs, contain or reference acceptance criteria, identify essential characteristics for safe use, and be approved before release.
+
+## Section: design-verification
+
+Demonstrate that design outputs meet design input requirements. Reference the verification protocol by ID and version.
+
+## Section: design-validation
+
+Demonstrate that the device meets the user needs and intended use under defined operating conditions. Use production-equivalent units. Reference the validation protocol by ID and version.
+
+## Section: design-changes
+
+Every change must be reviewed, verified, validated as appropriate, and approved before implementation. Maintain the change log.
+
+# Document Type: risk-management
+
+Risk management per clause 7.1, aligned with ISO 14971.
+
+## Section: hazard-identification
+
+Identify hazards across the lifecycle. Include foreseeable misuse. Cross-reference the risk register by ID.
+
+## Section: risk-control
+
+Apply controls in the order required by ISO 14971: inherently safe design, protective measures, information for safety. Document residual risk for each.
+
+# Document Type: capa
+
+CAPA process per clauses 8.5.2 and 8.5.3.
+
+## Section: root-cause-analysis
+
+Use a structured technique (e.g. 5-Whys, fishbone, fault tree). State the technique used and its outcome - do not jump straight to corrective actions.
+
+## Section: effectiveness-review
+
+Define how effectiveness will be measured, the timeframe, and the acceptance criteria before closing the CAPA.
+
+# Document Type: supplier-management
+
+Purchasing and supplier control per clause 7.4.
+
+## Section: supplier-evaluation
+
+Document the evaluation criteria, the evaluation result, and the approval decision. Re-evaluate at defined intervals.
+
+## Section: incoming-inspection
+
+State the acceptance activities for purchased product. Records must show what was inspected and the disposition.
+
+# Submission Checklist
+
+- Every claim is supported by a controlled document reference (ID + version)
+- All controlled vocabulary terms are used correctly (nonconformity, corrective action, etc.)
+- Roles are named and traceable to job descriptions or organisational records
+- Every record referenced is identified by record ID
+- Sections corresponding to mandatory ISO 13485 clauses are populated, not left blank
+- Document is approved by the management representative before release

mneme/profiles/mappings/dds.json

@@ -0,0 +1,21 @@
+{
+  "name": "Design Specification Import",
+  "description": "Maps CSV rows to design-spec wiki pages. Links back to requirements and forward to tests.",
+  "page_type": "design-spec",
+  "id_column": "ID",
+  "title_column": "Title",
+  "detect_headers": ["design spec", "dds", "design detail", "module", "component"],
+  "mapping": {
+    "ID": "frontmatter.id",
+    "Title": "frontmatter.title",
+    "Description": "body.summary",
+    "Module": "body.module",
+    "Interface": "body.interface",
+    "Constraints": "body.constraints",
+    "Requirement": "traces.derived-from",
+    "Linked Requirement": "traces.derived-from",
+    "Test Case": "traces.verified-by",
+    "Verification": "traces.verified-by",
+    "Status": "frontmatter.tags"
+  }
+}

mneme/profiles/mappings/requirements.json

@@ -0,0 +1,22 @@
+{
+  "name": "Requirements Import",
+  "description": "Maps CSV rows to requirement wiki pages. Supports trace links to design specs and tests.",
+  "page_type": "requirement",
+  "id_column": "ID",
+  "title_column": "Title",
+  "detect_headers": ["requirement", "req-", "req id", "shall", "acceptance criteria"],
+  "mapping": {
+    "ID": "frontmatter.id",
+    "Title": "frontmatter.title",
+    "Description": "body.summary",
+    "Acceptance Criteria": "body.acceptance-criteria",
+    "Priority": "frontmatter.tags",
+    "Category": "frontmatter.tags",
+    "Source": "frontmatter.sources",
+    "Derived From": "traces.derived-from",
+    "Design Spec": "traces.detailed-in",
+    "Verification": "traces.verified-by",
+    "User Need": "traces.derived-from",
+    "Status": "frontmatter.tags"
+  }
+}

mneme/profiles/mappings/risk-register.json

@@ -0,0 +1,24 @@
+{
+  "name": "Risk Register Import",
+  "description": "Maps CSV rows to hazard wiki pages with severity, probability, and risk control measures.",
+  "page_type": "hazard",
+  "id_column": "ID",
+  "title_column": "Hazard",
+  "detect_headers": ["hazard", "severity", "probability", "risk level", "risk control", "harm"],
+  "mapping": {
+    "ID": "frontmatter.id",
+    "Hazard": "frontmatter.title",
+    "Harm": "body.harm",
+    "Hazardous Situation": "body.hazardous-situation",
+    "Severity": "body.severity",
+    "Probability": "body.probability",
+    "Risk Level": "body.risk-level",
+    "Risk Control": "body.risk-control",
+    "Residual Risk": "body.residual-risk",
+    "Mitigation": "traces.mitigated-by",
+    "RMA": "traces.mitigated-by",
+    "Linked Requirement": "traces.implemented-by",
+    "Verification": "traces.verified-by",
+    "Status": "frontmatter.tags"
+  }
+}

mneme/profiles/mappings/test-cases.json

@@ -0,0 +1,21 @@
+{
+  "name": "Test Cases Import",
+  "description": "Maps CSV rows to verification wiki pages. Links back to requirements and design specs.",
+  "page_type": "verification",
+  "id_column": "ID",
+  "title_column": "Title",
+  "detect_headers": ["test case", "test id", "expected result", "pass/fail", "test method", "verification"],
+  "mapping": {
+    "ID": "frontmatter.id",
+    "Title": "frontmatter.title",
+    "Description": "body.summary",
+    "Test Method": "body.test-method",
+    "Expected Result": "body.expected-result",
+    "Actual Result": "body.actual-result",
+    "Pass/Fail": "body.result",
+    "Requirement": "traces.derived-from",
+    "Design Spec": "traces.derived-from",
+    "DDS": "traces.derived-from",
+    "Status": "frontmatter.tags"
+  }
+}

mneme/profiles/mappings/user-needs.json

@@ -0,0 +1,19 @@
+{
+  "name": "User Needs Import",
+  "description": "Maps CSV rows to user-need wiki pages. Each row becomes one page.",
+  "page_type": "user-need",
+  "id_column": "ID",
+  "title_column": "Title",
+  "detect_headers": ["user need", "un-", "need id", "stakeholder need"],
+  "mapping": {
+    "ID": "frontmatter.id",
+    "Title": "frontmatter.title",
+    "Description": "body.summary",
+    "Priority": "frontmatter.tags",
+    "Source": "frontmatter.sources",
+    "Acceptance Criteria": "body.acceptance-criteria",
+    "Rationale": "body.rationale",
+    "Linked Requirement": "traces.implemented-by",
+    "Status": "frontmatter.tags"
+  }
+}