Scenario Logic Must Live in the DSL

OpenSCENARIO DSL is the language for writing scenarios. But "writing in DSL" hides a trap — writing half in the DSL and half in a separate script. This post explains why that matters and why all scenario logic must be self-contained within the DSL.

The Anti-Pattern — Logic That Leaks

The common anti-pattern looks like this: the scenario's surface is written in OSC, but the actual composition data (which assets, where, how many) is buried in a separate Python helper script.

Rendering diagram…

When this was actually measured, 41% of maritime scenario OSC files depended on composition data in separate submit scripts. On the surface these looked like "OSC scenarios," but they couldn't be reproduced from OSC alone — they were only half the picture.

⚠️ Half-DSL = demo only — If half the scenario logic is buried in a code script, an end-user cannot recreate that scenario without knowing the code. That's something you can show once — not a product customers can use themselves.

The Standard — Can an End-User Reproduce It Using Only the DSL?

The criterion for a deliverable system is clear: can an end-user produce the same result using only the domain language (OSC, manifest, API)?

That's why these three questions are asked before building any new scenario or feature:

1. Is this a one-time demo, or a deliverable structure?
2. Can an end-user reproduce the same result using only the domain language?
3. Does a similar standard pattern already exist? If so, follow it.

💡 Catalogs as data, not code — The same philosophy applies to weapon and asset catalogs. Rather than hard-coding weapon characteristics in code, a single YAML line per entry means a new entry extends coverage from ground to air-defense to anti-ship with zero code changes. "Intent in the domain language/data; execution in the engine" is the principle.

Why This Strict?

The reason for insisting on self-containment is simple: this system is not a demo. Customers and engineers must be able to express their intent using only the system's domain language — that's what makes it a product. The moment logic leaks into internal scripts, only the team that wrote them can run it, and it becomes a one-off. Driving the self-contained ratio to 100% is a design goal, not a nice-to-have.

In a nutshell

📌 When half the scenario logic is in OSC and half is in scripts, it's demo-only. An end-user must be able to reproduce results using only the domain language (OSC, manifest, API) — that is the bar for a deliverable system. Intent belongs in the DSL/data; execution belongs in the engine. "This is not a demo" is what enforces self-containment.