SysML v2 language inventory and research findings

Purpose and evidence

Research date: 2026-10-20. This note inventories language entities, relationships, properties, constraints and behavior. It does not establish implementation support or conformance.

The user-provided NotebookLM notebook is titled SysML 2.0 Language Specification. nlm notebook get reported one source, ID c83ee3d3-22d7-4c7c-97f5-196a6fe0c27d, titled with the official OMG Language PDF URL. The retrieved source identifies SysML 2.0, Part 1, formal/2026-03-02, March 2026.

Seven notebook queries covered scope, structure, behavior, requirements/cases/views, shared properties, coverage and disputed details. Answers were reviewed alongside the source text fetched through nlm source content. Generated answers are research leads; the specification clauses take precedence. Some answers contained incorrect section numbers, inheritance labels and ownership explanations. Those mistakes are not accepted as facts here.

The companion language inventory JSON records:

• 98 named subsection entries in §§8.3.6–8.3.27: 93 metaclasses and 5 enumerations.
• 218 extracted declared property signatures, preserving types, multiplicities, slash notation and qualifiers as present on matching source lines.
• 365 named constraints, plus general classes and per-entry section references.
• Source metadata and content hash, notebook query topics, conversation IDs, question/answer hashes and coverage limitations.

These counts describe this extraction, not the entire SysML/KerML metamodel. It does not expand inherited properties, operation definitions, complete OCL bodies, every grammar rule or every library member. A missing extracted property does not establish that a metaclass lacks that property. Full implementation requires checking the official machine-readable metamodel and referenced KerML specification.

Specification layers

The specification describes language meaning. It does not prescribe our palette, storage engine, undo stack or layout algorithm. Proposed engineering choices below must remain distinguishable from language requirements.

Entity and relationship inventory

The following list is generated from dedicated subsection headings in the notebook source. Foundation concepts preceding §8.3.6 are recorded separately below. Each row links back to the OMG source; exact subsection IDs and declarations are in the JSON.

Foundations inherited or referenced from KerML

These must be part of the implementation coverage checklist even though they do not have dedicated class-detail entries in the extracted §§8.3.6–8.3.27 index. The Language PDF discusses foundations in §§8.3.2–8.3.5 and uses additional KerML classes throughout its grammar, generalizations and constraints. Exact inherited declarations need verification against KerML.

Distinguish grammar productions, library definitions and metaclasses. A relationship is itself a model element; its graphical representation does not replace its semantic structure.

The most important semantic distinctions

Ownership, featuring, composition and diagram nesting

These are four different mechanisms:

1. Owning membership owns a declaration in a namespace/model structure.
2. Feature membership establishes a feature of a type/context.
3. Composite feature semantics concerns dependence of modeled instances; Usage::isReference is derived from the complement of isComposite.
4. Diagram nesting is a presentation choice that can show ownership, features, imports or grouping according to the selected notation/view.

For example, a ref part declaration can be owned in the source model while its referenced instances are non-composite. A definition nested in another definition creates a scoped declaration; that does not itself create an owned part instance. See §§7.5–7.6, 8.3.6.2–8.3.6.4.

Definitions, usages and occurrences

A definition is a classifier; a usage is a feature in context. Do not represent them as one node type with a decorative label. Keep explicit typing/specialization references and preserve multiple usages of the same definition. Do not equate a usage declaration with a single runtime instance. See §8.3.6 and the type-specific families.

Ports, connections, interfaces, bindings and flows

These are separate semantic kinds. Record feature paths, end features, port typing and conjugation. A connection can require a presentation richer than one binary line. Bindings assert equality; successions express temporal ordering; flows model transfers. See §§8.3.12–8.3.16 and their corresponding semantics.

Port feature direction, flow direction, connection-end ordering and graphical arrow direction must remain separate fields/concepts.

Requirements and verification

SatisfyRequirementUsage is a usage with requirement/constraint semantics, not simply a colored edge. RequirementVerificationMembership is a specialized membership associated with verified requirements. A link to evidence and an executed verification result are different concepts. See §§8.3.21, 8.3.24, 8.4.17 and 8.4.20.

Metamodel properties, modeled attributes and notation

A leading slash in §8.3 declarations indicates derivation. This is distinct from a modeler's derived feature modifier. Stored, inherited, derived and implied information must be distinguishable in inventory records. See §8.3.1 and §8.3.6.

Property and relationship coverage checklist

The JSON retains declaration signatures rather than inventing a flattened database schema. Examples directly extracted from the source:

For every supported kind, inspect applicable inherited properties too: identity, names, visibility, owning relationships, typing, abstractness, direction, multiplicity bounds, ordering, uniqueness, composition/reference, specialization, value expressions, initial/default values, variation and temporal portions. Applicability and defaults depend on kind/context; do not expose every modifier on every element or assume a universal default multiplicity.

A relationship record needs more than source/target strings: preserve its own ID/kind, role-specific references, owning context, explicit/implied status and constraints. The renderer may choose a simpler edge representation without discarding the semantic record.

Behavioral coverage and runtime boundary

All families below belong in the language inventory.

Behavioral declarations, semantic validity, expression evaluation and execution semantics are separate inventory dimensions. Detailed behavior comes from §8.4 and model libraries, including referenced KerML foundations; this inventory records their scope without implementing an execution engine.

Views, variability, metadata and libraries

Views/viewpoints/renderings/exposure/filtering are model concepts (§8.3.26), distinct from arbitrary diagram presentation. Metadata definitions/usages (§8.3.27) and semantic extensions differ from untyped custom properties. Variation points and VariantMembership (§8.3.6) must not be treated as simultaneous owned features.

Library coverage must remain a separate workstream from metaclass enumeration:

These are coverage pointers, not an enumeration of every library element. Library symbols such as a verdict enumeration must not be mistaken for new §8.3 metaclasses. A library-aware parser/resolver is required before accurate inherited-feature and typing displays can be promised.

Source discrepancies and generated-answer corrections

These findings demonstrate why notebook answers cannot substitute for an official metamodel and clause-by-clause validation. No erratum was filed and no standard interpretation is claimed as approved.

Acceptance cases and open coverage

Use these examples to audit inventory coverage:

1. Inherited and redefined features remain distinguishable from directly declared ones.
2. Multiplicity, units, expressions and default/initial values survive inspection without flattening their meaning.
3. A conjugated port retains its typing and direction semantics.
4. A branching/concurrent action model displays control kinds without claiming simulation.
5. A guarded state transition retains triggers/effects and its exact memberships.
6. Satisfaction and verification retain their distinct semantic structures.
7. Metadata application and a filtered view reference existing elements without duplicating ownership.
8. Unsupported library features and unresolved references are retained and diagnosed rather than dropped.

Still open: complete inherited KerML schema, official metamodel validation, all library declarations, grammar/graphical-notation coverage, full OCL and derivation evaluation, source-preserving parser behavior, API/interchange scope and execution conformance. These acceptance cases are proposed, not run.

Reproduction and verification

The installed nlm CLI was used directly. The normal authenticated profile worked; no credentials were read or printed, and no notebook sources, notes, sharing settings or artifacts were changed. Queries may remain in notebook chat history.

nlm notebook get 68f78add-cb6f-42cf-9e2e-cb1b1ce42511
nlm source content c83ee3d3-22d7-4c7c-97f5-196a6fe0c27d \
  --output sandbox/sysml-notebook/source.txt
nlm notebook query 68f78add-cb6f-42cf-9e2e-cb1b1ce42511 \
  '<targeted language-inventory question>' \
  --json --new-conversation

The catalogue was extracted by reading unique named subsection headings in §§8.3.6–8.3.27, selecting their body occurrences, and collecting General Classes, one-line property declarations between Attributes and Operations, and constraint identifiers. It is sensitive to source-text layout; its raw declaration strings intentionally remain visible for review.

Raw retrieved text and generated answers are not included in this public repository. The catalogue retains query topics, conversation IDs and question/answer hashes. Original question wording included project-specific context and is omitted rather than rewritten as if different questions had been asked. Seven queries returned successfully, with the expected source ID. Verification checked JSON parsing, unique entry names/sections, counts, representative source declarations and local documentation links. The catalogue and documentation checks do not establish language conformance.

Research repository scope

This repository owns the ongoing SysML v2 inventory. Its records describe language constructs, source evidence and unresolved coverage. Notebook access may require authorization; no public sharing was enabled. Query topic summaries are descriptive labels, not verbatim historical prompts.