Cases/Blue Book

Evidence boundary: This report documents the technical reasoning and local closed-loop tests behind Liangding Yuan's personal research project, AI4MBSE. Ark and AI4MBSE are project codenames, not incorporated businesses, companies, or operating organizations. Screenshots and sample data come from local personal experiments and have not undergone an independent engineering audit.

Use boundary: This report is published for technical learning and academic exchange. It does not describe a software product, commercial solution, or project-delivery capability. Republishing it as an enterprise case or commercial claim would misrepresent the work.

Research at a glance

1. For non-MBSE readers: a model is more than a diagram

SysML represents the composition, behavior, requirements, and relationships of a complex system. Tools such as MagicDraw and Cameo maintain an engineering repository and display diagrams over that repository. A diagram is one view of the model.

A block-definition diagram may show a turnstile controller and a card reader. The repository also stores stable identifiers, ownership, type, and relationship endpoints. Correct box placement on a canvas does not prove that the relationship endpoints resolve or that the elements were written to the intended package.

AI4MBSE is an experimental prototype documented by Liangding Yuan on his personal technical site, mbse.ltd. It studies writes to authoritative engineering models. Later design, simulation, review, and documentation can consume that state, so acceptance has to inspect both the repository and the canvas.

The report uses one compact request throughout:

In the "Turnstile Control" package, create a use-case diagram containing Card Entry, QR Entry, and Administrator Override.

Before planning, the system must know which operation the user requested, which diagram type applies, and which existing project location should receive the change.

2. Why one large response leaves structural defects

An early path produced elements, relationships, and view data in one model response. It reduced calls and made failure difficult to isolate.

• An element name may be plausible while its owner does not exist.
• A relationship may read well while an endpoint ID refers to no accepted element.
• Three objects may reach the repository while the canvas displays only two.
• The user may name three use cases, the plan may contain two, and the operation may still report success.

Repairing the entire response could also alter correct portions. The research prototype therefore divides the main path into element, relationship, and view stages so each artifact can be checked before the next stage begins.

3. Connect three typed plans

The entry step converts the request into a job card with an operation, diagram type, and project scope.

Each stage consumes only accepted upstream artifacts.

An ADPS reconstruction of the job state follows.

ModelingJob
  action: chat | create | modify
  diagram_type: use_case | bdd | ibd | state | ...
  scope_ref: stable project reference | pending
  stage: intent | elements | relations | view | validated | applied
  element_plan: typed elements with stable references
  relation_plan: typed edges whose endpoints resolve
  view_plan: projection over accepted model objects
  outcome: applied | applied_with_warnings | blocked | noop
  writeback_receipt: state delta + rollback handle

ADPS describes the sequence as a typed intermediate-representation chain. In practical terms, a downstream stage reads checkable fields, types, and references rather than free-form upstream prose.

Three separate agents can implement the stages, as can three functions in one runtime. Input boundaries, isolated failure, and data contracts provide the engineering value; process count does not.

4. Process one diagram per operation

"Complete the turnstile model" has no stable boundary. It may require requirement, use-case, block-definition, internal-block, and state diagrams. An early deviation can propagate through later diagrams.

The research prototype limits one operation to:

one diagram type + one resolved project location.

That limit defines the write scope, pre-write acceptance set, rollback change set, and smallest regression test. The user receives one diagram, a change summary, and a rollback action.

This boundary also limits the impact of a defect. Branch merging, concurrent project writes, permission partitions, and long transactions remain outside the published case.

5. Pause the job when the project location is ambiguous

"Turnstile Control" may match multiple packages or none, so the runtime queries the project index first. A unique allowed match proceeds, a small candidate set goes to user selection, and no credible match asks for a more precise name or a separately created scope.

The system does not default to the project root or silently create a parent package tree.

While waiting, a pending operation stores action, diagram_type, candidate scopes, current stage, and available choices. A later response resumes at scope resolution instead of rerunning the complete intent and planning path.

The durable job provides resumability. The dialog only collects the missing fact.

6. Check explicit facts before write-back

The study groups recurring defects into conditions that program logic can verify. This report calls them write-back checks: deterministic conditions that must hold before an authoritative repository changes.

An operation ends in one of four states.

7. Assign program checks and model review to different questions

An early local experiment tested generation, model review, revision, and another review. Three issues appeared: review instructions diverged from the tool schema, latency and cost increased, and long comments did not improve write-back usability directly.

The current prototype removes post-write model self-review. It retains at most one bounded repair before assembly and gives write admission to program checks.

Reflection remains useful for semantic quality and cross-project improvement. Program checks own structural correctness. The choice follows computability, side-effect timing, and acceptable user wait.

8. Translate types explicitly across planning and host tools

Planning, a host API, and a write-back receipt may use different type names. The model may choose a fine domain name, the MagicDraw or Cameo API may use a metamodel name, and an import layer may return a normalized coarse type. Exact string comparison can reject a valid result or accept a coarse type in the wrong diagram.

The adapter therefore needs an explicit translation table.

planning type
  -> canonical domain type
  -> host metamodel type
  -> returned write-back type

The table varies by diagram type and host adapter. Logs retain the original and normalized values. A conversion defect can then be assigned to the adapter or profile rather than recorded generically as model hallucination.

ADPS currently catalogs this mechanism as a vocabulary-equivalence layer. Implementations should use the terminology familiar to their domain team.

9. Give each stage only the project context it needs

The full project tree, rules for every diagram type, and complete conversation history do not belong in every model call. The study applies five constraints.

1. Inject only the active diagram profile.
2. Produce one stable business summary for relationship and view stages.
3. Supply nearby packages, elements, and reusable objects as local context; keep distant project constraints and progress as summaries.
4. Use a lighter model for intent and clarification where appropriate; reserve the primary model for element and relationship planning.
5. Let program rules perform deterministic view filtering.

This arrangement reduces the input surface of each call. The available material contains no comparative token, latency, or success-rate data, so this report records a design judgment rather than an aggregate performance result.

10. Local experiment screenshots

The following screenshots come from Liangding Yuan's local experiment environment. They explain host integration, one intent result, and one relationship write-back. They support only the runs shown and do not establish commercial readiness or a longitudinal success rate.

11. The next report should add these measurements

Results should be stratified by diagram type, create versus modify, host tool, and user experience.

12. An eight-step transfer method

1. Select one diagram type and one representative project scope.
2. Reduce the request to an operation, diagram type, and stable scope reference.
3. Separate element, relationship, and view work into typed stage artifacts.
4. Define each stage's input allowlist, output schema, and forbidden behavior.
5. List scope, type, reference, count, and state-delta conditions that program logic can decide.
6. Send all writes through one path and produce a change summary, receipt, and rollback handle.
7. Persist a pending operation for ambiguous scope; test completion, resume, cancellation, and timeout.
8. Measure false success, dangling references, and rollback completeness before expanding diagram coverage.

EDA, BIM, ERP master data, CMDB, and process-route systems can share local conditions: structures enter an authoritative repository, references must resolve, and a wrong write affects later work. Transfer the stage contracts, stable references, deterministic checks, and receipt-backed write path rather than the SysML type table.

13. Compare the three case reports

The two field cases and this personal research report support one engineering observation: exact structural coordinates should travel through traceable program state, while a model proposes intent and plans. The location of validation depends on side effects, external observability, and the available repair window. More independent evidence is needed before treating this observation as a general result.

14. Limits and ADPS mapping

This design fits bounded writes to authoritative model repositories. Reports, slide decks, and open-ended retrieval usually permit regeneration and do not require the full structural-checking path. The published case does not cover concurrent team writes, model-branch merging, permission partitions, long-transaction compensation, or safety-critical certification.

SysML v2 offers stronger semantics and standardized model access, which can reduce proprietary adapter work. Scope resolution, reference integrity, and transaction receipts remain application-runtime concerns.

Author and citation

Liangding Yuan is a Chengdu-based architect documenting a personal technical research project. He has sixteen years of development and architecture experience across workflow, search, collaboration, authorization, and knowledge systems. He now records AI-assisted MBSE and SysML learning, technical reasoning, and local experiments on mbse.ltd. AI4MBSE is his personal experimental prototype.

Personal technical site: mbse.ltd is a personal experiment site for technical learning and academic exchange.

Suggested citation: ADPS and Liangding Yuan, "Natural Language to SysML: A One-Diagram Write-Back Study," ADPS Agent Systems Blue Book, Research Report 03, v0.6, 2026.