In System-as-Code Fest 2026-H1, the speakers were not pitching proof of concepts. They were describing SysML v2 systems already running in production. Ten systems engineering leaders presented SysML v2 work spanning space, defense, medical devices, and finance, each grounded in production adoption rather than exploratory proof of concept.

The Fest (a hybrid gathering, held online and on-site in Detroit with our co-host from System Strategy, Inc.) drew more than 300 registrants. Participants tuned in from India, Japan, the EU, and the US, several joining outside their normal working hours on a Friday evening.

What follows are notes from the room: what stood out, surprised, or stuck long after the Fest was over. We hereby cover the talks related to the topic of integrated workflows and automation. This will be a series of 2 posts; the upcoming blog post will focus on the remaining 5 talks, connected to methodologies.

1. Anduril closes the loop in Product Engineering with Syside

Cole Smith, a systems engineer at Anduril Industries, used his talk, Modernizing Model-Based Workflows: Automated Feedback for All Stages of System Development/Integration, to walk through a problem familiar to those doing systems engineering at software speed: traditional MBSE (model-based systems engineering) tooling tends to isolate the systems engineer's model from domain engineer's workflow, making it nearly impossible to close the loop from that model back to the real system.

Problem: isolated artefacts and documents

At Anduril, that isolation showed up as scattered documentation, growing technical debt, and tests written to check functionality without ever tying back to a requirement or its metric.

The fix: a four-layer stack

Smith's team built an entire SysML v2 ecosystem on top of Sensmetry's Syside to connect the model to Anduril's internal infrastructure:

• A shared foundations layer of libraries that abstracts away the Syside API and handles common parsing and typing.
• A model layer where the SysML v2 model itself lives alongside custom analysis tooling.
• A CI (continuous integration) layer that auto-generates artifacts, documents, safety analyses, and raw test results every time the model changes, syncing everything through webhooks.
• A front-end layer: an interactive dashboard that gives non-modelers a way into the same data.

Anduril’s system development goes across three phases:

1. Early model development. Engineers work through a CLI that treats the model like code: checking it for correctness, rolling up cost and mass, and running deeper systems or safety analysis. Smith also showed an agentic option, using an LLM to add or update model elements from a plain-language instruction, with every change still passing through the same model checks before being accepted.
2. System integration. As real components and software come online, the model runs unit tests against them and pulls in real software for larger simulation-in-the-loop tests, automatically checking results against the constraints and requirements defined in the model.
3. Performance monitoring. In live operation, the model's defined key performance metrics connect to the data lake Anduril's fielded vehicles feed, pushing results to a dashboard so engineers can trend metrics over time, drill into deviations, and see the effect of a design change in near real time.

Takeaway: SysML v2 provides a solution supporting existing workflows

Asked how his team got engineers to embrace this level of rigor, Smith credited usefulness over mandate: once people could see the tooling solve real problems, adoption followed, helped by keeping the system deliberately unobtrusive to other teams' existing workflows.

"This is the real power: everything is orchestrated and controlled directly from the model"

Cole Smith

2. GDIT's Case for Treating Cyber Controls as Code, Not Paperwork

Dr. Aldo Fabregas, a digital engineering and MBSE leader at General Dynamics Information Technology, opened his talk, Model-Based Cyber Assurance with SysML v2 and OSCAL, with a familiar issue: cyber security usually arrives after a design already exists, and governance, risk, and compliance work remains largely manual, document-heavy, and disconnected from the design itself.

Problem: risk management after the design phase is far too late

The issue, Fabregas said, is that the Risk Management Framework (RMF) typically gets applied as after-the-fact paperwork. Engineers design the system, cyber security teams document controls against a design that already exists, and assessors and authorizing officials sign off on an architecture that has already been built. Recently, the US Department of War's new Cybersecurity Risk Management Construct pushes in the same direction, calling for security embedded at the design phase rather than bolted on afterward.

"If cyber [security] starts when the system already exists, we're documenting risk, not shaping it."

Dr Aldo Fabregas

The fix: controls as code

His pitch is that system-as-code makes that shift practical. GDIT's pipeline pulls a full NIST control baseline out of the Open Security Controls Assessment Language (OSCAL) and turns it into a reusable SysML v2 control library, preserving each control's metadata, provenance, and parameters. A cyber specialist then specializes a general control down to a specific one, for example an error-handling control from the "System and Information Integrity" family, and satisfies it against a specific part of the architecture, such as an authentication service, by filling in the parameters it needs. That relationship, and the control's full rendered text, stay attached to that exact model element from then on.

Fabregas demoed on a deliberately unclassified example: a "Program Performance Evidence Portal," a simple SaaS app a program office might use to track cost, schedule, and deliverable evidence.

1. Model first — systems engineers build out the portal's parts and services.
2. Select and tailor — a cyber specialist works through RMF's Select and Tailor steps inside that same model, attaching and customizing controls against specific components instead of a separate document.
3. Draft with AI — because tailoring lives in text, it lends itself to AI-assisted generation of control libraries and traceability patterns.

Verification and continuous monitoring, tying each control to live evidence over time, is the piece Fabregas flagged as future work.

Takeaway: integrated model of cyber assurance

• Organizing the control library is a real open tradeoff: one package per control family mirrors how RMF already organizes controls but gets unwieldy at scale. Meanwhile, one shared namespace is easier to import, but harder to filter and own. As a compromise, the team is leaning toward tags and metadata layered on top of generated views.
• The harder problem than tooling may be culture — getting cyber security teams comfortable with modeling, not merely tolerant of it.

3. Istari Digital's AI-Generated Models: Trusted, But Verified

Christopher Benson spent years working on the U.S. Air Force nuclear deterrence programs before co-founding Istari Digital. His talk, Move Fast, Don't Break Things: AI Is Fast… Istari Makes It Safe, asked a version of the same question that once governed nuclear arms control: if AI lets engineering teams move fast, how do you make sure they are moving safely?

Problem: fast AI produces unverified outputs

Teams migrating from SysML v1 to v2 keep wondering about the obvious shortcut: can you just drop the old model into ChatGPT and get v2 back? A year ago, Benson said, that didn't really work. Today it does, on the surface — ChatGPT accepts a v1 .mdzip file and hands back a full package: a converted model, a summary, a README. It "looks pretty compelling", he comments. The catch, as he put it, is that compelling and correct are not the same thing, and a generated engineering artifact still has to be checked, tested, and trusted before anyone builds on it.

The fix: trusted, but verified… sevenfold

Istari solved the problem with one AI doing the translating, and seven independent checks trying to catch it out.

AI-check type	Scope	AI checks
Deterministic guardrails	Python tests: does every v1 element survive into v2, keep its relationships, and validate clean against Syside	5
Probabilistic guides	An adversarial LLM rubric scoring whether elements were translated correctly and whether intent, not just data, survived	2

7 is a translator-to-checker ratio Benson said the field is converging on, somewhere between five-to-one and ten-to-one.

Run against a real ChatGPT conversion, three of seven checks passed and Syside's compiler rejected the model outright. Feeding the failures back into the AI and rerunning the loop brought it up to five passing checks and, eventually, a model that compiled cleanly — with a few flags left for a human to fix or knowingly accept.

"The probabilistic judge is fooled; the deterministic gate is not."

Christopher Benson

Takeaway: the gate beats the score

• The probabilistic judge can be fooled where the deterministic gate cannot: the AI rubric scored ChatGPT's broken conversion with 77 out of a 100 — nearly identical to the working pipeline's 88 score. Meanwhile, Syside's compiler flatly rejected the same model with 112 errors. Trust the AI judge alone and you would ship something that does not even compile.
• One hard gate (compile clean) still beats a soft score for catching the failure that actually matters.
• Failures are not a dead end — feeding them back into the same AI closes the loop and can push a rejected model to compiling, without a human redoing the translation by hand.
• It is still not fully hands-off: the flags remaining on a passing model need a person to decide, fix or accept.

4. One Engineer's Plan to Make Medical Device Safety Compile Like Code

Somesh Kashyap, a senior principal software systems architect at Medtronic, opened his talk, MEMO: Medical Device Architecture Modeling as Code for Ontology-Backed Safety Assurance, with a disclaimer: MEMO is his own open-source project, not something Medtronic sponsors, and he was there to recruit help turning it into a real standard.

Problem: safety evidence scattered across silos

In medical devices, design tends to move faster than the safety evidence meant to support it. Requirements, risk, and verification data exist, but typically in separate silos rather than a connected model — unlike aerospace and automotive, where architecture is written directly into the standards and ties these parts together.

Kashyap attributed the gap to a few compounding factors:
– medical device teams are cross-functional and still document-heavy,
– large companies frequently acquire startups with a code-first culture and little modeling background, and
– even willing teams face real cost and complexity in simply setting a model up.

The fix: a safety argument that compiles

MEMO makes SysML v2 work for the medical-device domain. It layers a shared core, an architecture, a methodology, and device-specific extensions on top, so a team can adopt only what it needs.

Kashyap framed the central idea as an analogy to software: teams already compile their code and act on its errors and warnings. MEMO applies the same discipline to the safety argument itself — a command such as memo validate reports a missing risk control or an incomplete evidence path as a concrete error, rather than something an auditor discovers later.

He demonstrated this on GPCA (Generic Patient-Controlled Analgesia), a public FDA infusion-pump reference model from 2012–2016. In MEMO, a single hazard connects through to its evidence as one typed, traceable chain: hazard, requirement, component, risk control, verification and evidence.

"[Compiling it this way means] the failures are in your face, not at the time of the audit."

Somesh Kashyap

Takeaway: safety argument is not a proof

• Compiling the safety argument does not prove safety by itself. It surfaces gaps early enough for engineering, safety, and verification teams to act on them before a formal review.
• Rollout advice: begin narrow — one clinically meaningful use case, walked end to end through architecture, safety, and evidence — rather than modeling everything at once.

5. SysML v2 Code is for Machines, Diagrams Are for the Stakeholders

Devon Clark, a digital engineering specialist at Deloitte framed the talk Models as Code: MBSE at the Speed of Software around a deliberate phrase: models as code, not systems as code, to sidestep an existing trademark.

Problem: a strategy narrowed down to tooling

The 2018 DoD (Department of Defense) Digital Engineering Strategy promised value through integrated data and culture, not just new tools. Clark observed that most organizations narrowed that promise down to process and tooling alone. The result is an ecosystem problem, not a modeling problem: the models exist, but the connections between them do not, in part because SysML v1 models lived as vendor-locked format, disconnected from CI/CD (continuous integration/deployment) and agile practice.

"The models are there, but the connections are not."

Devon Clark

The fix: treating the model like source code

Clark's proposal treats SysML v2's text-native notation as a hub connecting the model, agentic AI, CI/CD discipline, and the broader digital thread into one system.

One knowledge base serves two interfaces:

1. engineers write directly into the text model,
2. stakeholders continue to receive the diagrams and dashboards generated from that same source.

Agents act as co-pilots inside that loop rather than replacements for it. Clark described asking an agentic system to regenerate the affected functional architecture after a ten percent increase in a maximum-altitude requirement, with engineers still validating the result before it is committed to baseline. The recommended rollout treats the model itself like source code, phased rather than adopted all at once: near-term for version control and peer review, mid-term for automated linting and constraint checks, long-term for continuously generated, auto-synced artifacts.

Takeaway: connection over modeling

• Modeling alone will not resolve the ecosystem challenge; integration will. The advantage comes from connecting engineering, AI, DevSecOps (development, security, and operations run as one workflow), and the digital thread as one operating model, so that engineering can move at the speed of software without losing rigor along the way.
• Progress compounds: even a modest first step, such as managing models in git with ordinary peer review, delivers value immediately and builds toward broader automation over time.

The common thread

One thread ran through all five talks: text stopped being documentation and became the mechanism itself. Anduril's model drives its own CI/CD pipeline and pulls live telemetry back in, and GDIT and Medtronic point that same machinery at governance and safety, so a control library or a hazard chain now passes or fails the way a build does, not the way an audit does. Devon Clark gave that shift its clearest name: a model that's a hub, not a deliverable. Istari pushed the idea to its edge, showing that even when an AI writes the text, a hard, deterministic check still gets the final word. Nobody in the room was trading rigor for speed; they were finding out how much faster rigor could go once it lived inside the model instead of beside it.

This is Part One of a two post series. Part Two will cover the remaining talks from the day, across further domains and use cases. System-as-Code Fest 2026-H2 is confirmed for early November, hybrid as before: free to join from anywhere online, or in person in Munich, Germany.