AI4MBSE · personal experiment prototype

AI4MBSE is a personal experiment prototype / technical exploration project (research project code only — no matching company): conversational SysML / MBSE under knowledge constraints. For technical validation and academic exchange only; no formal release.

Personal technical lab · methodology packs · UI locale · clickable local demos

What AI4MBSE is

AI4MBSE is a personal experiment prototype / technical exploration project (research project code only — no matching company). Grounded by KB notes and MBSE RAG sketches, it explores advancing one diagram at a time, reviewing checkable candidates, and writing back only after human confirmation. For technical validation and academic exchange only — no deployment, licensing, or technical service; no formal release (see the Disclaimer).

Diagrams and UI sketches below are from a local test environment with simulated data — not a real enterprise engineering project. Technical illustration only.

Problem it targets

MBSE programs stall when knowledge lives in documents, when only a few experts can navigate SysML tools, and when generic LLM chat hallucinates structure that fails review. AI4MBSE sits beside the modeling environment you already use, respects methodology rhythm, and retrieves project conventions so suggestions sound like your program — because they are constrained by your KB slices.

Core capabilities

CapabilityEngineering meaning
Conversational modelingState the sprint goal; assistant advances the active view
One diagram at a timeNine common SysML views paced by session — not whole-system generation
Methodology packsSwitch MagicGrid / OOSEM / Harmony-SE mid-session; retrieval & next-diagram hints follow
MBSE RAGRetrieve standards, examples, and rules by method + diagram type
Incremental editAfter confirm: add, rename, or remove in this turn; other views stay put
UI internationalizationSide-assistant chrome in 中文 / EN; dialogue language stays yours
Checkable candidatesInspectable structure; explicit unknowns
Human confirm → write-backPeople own baselines; AI accelerates drafting
Kernel + adaptersSwap hosts without rewriting the assistant core

Try the rhythm (no real project)

Clickable sketches of methodology packs, incremental edits, and UI locale — simulated transcript only. Not a trial, not a write-back to any model repository.

What this sketch shows

  • One diagram at a time — finish this view before jumping to the whole system.
  • Methodology packs — MagicGrid / OOSEM / Harmony-SE change retrieval focus and next-diagram hints.
  • Incremental edit — rename, add, or remove within the active session after confirmation.
  • UI internationalization — chrome locale follows 中文 / EN; dialogue language stays yours.

Deeper method notes: Methodology. Simulated cases: Cases.

UI internationalization

The host-side assistant separates UI locale from dialogue language: buttons, status, and methodology display names switch between Chinese and English, while engineers may still describe goals in either natural language. This site is fully bilingual (language switch in the nav).

Methodology packs & next-diagram hints

Teams rarely share one method. The experiment treats MagicGrid, OOSEM, and Harmony-SE as switchable packs: after a switch, retrieval focus and “suggested next diagram” chips change — rhythm, not cosmetics. See the Methodology page.

Difference from chat-only LLMs

Chat models optimize fluent language. AI4MBSE optimizes modeling rhythm: which diagram is in scope, which elements may be created, which retrieval fragments apply, and which write-back API calls are allowed after confirmation. It will refuse to silently invent trace edges or requirement IDs when the KB does not support them — experimental honesty over exaggerated claims.

Architecture: one kernel · multi-platform adapters

Common narratives say “understand human language”; this experiment still has to attach to a modeling host. AI4MBSE sketches a core library + platform adapters: capability in the kernel, UI and project landing in the host. The kernel owns dialog rhythm, knowledge constraints, and checkable candidates; adapters own side chat, confirm-then-write into the host project, and syncing host state back into the assistant context.

Capability in the kernel, UI in the host; swap platforms via adapters — not the assistant’s engineering rules.

  • KernelDialogue orchestration, intent & subflows, knowledge retrieval, candidate structure, human confirm then write-back — one main chain reusable across hosts.
  • AdaptersThin per-platform packages: modeling-tool APIs, side chat UI, or custom UI / gateway sketches. The core is not locked to one desktop tool.
  • BoundaryHosts own presentation and project landing; the kernel owns a verifiable assistant rhythm. Adapter evolution must not force rewriting the whole AI chain.

Adapter packages (current map)

HostArtifactRoleStatus
MagicDraw / Cameo ltd.mbse:ai4mbse-magicdraw First host adapter: side chat, confirm-then-write into the project In progress
SysML v2 API ltd.mbse:ai4mbse-sysmlv2 Peer host adapter sketch (same level as MagicDraw) Sketch
Capella / SysON Open modeling hosts (experiment sketch) Sketch
Custom UI / gateway Embed kernel contracts into custom UI surfaces (experiment sketch) Sketch

Diagram is architectural intent, not a shipped checklist. Focus now: harden the reusable core and the MagicDraw host adapter; more hosts join as peer packages. Writing the host project happens in the adapter after human confirmation. Technical-idea discussion only.

Relationship to the knowledge base

The KB is not a generic document pile. Curators slice content by methodology (MagicGrid, OOSEM, Harmony-SE), diagram type, and project convention. At task time, MBSE RAG pulls the smallest useful context — enough to constrain candidates, not enough to drown the session. This site also presents the KB as its own learning topic that could later feed simulation themes; see the Knowledge base page.

Typical session workflow

  1. Engineer selects host project, methodology pack, and diagram goal.
  2. Assistant retrieves KB fragments and prior model context.
  3. Candidate structure renders for review with diffs where possible.
  4. After explicit confirmation, the adapter writes into the host project (create or incremental edit).
  5. Session keeps a short action summary for later review.

Methodology awareness

Teams follow different MBSE paths. AI4MBSE does not force a single notation gimmick; it loads methodology packs so MagicGrid domains, OOSEM operational views, or Harmony-SE use cases shape retrieval and pacing. Read more on the Methodology page and explore simulated experiments.

Tooling stance

MagicDraw and Cameo remain the first adapter path under discussion; SysML v2 API is a peer adapter sketch; Capella and SysON stay as open-host experiment ideas. The narrative does not ask you to rip out tooling — adapters meet you where models live.

About demo entry points

This site does not offer online trials, booked demos, or business experience entries. The clickable “local demos” above do not connect to any real project. Personal experiments remain local.

See FAQ and the Disclaimer.

Simulated experiment examples

Author & standards context

Yuan Liangding (Chengdu, individual) writes these experiment notes, drawing on prior engineering experience and AI-assisted MBSE explorations. Public materials from INCOSE, OMG SysML v2, Capella, and SysON inform the sketches — without implying endorsement.

Why this experiment matters (research thesis)

The notes explore time-to-clarity: turning verbal agreements into reviewable SysML artifacts. Thesis for researchers: MBSE RAG + one-diagram pacing + human-in-the-loop write-back — technical idea discussion, not a sales claim.

Related technical report

Personal AI4MBSE simulation experiment report on adpsagent.com (author’s peer technical-experiment site series — not an enterprise product case).

What to read next