Vehicle Machine Language (VML) FAQ

VML (Vehicle Machine Language) is a proposed formal language for describing vehicle behavior in a way that can be interpreted, verified, tested, monitored, and executed by deterministic systems.

Instead of allowing natural language to directly influence safety-critical runtime behavior, VML acts as a formal intermediate representation between human intent and vehicle execution. Foundation models may help create VML specifications, but runtime systems operate only on formally defined VML artifacts.

References: VML White Paper (PDF), TWG-FAS Index (HTML)

No.

VML is not intended to replace AI, machine learning, perception systems, planners, or foundation models.

VML aims to provide a formal representation of behavioral intent that can be shared between engineering, planning, verification, simulation, testing, and runtime monitoring. The goal is to standardize the behavior description layer, not the AI implementation itself.

Reference: VML White Paper (PDF)

Natural language is excellent for communication between humans but problematic for safety-critical runtime systems.

A statement such as:

"Yield to pedestrians when necessary"

leaves many questions unanswered:

• What is a pedestrian?
• What does "necessary" mean?
• What risk threshold triggers yielding?
• What happens if yielding is impossible?

VML requires such concepts to be expressed explicitly and formally, making the behavior analyzable and testable.

Reference: VML White Paper (PDF)

Yes.

A large language model can serve as a semantic compiler that translates natural language requirements, regulations, design intent, or spoken instructions into VML.

For example:

"Turn left when it is safe"

may be transformed into a formal specification involving risk thresholds, traffic participants, and fallback obligations.

However, the generated VML is then processed by deterministic components such as parsers, type checkers, monitors, and verification tools. The output can therefore be validated independently of the model that generated it.

Reference: VML White Paper (PDF)

Potentially yes.

A voice-controlled assistant could translate spoken commands into VML.

Example:

Driver says:

"Park near the entrance but avoid blocking pedestrians."

An AI assistant could convert that request into VML constraints and goals.

Before execution, the resulting VML would be checked for:

• Syntactic correctness
• Semantic validity
• Safety rule compliance
• Conflicts with existing obligations

Only validated VML would be accepted by the runtime system. This differs fundamentally from directly executing natural-language instructions.

Not necessarily.

Current state-of-the-art language models already demonstrate an ability to understand formal languages and structured specifications.

For experimentation and prototyping, large models may be used with only prompt-based explanations of VML.

However, specialized models trained or fine-tuned on VML are likely to be:

• Smaller
• Faster
• Cheaper
• More reliable

than general-purpose models.

VML therefore does not require custom training, but dedicated training may significantly improve efficiency and quality.

Potentially yes.

One motivation for VML is that understanding unrestricted natural language is computationally expensive. A language model that only needs to translate intent into a constrained formal language can be substantially smaller than a model that must support unrestricted language understanding.

The formal runtime components themselves (parsers, monitors, rule engines, and verifiers) can be implemented using classical software techniques.

Reference: VML White Paper (PDF)

Not in the traditional sense.

VML is better viewed as a behavioral specification language. It focuses on:

• Obligations
• Prohibitions
• Goals
• Temporal constraints
• Safety policies
• Probabilistic reasoning

It describes what behavior is allowed, required, or forbidden, rather than how algorithms should be implemented.

Reference: VML White Paper (PDF)

No.

VML is a language specification, not a file format.

The current draft uses a human-readable ASCII syntax for transparency, review, and engineering collaboration. However, VML does not currently prescribe how artifacts must be stored, transported, or exchanged.

The standard focuses on semantics and language constructs, while implementations may choose different containers or encodings as long as the normative meaning is preserved.

Design principle: Container neutrality.

In short: VML defines meaning, not storage.

VML builds upon ideas found in formal methods, including temporal logic, deontic logic, ontologies, probabilistic reasoning, and runtime verification.

However, VML is intended as an engineering language for real automotive systems rather than as a pure academic logic formalism. Its goal is to integrate multiple behavioral concerns into a single practical representation.

Reference: VML White Paper (PDF)

VML introduces deterministic semantics, explicit rules, monitor semantics, type checking, and verification interfaces.

A VML specification can be:

• Inspected by engineers
• Reviewed by auditors
• Analyzed by formal tools
• Monitored during runtime
• Tested in simulation

This makes behavioral intent transparent and traceable.

References: VML White Paper (PDF), TWG-FAS Index (HTML)

Traditional planners often encode many decisions inside large cost functions. This can make behavior difficult to interpret.

VML separates:

• Hard constraints
• Obligations
• Prohibitions
• Goals
• Optimization objectives

This allows behavior to be expressed explicitly while still supporting optimization-based planning.

Reference: VML White Paper (PDF)

No.

While autonomous driving is a primary motivation, VML could potentially be applied to:

• Advanced Driver Assistance Systems (ADAS)
• Automated parking
• Robotics
• Industrial automation
• Autonomous logistics systems
• Other safety-critical autonomous platforms

The central concept is domain-independent: a formal representation of behavioral intent.

VML does not govern AI models themselves. Instead, it provides a transparent and inspectable description of behavioral intent.

This separation may help:

• Safety assessments
• Regulatory reviews
• Compliance processes
• Traceability requirements
• Certification activities

A governance framework can review the behavioral specification independently of the underlying AI implementation.

Reference: VML White Paper (PDF)

That is the intention.

The TWG-FAS initiative proposes a vendor-neutral, openly developed standard, allowing multiple independent implementations and avoiding lock-in to any specific AI architecture, vendor, or vehicle platform.

References: TWG-FAS Index (HTML), VML White Paper (PDF)

TWG·FAS believes that the formal specification of behavior in safety-critical autonomous systems should not be controlled by a single company, vendor, or proprietary ecosystem.

A proprietary behavioral standard would create natural barriers to adoption. Automotive manufacturers, suppliers, tool vendors, researchers, regulators, and certification bodies are unlikely to build long-term safety processes around a language controlled by a single commercial entity. Broad adoption requires a vendor-neutral foundation that all stakeholders can trust.

More importantly, autonomous driving systems raise questions that extend beyond commercial interests. Society, regulators, and certification authorities must be able to understand and evaluate the behavioral logic that governs vehicle decisions. An open standard allows behavioral intent, safety policies, and verification artifacts to be reviewed independently, without requiring companies to disclose proprietary algorithms, model architectures, training data, or intellectual property.

This separation is fundamental. Companies should be able to protect their innovations while still providing transparent evidence of how safety-critical behavior is specified, verified, and monitored.

TWG·FAS therefore views openness not only as an engineering choice but as an ethical responsibility. A common, openly governed standard can promote transparency, independent verification, regulatory cooperation, scientific research, and public trust. By enabling scrutiny of behavioral specifications while preserving legitimate intellectual property, the initiative aims to support the safe and responsible development of future autonomous systems.

In this sense, openness is not merely a governance model—it is a contribution to safety, accountability, and the public good.

Prompt brittleness refers to the tendency of AI systems that rely on natural language prompts to behave unpredictably when those prompts are only slightly changed, rephrased, or encountered in a context that differs from training.

Even a minor variation in wording, punctuation, or context can produce substantially different outputs from the same underlying model. For general-purpose AI applications this is often an inconvenience; for safety-critical automotive systems it represents a fundamental problem.

In an automotive context, prompt brittleness matters because:

• Safety behavior must be deterministic and repeatable — a vehicle must respond consistently to the same scenario every time.
• Certification and homologation processes require evidence that behavior is stable and bounded, which is incompatible with prompt-sensitive outputs.
• Brittle prompts make systematic testing and formal verification impractical, since the effective input space becomes unbounded.
• Runtime conditions — sensor noise, unexpected phrasing from voice interfaces, or edge-case scenarios — can trigger degraded or unsafe responses with no predictable boundary.

VML addresses this directly by removing natural language from the safety-critical runtime path entirely. Engineering-time prompts are compiled into formal VML artifacts by a foundation model; the vehicle runtime then operates exclusively on those formally defined, verifiable artifacts rather than on raw prompts.

For a detailed treatment of this topic, see: Prompt Brittleness — How It Matters (PDF)

This is not an easy question to answer. Training AI models predominantly on VML would come with clear advantages but also with real risks and disadvantages, and the balance between them is non-trivial.

Potential advantages include stronger alignment with formal semantics, reduced prompt brittleness in safety-critical contexts, more predictable and verifiable outputs, and the possibility of smaller, more efficient models that are easier to certify.

Potential risks and disadvantages include reduced generalization to natural language and real-world variability, dependence on the quality and coverage of the VML corpus, a possible loss of reasoning capabilities that emerge from diverse training data, and the risk of overfitting to a constrained formal vocabulary in ways that may not transfer well to novel scenarios.

Another feasible approach could be to distill an existing model toward VML rather than train predominantly on VML from scratch, especially when the goal is to retain broader generalization while improving formal-language behavior.

For a detailed discussion of the trade-offs, see: The Role of Formal Languages as Primary Training Media (PDF)

See also: Distilling Towards VML (PDF)