spdx · goneall · Mar 26, 2026 · Oct 27, 2025 · Jan 7, 2026 · Jan 8, 2026
diff --git a/conformance/example1/README.md b/conformance/example1/README.md
@@ -24,6 +24,56 @@ data (digital and physical identifiers) and packaging the product:
   - Model
   - Serial Number
 
+## Demonstrated System Engineering Process and Tools
+
+### System Engineering Body of Knowledge (SEBoK)
+
+This example is attempting to follow the best practices described in the
+[Guide to the Systems Engineering Body of Knowledge (SEBoK)](https://sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK)).
+
+The SEBoK Wiki Glossary quotes the following definition for the
+[Vee (V) Model](https://sebokwiki.org/wiki/Vee_(V)_Model_(glossary)):
+
+> The technical aspect of the project cycle is envisioned as a "Vee", starting with User needs on the upper left and ending with a User-validated system on the upper right. (Forsberg and Mooz 1991)
+
+The SEBoK considers Users to be a subset of the set of Stakeholders.
+This results in approximately the following Vee Model:
+
+```
+  Stakeholder Needs
+        ^
+        \  Stakeholder Requirements <-- proven met by -- System Validations
+         \   (solution constraints)                    ^
+          \                                           /
+  +--> System Requirements <--- verified by ---- System Verifications
+  | repeat  ^                                       ^
+  | until    \  System Architecture                 /
+  | directly  \  decomposes System into            /
+  | implement  \                                  /
+  +--------- SysElement Requirements <------ sysElement Verification
+```
+
+Each resulting SysElement then is treated as a new System-of-interest (SOI)
+and is further decomposed until it is small enough to be directly implemented
+and verified.
+
+
+### International Council on System Engineering (INCOSE)
+
+This example also attempts to write requirements following the
+[International Council on Systems Engineering](https://www.incose.org/) recommendations. 
+A soft copy of their [Guide to Writing Requirements Summary Sheet](https://portal.incose.org/commerce/store?productId=commerce-merchandise%23INCOSE-GUIDEWRITINGREQSUM)
+may be purchased from the INCOSE store by non-members for $0.00 (zero).
+
+The example content is initially being captured using the open-source
+tool [StrictDoc](https://github.com/strictdoc-project/strictdoc),
+which is a FOSS software tool for technical documentation and requirements management.
+StrictDoc has been successfully used for technical documentation certified by
+the European Space Agency. It supports the following features key to this example:
+- document creators can specify their own document node types,
+- node relationship directions and trace analysis,
+- support for generating graphs from editable textual graph descriptions (Mermaid UML)
+
 
 ## Comments
 

diff --git a/conformance/example1/content/src/.gitignore b/conformance/example1/content/src/.gitignore
@@ -0,0 +1 @@
+__pycache__
diff --git a/conformance/example1/content/src/SOI/SAMPLE/interface_requirements/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/interface_requirements/sdoc/index.sdoc
@@ -0,0 +1,26 @@
+[DOCUMENT]
+MID: 43b3bf7d570d4089b3cd76a4c765cd62
+TITLE: Interface Requirements
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_interface_requirements_grammar
+
+[TEXT]
+MID: 9be29edda6c5401fbb2a05ff71cd0fd0
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: 1d78c62fa24740e49fd245550e11dd13
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - interface <https://sebokwiki.org/wiki/Interface_(glossary)>`_:
+
+- A shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics. (ISO/IEC 1993)
+
+- A hardware or software component that connects two or more other components for the purpose of passing information from one to the other. (ISO/IEC 1993)
+
+- To connect two or more components for the purpose of passing information from one to the other. (ISO/IEC/IEEE 2009)
+<<<
diff --git a/conformance/example1/content/src/SOI/SAMPLE/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/sdoc/index.sdoc
@@ -0,0 +1,51 @@
+[DOCUMENT]
+TITLE: SAMPLE
+
+[TEXT]
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+STATEMENT: >>>
+The System-of-Interest named SAMPLE is the top-level system in this example. 
+
+It is expected to be composed of the following subsystems:
+
+.. raw:: html
+
+    <pre class="mermaid">
+    ---
+    title: Topology of Systems-of-Interest
+    ---
+    stateDiagram-v2
+
+        state SAMPLE {
+            TBD_Security_Vulnerability_Reporting: TBD <br/> Security <br/> Vulnerability <br/> Reporting <br/> Server
+            TBD_Desktop_SW: TBD <br/> Desktop SW
+            TBD_Mobile_SW: TBD <br/> Mobile SW
+            TBD_Devices: TBD <br/> Device(s)
+            TBD_Cloud_SW: TBD <br/> Cloud SW
+            TBD_Digital_Component_Update_Server: TBD <br/> Digital <br/> Component <br/> Update <br/> Server
+        }
+
+    </pre>
+<<<
+
+[DOCUMENT_FROM_FILE]
+FILE: ../system_requirements/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../system_verifications/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../system_architectures/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../interface_requirements/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../system_element_requirements/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../system_element_verifications/sdoc/index.sdoc
diff --git a/conformance/example1/content/src/SOI/SAMPLE/system_architectures/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/system_architectures/sdoc/index.sdoc
@@ -0,0 +1,26 @@
+[DOCUMENT]
+MID: af66c5de119447b58b950dd710d34b8a
+TITLE: System Architecture(s)
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_system_architectures_grammar
+
+[TEXT]
+MID: 84713f51e27b4ea4bc3242a8e2f1fba7
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: 0f68a238be874bdcb25a5fbb9f9bcb5c
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - Architecture <https://sebokwiki.org/wiki/Architecture_(glossary)>`_:
+
+- fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO/IEC/IEEE 2015, Section 4.5)
+
+- The organizational structure of a system or component; the organizational structure of a system and its implementation guidelines. (ISO/IEC 2009, 1)
+
+- Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (ISO/IEC 2011, section 3.2)
+<<<
diff --git a/conformance/example1/content/src/SOI/SAMPLE/system_element_requirements/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/system_element_requirements/sdoc/index.sdoc
@@ -0,0 +1,22 @@
+[DOCUMENT]
+MID: 9a5689a75c354b019acf55761ae02ca7
+TITLE: System Element Requirements
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_system_element_requirements_grammar
+
+[TEXT]
+MID: 2f9e70c900604e35a4a61961afb6e19b
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: 49ebfa8c1d414aa2aa66aff2153c2f13
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - system element <https://sebokwiki.org/wiki/System_Element_(glossary)>`_:
+
+- A member of a set of elements that constitutes a system. A system element is a discrete part of a system that can be implemented to fulfill specified requirements. A system element can be hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, minerals), or any combination. (ISO/IEC 15288:2015)
+<<<
diff --git a/conformance/example1/content/src/SOI/SAMPLE/system_element_verifications/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/system_element_verifications/sdoc/index.sdoc
@@ -0,0 +1,30 @@
+[DOCUMENT]
+MID: 97fadfb8f97a481a8205cf619c53f4f6
+TITLE: System Element Verifications
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_system_element_verifications_grammar
+
+[TEXT]
+MID: 715801b3dc784aefab88fe5afc443e3e
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: 849ea88ccbf040bcbce53b9c15dbf7f8
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - verification <https://sebokwiki.org/wiki/Verification_(glossary)>`_:
+
+- Confirmation, through the provision of objective evidence, that specified (system) requirements have been fulfilled. (ISO/IEC 2008, section 4.38)
+
+- Verification is a set of activities that compares a system or system element against the required characteristics. This includes, but is not limited to, specified requirements, design description and the system itself. The system was built right. (ISO/IEC/IEEE 2015, 1, Section 6.4.6)
+
+- The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation. (PMI 2013)
+
+- The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (IEEE 1012-2004, 3.1.36)
+
+- Process of providing objective evidence that the software and its associated products comply with requirements for all life cycle activities during each life cycle process, satisfy standards, practices, and conventions during life cycle processes, and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities. (IEEE 829-2008, 3.1.54)
+<<<
diff --git a/conformance/example1/content/src/SOI/SAMPLE/system_requirements/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/system_requirements/sdoc/index.sdoc
@@ -0,0 +1,24 @@
+[DOCUMENT]
+MID: 85ae378632b7425589c55bed12493f99
+TITLE: System Requirements
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_system_requirements_grammar
+
+[TEXT]
+MID: caf6ea3cac33409b990281d4d820cc27
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: ccbf7caa1def41da93bd3fb1e1f1d760
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - system requirement <https://sebokwiki.org/wiki/System_Requirement_(glossary)>`_:
+
+- A statement that transforms the stakeholder, user-oriented view of desired capabilities into a technical view, of a solution that meets the operational needs of the user. (ISO/IEC/IEEE, 2015, section 6.4.2)
+
+- The System Requirement Definition process creates a set of measurable system requirements that specify, from the supplier’s perspective, what characteristics, attributes, and functional and performance requirements the system is to possess, in order to satisfy stakeholder requirements. (ISO/IEC/IEEE, 2015, section 6.4.2)
+<<<
diff --git a/conformance/example1/content/src/SOI/SAMPLE/system_verifications/sdoc/index.sdoc b/conformance/example1/content/src/SOI/SAMPLE/system_verifications/sdoc/index.sdoc
@@ -0,0 +1,30 @@
+[DOCUMENT]
+MID: 48e1355c717642e2bca757865187eda6
+TITLE: System Verifications
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_system_verifications_grammar
+
+[TEXT]
+MID: 1aa664e9e0174cea9c59734ce2a23f2a
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: ddd4ee5dd24949c6813408d550a982b3
+STATEMENT: >>>
+From `SEBoK Wiki Glossary -  verification <https://sebokwiki.org/wiki/Verification_(glossary)>`_:
+
+- Confirmation, through the provision of objective evidence, that specified (system) requirements have been fulfilled. (ISO/IEC 2008, section 4.38)
+
+- Verification is a set of activities that compares a system or system element against the required characteristics. This includes, but is not limited to, specified requirements, design description and the system itself. The system was built right. (ISO/IEC/IEEE 2015, 1, Section 6.4.6)
+
+- The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation. (PMI 2013)
+
+- The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (IEEE 1012-2004, 3.1.36)
+
+- Process of providing objective evidence that the software and its associated products comply with requirements for all life cycle activities during each life cycle process, satisfy standards, practices, and conventions during life cycle processes, and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities. (IEEE 829-2008, 3.1.54)
+<<<
diff --git a/conformance/example1/content/src/SOI/sdoc/index.sdoc b/conformance/example1/content/src/SOI/sdoc/index.sdoc
@@ -0,0 +1,19 @@
+[DOCUMENT]
+TITLE: System-of-Interest Catalog
+
+[TEXT]
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - system-of-interest <https://sebokwiki.org/wiki/System_Requirement_(glossary)>`_:
+
+- The system whose life cycle is under consideration. (ISO/IEC/IEEE 15288, 2015)
+
+- The system of interest to an observer. (von Bertalanffy, L. 1968. General system theory: Foundations, development, applications, revised ed. New York, NY: Braziller.)
+<<<
+
+[DOCUMENT_FROM_FILE]
+FILE: ../SAMPLE/sdoc/index.sdoc
diff --git a/conformance/example1/content/src/index.sdoc b/conformance/example1/content/src/index.sdoc
@@ -0,0 +1,17 @@
+[DOCUMENT]
+TITLE: SEBoK Product as System - Commodity Consumer Electronics
+
+[DOCUMENT_FROM_FILE]
+FILE: problem_space/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: system_concept_of_operations/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: system_validations/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: shared/interface_specifications/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: SOI/sdoc/index.sdoc
diff --git a/conformance/example1/content/src/problem_space/personas/sdoc/index.sdoc b/conformance/example1/content/src/problem_space/personas/sdoc/index.sdoc
@@ -0,0 +1,24 @@
+[DOCUMENT]
+MID: dba1eb04ad064dafbc9b7115c9e04985
+TITLE: Personas
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_personas_grammar
+
+[TEXT]
+MID: d495970e0ad34b9995417f85b90522f6
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: 05ec8177ef09485bab9276d64d2cc4a5
+STATEMENT: >>>
+From ISO/IEC/IEEE 24765:2017(en) Systems and software engineering - Vocabulary definition (2):
+
+  representation of a type of user that includes a concise summary of the characteristics of the user that is most informative to the design or illustrative of specific user requirements *[ISO/IEC 25063:2014 Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for usability: Context of use description]*
+
+  Note 1 to entry: A persona typically includes behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character.`
+<<<
diff --git a/conformance/example1/content/src/problem_space/sdoc/index.sdoc b/conformance/example1/content/src/problem_space/sdoc/index.sdoc
@@ -0,0 +1,28 @@
+[DOCUMENT]
+TITLE: Problem Space Catalog
+
+[TEXT]
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+STATEMENT: >>>
+The Problem Space Catalog contains Stakeholder-level content 
+(i.e., characteristics, needs and requirements) 
+that describes the potential problem space under consideration for a solution. 
+This problem space is likely larger than what will be addressed by a specific solution 
+(e.g., product, product-line, or business).
+<<<
+
+[DOCUMENT_FROM_FILE]
+FILE: ../stakeholders/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../personas/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../stakeholder_needs/sdoc/index.sdoc
+
+[DOCUMENT_FROM_FILE]
+FILE: ../stakeholder_requirements/sdoc/index.sdoc
diff --git a/conformance/example1/content/src/problem_space/stakeholder_needs/sdoc/index.sdoc b/conformance/example1/content/src/problem_space/stakeholder_needs/sdoc/index.sdoc
@@ -0,0 +1,22 @@
+[DOCUMENT]
+MID: e27425f14a3548dcbdad3a8057117401
+TITLE: Stakeholder Needs
+OPTIONS:
+  ENABLE_MID: True
+
+[GRAMMAR]
+IMPORT_FROM_FILE: @sample_stakeholder_needs_grammar
+
+[TEXT]
+MID: 8a9d00f76be647858c56f3c9a31cff0d
+STATEMENT: >>>
+SPDX-License-Identifier: Apache-2.0
+<<<
+
+[TEXT]
+MID: 695a3cb9a9bf4f30bf57f1469bc6c8eb
+STATEMENT: >>>
+From `SEBoK Wiki Glossary - stakeholder needs <https://sebokwiki.org/wiki/Stakeholder_Needs_and_Requirements_(glossary)>`_:
+
+- Stakeholder needs include elicitation of needs, wants, desires, expectations and perceived constraints of identified stakeholders. Needs concentrate on system purpose and behavior, and are described in the context of the operational environment and conditions. (ISO/IEC/IEEE 15288, 2023, Section 6.4.2)
+<<<