memo_core_common¶

SysML API


Public namespace	`memo::core::common`
Declared package	`memo_core_common`
Source	`src/core/common/memo_common.sysml`

Namespace hierarchy¶

memo → memo::core → memo::core::common

Packages¶

Package
`memo_core_common`

Imports¶

Visibility	Target
private	`ScalarValues::*`
private	`memo_core_dimensions::*`
private	`memo_core_terminology::*`
private	`memo_core_enumerations::*`

Declarations¶

Name	SysML kind	Description	Specializes
`MemoIdentity`	`metadata def`	Memo identity definition.	—
`MemoKind`	`metadata def`	Marks a definition as a KIND — an extension of the ontology — rather than a model element. A project definition that specializes an ontology kind is, structurally, either a new kind (`AfferaStakeholder`) or one particular thing (`HospitalEpRecordingSystem`); nothing in the Sys…	—
`MemoPart`	`part def`	Memo part definition.	—
`RequirementDriver`	`part def`	Requirement driver definition specializing `MemoPart`.	`MemoPart`
`VerifiableElement`	`part def`	Verifiable element definition specializing `MemoPart`.	`MemoPart`
`InterfaceElement`	`part def`	Interface element definition specializing `MemoPart`.	`MemoPart`
`EvidenceKind`	`enum def`	Controlled values for evidence: `testArtifact`.	—
`MemoEvidence`	`part def`	Memo evidence definition specializing `MemoPart`.	`MemoPart`
`AnalysisArtifact`	`part def`	Analysis artifact definition specializing `MemoPart`.	`MemoPart`
`MemoAction`	`action def`	Behavioral foundation: operational activities, tasks, system actions, and interaction steps specialize MemoAction.	—
`MemoConstrainedOccurrence`	`occurrence def`	An occurrence whose start is guarded by a precondition and whose end by a postcondition: it starts only once the precondition holds and is done only once the postcondition does.…	—
`MemoPort`	`port def`	Boundary feature foundation for typed ports.	—
`MemoInterface`	`interface def`	Interaction-contract foundation for interface definitions between ports.	—
`MemoItem`	`item def`	Single item foundation. Standards, hazards, stored software data, and message payloads are all item-native concepts. Whether an item is exchanged is expressed by its use in a port or flow, not by a second ontology root.	—
`MemoUseCase`	`use case def`	Memo use case definition.	—
`MemoConstraint`	`constraint def`	General constraint foundation. Executable consistency rules and reusable quantitative constraints are both native constraint defs.	—
`MemoRequirementElement`	`requirement def`	Memo requirement element definition.	—
`MemoNeed`	`requirement def`	Memo need definition specializing `MemoRequirementElement`.	`MemoRequirementElement`
`MemoRequirement`	`requirement def`	Memo requirement definition specializing `MemoRequirementElement`.	`MemoRequirementElement`
`MemoMission`	`requirement def`	Memo mission definition specializing `MemoRequirementElement`.	`MemoRequirementElement`
`MemoVerificationCase`	`verification def`	Memo verification case definition.	—
`StateKind`	`enum def`	Controlled values for state: `mode`.	—
`MemoState`	`state def`	Memo state definition.	—
`Citation`	`part def`	Citation definition specializing `MemoPart`.	`MemoPart`

MemoIdentity¶

metadata def MemoIdentity

Property	Value
Description	Memo identity definition.
Kind	`metadata def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

MemoKind¶

metadata def MemoKind

Property	Value
Description	Marks a definition as a KIND — an extension of the ontology — rather than a model element. A project definition that specializes an ontology kind is, structurally, either a new kind (`AfferaStakeholder`) or one particular thing (`HospitalEpRecordingSystem`); nothing in the Sys…
Kind	`metadata def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

MemoPart¶

abstract part def MemoPart

Property	Value
Description	Memo part definition.
Kind	`part def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

RequirementDriver¶

part def RequirementDriver specializes MemoPart

Property	Value
Description	Requirement driver definition specializing `MemoPart`.
Kind	`part def`
Abstract	No
Specializes	`MemoPart`
Owning package	`memo_core_common`

VerifiableElement¶

abstract part def VerifiableElement specializes MemoPart

Property	Value
Description	Verifiable element definition specializing `MemoPart`.
Kind	`part def`
Abstract	Yes
Specializes	`MemoPart`
Owning package	`memo_core_common`

InterfaceElement¶

part def InterfaceElement specializes MemoPart

Property	Value
Description	Interface element definition specializing `MemoPart`.
Kind	`part def`
Abstract	No
Specializes	`MemoPart`
Owning package	`memo_core_common`

EvidenceKind¶

enum def EvidenceKind

Property	Value
Description	Controlled values for evidence: `testArtifact`.
Kind	`enum def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

MemoEvidence¶

part def MemoEvidence specializes MemoPart

Property	Value
Description	Memo evidence definition specializing `MemoPart`.
Kind	`part def`
Abstract	No
Specializes	`MemoPart`
Owning package	`memo_core_common`

AnalysisArtifact¶

abstract part def AnalysisArtifact specializes MemoPart

Property	Value
Description	Analysis artifact definition specializing `MemoPart`.
Kind	`part def`
Abstract	Yes
Specializes	`MemoPart`
Owning package	`memo_core_common`

MemoAction¶

action def MemoAction

Property	Value
Description	Behavioral foundation: operational activities, tasks, system actions, and interaction steps specialize MemoAction.
Kind	`action def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

MemoConstrainedOccurrence¶

abstract occurrence def MemoConstrainedOccurrence

Property	Value
Description	An occurrence whose start is guarded by a precondition and whose end by a postcondition: it starts only once the precondition holds and is done only once the postcondition does.…
Kind	`occurrence def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

MemoPort¶

port def MemoPort

Property	Value
Description	Boundary feature foundation for typed ports.
Kind	`port def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

MemoInterface¶

abstract interface def MemoInterface

Property	Value
Description	Interaction-contract foundation for interface definitions between ports.
Kind	`interface def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

MemoItem¶

abstract item def MemoItem

Property	Value
Description	Single item foundation. Standards, hazards, stored software data, and message payloads are all item-native concepts. Whether an item is exchanged is expressed by its use in a port or flow, not by a second ontology root.
Kind	`item def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

MemoUseCase¶

abstract use case def MemoUseCase

Property	Value
Description	Memo use case definition.
Kind	`use case def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

MemoConstraint¶

abstract constraint def MemoConstraint

Property	Value
Description	General constraint foundation. Executable consistency rules and reusable quantitative constraints are both native constraint defs.
Kind	`constraint def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

MemoRequirementElement¶

abstract requirement def MemoRequirementElement

Property	Value
Description	Memo requirement element definition.
Kind	`requirement def`
Abstract	Yes
Specializes	—
Owning package	`memo_core_common`

MemoNeed¶

requirement def MemoNeed :> MemoRequirementElement

Property	Value
Description	Memo need definition specializing `MemoRequirementElement`.
Kind	`requirement def`
Abstract	No
Specializes	`MemoRequirementElement`
Owning package	`memo_core_common`

MemoRequirement¶

requirement def MemoRequirement :> MemoRequirementElement

Property	Value
Description	Memo requirement definition specializing `MemoRequirementElement`.
Kind	`requirement def`
Abstract	No
Specializes	`MemoRequirementElement`
Owning package	`memo_core_common`

MemoMission¶

abstract requirement def MemoMission :> MemoRequirementElement

Property	Value
Description	Memo mission definition specializing `MemoRequirementElement`.
Kind	`requirement def`
Abstract	Yes
Specializes	`MemoRequirementElement`
Owning package	`memo_core_common`

MemoVerificationCase¶

verification def MemoVerificationCase

Property	Value
Description	Memo verification case definition.
Kind	`verification def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

StateKind¶

enum def StateKind

Property	Value
Description	Controlled values for state: `mode`.
Kind	`enum def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

MemoState¶

state def MemoState

Property	Value
Description	Memo state definition.
Kind	`state def`
Abstract	No
Specializes	—
Owning package	`memo_core_common`

Citation¶

part def Citation specializes MemoPart

Property	Value
Description	Citation definition specializing `MemoPart`.
Kind	`part def`
Abstract	No
Specializes	`MemoPart`
Owning package	`memo_core_common`

Source¶

core/common/memo_common.sysml

// MEMO base hierarchy. Construct-specific foundations: one base per
// SysML v2 metaclass family (part, action, port, interface, item, use case,
// requirement, constraint, verification, state, connection), each carrying
// the shared MEMO semantics. Common inheritance across metaclasses is not
// portable, so classification is shared through the metadata defs in
// memo_core_dimensions rather than through a superclass.
//
// ─── Where identity lives ───────────────────────────────────────────────
// Not in these bases. `@MemoIdentity`, below, is the one carrier: a
// `metadata def` annotates an element of ANY metaclass, so it reaches the
// action, port, item, requirement and connection families that KerML will
// not let inherit from a part def. The bases used to re-declare an
// "identification core" ten times over for exactly that reason, and ten
// copies of one fact drifted every time (MemoPort carried no sourceReference
// and no status; MemoRequirement and MemoNeed each invented their own status
// attribute). One declaration replaced ten.
//
// `name` and `description` were the last two to go. Neither was ever MEMO's
// to declare: every SysML element already has a native name, and `doc` is
// already the native slot for prose. What the bases added was a second place
// to write the same fact, and 188 of the 1373 elements that set `name` set it
// to the identifier they were already declared under. Display text is now
// `@MemoIdentity { label }` and prose is `doc`.
//
// What remains on a base is domain semantics — `status`, and whatever that
// metaclass family genuinely needs.
//
// `uuid` is the stable technical identity: never displayed, never used as a
// label, never reused. Authors normally leave it unset and let the compiler
// derive it (memo-tools assigns a v5 UUID over file+kind+id); set it
// explicitly on an element whose file or id must be free to change without
// breaking external references to it, and the authored value wins.
package memo_core_common {
    private import ScalarValues::*;

    private import memo_core_dimensions::*;
    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 was once declared ten times
    // over. Metadata has no such limit, so one declaration replaced 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];
    }

    // Marks a definition as a KIND — an extension of the ontology — rather than a model element.
    // A project definition that specializes an ontology kind is, structurally, either a new kind
    // (`AfferaStakeholder`) or one particular thing (`HospitalEpRecordingSystem`); nothing in the
    // SysML tells the two apart, so the author says which. A marked definition, and what is typed
    // by it, takes `idPrefix` as the family of its display ids (`<idPrefix>-1`). Anything unmarked
    // takes the family of the ontology kind it descends from.
    metadata def MemoKind {
        attribute idPrefix : String;
    }

    // ─── Single abstract part root ──────────────────────────────────
    // Every structural MEMO concept specializes MemoPart. Identity and
    // traceability are attributes of this one root — MEMO has no separate
    // IdentifiedElement/TraceableElement classes, because *everything* is
    // identifiable and traceable by definition; that is not a type a modeler
    // picks. MemoPart is abstract: never instantiated, only specialized.
    //
    // Axis ownership (horizontal architecture layer vs. vertical assurance
    // discipline) is NOT an attribute — it is the element's owning package
    // (memo_architecture_* xor memo_assurance_*), enforced by CR-ONT-045.
    // The remaining dimensions are orthogonal to the axis: realization stage,
    // cross-cutting concern, and editorial status.
    // Deliberately NOT declared here: `name` and `description`. A name slot on
    // a MEMO base is a second spelling of the native name every SysML element
    // already has, and a description slot is a second spelling of `doc`. Both
    // were carried for years and both drifted: 1373 elements set `name`, and
    // 188 of them set it to the identifier they were already declared under.
    // The display label — free text, legitimately repeating — lives on
    // `@MemoIdentity { label }`, which annotates any metaclass and so reaches
    // the behaviours and views that cannot specialize a part. The long prose
    // lives in `doc`. `shortDescription` on `@MemoIdentity` remains the
    // one-line register a table cell or chip shows whole; it is a different
    // density, not a different authority.
    abstract part def MemoPart {
        // editorial status and lifecycle
        attribute status : ElementStatusKind;
        attribute lifecycleState : LifecycleStateKind;
        // orthogonal dimensions
        attribute realizationStage : RealizationStageKind[0..1];
        attribute crossCuttingConcerns : CrossCuttingConcernKind[0..*];
        attribute concerns : ConcernKind[0..*];
        attribute applicableStandards : ExternalReference[0..*];
        attribute codes : TerminologyCode[0..*];
        // The part's identity in the product structure, assigned by the user, not by MEMO. A revision is
        // alphabetic: A, B, … Z, AA.
        attribute partNumber : String[0..1];
        attribute revision : String[0..1];
    }

    // ─── Role bases retained from the original kernel, re-founded on
    //     MemoPart so all existing content inherits the dimensions. ───
    part def RequirementDriver specializes MemoPart;
    abstract part def VerifiableElement specializes MemoPart;
    part def InterfaceElement specializes MemoPart;
    enum def EvidenceKind { enum testArtifact; enum evidence; enum formativeEvaluation; enum usabilityValidation; enum securityClaim; }
    part def MemoEvidence specializes MemoPart {
        attribute evidenceKind : EvidenceKind;
        attribute version : String;
        attribute artifactKind : ArtifactKind[0..1];
        attribute resultSummary : String;
        attribute evidenceType : String;
        attribute integrityStatus : String;
        // Promoted from the retired `UsabilityValidation` and
        // `FormativeEvaluation` specializations. The collapse in `02083c5`
        // deleted both subclasses without carrying their fields up, so an
        // IEC 62366-1 evaluation record lost what it actually reports.
        // Promoted on the standard's terms, not on in-tree usage: MEMO is a
        // library, so what its own examples happen to set says nothing about
        // what an adopter's usability file needs.
        attribute participantProfile : String;
        attribute participantCount : Integer;
        attribute acceptanceCriteria : String;
        attribute evaluationMethod : String;
        attribute findingsSummary : String;
        attribute designChangesTriggered : String;
    }
    abstract part def AnalysisArtifact specializes MemoPart;

    // ─── Construct-specific foundations (non-part metaclasses) ───────

    // Behavioral foundation: operational activities, tasks, system actions,
    // and interaction steps specialize MemoAction.
    action def MemoAction {
        attribute status : ElementStatusKind;
    }

    // An occurrence whose start is guarded by a precondition and whose end by a postcondition: it
    // starts only once the precondition holds and is done only once the postcondition does. The
    // two are native `constraint` features a usage redefines with its own expression:
    //
    //     action fnDose : SystemFunction {
    //         in rate : Real;
    //         constraint :>> precondition { rate >= 0 }
    //     }
    //
    // The shape is the SYSMOD method's `ConstrainedOccurrence`. It is declared on an `occurrence def`
    // because `startShot` and `endShot` are found through one; `MemoFunction` specializes it.
    abstract occurrence def MemoConstrainedOccurrence {
        constraint precondition;
        constraint postcondition;
        ref occurrence :>> startShot { assert constraint :> precondition; }
        ref occurrence :>> endShot { assert constraint :> postcondition; }
    }

    // Boundary feature foundation for typed ports.
    port def MemoPort {
        attribute status : ElementStatusKind;
    }

    // Interaction-contract foundation for interface definitions between ports.
    abstract interface def MemoInterface {
        end source;
        end target;
    }

    // Single item foundation. Standards, hazards, stored software data, and
    // message payloads are all item-native concepts. Whether an item is
    // exchanged is expressed by its use in a port or flow, not by a second
    // ontology root.
    abstract item def MemoItem {
        attribute status : ElementStatusKind;
        // What the item CARRIES, as distinct from what it is called. Removed
        // by `595bfac` while modelling native wrappers; nothing replaced them,
        // and every exchange item in the examples went on setting them. A
        // measured value without its unit, its range, or its terminology code
        // is not a regulated data item — an IVD result is "5.5 mg/dL, LOINC
        // 2345-7", not "5.5".
        attribute semantics : String;
        attribute unit : String;
        attribute minValue : String;
        attribute maxValue : String;
        attribute encoding : String;
        attribute timestampRequired : Boolean;
        attribute codes : TerminologyCode[0..*];
    }

    // Use-case foundation. The domain UseCase adds its goal and actor
    // references; identity is `@MemoIdentity`, as everywhere else.
    abstract use case def MemoUseCase {
        attribute status : ElementStatusKind;
    }

    // General constraint foundation. Executable consistency rules and
    // reusable quantitative constraints are both native constraint defs.
    abstract constraint def MemoConstraint {
        attribute status : ElementStatusKind;
    }

    // Requirement-family foundations. MemoNeed captures a problem-space
    // expectation in stakeholder language; MemoRequirement a testable
    // solution-space obligation.
    // Shared base of the requirement family. It exists so a relation end can
    // 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 status : ElementStatusKind;
        attribute statement : String;
    }

    requirement def MemoNeed :> MemoRequirementElement {
        attribute needSource : String;
        attribute priority : String;
    }

    requirement def MemoRequirement :> MemoRequirementElement {
        attribute acceptanceCriteria : String;
    }

    // Top-level goal a system or operation exists to fulfil, with its success
    // criteria and context. Domain layers specialize it; the medical-device
    // intended use (memo_architecture_operational_structure::IntendedUse) is a
    // MemoMission. It is a `requirement def` because a mission is the top
    // obligation everything below it derives from, not a structural thing —
    // it was a `part def` under MemoPart. The prose a document renders is
    // `doc`, and the one-line register a table cell shows is
    // `@MemoIdentity`'s `shortDescription`.
    abstract requirement def MemoMission :> MemoRequirementElement {
        attribute missionKind : String;
        attribute successCriteria : String;
        attribute operationalContext : String;
    }

    // Verification-case foundation. A SysML v2 verification case is a behaviour
    // (it checks requirements), and KerML forbids a behaviour from specializing
    // the part-based MemoPart — so, like MemoAction, it stands on its own and
    // takes its identity from `@MemoIdentity`.
    verification def MemoVerificationCase {
        attribute status : ElementStatusKind;
    }

    // State foundation. SysML v2 states (state machines and their mode states)
    // are behaviours, so — like MemoAction and MemoVerificationCase — they
    // cannot specialize MemoPart and are annotated instead.
    // Transitions stay part-based to keep their traceable safety
    // attributes (id, sourceReference, priority, sameStepCritical).
    enum def StateKind { enum mode; enum logical; }

    state def MemoState {
        attribute stateKind : StateKind;
        attribute status : ElementStatusKind;
        attribute modeKind : String;
        attribute entryCondition : String;
        attribute exitCondition : String;
        attribute modePurpose : String;
    }

    part def Citation specializes MemoPart {
        attribute source : String;
        attribute section : String;
        attribute uri : String;
        attribute year : String;
    }
}