A Methodical Approach to AI System Modeling: Claude & Syside (Part 1)

No, I'm not the first person to experiment with SysML v2 and Claude. Still, I think this series of articles addresses an important gap: scalability.

In the first part, we’ll set up a Git-based development environment in which the AI doesn’t simply „generate SysML somehow,“ but rather operates based on a lightweight development process tailored to the example product. We derive this process from existing references such as SYSMOD and the SysML v2 specification and document it directly in the repository.

Next, we apply the first process step: We identify stakeholders and stakeholder needs, review them together, and model them in SysML v2. This lays the foundation for the following phases, in which we gradually develop the system context and use cases, system requirements, architecture, and verification and validation.

The real focus here is not so much on whether Claude can write SysML v2. What is more interesting is how AI can be integrated into a methodically managed development process in such a way that it functions consistently, transparently, and effectively, even in larger and longer-term projects.

Embedding Knowledge in AI

I recently had an exciting session with Matthias Priebe, who had created a system model with Claude. What was particularly interesting was that he had explicitly chosen SYSMOD as his method. He used the Git repository from SYSMOD for SysML v2 from Tim Weilkiens.

But this raises the question: Is that enough? Not really—the developments are simply too diverse for that. That’s why I recommend a three-layer structure:

• Bottom level: Library. A collection of relevant references on methodology, language, and tools. This includes, for example, SYSMOD, as well as the SysML v2 specification and, if necessary, tool documentation.
• Middle layer: Product class information (optional). To scale this approach, it is recommended to use a middle layer that provides a generic adaptation for a Product Category contains.
• Top layer: Product-specific methodological guide. This is the adaptation to the specific product that is being newly developed or further developed.

These layers contain not only methodological knowledge, but also knowledge of modeling languages and tools. These three elements cannot be completely separated from one another when carrying out a specific MBSE project.

Let's take a closer look at these layers.

Library

This library should be managed centrally and merely referenced by the AI.

If we want to use SYSMOD, we can not only use the Git repository, but also, for example, the SYSMOD book, which Tim has kindly made available without copy protection via Leanpub sold. To use such content legally and on a larger scale, MBSE4U also offers Institutional Licensing & Enterprise Access Please be fair and pay for the content you use.

Many AI systems cannot process e-books in EPUB format directly. However, an EPUB without copy protection is simply a ZIP file containing the book's content in formats such as HTML.

SYSMOD for SysML v2 requires the use of SysML v2. It may therefore be useful to provide additional explicit knowledge about the language, even though modern AI systems already possess a great deal of SysML knowledge.

Of course, there are other modeling languages as well. ROOM, for example, is an interesting alternative with many freely available resources. Particularly noteworthy is the ROOM Book by Bran Selic et al., which offers *Protos* for free download without DRM.

Tool-related knowledge can also be incorporated into this library. Since I use Syside Since I will be working with textual notation, this is less important for my example at first. As soon as tool-specific functions, validations, or automations become relevant, the corresponding Syside documentation should also be included in the reference base.

My library now contains:

• SYSMOD for SysML v2
• The SysML v2 Book
• OMG SysML v2 Specification: SysML/2.0/Language/PDF

Side Note: Working with Libraries

The SYSMOD for SysML v2-The library should also be integrated just like a real library. The simplest—but incorrect—way would be to simply copy the files into the project. Even if they aren't checked in, this is not recommended: The library's origin and version become unclear, and it is difficult to keep track of updates.

I see two reasonable options:

• Git Submodules: The SYSMOD repository is integrated into the project as a separate Git repository. This ensures that the exact commit to be used is specified. Updates are intentionally applied to a new revision. This works regardless of which SysML v2 tool is used.
• Sysand: Sysand is a package manager for SysML v2 and KerML, similar to Maven, npm, or pip. SYSMOD is available there as a package and can be installed using sysand add mbse4u/sysmod be included as a dependency. Conceptually, this is the cleaner solution for reusable SysML v2 libraries and, in particular, simplifies version control and dependency management.

To keep this example as tool-independent as possible, I used Git submodules. This way, the repository depends only on Git and not on an additional SysML v2 package manager. The README.md The project section describes what to keep in mind when setting up the work environment.

Adjustment by product class (optional)

To scale the approach described here, it is recommended to compile method, language, and tool information specific to the organization and the respective product class. If an organization has only one relevant product class, a single such layer is sufficient.

Wagner, for example, is a manufacturer of fire protection systems. In this context, it might make sense to distinguish between stationary systems—such as a warehouse—and mobile systems—such as a train.

For my sample project, I'm leaving this layer out.

Adaptation for Product Development

This is the information that the AI will use directly and that is stored in the repository as Markdown files. It can and should reference the underlying reference layers to avoid redundancy and duplication.

I am deliberately avoiding the term „project“ here, as it suggests that the product’s life cycle is irrelevant.

This description can now take into account specific product-related characteristics. Is this a greenfield development or a further development? What regulations must be taken into account that are not yet included in the product class information? What modeling decisions and working methods should apply to this specific product?

At this point, at the latest, information regarding the tools used and the CI process should also be included, provided that it is relevant to the specific product development.

Claude Code or Claude Chat in VS Code?

It's probably clear that a project like this shouldn't be developed in a web browser. Furthermore, in September 2026, the AI chose Claude.

Furthermore, choosing the development environment was just as simple: the only options were VS Code or one of its derivatives. I use VSCodium, mainly so that Git Copilot doesn't get in the way—it can't be turned off in VS Code.

But the next question was how exactly I would use Claude. The „obvious“ choice would be Claude Code on the console. But the Claude Extension also has its appeal. Here’s a comparison of the key aspects:

According to this table, chat is the clear winner, at least in the early stages, when a lot of work is done interactively.

Implementation

We shouldn't define the entire product development process in one go. Instead, I would develop it step by step. The following README.md in the directory method reflects this approach.

AI-Specific Instructions

Nothing said so far assumes the use of any specific AI. At present (September 2026), Claude is the obvious choice, but that may change.

My recommendation is to keep the project AI-neutral by creating an AGENTS.md file.

For Claude, there could be a very short CLAUDE.md file in the root directory:

CLAUDE.md

Read and follow `AGENTS.md`.

Example Product: The Smart Fan

Anyone who remembers this summer’s heat waves will surely be excited about the sample project: the smart desk fan. A mockup can be seen in the cover image (though, of course, it’s not meant to give away the solution). The device is designed to cool a person at their desk and automatically adjust the airflow to their position.

This example is a greenfield product. This means there is no existing architecture that needs to be taken into account. At the same time, it is intentionally a small-scale demonstrator. Issues such as functional safety, certification, or extensive regulatory requirements do not play a major role at this stage, but we can still consider them as examples.

This means we don't need a comprehensive development methodology either. Instead of adopting a methodology in its entirety, I'd like to tailor it to this product. The following applies here: KISS Principle: As little process and modeling as possible, but enough to ensure that development is traceable and carried out in a methodologically sound manner.

Create a Development Process

The first step, therefore, is to derive a simple, product-specific development process from the references. This is documented in method/01-development-process.md.

Here is the prompt for generating the method:

Prompt for generating method/01-development-process.md

Create `method/01-development-process.md` for this repository.
Context: We are developing a small, greenfield demonstration product: an intelligent desktop cooling device.
The product should ultimately provide cooling to a person at a desk and adapt the airflow to the person’s position. A possible later implementation could use a fan, sensors, and an automatically adjustable orientation, but the development process must not assume this solution.
This is intentionally a small educational project used to demonstrate AI-assisted systems engineering with SysML v2.
Project characteristics:
- Greenfield development
- Small product and small model
- Educational/demonstration purpose
- Few relevant regulatory constraints
- SysML v2 is used for system modeling
- SYSMOD is the primary methodological reference
- Syside is used as the modeling environment
- Follow the KISS principle
- Avoid process steps and artifacts that do not add value to this example
- Maintain a clear progression from user needs toward architecture
- Do not introduce solution decisions prematurely
Use the reference material described in `references/README.md`.
Follow the principles defined in `method/README.md`.
Consult the methodological sources before defining the development process.
Do not include detailed guidance for individual engineering activities. These will be documented in separate files as the project progresses, for example:
- `02-requirements.md`
- `03-system-context.md`
- ...
This document should define only the minimum process required for this product:
- the main development activities;
- their sequence;
- the expected result of each activity;
- important tailoring decisions.
Do not describe detailed inputs, outputs, completion criteria, or activity guidance unless they are necessary to understand the overall process.
Keep the document brief. It is better to omit information than to be overly comprehensive.
For important methodological choices, cite the source material that supports the choice.
Before writing the file, briefly outline the proposed process and the methodological sources used so that the tailoring decision can be reviewed.

For this task, I used Opus 5 set to „Medium,“ which resulted in the following document:

The result clearly illustrates what is meant by „tailoring“: Claude reduced the eleven SYSMOD activities to five. In doing so, he did not simply eliminate steps, but rather combined them or deliberately classified them as unnecessary. Project framing is considered a given; system context and use cases are combined; a separate early system concept is omitted; and the architecture is initially treated as a single activity. At the same time, the essential development steps remain intact: from stakeholders and needs, through context and requirements, to architecture, and finally to verification and validation. For me, this is a good example of how AI can tailor methodological knowledge to a specific development project.

Step 1: Stakeholders and Needs

All right, our tailored development process begins with “Stakeholders and Needs.” Before we consider which stakeholders and needs are relevant to our example, we need to determine how we want to represent them methodically and in SysML v2.

To this end, we are creating another methodological guide. Here, for the first time, we are combining the method with concrete SysML v2 modeling. To do this, Claude must consult methodological sources such as SYSMOD and The SysML v2 Book as well as consult the SysML v2 language reference.

Prompt for generating method/02-stakeholders-and-needs.md

Create `method/02-stakeholders-and-needs.md` for this repository.
Context:
The first activity in `method/01-development-process.md` is "Stakeholders and Needs".
Before identifying the actual stakeholders and needs for this product, define how this activity should be performed and how its results should be represented in SysML v2.
Use:
- `method/README.md`
- `method/01-development-process.md`
- `references/README.md`
Consult the relevant methodological sources, especially SYSMOD and The SysML v2 Book.
Consult the SysML v2 specification when language semantics or notation are involved.
Keep the guidance minimal and specific to this small educational project.
The document should define:
- how relevant stakeholders are identified;
- what qualifies as a stakeholder need;
- how needs should be formulated;
- how solution bias should be avoided;
- how stakeholders and needs are represented in SysML v2;
- any minimal traceability required at this stage.
Do not identify the actual stakeholders or needs yet.
For important methodological or language choices, reference the supporting source material.
Before writing the document, briefly state the proposed approach and the sources used so that the method can be reviewed.

Start early, check regularly

Especially in the beginning, the AI should be strictly guided. If it’s already heading in the wrong direction when it comes to stakeholders or needs, every subsequent step builds on that. This quickly results in a lot of material that is well-written but technically inappropriate. That costs time and tokens, because entire chains of needs, requirements, and architectural elements have to be corrected later on.

That’s why I incorporate brief review points between the content-related steps: first, propose, review, and approve stakeholders; then, identify, review, and approve needs; and only then do I proceed with modeling. The AI continues to handle the bulk of the work, but the direction is monitored early on and on an ongoing basis.

Incorrect SysML v2 syntax, on the other hand, is usually just a minor annoyance because it can be quickly identified and corrected with the help of tools.

It's not worth listing the prompts one by one here. But these are the steps that also illustrate the level of detail at which I work with the AI:

1. Identify stakeholders. Claude proposes, based on the Project Frame and 02-stakeholders-and-needs.md I propose a group of relevant stakeholders that is as small as possible. I review, scrutinize, and confirm this group.
2. Identify needs. Claude will define the requirements for the confirmed stakeholders. I will focus in particular on ensuring that the requirements are solution-neutral, complete, and necessary.
3. Modeling in SysML v2. Claude is only now modeling the approved stakeholders and needs according to the methodology guide. I'm reviewing the model and the Syside validation.
4. Apply changes. Claude shows the changes and the key decisions. I review the diff and commit the changes.

Modeling: With and Without Syside

To explore Claude's capabilities and limitations, I ran Step 3 using the following prompt, but without having installed Syside beforehand. What's interesting here is the sentence at the end: „Validate the result with the available Syside tooling if possible.“

Prompt Step 3: Modeling in SysML v2.

Model the stakeholders and needs in SysML v2 according to
method/02-stakeholders-and-needs.md.
Create the necessary model files, use the SYSMOD library as specified, and keep the model minimal.
Validate the result using the available Syside tools, if possible.
Then demonstrate what was created and report any validation issues.

Claude creates the model, but is unable to run the validation because Syside is not installed. It turns out that the generated model is flawed. The error was trivial: In concern that must subject come first. But without Syside, Claude couldn't find the error.

The generated models can be found on GitHub. There is also a script there that generates MD tables from SysML. Even though Syside allows for table-based visualization (with the paid Modeler), I wanted a lightweight solution for easy sharing (read-only) that would let me insert tables here on the blog, among other places.

Result: Stakeholders and Stakeholder Needs

Here are the tables listing the stakeholders and their needs:

Stakeholders

Priority is determined according to the SYSMOD stakeholder priority map.

Stakeholder Needs

Visualize Requirements with Syside

To create the table of requirements above, I cheated a little: I generated it using a small Python script (also on GitHub). Of course, most tools can display this information as well, but the default view is a chart, not a table. Here’s the visualization using Syside:

It is clear that this view neither scales nor offers the same level of utility as the table view.

Fortunately, SysML v2 offers the ability to create views. However, experimenting with this has been frustrating: For example, it is not possible—or only very difficult—to include stakeholders in the view as shown above. But even if that were to work, the view would be locked into the selected tool. This creates friction, which in turn slows down the Design in Progress (DIP) workflow.

So here’s my practical recommendation: Find out which stakeholders need what information and when. Then find the best way to ensure this happens. This could mean retrieving the data on demand from the database via the SysML v2 API and mirroring it (read-only) in other systems. Or it could be a simple script, which is well-suited for a straightforward educational project like this one.

A Look Ahead to the Next Installments

I will continue working on this project over the next few weeks and will publish the results when they are ready. In doing so, I will follow the development process. Coming soon:

• System Context and Use Cases: Model system boundaries, actors, and relevant interactions.
• System Requirements: Derive verifiable system requirements from stakeholder needs and ensure they are traceable.
• System Architecture: Develop behaviors and structures that meet these requirements.
• Verification and Validation: Provide supporting documentation to demonstrate that requirements are met and stakeholder needs are addressed.

The focus should always be on the benefits for stakeholders. The model is not an end in itself. Modeling should be limited to what is necessary to make better decisions, reveal interrelationships, and support stakeholder value.