From 3025cdbe3f69a95d303a9ce9ce2e71aac4060cb3 Mon Sep 17 00:00:00 2001 From: "devin-ai-integration[bot]" <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Tue, 11 Aug 2026 23:50:49 +0000 Subject: [PATCH 01/91] feat(libs): declare and evaluate exp, ln, log and atan2 in a Systemica extension library The OMG Kernel Function Library declares no signature for any of them, and the vendored files stay byte-identical, so a non-normative Systemica extension package declares them and the runtime registry supplies the implementations. --- libraries/SystemicaMathFunctions.kerml | 47 ++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 libraries/SystemicaMathFunctions.kerml diff --git a/libraries/SystemicaMathFunctions.kerml b/libraries/SystemicaMathFunctions.kerml new file mode 100644 index 0000000..54950c7 --- /dev/null +++ b/libraries/SystemicaMathFunctions.kerml @@ -0,0 +1,47 @@ +library package SystemicaMathFunctions { + doc + /* + * NON-NORMATIVE. This package is a Systemica extension, not part of the OMG KerML + * standard library: it declares the exponential, logarithmic and two-argument + * arctangent functions the Kernel Function Library omits. The vendored OMG files are + * unmodified. A model that needs these writes `import SystemicaMathFunctions::*;`. + */ + + public import ScalarValues::*; + + function exp { + doc + /* + * The exponential of x: e raised to the power x. + */ + in x: Real[1]; return : Real[1]; + } + + function ln { + doc + /* + * The natural logarithm of x, the inverse of exp. Defined for x > 0.0. + */ + in x: Real[1]; return : Real[1]; + } + + function log { + doc + /* + * The logarithm of x to the given base, ln(x) / ln(base). Defined for x > 0.0 and + * a base that is positive and not 1.0. The base is a parameter rather than + * implied, so a call states whether it means base 10, base 2 or another base. + */ + in x: Real[1]; in base: Real[1]; return : Real[1]; + } + + function atan2 { + doc + /* + * The angle in radians from the positive x axis to the point (x, y), in + * (-pi, pi]. The parameters are ordered y then x, as in IEEE 754, so the angle + * carries the quadrant that arctan(y / x) loses. Undefined at the origin. + */ + in y: Real[1]; in x: Real[1]; return : Real[1]; + } +} From 4151ec3f7fe2c7332bb946df513007e427a2222f Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Tue, 18 Aug 2026 01:09:06 +0000 Subject: [PATCH 02/91] refactor(libs): rename the non-normative math library to OpenSysMLMathFunctions Co-Authored-By: jason.han --- ...temicaMathFunctions.kerml => OpenSysMLMathFunctions.kerml} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename libraries/{SystemicaMathFunctions.kerml => OpenSysMLMathFunctions.kerml} (90%) diff --git a/libraries/SystemicaMathFunctions.kerml b/libraries/OpenSysMLMathFunctions.kerml similarity index 90% rename from libraries/SystemicaMathFunctions.kerml rename to libraries/OpenSysMLMathFunctions.kerml index 54950c7..b511082 100644 --- a/libraries/SystemicaMathFunctions.kerml +++ b/libraries/OpenSysMLMathFunctions.kerml @@ -1,10 +1,10 @@ -library package SystemicaMathFunctions { +library package OpenSysMLMathFunctions { doc /* * NON-NORMATIVE. This package is a Systemica extension, not part of the OMG KerML * standard library: it declares the exponential, logarithmic and two-argument * arctangent functions the Kernel Function Library omits. The vendored OMG files are - * unmodified. A model that needs these writes `import SystemicaMathFunctions::*;`. + * unmodified. A model that needs these writes `import OpenSysMLMathFunctions::*;`. */ public import ScalarValues::*; From d19808786dcf452658a6da13cf3bc26d823bf4ee Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Tue, 18 Aug 2026 01:10:24 +0000 Subject: [PATCH 03/91] docs: rename the product to OpenSysML across docs, comments and fixtures Co-Authored-By: jason.han --- libraries/OpenSysMLMathFunctions.kerml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/OpenSysMLMathFunctions.kerml b/libraries/OpenSysMLMathFunctions.kerml index b511082..0eae738 100644 --- a/libraries/OpenSysMLMathFunctions.kerml +++ b/libraries/OpenSysMLMathFunctions.kerml @@ -1,7 +1,7 @@ library package OpenSysMLMathFunctions { doc /* - * NON-NORMATIVE. This package is a Systemica extension, not part of the OMG KerML + * NON-NORMATIVE. This package is a OpenSysML extension, not part of the OMG KerML * standard library: it declares the exponential, logarithmic and two-argument * arctangent functions the Kernel Function Library omits. The vendored OMG files are * unmodified. A model that needs these writes `import OpenSysMLMathFunctions::*;`. From 74921ab71f394a365c53993e19af4b8555c1ca0d Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Tue, 18 Aug 2026 01:10:28 +0000 Subject: [PATCH 04/91] docs: fix article before OpenSysML Co-Authored-By: jason.han --- libraries/OpenSysMLMathFunctions.kerml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/OpenSysMLMathFunctions.kerml b/libraries/OpenSysMLMathFunctions.kerml index 0eae738..8a57e19 100644 --- a/libraries/OpenSysMLMathFunctions.kerml +++ b/libraries/OpenSysMLMathFunctions.kerml @@ -1,7 +1,7 @@ library package OpenSysMLMathFunctions { doc /* - * NON-NORMATIVE. This package is a OpenSysML extension, not part of the OMG KerML + * NON-NORMATIVE. This package is an OpenSysML extension, not part of the OMG KerML * standard library: it declares the exponential, logarithmic and two-argument * arctangent functions the Kernel Function Library omits. The vendored OMG files are * unmodified. A model that needs these writes `import OpenSysMLMathFunctions::*;`. From f4a1325ad3678e21923459213289a4908d85873c Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 29 Aug 2026 01:03:28 +0000 Subject: [PATCH 05/91] feat(query): add native document query planning Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 78 +++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 libraries/DocumentQueries.sysml diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml new file mode 100644 index 0000000..1fc35b6 --- /dev/null +++ b/libraries/DocumentQueries.sysml @@ -0,0 +1,78 @@ +library package DocumentQueries { + /* NON-NORMATIVE OpenSysML document-query vocabulary; + * not part of the OMG SysML or KerML standard library. */ + + private import KerML::Root::Element; + private import ScalarValues::*; + + abstract calc def Query { + return result : Element[0..*] ordered; + } + + calc def OwnedElements { + in source : Element[0..*] ordered; + return result : Element[0..*] ordered; + } + + calc def Descendants { + in source : Element[0..*] ordered; + in maxDepth : Integer[1]; + return result : Element[0..*] ordered; + } + + calc def Ancestors { + in source : Element[0..*] ordered; + in maxDepth : Integer[1]; + return result : Element[0..*] ordered; + } + + calc def RelatedElements { + in source : Element[0..*] ordered; + in relationshipKind : String[1]; + in direction : String[1]; + in maxDepth : Integer[1]; + return result : Element[0..*] ordered; + } + + calc def WhereType { + in source : Element[0..*] ordered; + in type : String[1]; + return result : Element[0..*] ordered; + } + + calc def WhereMetadata { + in source : Element[0..*] ordered; + in metadata : String[1]; + return result : Element[0..*] ordered; + } + + calc def WhereName { + in source : Element[0..*] ordered; + in operator : String[1]; + in value : String[1]; + return result : Element[0..*] ordered; + } + + calc def WhereFeature { + in source : Element[0..*] ordered; + in feature : String[1]; + in operator : String[1]; + in value : String[1]; + return result : Element[0..*] ordered; + } + + calc def OrderBy { + in source : Element[0..*] ordered; + in property : String[1]; + in direction : String[1]; + in missing : String[1]; + in multiple : String[1]; + return result : Element[0..*] ordered; + } + + calc def Project { + in source : Element[0..*] ordered; + in properties : String[1..*] ordered; + return result : Element[0..*] ordered; + } +} From 45ffbe17771a37d696ff5a770eddd468264b55b6 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sun, 30 Aug 2026 04:50:11 +0000 Subject: [PATCH 06/91] feat(query): execute native document queries Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 1fc35b6..12b02f2 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -42,7 +42,7 @@ library package DocumentQueries { calc def WhereMetadata { in source : Element[0..*] ordered; - in metadata : String[1]; + in 'metadata' : String[1]; return result : Element[0..*] ordered; } @@ -55,7 +55,7 @@ library package DocumentQueries { calc def WhereFeature { in source : Element[0..*] ordered; - in feature : String[1]; + in 'feature' : String[1]; in operator : String[1]; in value : String[1]; return result : Element[0..*] ordered; From 131bf558cf73f5c23e07a2cf77899ae11cf6805e Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sun, 30 Aug 2026 15:43:17 +0000 Subject: [PATCH 07/91] feat(queryexec): execute named relationship traversal in document queries Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 12b02f2..22701d0 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -28,6 +28,9 @@ library package DocumentQueries { calc def RelatedElements { in source : Element[0..*] ordered; + /* relationshipKind: "specialization", "subsetting", "redefinition", + * "typing", "connection", "allocation", "satisfaction" or + * "verification"; direction: "outgoing" or "incoming". */ in relationshipKind : String[1]; in direction : String[1]; in maxDepth : Integer[1]; From cba1d66e230e036192d78fac8a56b76f605cbd8d Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sun, 30 Aug 2026 15:56:02 +0000 Subject: [PATCH 08/91] feat(docplan): native document planning and backend-agnostic document IR Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 12b02f2..c7fee5f 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -75,4 +75,26 @@ library package DocumentQueries { in properties : String[1..*] ordered; return result : Element[0..*] ordered; } + + abstract part def Document { + attribute title : String[1]; + } + + abstract part def Section { + attribute title : String[1]; + } + + abstract part def ContentBlock; + + part def Paragraph :> ContentBlock { + attribute text : String[0..1]; + } + + part def Table :> ContentBlock { + attribute caption : String[0..1]; + } + + part def List :> ContentBlock { + attribute style : String[0..1]; + } } From 7413d5de5cbea6d7bf0e565d9a23aa739397f48d Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sun, 30 Aug 2026 22:14:31 +0000 Subject: [PATCH 09/91] feat(docrender): embed generated diagrams as document content blocks Adds a Diagram content block to the DocumentQueries vocabulary that references a declared view or an element with a stated rendering kind, carries caption and flow direction, and renders through the existing view engine: fenced Mermaid for graph kinds, pipe tables for table kinds, with typed diagnostics at planning, evaluation and rendering. Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 856c7ce..f4fd901 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -100,4 +100,15 @@ library package DocumentQueries { part def List :> ContentBlock { attribute style : String[0..1]; } + + part def Diagram :> ContentBlock { + attribute caption : String[0..1]; + /* kind: a supported rendering kind ("tree", "interconnection", + * "state", "action", "table" or "sequence"); required when source + * is a plain element, stated by the view when source is a view. */ + attribute kind : String[0..1]; + /* direction: "TB", "LR", "RL" or "BT", for kinds drawn as graphs. */ + attribute direction : String[0..1]; + ref source : Element[0..1]; + } } From 63f7f2de370d63dfff76b5b22635d9faec507035 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Mon, 31 Aug 2026 01:44:23 +0000 Subject: [PATCH 10/91] feat(docplan): inline runs, cross-references and grouped tables in native documents Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index f4fd901..af14d80 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -93,8 +93,33 @@ library package DocumentQueries { attribute text : String[0..1]; } + /* Inline runs compose a paragraph in declaration order, joined by + * single spaces. */ + abstract part def Run; + + part def Span :> Run { + attribute text : String[1]; + /* style: "plain", "emphasis", "strong" or "code". */ + attribute style : String[0..1]; + } + + part def Link :> Run { + attribute text : String[1]; + attribute target : String[1]; + } + + /* Ref links to another named content block of the same document; text + * defaults to the target's title, caption or name. */ + part def Ref :> Run { + attribute text : String[0..1]; + ref target : Element[1]; + } + part def Table :> ContentBlock { attribute caption : String[0..1]; + /* groupBy: a projected column name; rows are grouped by its value + * into subtables in order of first appearance. */ + attribute groupBy : String[0..1]; } part def List :> ContentBlock { From 647adf9278c4644153651009b3f42ff662277ea9 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Mon, 31 Aug 2026 03:47:46 +0000 Subject: [PATCH 11/91] feat(queryexec): computed expression columns in Project projections A projection may pair declared properties with named Column(name, expression) computed columns evaluated once per row: arithmetic, string concatenation, unary +/- and ?? defaults over the row element's features. Names are explicit, visible to OrderBy, groupBy validation and docplan's static projection inspection. A failing expression fails the query with a typed, provenance-carrying error; ?? is the deliberate absent-value mechanism. Planning validates column forms, unknown features, unsupported operators, static type mismatches, duplicates and empty projections with source spans. Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index af14d80..61f5b7d 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -73,9 +73,25 @@ library package DocumentQueries { return result : Element[0..*] ordered; } + /* One computed table column: an explicit name plus a calc expression + * evaluated on each projected row element. */ + attribute def ColumnSpec; + + /* A column expression references row properties by their declared + * feature (e.g. Subsystem::mass), supports +, -, *, / arithmetic, + * string concatenation with +, and ?? for absent-value defaults. + * A failing expression fails the query with a typed error naming + * the row, column and expression. */ + calc def Column { + in name : String[1]; + in expression : ScalarValue[0..1]; + return result : ColumnSpec[1]; + } + calc def Project { in source : Element[0..*] ordered; - in properties : String[1..*] ordered; + in properties : String[0..*] ordered = null; + in columns : ColumnSpec[0..*] ordered = null; return result : Element[0..*] ordered; } From 3ff8f7c45d0f1622434baebfb5fb179ba77eaa68 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Mon, 31 Aug 2026 04:19:20 +0000 Subject: [PATCH 12/91] fix(queryexec): reject empty projections at planning, scope qualified feature reads to conforming rows, and fail typed on bare absent columns Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 61f5b7d..9481caf 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -80,8 +80,10 @@ library package DocumentQueries { /* A column expression references row properties by their declared * feature (e.g. Subsystem::mass), supports +, -, *, / arithmetic, * string concatenation with +, and ?? for absent-value defaults. - * A failing expression fails the query with a typed error naming - * the row, column and expression. */ + * A row not conforming to the feature's declaring type reads it as + * absent; a failing expression or an absent result not defaulted + * with ?? fails the query with a typed error naming the row and + * column. */ calc def Column { in name : String[1]; in expression : ScalarValue[0..1]; From 0317efcc9188a62897e40c85db0bcf44a08dc8d3 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Mon, 31 Aug 2026 04:52:38 +0000 Subject: [PATCH 13/91] fix(queryexec): allow positional Project, default unrelated rows, enforce scalar computed results, and read qualified features from declarations Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 9481caf..84ec376 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -81,9 +81,9 @@ library package DocumentQueries { * feature (e.g. Subsystem::mass), supports +, -, *, / arithmetic, * string concatenation with +, and ?? for absent-value defaults. * A row not conforming to the feature's declaring type reads it as - * absent; a failing expression or an absent result not defaulted - * with ?? fails the query with a typed error naming the row and - * column. */ + * absent; a failing expression, an absent result not defaulted + * with ??, or a multi-valued result fails the query with a typed + * error naming the row and column. */ calc def Column { in name : String[1]; in expression : ScalarValue[0..1]; From 854fe473bc6fa9f934a9367e1c455df5a288b497 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Mon, 31 Aug 2026 07:00:29 +0000 Subject: [PATCH 14/91] feat(docplan): style query-produced text through column runs A query-backed paragraph or list may nest SpanColumn/LinkColumn column runs mapping projected columns - declared properties and computed Column names alike - to emphasis/strong/code spans (fixed style or a per-row style column) and external links (a target column). Plans stay immutable, unknown columns and invalid styles are typed planning errors with source spans when the projection is statically known and typed runtime errors naming query, column and row otherwise, and each generated run keeps its projected value's provenance. Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 84ec376..b77d33c 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -133,6 +133,27 @@ library package DocumentQueries { ref target : Element[1]; } + /* Column runs style a query-backed paragraph's or list's text: each + * result row renders one run per column run, in declaration order. */ + abstract part def ColumnRun; + + part def SpanColumn :> ColumnRun { + /* column: the projected column whose values become the run text. */ + attribute column : String[1]; + /* style: "plain", "emphasis", "strong" or "code". */ + attribute style : String[0..1]; + /* styleColumn: a projected column supplying each row's style. */ + attribute styleColumn : String[0..1]; + } + + part def LinkColumn :> ColumnRun { + /* column: the projected column whose values become the link text. */ + attribute column : String[1]; + /* targetColumn: a projected column supplying each row's one link + * destination. */ + attribute targetColumn : String[1]; + } + part def Table :> ContentBlock { attribute caption : String[0..1]; /* groupBy: a projected column name; rows are grouped by its value From f1d46f2f19d474784ed2880c999f92cbd0c6cf90 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Mon, 31 Aug 2026 07:23:13 +0000 Subject: [PATCH 15/91] feat(docgen): cross-document Ref targets with linked multi-document rendering Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 84ec376..d72392a 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -126,8 +126,9 @@ library package DocumentQueries { attribute target : String[1]; } - /* Ref links to another named content block of the same document; text - * defaults to the target's title, caption or name. */ + /* Ref links to a named content block of this or another document, or to + * another document itself; text defaults to the target's title, caption + * or name. */ part def Ref :> Run { attribute text : String[0..1]; ref target : Element[1]; From 77be1bc7572e3e67af64cd75d851710e30f8a50a Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Tue, 1 Sep 2026 03:42:01 +0000 Subject: [PATCH 16/91] feat(identity): IdentityMetadata library, identity side table, and validation pass Implements phases 1-3 of docs/project/element-identity-annotations.md: the IdentityMetadata stdlib extension, an identity side table computing effective element ids and ProjectRef scopes, and a constraint-tier pass validating id shape, scope binding, and uniqueness over the generated id space. Co-Authored-By: jason.han --- libraries/IdentityMetadata.sysml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 libraries/IdentityMetadata.sysml diff --git a/libraries/IdentityMetadata.sysml b/libraries/IdentityMetadata.sysml new file mode 100644 index 0000000..815716a --- /dev/null +++ b/libraries/IdentityMetadata.sysml @@ -0,0 +1,17 @@ +standard library package IdentityMetadata { + doc /* Binds notation to repository identity. Non-normative OpenSysML + * extension, proposed for standardization; see the design record. */ + + metadata def ElementId { + doc /* The annotated element is the repository element with this id. */ + attribute id : ScalarValues::String; + } + + metadata def ProjectRef { + doc /* Elements below the annotated namespace that carry ElementId + * resolve against this project and branch. */ + attribute projectId : ScalarValues::String; + attribute branch : ScalarValues::String[0..1]; + attribute org : ScalarValues::String[0..1]; + } +} From 45fd4d442860485f9596cebd48a35bf507e6d225 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 5 Sep 2026 17:54:35 +0000 Subject: [PATCH 17/91] feat(libs): add OOSEM library, example and prefixed use-case parsing Bundles a non-normative OOSEM vocabulary (definitions, base usages and semantic-metadata keywords for enterprise, requirement, logical, physical and node modelling) that reuses ParametersOfInterestMetadata, TradeStudies, RequirementDerivation and CauseAndEffect, plus a wildfire-watch example. Fixes leadingPrefixIsDefUsage so '#kw use case ...' dispatches. Rebaselines the pilot differential and RDF round-trip ratchets for the new example. Co-Authored-By: jason.han --- libraries/OOSEM.sysml | 424 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 424 insertions(+) create mode 100644 libraries/OOSEM.sysml diff --git a/libraries/OOSEM.sysml b/libraries/OOSEM.sysml new file mode 100644 index 0000000..943c604 --- /dev/null +++ b/libraries/OOSEM.sysml @@ -0,0 +1,424 @@ +library package OOSEM { + doc + /* + * NON-NORMATIVE OpenSysML vocabulary for the Object-Oriented Systems Engineering Method (OOSEM). + * Each OOSEM artefact gets a definition specialising its native SysML type, a base usage, and a + * semantic-metadata keyword applying both at once: `#system part sat : Satellite;`. + * MOE/MOP, trade studies, derivation and causation reuse the standard domain libraries, re-exported here. + */ + + private import ScalarValues::String; + private import Metaobjects::SemanticMetadata; + private import Parts::Part; + private import Parts::parts; + private import Items::Item; + private import Items::items; + private import Actions::Action; + private import Actions::actions; + private import Requirements::RequirementCheck; + private import Requirements::requirementChecks; + private import UseCases::UseCase; + private import UseCases::useCases; + private import AnalysisCases::AnalysisCase; + private import AnalysisCases::analysisCases; + + public import ParametersOfInterestMetadata::*; + public import TradeStudies::*; + public import RequirementDerivation::*; + public import CauseAndEffect::*; + + /* Enterprise and stakeholder needs analysis */ + + part def Enterprise :> Part { + doc /* An Enterprise is the organisation, or system of systems, whose mission the system of interest + * serves. OOSEM models the as-is enterprise to find the problem and the to-be enterprise that + * includes the system of interest. */ + } + + abstract part enterprises : Enterprise[0..*] nonunique :> parts; + + part def Stakeholder :> Part { + doc /* A Stakeholder is a person, organisation or external system whose needs, concerns and measures of + * effectiveness the enterprise and system must satisfy. */ + } + + abstract part stakeholderParts : Stakeholder[0..*] nonunique :> parts; + + analysis def CausalAnalysis :> AnalysisCase { + doc /* A CausalAnalysis is the OOSEM analysis of an as-is enterprise that traces the problems it + * exhibits to their causes, so the to-be enterprise addresses causes rather than symptoms. The + * causes and effects themselves are modelled with the CauseAndEffect library re-exported here. */ + } + + abstract analysis causalAnalyses : CausalAnalysis[0..*] nonunique :> analysisCases; + + use case def EnterpriseUseCase :> UseCase { + doc /* An EnterpriseUseCase describes how the enterprise as a whole achieves a goal for its + * stakeholders. Its subject is the enterprise; the system of interest is at most one of its + * participants. */ + } + + abstract use case enterpriseUseCases : EnterpriseUseCase[0..*] nonunique :> useCases; + + /* Requirements, by the enterprise level they are stated at. */ + + requirement def StakeholderNeed :> RequirementCheck { + doc /* A StakeholderNeed states, in the stakeholder's own terms, a capability or quality the enterprise + * must provide. Mission requirements are derived from it. */ + } + + abstract requirement stakeholderNeeds : StakeholderNeed[0..*] nonunique :> requirementChecks; + + requirement def MissionRequirement :> RequirementCheck { + doc /* A MissionRequirement states what the enterprise must achieve, with its measures of + * effectiveness, to satisfy the stakeholder needs. It is the top of the derivation chain that ends + * in component requirements. */ + } + + abstract requirement missionRequirements : MissionRequirement[0..*] nonunique :> requirementChecks; + + requirement def SystemRequirement :> RequirementCheck { + doc /* A SystemRequirement states what the system of interest, treated as a black box in its context, + * must do or be. It is derived from mission requirements and use cases. */ + } + + abstract requirement systemRequirements : SystemRequirement[0..*] nonunique :> requirementChecks; + + requirement def ComponentRequirement :> RequirementCheck { + doc /* A ComponentRequirement states what a logical or physical component of the system must do or be, + * as derived from the system requirements allocated to it. */ + } + + abstract requirement componentRequirements : ComponentRequirement[0..*] nonunique :> requirementChecks; + + /* System requirements analysis: the black-box system in its context */ + + part def SystemOfInterest :> Part { + doc /* The SystemOfInterest is the system being specified and designed. In the system context it is a + * black box whose interfaces, behaviour and requirements are stated without reference to its + * internal structure. */ + } + + abstract part systemsOfInterest : SystemOfInterest[0..*] nonunique :> parts; + + part def ExternalSystem :> Part { + doc /* An ExternalSystem is a system outside the boundary of the system of interest that it exchanges + * matter, energy or information with. */ + } + + abstract part externalSystems : ExternalSystem[0..*] nonunique :> parts; + + part def User :> Part { + doc /* A User is a person, or class of persons, who interacts with the system of interest across its + * boundary: an operator, maintainer or other human actor. */ + } + + abstract part users : User[0..*] nonunique :> parts; + + part def Environment :> Part { + doc /* An Environment is the natural or induced physical environment that surrounds the system of + * interest and acts on it: terrain, weather, radiation, orbit, and so on. */ + } + + abstract part environments : Environment[0..*] nonunique :> parts; + + part def SystemContext :> Part { + doc /* A SystemContext is the composition of the system of interest with everything it interacts with. + * It is the subject of system use cases and the frame in which the system's external interfaces + * are defined. */ + + part systemOfInterest : SystemOfInterest[1] :> systemsOfInterest { + doc /* The one system of interest this context is drawn around. */ + } + + part externalSystems : ExternalSystem[0..*] :> OOSEM::externalSystems { + doc /* The external systems the system of interest interacts with. */ + } + + part users : User[0..*] :> OOSEM::users { + doc /* The users who interact with the system of interest. */ + } + + part environment : Environment[0..1] :> environments { + doc /* The physical environment the system of interest operates in. */ + } + } + + abstract part systemContexts : SystemContext[0..*] nonunique :> parts; + + use case def SystemUseCase :> UseCase { + doc /* A SystemUseCase describes a goal an actor achieves through the system of interest. Its subject + * is the system context, so its scenarios show the black-box system exchanging inputs and outputs + * with its actors. */ + } + + abstract use case systemUseCases : SystemUseCase[0..*] nonunique :> useCases; + + item def IOEntity :> Item { + doc /* An IOEntity is something that crosses the boundary of the system of interest: an item of matter, + * energy or information it receives or produces. */ + } + + abstract item ioEntities : IOEntity[0..*] nonunique :> items; + + item def Store :> Item { + doc /* A Store holds items, typically data, that persist between the actions of a scenario so that one + * action can deposit what a later one retrieves. */ + } + + abstract item stores : Store[0..*] nonunique :> items; + + /* Logical architecture */ + + part def LogicalComponent :> Part { + doc /* A LogicalComponent is a part of the logical decomposition of the system of interest: it is + * defined by the functions and interfaces allocated to it, independent of the technology that will + * realise it. */ + } + + abstract part logicalComponents : LogicalComponent[0..*] nonunique :> parts; + + action def LogicalScenario :> Action { + doc /* A LogicalScenario is a white-box realisation of a system use case scenario: the same externally + * visible behaviour, decomposed into actions performed by the logical components and the flows + * between them. */ + } + + abstract action logicalScenarios : LogicalScenario[0..*] nonunique :> actions; + + part def Node :> Part { + doc /* A Node is a locus of the system to which logical components are distributed before they are + * realised: a site, a vehicle, a rack. Nodes partition the logical architecture and define the + * interfaces between partitions. */ + } + + abstract part nodes : Node[0..*] nonunique :> parts; + + /* Physical architecture */ + + part def PhysicalComponent :> Part { + doc /* A PhysicalComponent realises one or more logical components in a chosen technology. Hardware, + * software, data and operational procedures are its kinds. */ + } + + abstract part physicalComponents : PhysicalComponent[0..*] nonunique :> parts; + + part def HardwareComponent :> PhysicalComponent { + doc /* A HardwareComponent is a physical component realised in hardware. */ + } + + abstract part hardwareComponents : HardwareComponent[0..*] nonunique :> physicalComponents; + + part def SoftwareComponent :> PhysicalComponent { + doc /* A SoftwareComponent is a physical component realised in software. */ + } + + abstract part softwareComponents : SoftwareComponent[0..*] nonunique :> physicalComponents; + + part def OperationalProcedure :> PhysicalComponent { + doc /* An OperationalProcedure is a physical component realised as a procedure that a user follows + * rather than as hardware or software. */ + } + + abstract part operationalProcedures : OperationalProcedure[0..*] nonunique :> physicalComponents; + + item def DataComponent :> Item { + doc /* A DataComponent is data the physical architecture stores or transfers, when the data itself is a + * design element rather than a value flowing through one. */ + } + + abstract item dataComponents : DataComponent[0..*] nonunique :> items; + + /* Lifecycle */ + + enum def EnterpriseStateKind { + doc /* Whether a model of the enterprise or system describes what exists today or what is proposed. */ + asIs; + toBe; + } + + metadata def AsIs { + doc /* Marks an as-is model: the enterprise or system as it exists before the system of interest is + * introduced. */ + attribute kind : EnterpriseStateKind = EnterpriseStateKind::asIs; + } + + metadata def ToBe { + doc /* Marks a to-be model: the enterprise or system as proposed. */ + attribute kind : EnterpriseStateKind = EnterpriseStateKind::toBe; + } + + /* Package template: OOSEMPackage records which method activity a package holds. */ + + enum def OOSEMPackageKind { + enterpriseModel; + stakeholderNeeds; + missionRequirements; + systemRequirements; + logicalArchitecture; + physicalArchitecture; + analysisModel; + verificationModel; + tradeStudies; + } + + metadata def OOSEMPackage { + doc /* Classifies a package by the OOSEM activity whose artefacts it holds. */ + :> annotatedElement : SysML::Package; + attribute kind : OOSEMPackageKind; + attribute description : String[0..1]; + } + + /* Aliases for the earlier OOSEM stub's MOE/MoP names; prefer #moe and #mop. */ + + package 'OOSEM Measures' { + alias MOE for ParametersOfInterestMetadata::measuresOfEffectiveness; + alias MoP for ParametersOfInterestMetadata::measuresOfPerformance; + } + + /* Semantic metadata: the user-defined keywords of the method */ + + metadata def EnterpriseMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = enterprises meta SysML::Usage; + } + + metadata def StakeholderMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = stakeholderParts meta SysML::Usage; + } + + metadata def CausalAnalysisMetadata :> SemanticMetadata { + :> annotatedElement : SysML::AnalysisCaseDefinition; + :> annotatedElement : SysML::AnalysisCaseUsage; + :>> baseType = causalAnalyses meta SysML::Usage; + } + + metadata def EnterpriseUseCaseMetadata :> SemanticMetadata { + :> annotatedElement : SysML::UseCaseDefinition; + :> annotatedElement : SysML::UseCaseUsage; + :>> baseType = enterpriseUseCases meta SysML::Usage; + } + + metadata def StakeholderNeedMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = stakeholderNeeds meta SysML::Usage; + } + + metadata def MissionRequirementMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = missionRequirements meta SysML::Usage; + } + + metadata def SystemRequirementMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = systemRequirements meta SysML::Usage; + } + + metadata def ComponentRequirementMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = componentRequirements meta SysML::Usage; + } + + metadata def SystemOfInterestMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = systemsOfInterest meta SysML::Usage; + } + + metadata def ExternalSystemMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = externalSystems meta SysML::Usage; + } + + metadata def UserMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = users meta SysML::Usage; + } + + metadata def EnvironmentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = environments meta SysML::Usage; + } + + metadata def SystemContextMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = systemContexts meta SysML::Usage; + } + + metadata def SystemUseCaseMetadata :> SemanticMetadata { + :> annotatedElement : SysML::UseCaseDefinition; + :> annotatedElement : SysML::UseCaseUsage; + :>> baseType = systemUseCases meta SysML::Usage; + } + + metadata def IOEntityMetadata :> SemanticMetadata { + :> annotatedElement : SysML::ItemDefinition; + :> annotatedElement : SysML::ItemUsage; + :>> baseType = ioEntities meta SysML::Usage; + } + + metadata def StoreMetadata :> SemanticMetadata { + :> annotatedElement : SysML::ItemDefinition; + :> annotatedElement : SysML::ItemUsage; + :>> baseType = stores meta SysML::Usage; + } + + metadata def LogicalComponentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = logicalComponents meta SysML::Usage; + } + + metadata def LogicalScenarioMetadata :> SemanticMetadata { + :> annotatedElement : SysML::ActionDefinition; + :> annotatedElement : SysML::ActionUsage; + :>> baseType = logicalScenarios meta SysML::Usage; + } + + metadata def NodeMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = nodes meta SysML::Usage; + } + + metadata def PhysicalComponentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = physicalComponents meta SysML::Usage; + } + + metadata def HardwareComponentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = hardwareComponents meta SysML::Usage; + } + + metadata def SoftwareComponentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = softwareComponents meta SysML::Usage; + } + + metadata def OperationalProcedureMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = operationalProcedures meta SysML::Usage; + } + + metadata def DataComponentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::ItemDefinition; + :> annotatedElement : SysML::ItemUsage; + :>> baseType = dataComponents meta SysML::Usage; + } +} From e6b1ff5012b3977c562a1fc8fd38cd2cf3b46c01 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 5 Sep 2026 18:57:33 +0000 Subject: [PATCH 18/91] feat(docgen): project shortName/documentation and render query rows as prose MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Queries gain the KerML Element features shortName, declaredShortName and documentation as projectable properties, wired through Project, OrderBy, WhereFeature, Column expressions (Element::...), the gRPC and OSLC surfaces and reflective access. documentation is the normalized body of each doc comment in declaration order, read through a source-text lookup the semantic model now carries; the LSP hover shares the normalizer. Documents gain the Definitions content kind: one term/description entry per row of the bound query, rendered as "**term** — description" paragraphs in Markdown (and so PDF) and as a
of
/
pairs in HTML. Missing or unprojected columns are typed errors at planning time when the projection is static, otherwise at evaluation. Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 689c050..625b51a 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -166,6 +166,15 @@ library package DocumentQueries { attribute style : String[0..1]; } + /* Definitions renders each row of its query as one term with its + * description(s): prose from the model rather than a table of it. */ + part def Definitions :> ContentBlock { + /* term: the projected column whose value names each entry. */ + attribute term : String[1]; + /* description: the projected column whose values describe it. */ + attribute description : String[1]; + } + part def Diagram :> ContentBlock { attribute caption : String[0..1]; /* kind: a supported rendering kind ("tree", "interconnection", From 7994edcab2c80ca2a1b6a7686ac3ce732f8fcf4c Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 5 Sep 2026 19:17:29 +0000 Subject: [PATCH 19/91] feat(libs): add OOSEM viewpoints, views and method checks Adds five OOSEM viewpoints and eight view definitions that specialise the standard view definitions with the method's filters and renderings, so a model writes only the view usage and what it exposes. Adds OOSEMMethodPass, constraint-tier warnings that a requirement derives from the level above and is satisfied, that a logical component is allocated, and that a use case's subject is the system context or enterprise; each rule waits until the model declares the level it traces to. Fixes Resolver.importAdmits so a view usage's expose honours the filter conditions inherited from its view definition and that definition's supertypes. Rebaselines the pilot differential for the grown example. Co-Authored-By: jason.han --- libraries/OOSEM.sysml | 109 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/libraries/OOSEM.sysml b/libraries/OOSEM.sysml index 943c604..ef7eb82 100644 --- a/libraries/OOSEM.sysml +++ b/libraries/OOSEM.sysml @@ -5,6 +5,8 @@ library package OOSEM { * Each OOSEM artefact gets a definition specialising its native SysML type, a base usage, and a * semantic-metadata keyword applying both at once: `#system part sat : Satellite;`. * MOE/MOP, trade studies, derivation and causation reuse the standard domain libraries, re-exported here. + * The method's standard products are view definitions on the standard view definitions, each + * satisfying an OOSEM viewpoint; a view typed by one exposes a model and shows only that product. */ private import ScalarValues::String; @@ -21,6 +23,10 @@ library package OOSEM { private import UseCases::useCases; private import AnalysisCases::AnalysisCase; private import AnalysisCases::analysisCases; + private import StandardViewDefinitions::*; + private import Views::asTreeDiagram; + private import Views::asInterconnectionDiagram; + private import Views::asElementTable; public import ParametersOfInterestMetadata::*; public import TradeStudies::*; @@ -276,6 +282,109 @@ library package OOSEM { alias MoP for ParametersOfInterestMetadata::measuresOfPerformance; } + /* Viewpoints and views: the method's standard products, as view conditions over its keywords */ + + concern def StakeholderNeedsConcern { + doc /* Whose needs the enterprise serves, and what in the as-is enterprise keeps them unmet. */ + } + + concern def SystemBoundaryConcern { + doc /* Where the boundary of the system of interest lies, and what crosses it. */ + } + + concern def RequirementsTraceabilityConcern { + doc /* Whether every requirement derives from a need and is measured, satisfied and verified. */ + } + + concern def LogicalDecompositionConcern { + doc /* How the system's functions and interfaces partition into technology-independent components. */ + } + + concern def PhysicalRealizationConcern { + doc /* Which hardware, software, data and procedures realise the logical components, at which nodes. */ + } + + viewpoint def EnterpriseViewpoint { + doc /* The enterprise and stakeholder needs analysis, as the stakeholders and mission planners see it. */ + frame concern : StakeholderNeedsConcern; + } + + viewpoint def SystemContextViewpoint { + doc /* The black-box system in its context, as the system requirements analysis sees it. */ + frame concern : SystemBoundaryConcern; + } + + viewpoint def RequirementsViewpoint { + doc /* The requirement chain from stakeholder need to component requirement. */ + frame concern : RequirementsTraceabilityConcern; + } + + viewpoint def LogicalArchitectureViewpoint { + doc /* The logical decomposition and its distribution over nodes. */ + frame concern : LogicalDecompositionConcern; + } + + viewpoint def PhysicalArchitectureViewpoint { + doc /* The physical realisation of the logical architecture. */ + frame concern : PhysicalRealizationConcern; + } + + view def EnterpriseModelView :> BrowserView { + doc /* Tree of the enterprise, its stakeholders, enterprise use cases and causal analyses. */ + satisfy EnterpriseViewpoint; + filter @EnterpriseMetadata or @StakeholderMetadata or @EnterpriseUseCaseMetadata or @CausalAnalysisMetadata; + render asTreeDiagram; + } + + view def SystemContextView :> InterconnectionView { + doc /* Interconnection diagram of the system context: the system of interest, external systems, + * users and environment, with the connections between them. */ + satisfy SystemContextViewpoint; + filter @SystemContextMetadata or @SystemOfInterestMetadata or @ExternalSystemMetadata or @UserMetadata or @EnvironmentMetadata; + render asInterconnectionDiagram; + } + + view def SystemUseCaseView :> BrowserView { + doc /* Tree of the system use cases and the entities that cross the system boundary. */ + satisfy SystemContextViewpoint; + filter @SystemUseCaseMetadata or @IOEntityMetadata or @StoreMetadata; + render asTreeDiagram; + } + + view def RequirementsView :> GridView { + doc /* Table of the stakeholder needs and mission, system and component requirements. */ + satisfy RequirementsViewpoint; + filter @StakeholderNeedMetadata or @MissionRequirementMetadata or @SystemRequirementMetadata or @ComponentRequirementMetadata; + render asElementTable; + } + + view def MeasuresView :> GridView { + doc /* Table of the measures of effectiveness and performance. */ + satisfy RequirementsViewpoint; + filter @MeasureOfEffectiveness or @MeasureOfPerformance; + render asElementTable; + } + + view def LogicalArchitectureView :> BrowserView { + doc /* Tree of the logical components and the nodes they are distributed to. */ + satisfy LogicalArchitectureViewpoint; + filter @LogicalComponentMetadata or @NodeMetadata; + render asTreeDiagram; + } + + view def LogicalScenarioView :> ActionFlowView { + doc /* Action flow diagram of the logical scenarios. */ + satisfy LogicalArchitectureViewpoint; + filter @LogicalScenarioMetadata; + } + + view def PhysicalArchitectureView :> BrowserView { + doc /* Tree of the nodes and the hardware, software, data and procedures they hold. */ + satisfy PhysicalArchitectureViewpoint; + filter @NodeMetadata or @PhysicalComponentMetadata or @HardwareComponentMetadata or @SoftwareComponentMetadata or @OperationalProcedureMetadata or @DataComponentMetadata; + render asTreeDiagram; + } + /* Semantic metadata: the user-defined keywords of the method */ metadata def EnterpriseMetadata :> SemanticMetadata { From 0b777c999a557335cdffa7b855ba6e2a09fd9cab Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Fri, 11 Sep 2026 07:02:56 +0000 Subject: [PATCH 20/91] feat(libs): add the MOSA standard library Bundle a non-normative OpenSysML library for the Modular Open Systems Approach: the statutory vocabulary (MajorSystemPlatform, MajorSystemComponent, ModularSystem, ModularSystemInterface) with #keyInterface as a documented practitioner alias, standards and conformance, data rights, proprietary and interface-control metadata, MOSA requirements, viewpoints and views, document queries and an InterfaceControlDocument specialization. A semantic metadata definition that binds no baseType of its own now inherits its supertype's binding, so #keyInterface classifies as a modular system interface. Co-Authored-By: jason.han --- libraries/MOSA.sysml | 515 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 515 insertions(+) create mode 100644 libraries/MOSA.sysml diff --git a/libraries/MOSA.sysml b/libraries/MOSA.sysml new file mode 100644 index 0000000..afb9e7a --- /dev/null +++ b/libraries/MOSA.sysml @@ -0,0 +1,515 @@ +library package MOSA { + doc + /* + * NON-NORMATIVE OpenSysML vocabulary for the Modular Open Systems Approach (MOSA), the + * integrated business and technical strategy 10 U.S.C. § 4401 requires of United States + * Department of Defense major defense acquisition programs. Its concepts and their names + * are the statute's: the major system platform, the major system components mounted on + * it, the modular systems that can be separated and recombined, and the modular system + * interfaces between them, each verified against a widely supported, consensus-based + * standard or documented in machine-readable form, with the rights in technical data that + * let a component be competed, upgraded or replaced over the life cycle. + * Each MOSA artefact gets a definition specialising its native SysML type, a base usage, and + * a semantic-metadata keyword applying both at once: `#majorSystemComponent part radar : Radar;`. + * Standards conformance, data rights, interface control and conformance assessment are + * metadata over the standard model. The library's products are view definitions on the + * standard view definitions and document queries for an interface control document. + * Measures, requirement derivation and status/rationale metadata reuse the standard domain + * libraries, re-exported here. + */ + + private import ScalarValues::String; + private import Metaobjects::SemanticMetadata; + private import KerML::Root::Element; + private import Parts::Part; + private import Parts::parts; + private import Items::Item; + private import Items::items; + private import Interfaces::Interface; + private import Interfaces::interfaces; + private import Interfaces::BinaryInterface; + private import Interfaces::binaryInterfaces; + private import Requirements::RequirementCheck; + private import Requirements::requirementChecks; + private import StandardViewDefinitions::*; + private import Views::asTreeDiagram; + private import Views::asInterconnectionDiagram; + private import Views::asElementTable; + private import DocumentQueries::*; + + public import ParametersOfInterestMetadata::*; + public import RequirementDerivation::*; + public import ModelingMetadata::*; + + /* Modular design: the statutory structure of a major system */ + + part def MajorSystemPlatform :> Part { + doc /* A MajorSystemPlatform is the highest-level structure of a major weapon system that is not + * itself mounted on a higher-level structure, and on which major system components are + * mounted or installed (10 U.S.C. § 4401(b)). */ + } + + abstract part majorSystemPlatforms : MajorSystemPlatform[0..*] nonunique :> parts; + + part def MajorSystemComponent :> Part { + doc /* A MajorSystemComponent is a high-level subsystem or assembly — hardware, software or an + * integrated assembly of components — that is mounted on or installed in a major system + * platform, or is itself a major system, and that is designed to be severable and replaced + * incrementally over the life cycle. */ + } + + abstract part majorSystemComponents : MajorSystemComponent[0..*] nonunique :> parts; + + part def ModularSystem :> Part { + doc /* A ModularSystem is a system or component that executes without requiring the coincident + * execution of other systems or components, communicates across component boundaries through + * interfaces, and functions as a module that can be separated, recombined and connected with + * other systems or components to achieve various effects, missions or capabilities. + * It is what the MOSA Implementation Guidebook calls a MOSA module. */ + } + + abstract part modularSystems : ModularSystem[0..*] nonunique :> parts; + + /* Modular system interfaces: the shared boundaries a modular design designates */ + + enum def InterfaceCharacteristicKind { + doc /* The physical, logical and functional characteristics the statute names as defining a + * modular system interface. An interface may have several. */ + electrical; + mechanical; + fluidic; + optical; + radioFrequency; + data; + networking; + software; + } + + interface def ModularSystemInterface :> Interface { + doc /* A ModularSystemInterface is a shared boundary between major systems, major system + * components or modular systems, defined by physical, logical and functional characteristics + * such as electrical, mechanical, fluidic, optical, radio-frequency, data, networking or + * software elements. MOSA verifies each against a consensus-based standard or documents it + * in machine-readable form: the interface's ports, items and attributes are that + * documentation, and a StandardConformance names the standards. + * The `#modularSystemInterface` keyword declares the binary case, which is the usual one; + * an interface with more than two ends specializes this definition directly. */ + attribute characteristics : InterfaceCharacteristicKind[0..*]; + } + + abstract interface modularSystemInterfaces : ModularSystemInterface[0..*] nonunique :> interfaces; + + interface def BinaryModularSystemInterface :> ModularSystemInterface, BinaryInterface { + doc /* A BinaryModularSystemInterface is a modular system interface between two ports. */ + } + + abstract interface binaryModularSystemInterfaces : BinaryModularSystemInterface[0..*] nonunique :> modularSystemInterfaces, binaryInterfaces; + + /* Open standards and conformance to them */ + + item def Standard :> Item { + doc /* A Standard is a published specification an interface, module or data item can be verified + * against. Where the standard's text is held in a standards registry or interface repository, + * registry holds a machine-readable reference to that entry. */ + attribute organization : String[0..1]; + attribute identifier : String[0..1]; + attribute version : String[0..1]; + attribute registry : String[0..1]; + } + + abstract item standards : Standard[0..*] nonunique :> items; + + item def ConsensusStandard :> Standard { + doc /* A ConsensusStandard is a widely supported, consensus-based standard — an open standard in + * the guidebook's terms — developed and maintained by a recognised standards body with the + * participation of the market its interfaces are competed in. Verification against one is + * what the statute asks of a modular system interface. */ + } + + abstract item consensusStandards : ConsensusStandard[0..*] nonunique :> standards; + + ref conformingElements[*] { + doc /* conformingElements are the interfaces, modules or items that conform in a StandardConformance. */ + } + + ref conformedStandards : Standard[*] { + doc /* conformedStandards are the standards conformed to in a StandardConformance. */ + } + + abstract connection def StandardConformance { + doc /* A StandardConformance states that its conforming elements are verified against its standards. + * Write one as a connection with a `#conformant` end and a `#conformsTo` end: + * `#conformance connection { end #conformant ::> dataLink; end #conformsTo ::> ethernet; }`. */ + ref conformingElement[1..*] :>> conformingElements :> participant { + doc /* The elements that conform. */ + } + ref conformedStandard[1..*] :>> conformedStandards :> participant { + doc /* The standards they conform to. */ + } + } + + abstract connection standardConformances : StandardConformance[0..*] nonunique { + doc /* standardConformances is the base feature for StandardConformance connection usages. */ + } + + /* Openness: data rights and proprietary elements */ + + enum def DataRightsKind { + doc /* The license categories for technical data and computer software the Defense Federal + * Acquisition Regulation Supplement provides for, which decide whether a component's technical + * data can be used to compete, upgrade or replace it. */ + unlimited; + governmentPurpose; + limited; + restricted; + smallBusinessInnovationResearch; + speciallyNegotiated; + } + + metadata def DataRights { + doc /* DataRights records the rights the acquiring organisation holds in the technical data and + * software of the annotated element, who asserted any restriction, and the basis of the assertion. */ + attribute kind : DataRightsKind; + attribute asserter : String[0..1]; + attribute basis : String[0..1]; + } + + metadata def Proprietary { + doc /* Proprietary marks an element — an interface, module, standard or data item — that a vendor + * controls rather than a consensus standard, with the rationale MOSA asks for keeping it so. */ + attribute owner : String[0..1]; + attribute rationale : String[0..1]; + } + + metadata def InterfaceControl { + doc /* InterfaceControl records the authority that controls changes to the annotated interface + * and the interface control document, if any, that publishes it. */ + attribute authority : String; + attribute document : String[0..1]; + } + + /* Requirements the strategy states */ + + requirement def MOSAObjective :> RequirementCheck { + doc /* A MOSAObjective states what the program expects its modular open systems approach to + * achieve — competition, incremental upgrade, interoperability, reuse or reduced life-cycle cost — + * with the measures that show it did. Modularity and interface requirements derive from it. */ + } + + abstract requirement mosaObjectives : MOSAObjective[0..*] nonunique :> requirementChecks; + + requirement def ModularityRequirement :> RequirementCheck { + doc /* A ModularityRequirement states how the system partitions into modules: which components are + * severable, what may be replaced independently of what, and the coupling permitted between them. */ + } + + abstract requirement modularityRequirements : ModularityRequirement[0..*] nonunique :> requirementChecks; + + requirement def InterfaceRequirement :> RequirementCheck { + doc /* An InterfaceRequirement states what a modular system interface must provide, the standard + * it must conform to, or the documentation and rights that must accompany it. */ + } + + abstract requirement interfaceRequirements : InterfaceRequirement[0..*] nonunique :> requirementChecks; + + /* Conformance assessment */ + + enum def MOSAConformanceCriterion { + doc /* The criteria a MOSA conformance assessment judges a program against, after the assessment + * criteria of the MOSA Implementation Guidebook. */ + objectives; + keyInterfaces; + standardsCompliance; + modules; + modularity; + openness; + lifeCycleCharacteristics; + conformance; + } + + metadata def MOSAConformance { + doc /* MOSAConformance records the assessed status of the annotated element or package against one + * conformance criterion, with the evidence the assessment rests on. */ + attribute criterion : MOSAConformanceCriterion; + attribute status : StatusKind; + attribute evidence : String[0..1]; + } + + /* Package template: MOSAPackage records which pillar of the approach a package serves. */ + + enum def MOSAPillar { + doc /* The five pillars of the MOSA Implementation Guidebook. */ + modularDesign; + keyInterfaces; + openStandards; + conformance; + enablingEnvironment; + } + + metadata def MOSAPackage { + doc /* Classifies a package by the MOSA pillar whose artefacts it holds. */ + :> annotatedElement : SysML::Package; + attribute pillar : MOSAPillar; + attribute description : String[0..1]; + } + + /* Viewpoints and views: the approach's products, as view conditions over its keywords */ + + concern def ModularityConcern { + doc /* How the system partitions into a platform, major system components and modular systems that + * can be separated, replaced and recombined. */ + } + + concern def InterfaceOpennessConcern { + doc /* Which boundaries between modules are designated modular system interfaces, and whether each is + * verified against a consensus standard or documented and controlled in the open. */ + } + + concern def TechnicalDataRightsConcern { + doc /* Whether the rights held in each component's technical data let it be competed, upgraded or + * replaced, and which elements remain proprietary and why. */ + } + + concern def ConformanceConcern { + doc /* Whether the program's objectives, modules, interfaces and standards meet the conformance + * criteria of the approach. */ + } + + viewpoint def ModularDesignViewpoint { + doc /* The modular structure of the system, as the architect and the program office see it. */ + frame concern : ModularityConcern; + } + + viewpoint def ModularInterfaceViewpoint { + doc /* The modular system interfaces and the standards they conform to, as an interface control + * working group sees them. */ + frame concern : InterfaceOpennessConcern; + } + + viewpoint def TechnicalDataViewpoint { + doc /* Data rights and proprietary elements, as the contracting officer and the competition + * planner see them. */ + frame concern : TechnicalDataRightsConcern; + } + + viewpoint def ConformanceViewpoint { + doc /* The MOSA requirements and the assessed conformance against them. */ + frame concern : ConformanceConcern; + } + + view def ModularDecompositionView :> BrowserView { + doc /* Tree of the major system platform, its major system components and their modular systems. */ + satisfy ModularDesignViewpoint; + filter @MajorSystemPlatformMetadata or @MajorSystemComponentMetadata or @ModularSystemMetadata; + render asTreeDiagram; + } + + view def ModularInterfaceView :> InterconnectionView { + doc /* Interconnection diagram of the major system components and modular systems with the modular + * system interfaces between them. */ + satisfy ModularInterfaceViewpoint; + filter @MajorSystemPlatformMetadata or @MajorSystemComponentMetadata or @ModularSystemMetadata or @ModularSystemInterfaceMetadata; + render asInterconnectionDiagram; + } + + view def InterfaceRegisterView :> GridView { + doc /* Table of the modular system interfaces. */ + satisfy ModularInterfaceViewpoint; + filter @ModularSystemInterfaceMetadata; + render asElementTable; + } + + view def StandardsView :> GridView { + doc /* Table of the standards the model names, consensus-based or not. */ + satisfy ModularInterfaceViewpoint; + filter @StandardMetadata or @ConsensusStandardMetadata; + render asElementTable; + } + + view def ProprietaryElementsView :> GridView { + doc /* Table of the elements marked proprietary. */ + satisfy TechnicalDataViewpoint; + filter @Proprietary; + render asElementTable; + } + + view def DataRightsView :> GridView { + doc /* Table of the elements whose data rights are recorded. */ + satisfy TechnicalDataViewpoint; + filter @DataRights; + render asElementTable; + } + + view def MOSARequirementsView :> GridView { + doc /* Table of the MOSA objectives and the modularity and interface requirements. */ + satisfy ConformanceViewpoint; + filter @MOSAObjectiveMetadata or @ModularityRequirementMetadata or @InterfaceRequirementMetadata; + render asElementTable; + } + + view def ConformanceView :> GridView { + doc /* Table of the elements carrying a conformance assessment. */ + satisfy ConformanceViewpoint; + filter @MOSAConformance; + render asElementTable; + } + + /* Document queries: the registers an interface control document tabulates. Each walks the + * members owned below root, so a document binds root to a usage that declares the elements. */ + + calc def ModularSystemInterfaces :> Query { + doc /* The modular system interfaces declared below root: every interface definition or usage + * that conforms to ModularSystemInterface, whether it carries the keyword itself or is typed by + * a definition that does. */ + in root : Element; + WhereType( + source = Descendants(source = root, maxDepth = 16), + type = "MOSA::ModularSystemInterface" + ) + } + + calc def InterfaceRegister :> Query { + doc /* One row per modular system interface below root: name, type, characteristics and documentation. */ + in root : Element; + Project( + source = ModularSystemInterfaces(root = root), + properties = ("name", "type", "characteristics", "documentation") + ) + } + + calc def Standards :> Query { + doc /* The standards declared below root: every item that conforms to Standard. */ + in root : Element; + WhereType( + source = Descendants(source = root, maxDepth = 16), + type = "MOSA::Standard" + ) + } + + calc def StandardsRegister :> Query { + doc /* One row per standard below root: name, organisation, identifier, version and registry entry. */ + in root : Element; + Project( + source = Standards(root = root), + properties = ("name", "organization", "identifier", "version", "registry") + ) + } + + calc def ProprietaryElements :> Query { + doc /* The elements below root marked proprietary. */ + in root : Element; + WhereMetadata( + source = Descendants(source = root, maxDepth = 16), + 'metadata' = "MOSA::Proprietary" + ) + } + + calc def ProprietaryRegister :> Query { + doc /* One row per proprietary element below root: name, type and documentation. */ + in root : Element; + Project( + source = ProprietaryElements(root = root), + properties = ("name", "type", "documentation") + ) + } + + calc def DataRightsRegister :> Query { + doc /* One row per element below root whose data rights are recorded: name, type and documentation. */ + in root : Element; + Project( + source = WhereMetadata( + source = Descendants(source = root, maxDepth = 16), + 'metadata' = "MOSA::DataRights" + ), + properties = ("name", "type", "documentation") + ) + } + + /* Interface control document: a document definition to specialize, with the registers above as its tables */ + + abstract part def InterfaceControlDocument :> Document { + doc /* An InterfaceControlDocument publishes the modular system interfaces of a system, the + * standards they conform to and the rights held in them, as MOSA asks of a program's interface + * documentation. Specialize it and add sections whose tables run InterfaceRegister, + * StandardsRegister, DataRightsRegister and ProprietaryRegister over the system's root: + * `part def VehicleICD :> InterfaceControlDocument { part interfaces : Section { part register : Table { + * calc rows : InterfaceRegister { in :>> root = vehicle; } } } }`. */ + :>> title default = "Interface Control Document"; + } + + /* Semantic metadata: the user-defined keywords of the approach */ + + metadata def MajorSystemPlatformMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = majorSystemPlatforms meta SysML::Usage; + } + + metadata def MajorSystemComponentMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = majorSystemComponents meta SysML::Usage; + } + + metadata def ModularSystemMetadata :> SemanticMetadata { + :> annotatedElement : SysML::PartDefinition; + :> annotatedElement : SysML::PartUsage; + :>> baseType = modularSystems meta SysML::Usage; + } + + metadata def ModularSystemInterfaceMetadata :> SemanticMetadata { + :> annotatedElement : SysML::InterfaceDefinition; + :> annotatedElement : SysML::InterfaceUsage; + :>> baseType = binaryModularSystemInterfaces meta SysML::Usage; + } + + metadata def KeyInterfaceMetadata :> ModularSystemInterfaceMetadata { + doc /* KeyInterfaceMetadata is the practitioner's name for a modular system interface the program + * has chosen to manage: "key interface" is not a statutory term, so a key interface is a modular + * system interface first, and every view and check treats it as one. */ + } + + metadata def StandardMetadata :> SemanticMetadata { + :> annotatedElement : SysML::ItemDefinition; + :> annotatedElement : SysML::ItemUsage; + :>> baseType = standards meta SysML::Usage; + } + + metadata def ConsensusStandardMetadata :> StandardMetadata { + :>> baseType = consensusStandards meta SysML::Usage; + } + + metadata def ConformantMetadata :> SemanticMetadata { + :> annotatedElement : SysML::Usage; + :>> baseType = conformingElements meta SysML::Usage; + } + + metadata def ConformedStandardMetadata :> SemanticMetadata { + :> annotatedElement : SysML::Usage; + :>> baseType = conformedStandards meta SysML::Usage; + } + + metadata def StandardConformanceMetadata :> SemanticMetadata { + :> annotatedElement : SysML::ConnectionDefinition; + :> annotatedElement : SysML::ConnectionUsage; + :>> baseType = standardConformances meta SysML::Usage; + } + + metadata def MOSAObjectiveMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = mosaObjectives meta SysML::Usage; + } + + metadata def ModularityRequirementMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = modularityRequirements meta SysML::Usage; + } + + metadata def InterfaceRequirementMetadata :> SemanticMetadata { + :> annotatedElement : SysML::RequirementDefinition; + :> annotatedElement : SysML::RequirementUsage; + :>> baseType = interfaceRequirements meta SysML::Usage; + } +} From 19a8dfe33c8e98a7d04777354120ceafb497ce1f Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Fri, 11 Sep 2026 16:26:18 +0000 Subject: [PATCH 21/91] feat(libs): let MOSA registers take the depth they walk below root Co-Authored-By: jason.han --- libraries/MOSA.sysml | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/libraries/MOSA.sysml b/libraries/MOSA.sysml index afb9e7a..444c790 100644 --- a/libraries/MOSA.sysml +++ b/libraries/MOSA.sysml @@ -18,6 +18,7 @@ library package MOSA { * libraries, re-exported here. */ + private import ScalarValues::Integer; private import ScalarValues::String; private import Metaobjects::SemanticMetadata; private import KerML::Root::Element; @@ -354,16 +355,17 @@ library package MOSA { render asElementTable; } - /* Document queries: the registers an interface control document tabulates. Each walks the - * members owned below root, so a document binds root to a usage that declares the elements. */ + /* Document queries: the registers an interface control document tabulates. Each walks depth + * ownership levels below root and omits what lies deeper; a document binds root and, if need be, depth. */ calc def ModularSystemInterfaces :> Query { doc /* The modular system interfaces declared below root: every interface definition or usage * that conforms to ModularSystemInterface, whether it carries the keyword itself or is typed by * a definition that does. */ in root : Element; + in depth : Integer = 16; WhereType( - source = Descendants(source = root, maxDepth = 16), + source = Descendants(source = root, maxDepth = depth), type = "MOSA::ModularSystemInterface" ) } @@ -371,8 +373,9 @@ library package MOSA { calc def InterfaceRegister :> Query { doc /* One row per modular system interface below root: name, type, characteristics and documentation. */ in root : Element; + in depth : Integer = 16; Project( - source = ModularSystemInterfaces(root = root), + source = ModularSystemInterfaces(root = root, depth = depth), properties = ("name", "type", "characteristics", "documentation") ) } @@ -380,8 +383,9 @@ library package MOSA { calc def Standards :> Query { doc /* The standards declared below root: every item that conforms to Standard. */ in root : Element; + in depth : Integer = 16; WhereType( - source = Descendants(source = root, maxDepth = 16), + source = Descendants(source = root, maxDepth = depth), type = "MOSA::Standard" ) } @@ -389,8 +393,9 @@ library package MOSA { calc def StandardsRegister :> Query { doc /* One row per standard below root: name, organisation, identifier, version and registry entry. */ in root : Element; + in depth : Integer = 16; Project( - source = Standards(root = root), + source = Standards(root = root, depth = depth), properties = ("name", "organization", "identifier", "version", "registry") ) } @@ -398,8 +403,9 @@ library package MOSA { calc def ProprietaryElements :> Query { doc /* The elements below root marked proprietary. */ in root : Element; + in depth : Integer = 16; WhereMetadata( - source = Descendants(source = root, maxDepth = 16), + source = Descendants(source = root, maxDepth = depth), 'metadata' = "MOSA::Proprietary" ) } @@ -407,8 +413,9 @@ library package MOSA { calc def ProprietaryRegister :> Query { doc /* One row per proprietary element below root: name, type and documentation. */ in root : Element; + in depth : Integer = 16; Project( - source = ProprietaryElements(root = root), + source = ProprietaryElements(root = root, depth = depth), properties = ("name", "type", "documentation") ) } @@ -416,9 +423,10 @@ library package MOSA { calc def DataRightsRegister :> Query { doc /* One row per element below root whose data rights are recorded: name, type and documentation. */ in root : Element; + in depth : Integer = 16; Project( source = WhereMetadata( - source = Descendants(source = root, maxDepth = 16), + source = Descendants(source = root, maxDepth = depth), 'metadata' = "MOSA::DataRights" ), properties = ("name", "type", "documentation") From 4b2d9dfaf53006742ca2e8f033a8d6282dd4c8e7 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 12 Sep 2026 05:35:38 +0000 Subject: [PATCH 22/91] feat(view): add Graphviz DOT render form Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 625b51a..3b6cb58 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -183,6 +183,9 @@ library package DocumentQueries { attribute kind : String[0..1]; /* direction: "TB", "LR", "RL" or "BT", for kinds drawn as graphs. */ attribute direction : String[0..1]; + /* form: "mermaid" (the default) or "dot", the diagram source a + * graph-shaped kind is written as; a table is always a table. */ + attribute form : String[0..1]; ref source : Element[0..1]; } } From b3aa588c3a53bde73819f19f27d840d826b13f39 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 12 Sep 2026 05:42:05 +0000 Subject: [PATCH 23/91] feat(libs): add the DiagramLayout metadata library Co-Authored-By: jason.han --- libraries/DiagramLayout.sysml | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 libraries/DiagramLayout.sysml diff --git a/libraries/DiagramLayout.sysml b/libraries/DiagramLayout.sysml new file mode 100644 index 0000000..d48c4b4 --- /dev/null +++ b/libraries/DiagramLayout.sysml @@ -0,0 +1,30 @@ +standard library package DiagramLayout { + doc /* Diagram geometry in notation: where a view draws an element, the + * waypoints an edge is drawn through and the extent of the drawing + * surface. Units are pixels, y down, origin at the top left. + * Non-normative OpenSysML extension, proposed for standardization; + * see the design record. */ + + metadata def Layout { + doc /* Where the annotated element is drawn: the top-left corner of its + * box, an optional fixed size, and whether its body is folded. */ + attribute x : ScalarValues::Real; + attribute y : ScalarValues::Real; + attribute width : ScalarValues::Real[0..1]; + attribute height : ScalarValues::Real[0..1]; + attribute collapsed : ScalarValues::Boolean[0..1]; + } + + metadata def Route { + doc /* The waypoints a connection, transition, succession or flow is + * drawn through, in order, flattened as x0, y0, x1, y1, ... */ + attribute points : ScalarValues::Real[0..*] ordered; + } + + metadata def Canvas { + doc /* The unit and extent of a view's drawing surface. */ + attribute unit : ScalarValues::String[0..1]; + attribute width : ScalarValues::Real[0..1]; + attribute height : ScalarValues::Real[0..1]; + } +} From c83f16a5dc340ee81b246cc80c84539534cdbb5e Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 12 Sep 2026 06:48:58 +0000 Subject: [PATCH 24/91] fix(semantics): let metadata body declarations redefine nonunique features A metadata body declaration without a redefinition clause redefines the metadata type's feature of its name, so the value uniqueness check now follows that implicit redefinition and honours a nonunique target. Route.points in DiagramLayout is declared nonunique, as flattened waypoint lists repeat coordinates along axis-aligned segments. Co-Authored-By: jason.han --- libraries/DiagramLayout.sysml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/DiagramLayout.sysml b/libraries/DiagramLayout.sysml index d48c4b4..52454ba 100644 --- a/libraries/DiagramLayout.sysml +++ b/libraries/DiagramLayout.sysml @@ -18,7 +18,7 @@ standard library package DiagramLayout { metadata def Route { doc /* The waypoints a connection, transition, succession or flow is * drawn through, in order, flattened as x0, y0, x1, y1, ... */ - attribute points : ScalarValues::Real[0..*] ordered; + attribute points : ScalarValues::Real[0..*] ordered nonunique; } metadata def Canvas { From e0ac06157ce1055af5ce0b1d2e6c992ae27804d3 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 12 Sep 2026 07:48:54 +0000 Subject: [PATCH 25/91] refactor(docrender): choose the diagram form at render time, not in the model Remove the form attribute from DocumentQueries::Diagram and its carriage through docplan and docir: a Diagram block states what is drawn, not the notation. The Markdown and HTML backends take the form as a render option (MarkdownOptions.DiagramForm, HTMLOptions.DiagramForm), Mermaid by default, applied to every graph-shaped diagram of the document while a table stays a table. The CLI exposes it as -diagram-form on -render-document and -render-documents in every -doc-form, the REPL as %render-document [mermaid|dot], the LSP as diagramForm on opensysml/renderDocument; RenderDocument over gRPC keeps the default. Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 3 --- 1 file changed, 3 deletions(-) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 3b6cb58..625b51a 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -183,9 +183,6 @@ library package DocumentQueries { attribute kind : String[0..1]; /* direction: "TB", "LR", "RL" or "BT", for kinds drawn as graphs. */ attribute direction : String[0..1]; - /* form: "mermaid" (the default) or "dot", the diagram source a - * graph-shaped kind is written as; a table is always a table. */ - attribute form : String[0..1]; ref source : Element[0..1]; } } From 8b8f444ca54696d00d8300d1489493be894f5731 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sun, 13 Sep 2026 06:37:55 +0000 Subject: [PATCH 26/91] feat(view): draw DOT in the Pilot's Standard B&W style with named palettes The DOT form now draws as the OMG SysML v2 Pilot Implementation's PlantUML visualizer does, after the sysmlbw skin by Hisashi Miyashita (Mgnite Inc.): Helvetica, white fills, Open-MBEE/OpenSysML#181818 thin lines, square definitions and rounded usages, the keyword line in italics, cluster border widths per the skin, connections at penwidth 3 and unnamed pseudo-states as the filled black dot. Geometry, IDs, labels, escaping, routes, anchors and ordering are unchanged. A view.Palette (okabe-ito, tol-bright, tol-muted, tol-light, brewer-set2, brewer-dark2, viridis, cividis) fills nodes by keyword family with black text kept at WCAG AA contrast; it travels with the direction in one view.Options through the Diagram document block, -render-palette, %render and the LSP render request. Mermaid notes a palette as not represented; unknown names are one typed error on every surface. Co-Authored-By: jason.han --- libraries/DocumentQueries.sysml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/libraries/DocumentQueries.sysml b/libraries/DocumentQueries.sysml index 625b51a..7d82893 100644 --- a/libraries/DocumentQueries.sysml +++ b/libraries/DocumentQueries.sysml @@ -183,6 +183,10 @@ library package DocumentQueries { attribute kind : String[0..1]; /* direction: "TB", "LR", "RL" or "BT", for kinds drawn as graphs. */ attribute direction : String[0..1]; + /* palette: "okabe-ito", "tol-bright", "tol-muted", "tol-light", + * "brewer-set2", "brewer-dark2", "viridis" or "cividis"; fills the + * nodes of a DOT diagram by keyword family, black and white when absent. */ + attribute palette : String[0..1]; ref source : Element[0..1]; } } From b6d6a3bd3c9645ea35dc79e7eeebdb438ef31be5 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sun, 13 Sep 2026 18:21:02 +0000 Subject: [PATCH 27/91] feat(view): add a PlantUML rendering form Add `plantuml` as the fifth view rendering form beside `text`, `markdown`, `mermaid` and `dot`. The writer emits standard PlantUML from the rendering model for the tree, interconnection, state, action and sequence kinds, with the OMG SysML v2 Pilot visualizer's black-and-white style inlined as a `