Why we still invest in language engineering

Automata keeps two unusual things in public: ia-toolset, a toolset for Interface Automata theories with a textual modelling language, simulator, and debugger, and BahnDSL, a domain-specific language for configuring and modelling model railways — compiler, editors, and generated interlocking logic. Neither is a commercial product. Both are deliberate investments in a discipline most teams never practice.

The first reason is leverage. When a domain is complex enough — railway interlocking, financial rules, industrial configuration — generic code keeps accreting workarounds. A language designed for the domain lets experts express rules directly, makes invalid states unrepresentable, and catches errors at edit time instead of in production. For the organizations that need this, the difference is not incremental.

The second reason is what the discipline gives back. Building parsers, type systems, validators, and editors trains habits that transfer everywhere: precise thinking about syntax and semantics, validation at boundaries, tooling that makes correctness visible. We can see those habits in our mobile architecture and our AI pipelines, and we consider them part of the same craft.

We are clear-eyed about what this niche is. Language engineering is not a mainstream service, and we do not present it as one — it lives under Advanced Capabilities, and we take a limited number of engagements where specialized languages, modeling tools, or developer environments are genuinely the problem. For those organizations, though, it is rare to find a partner who has both the research background and the production habits to deliver tools that domain experts can actually use.

Depth is the point. A studio that goes deep in an unfashionable corner of the craft tends to build everything else more carefully too.