@memoarchitect/ontology 0.8.24 → 0.11.0

package/src/artifacts/standards/iso_iec_ieee_42010.sysml

@@ -12,8 +12,10 @@ package memo_artifacts_standards_iso_iec_ieee_42010 {
     private import memo_core_relationships::*;
     private import memo_artifacts_standards_traceability::*;
 
+    private import memo_core_common::*;
+    private import memo_core_common::MemoIdentity;
     item isoIecIeee42010 : RegulatoryStandard {
-        attribute :>> id = "STD-ISO-IEC-IEEE-42010";
+        @MemoIdentity { :>> providedId = "STD-ISO-IEC-IEEE-42010"; }
         attribute :>> name = "ISOIECIEEE42010";
         attribute :>> designation = "ISO/IEC/IEEE 42010:2022";
         attribute :>> edition = "2022";
@@ -22,21 +24,19 @@ package memo_artifacts_standards_iso_iec_ieee_42010 {
         // reference standard, cited by documents rather than required by a
         // market. Empty is the authored value, not an omission — see
         // appliesToRegime in memo_artifacts_standards_traceability.
+        item isoIecIeee42010Clause5 : StandardClause {
+            @MemoIdentity { :>> providedId = "STD-ISO-IEC-IEEE-42010-5"; }
+            attribute :>> name = "ISOIECIEEE42010Clause5";
+            attribute :>> clauseNumber = "5";
+            attribute :>> normativeStrength = "shall";
+        }
+        item isoIecIeee42010Clause6 : StandardClause {
+            @MemoIdentity { :>> providedId = "STD-ISO-IEC-IEEE-42010-6"; }
+            attribute :>> name = "ISOIECIEEE42010Clause6";
+            attribute :>> clauseNumber = "6";
+            attribute :>> normativeStrength = "shall";
+        }
     }
 
-    item isoIecIeee42010Clause5 : StandardClause {
-        attribute :>> id = "STD-ISO-IEC-IEEE-42010-5";
-        attribute :>> name = "ISOIECIEEE42010Clause5";
-        attribute :>> clauseNumber = "5";
-        attribute :>> normativeStrength = "shall";
-    }
-    item isoIecIeee42010Clause6 : StandardClause {
-        attribute :>> id = "STD-ISO-IEC-IEEE-42010-6";
-        attribute :>> name = "ISOIECIEEE42010Clause6";
-        attribute :>> clauseNumber = "6";
-        attribute :>> normativeStrength = "shall";
-    }
 
-    connection isoIecIeee42010Has5 : Composes connect parent ::> isoIecIeee42010 to child ::> isoIecIeee42010Clause5;
-    connection isoIecIeee42010Has6 : Composes connect parent ::> isoIecIeee42010 to child ::> isoIecIeee42010Clause6;
 }

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

@@ -16,7 +16,7 @@ required_for: ["CE", "FDA_510k", "MDR"]
 
 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.
+Hardware requirements are identified by the model's `requirementType` 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.
 
 ---
 
@@ -26,7 +26,7 @@ Summary metrics for the hardware requirements captured in the model:
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::hardware"
+where: requirementType == "RequirementTypeKind::hardware"
 display: count
 label: Total hardware requirements
 ```
@@ -35,11 +35,11 @@ label: Total hardware requirements
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::hardware"
+where: requirementType == "RequirementTypeKind::hardware"
 display: table
-columns: name, requirementKind, electricalSafetyRelevant, doc
+columns: name, requirementType, electricalSafetyRelevant, doc
 sort: name
-empty: "No hardware requirements defined. Add Requirement elements with requirementKind = hardware."
+empty: "No hardware requirements defined. Add Requirement elements with requirementType = hardware."
 ```
 
 ---
@@ -142,7 +142,7 @@ Hardware requirements traced to the elements that satisfy them:
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::hardware"
+where: requirementType == "RequirementTypeKind::hardware"
 traverse: outgoing satisfiedBy
 display: table
 columns: name, kind, layer, doc

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

@@ -16,7 +16,7 @@ required_for: ["CE", "FDA_510k", "MDR"]
 
 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`.
+Software, hardware and system requirements are distinguished by the model's own `requirementType` 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`.
 
 ---
 
@@ -26,14 +26,14 @@ Summary metrics for the requirements captured in the model:
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::software"
+where: requirementType == "RequirementTypeKind::software"
 display: count
 label: Total software requirements
 ```
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::system"
+where: requirementType == "RequirementTypeKind::system"
 display: count
 label: System requirements
 ```
@@ -48,7 +48,7 @@ Requirements carrying a `shall` obligation — the binding ones:
 kind: Requirement
 where: obligation == "ObligationKind::shall"
 display: table
-columns: name, requirementKind, safetyClass, doc
+columns: name, requirementType, safetyClass, doc
 sort: name
 empty: "No requirements carry a `shall` obligation. Set `obligation` on Requirement elements."
 ```
@@ -57,11 +57,11 @@ empty: "No requirements carry a `shall` obligation. Set `obligation` on Requirem
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::software"
+where: requirementType == "RequirementTypeKind::software"
 display: table
-columns: name, requirementKind, safetyClass, doc
+columns: name, requirementType, safetyClass, doc
 sort: name
-empty: "No software requirements defined. Add Requirement elements with requirementKind = software."
+empty: "No software requirements defined. Add Requirement elements with requirementType = software."
 ```
 
 ---
@@ -97,9 +97,9 @@ System requirements allocated to software per IEC 62304 §5.2, drawn from the mo
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::system"
+where: requirementType == "RequirementTypeKind::system"
 display: table
-columns: name, requirementKind, safetyClass, doc
+columns: name, requirementType, safetyClass, doc
 sort: name
 empty: "No system requirements defined."
 ```
@@ -155,7 +155,7 @@ empty: "No SOUP identified. Add DependsOnSoup links from software items to the S
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::software"
+where: requirementType == "RequirementTypeKind::software"
 traverse: outgoing verifiedBy
 display: table
 columns: name, kind, layer, doc

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

@@ -26,7 +26,7 @@ Summary metrics for the system requirements captured in the model:
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::system"
+where: requirementType == "RequirementTypeKind::system"
 display: count
 label: Total system requirements
 ```
@@ -41,7 +41,7 @@ Binding system requirements — those carrying a `shall` obligation:
 kind: Requirement
 where: obligation == "ObligationKind::shall"
 display: table
-columns: name, requirementKind, doc
+columns: name, requirementType, doc
 sort: name
 empty: "No requirements carry a `shall` obligation. Set `obligation` on Requirement elements."
 ```
@@ -50,11 +50,11 @@ empty: "No requirements carry a `shall` obligation. Set `obligation` on Requirem
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::system"
+where: requirementType == "RequirementTypeKind::system"
 display: table
-columns: name, requirementKind, safetyClass, doc
+columns: name, requirementType, safetyClass, doc
 sort: name
-empty: "No system requirements defined. Add Requirement elements with requirementKind = system."
+empty: "No system requirements defined. Add Requirement elements with requirementType = system."
 ```
 
 ---
@@ -67,7 +67,7 @@ How system requirements are allocated down to hardware and software.
 
 ```memo-query
 kind: Requirement
-where: requirementKind == "RequirementKind::system"
+where: requirementType == "RequirementTypeKind::system"
 traverse: outgoing satisfiedBy
 display: table
 columns: name, kind, layer, doc

package/src/assurance/cybersecurity/memo_cybersecurity.sysml

@@ -53,7 +53,6 @@ package memo_assurance_cybersecurity {
         attribute safetyImpact : String;
         attribute privacyImpact : String;
         attribute operationalImpact : String;
-        attribute linkedSafetyHazardId : String;
     }
 
     part def CyberRisk specializes Risk {

package/src/assurance/human_factors/memo_human_factors.sysml

@@ -15,7 +15,6 @@ package memo_assurance_human_factors {
 
     part def UseError specializes MemoPart {
         attribute errorCategory : UseErrorCategoryKind;
-        attribute taskReference : String;
         attribute severity : SeverityKind;
         attribute rootCauseType : String;
     }

package/src/assurance/requirements/memo_requirements.sysml

@@ -7,25 +7,32 @@ package memo_assurance_requirements {
     private import memo_assurance_requirements_needs::*;
     part def RiskDriver specializes RequirementDriver { attribute driverKind : String; }
 
-    // The kind of requirement. Was a subclass branch (SystemRequirement /
-    // SoftwareRequirement / HardwareRequirement) plus a parallel design-control
-    // specification hierarchy (DesignControlSpecification / System- / Software- /
-    // HardwareSpecification); now one attribute. The role-specific attributes
-    // below are all optional so a requirement carries only the ones its kind
-    // needs. IEC 62304 / design-control classification is preserved as the
-    // enum value, not lost.
-    enum def RequirementKind {
+    // What a requirement is about: the system, the software, the hardware, or
+    // the instructions for use. One axis, and the members are its values.
+    //
+    // It carried a second axis until now. `systemSpecification`,
+    // `softwareSpecification`, `hardwareSpecification` and `designControl` are
+    // the design-control ROLE — input versus output, 21 CFR 820.30(c)/(d) and
+    // ISO 13485 §7.3.3/§7.3.4 — multiplied into the subject. A requirement then
+    // could not say "software" without also committing to a role, the grid was
+    // incomplete by construction (there is no `ifuSpecification`, and there
+    // would have to be one for every future pairing), and nothing ever used the
+    // four: 250 requirements across the examples say system, software or
+    // hardware. A role, if a project needs one, is its own attribute.
+    //
+    // The instructions for use are neither hardware nor software: the device
+    // satisfies such a requirement with words rather than with a part or a
+    // module, and it is verified by reviewing the IFU rather than by testing a
+    // build (EU MDR Annex I §23.4, ISO 20417, IEC 62366-1 §7.2).
+    enum def RequirementTypeKind {
         enum system;
         enum software;
         enum hardware;
-        enum systemSpecification;
-        enum softwareSpecification;
-        enum hardwareSpecification;
-        enum designControl;
+        enum ifu;
     }
 
     requirement def Requirement specializes MemoRequirement {
-        attribute requirementKind : RequirementKind;
+        attribute requirementType : RequirementTypeKind;
         attribute :>> statement : String;
         attribute sourceKind : RequirementSourceKind;
         attribute concernKind : ConcernKind;
@@ -53,9 +60,6 @@ package memo_assurance_requirements {
         // design-control specification (ISO 13485 design output)
         attribute specificationDomain : String;
         attribute sourceFolder : String;
-        attribute linkedUserNeeds : String;
-        attribute linkedRisks : String;
-        attribute linkedTests : String;
     }
     // Named constant defined by a source requirements document (e.g. CriSys
     // GPCA App. A.4) and referenced from requirement statements.

package/src/assurance/requirements/needs/memo_needs.sysml

@@ -6,8 +6,15 @@
 package memo_assurance_requirements_needs {
     private import ScalarValues::*;
 
+    private import Metaobjects::SemanticMetadata;
+
     private import memo_core_common::*;
     private import memo_core_enumerations::*;
+    private import memo_core_relationships::*;
+    // A need is held by someone and arises in a context, and both are modelled
+    // elements. Assurance may depend on architecture; the reverse may not.
+    private import memo_architecture_operational_context_actors::*;
+    private import memo_architecture_operational_context_use_context::*;
 
     // The kind of need. Was a subclass branch (StakeholderNeed / UserNeed /
     // ClinicalUserNeed / PatientUserNeed / BusinessNeed / ServiceNeed /
@@ -29,15 +36,36 @@ package memo_assurance_requirements_needs {
 
     requirement def Need specializes MemoNeed {
         attribute needKind : NeedKind;
-        // user need (IEC 62366-1)
-        attribute userPopulationReference : String;
+        // A user need (IEC 62366-1) says WHOSE need it is with HeldBy, and the
+        // user's characteristics live on the User: `userPopulation`,
+        // `impairmentConsiderations`, `intendedTraining`, `intendedQualification`.
+        // A `userPopulationReference` string stood here and held prose — "ward
+        // nurses, including those wearing corrective lenses" — which is two
+        // typed attributes of a user profile written as one sentence nothing
+        // could read, on the wrong element.
         // regulatory need
         attribute jurisdiction : String;
         attribute regulationReference : String;
-        // operational need
-        attribute operationalContextReference : String;
+        // The context an operational need arises in. Typed, because UseContext
+        // carries the care setting, environment and jurisdiction that an
+        // `operationalContextReference` string could only describe.
+        ref useContext : UseContext[0..1];
         // design-control need (ISO 13485 design input)
         attribute sourceFolder : String;
-        attribute linkedDesignControls : String;
+    }
+
+    // Whose need this is. The holder is a modelled participant — a User, with
+    // the profile IEC 62366-1 asks for, or another operational participant —
+    // so "which users does this need serve" is a question the model answers
+    // rather than a sentence a reader interprets.
+    connection def HeldBy :> MemoRelationship {
+        end need : MemoNeed :>> source;
+        end holder : OperationalParticipant :>> target;
+    }
+    abstract connection heldByLinks : HeldBy[*];
+    metadata def <heldBy> HeldByMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = heldByLinks meta SysML::Usage;
     }
 }

package/src/assurance/safety_risk/memo_risk.sysml

@@ -6,6 +6,9 @@ package memo_assurance_safety_risk {
     private import memo_core_common::*;
     private import memo_core_enumerations::*;
     private import memo_assurance_requirements::*;
+    // For HazardRelatedScenario below. Assurance may depend on architecture;
+    // the reverse is what the string on the scenario was avoiding.
+    private import memo_architecture_operational_scenarios::*;
 
     // ISO 14971 / IEC 62366-1 risk-analysis input. A model element so hazards,
     // scenarios, requirements, and DHF records can trace to the foreseeable
@@ -135,6 +138,23 @@ package memo_assurance_safety_risk {
         :> annotatedElement : SysML::ConnectionUsage;
         :>> baseType = tracesRiskLinks meta SysML::Usage;
     }
+    // IEC 62366-1 3.9's hazard-related use scenario: the scenario a hazard can
+    // arise in. It is declared HERE rather than as a `hazardReference` string
+    // on the scenario, which is what stood in for it: a string names nothing a
+    // consumer can follow, and the layering is why it was written that way —
+    // assurance may depend on architecture, and the scenario package cannot
+    // see `Hazard`. On this side both ends are visible and the dependency runs
+    // the direction it already runs.
+    connection def HazardRelatedScenario :> MemoRelationship {
+        end hazard : RiskItem :>> source;
+        end scenario : OperativeScenario :>> target;
+    }
+    abstract connection hazardRelatedScenarioLinks : HazardRelatedScenario[*];
+    metadata def <hazardRelatedScenario> HazardRelatedScenarioMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = hazardRelatedScenarioLinks meta SysML::Usage;
+    }
     connection def AssessedAgainst :> MemoRelationship {
         end risk : Risk :>> source;
         end riskMatrix : RiskMatrix :>> target;

package/src/assurance/verification_validation/memo_assurance.sysml

@@ -19,8 +19,10 @@ package memo_assurance_verification_validation {
     // EXECUTION state, not an editorial one; execution state belongs in an
     // attribute of its own (see RiskControlMeasure.verificationStatus), not in
     // a second spelling of `status`.
-    verification def VerificationCase :> MemoVerificationCase {
-        attribute methodKind : VerificationMethodKind;
+    // Specializes the standard library verification case as well as MEMO's
+    // base, rather than shadowing it — see the note on UseCase.
+    verification def VerificationCase :> MemoVerificationCase, VerificationCases::VerificationCase {
+        attribute methodKind : MemoVerificationMethodKind;
         attribute acceptanceCriteria : String;
     }
     verification def ValidationCase :> MemoVerificationCase {
@@ -32,14 +34,7 @@ package memo_assurance_verification_validation {
     // Operational validation confirms the user's goal is achieved in the
     // use environment (§5): ValidationCase validates a UseCase.
     // Safety-critical functions must trace to verification (rules/coverage).
-    connection def ExecutesScenario :> MemoRelationship {
-        end verificationCase : VerificationCase :>> source;
-        end scenario : OperativeScenario :>> target;
-    }
-    abstract connection executesScenarioLinks : ExecutesScenario[*];
-    metadata def <executesScenario> ExecutesScenarioMetadata :> SemanticMetadata {
-        :> annotatedElement : SysML::ConnectionDefinition;
-        :> annotatedElement : SysML::ConnectionUsage;
-        :>> baseType = executesScenarioLinks meta SysML::Usage;
-    }
+    // `ExecutesScenario` is native `perform` (2026-08-18): OperativeScenario
+    // is an `action def`, so write `perform <scenario>;` inside the
+    // verification case, as `InvolvesFunction` already does.
 }

package/src/core/common/memo_common.sysml

@@ -34,6 +34,56 @@ package memo_core_common {
     private import memo_core_terminology::*;
     private import memo_core_enumerations::*;
 
+    // The metaclass-agnostic carrier for MEMO's identity fields.
+    //
+    // A `metadata def` annotates an element of ANY metaclass — restriction is
+    // opt-in through `annotatedElement`, and this one declares none. That is
+    // what the per-metaclass base definitions below cannot do: KerML will not
+    // let an action, port, item, requirement or connection inherit from a part
+    // def, which is why the identification core is currently declared ten
+    // times. Metadata has no such limit, so one declaration replaces ten.
+    //
+    // An element has five identities and they are not interchangeable:
+    //
+    //   1. code reference   `sfnAcquireMap`        native declaredName
+    //   2. display label    "Acquire EA Map"       `label`, below
+    //   3. number id        `SFN-1`                assigned, never authored
+    //   4. provided id      `SPEC-4471`            `providedId`, below
+    //   5. technical uuid   `e2f75cf6-…`           `uuid`, below
+    //
+    // 1 is native and needs no field here. 3 is generated by the compiler and
+    // recorded in `memo.identity.yaml`: it is monotonic, gaps are kept, and a
+    // retired number is never reused, so nothing authors it by hand.
+    //
+    // `label` is NOT a duplicate of the native name, which is the reading that
+    // nearly deleted it: the native name is a lowerCamelCase identifier and
+    // must be unique in its namespace, while a label is free text that
+    // legitimately repeats — measured 2026-08-18, 1278 labels across the
+    // ontology and examples share only 1216 distinct values, because seven
+    // different ports are all correctly labelled "TLM_MODE_IN". A label
+    // therefore cannot live in a name slot, native or otherwise.
+    //
+    // `providedId` is the identifier an EXTERNAL system knows the element by,
+    // and it exists because that system's scheme is not MEMO's: a customer
+    // numbering software requirements `SPEC-4471` cannot be made to use `SWR-`,
+    // and overwriting the generated number to please them would break the
+    // guarantee that numbers are never reassigned.
+    //
+    // `uuid` is machine identity. Authored values win over the registry, which
+    // wins over derivation — so an element whose file must move can pin its own
+    // uuid, which is what the attribute always advertised.
+    //
+    // Deliberately absent: `name` and `description` (native name and `doc`),
+    // `rationale` (standard `@Rationale`), and `id` — superseded by the
+    // generated number id and by `providedId`.
+    metadata def MemoIdentity {
+        attribute label : String[0..1];
+        attribute providedId : String[0..1];
+        attribute uuid : String[0..1];
+        attribute shortDescription : String[0..1];
+        attribute sourceReference : String[0..1];
+    }
+
     // ─── Single abstract part root ──────────────────────────────────
     // Every structural MEMO concept specializes MemoPart. Identity and
     // traceability are attributes of this one root — MEMO has no separate
@@ -48,8 +98,6 @@ package memo_core_common {
     // cross-cutting concern, and editorial status.
     abstract part def MemoPart {
         // identity
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
         // Two description registers on every MEMO element, because views have
         // two densities. `shortDescription` is the one-line form a table cell,
@@ -58,11 +106,8 @@ package memo_core_common {
         // renders. A view picks the register that fits — it never truncates
         // the long one, because a silently clipped sentence in a DHF table is
         // a defect, not a layout choice.
-        attribute shortDescription : String;
         attribute description : String;
         // traceability
-        attribute rationale : String;
-        attribute sourceReference : String;
         // editorial status and lifecycle
         attribute status : ElementStatusKind;
         attribute lifecycleState : LifecycleStateKind;
@@ -123,25 +168,15 @@ package memo_core_common {
     // Behavioral foundation: operational activities, tasks, system actions,
     // and interaction steps specialize MemoAction.
     action def MemoAction {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
     }
 
     // Boundary feature foundation for typed ports.
     port def MemoPort {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
     }
 
@@ -149,13 +184,8 @@ package memo_core_common {
     abstract interface def MemoInterface {
         end source;
         end target;
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
     }
 
     // Single item foundation. Standards, hazards, stored software data, and
@@ -163,13 +193,8 @@ package memo_core_common {
     // exchanged is expressed by its use in a port or flow, not by a second
     // ontology root.
     abstract item def MemoItem {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
         // What the item CARRIES, as distinct from what it is called. Removed
         // by `595bfac` while modelling native wrappers; nothing replaced them,
@@ -190,26 +215,16 @@ package memo_core_common {
     // references; identity is carried here so use cases do not maintain a
     // partial hand-written copy of the MEMO identification core.
     abstract use case def MemoUseCase {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
     }
 
     // General constraint foundation. Executable consistency rules and
     // reusable quantitative constraints are both native constraint defs.
     abstract constraint def MemoConstraint {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
     }
 
@@ -220,13 +235,8 @@ package memo_core_common {
     // say "a need or a requirement" with one type name — before it, every end
     // that had to accept both was left untyped.
     abstract requirement def MemoRequirementElement {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
         attribute statement : String;
     }
@@ -245,13 +255,8 @@ package memo_core_common {
     // the part-based MemoPart — so, like MemoAction, it re-declares the small
     // identification core rather than inheriting it.
     verification def MemoVerificationCase {
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
     }
 
@@ -264,13 +269,8 @@ package memo_core_common {
 
     state def MemoState {
         attribute stateKind : StateKind;
-        attribute id : String;
-        attribute uuid : String;
         attribute name : String;
-        attribute shortDescription : String;
         attribute description : String;
-        attribute rationale : String;
-        attribute sourceReference : String;
         attribute status : ElementStatusKind;
         attribute modeKind : String;
         attribute entryCondition : String;

package/src/core/enumerations/memo_enumerations.sysml

@@ -142,7 +142,7 @@ package memo_core_enumerations {
         enum maintenance;
         enum obsolete;
     }
-    enum def VerificationMethodKind {
+    enum def MemoVerificationMethodKind {
         enum inspection;
         enum analytical;
         enum demonstration;