> For the complete documentation index, see [llms.txt](https://infosys.selmotech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-documentation/1-why-selmo.md).

# 1 Why Selmo?

### An executive summary

Modern machines are powerful, networked and highly automated.\
At the same time, their behavior is becoming increasingly difficult to explain.

The code works –\
but it no longer answers central questions:

* Why is the machine stopped?
* What is currently being expected?
* What is allowed to happen here – and why?
* Who is responsible for what?

**Selmo exists to answer exactly these questions formally.**

***

### The core problem of today’s automation

In classic automation projects, machine logic is:

* implicitly distributed in the code
* mixed with operation and safety
* hard to trace
* hardly verifiable

Code describes **what happens**,\
but not **why it is allowed to happen**.

As a result:

* diagnosis is vague
* documentation inconsistent
* responsibility diffuse
* liability hard to argue

***

### What Selmo does differently

Selmo shifts the focus:

**from code → to the model**

Instead of commands, Selmo describes:

* states
* expectations
* monitoring
* reactions

Machine behavior becomes:

* explicit
* complete
* deterministically
* traceable

> **The model becomes the truth.**\
> **Code is only an implementation.**

***

### What Selmo delivers concretely

With Selmo, a **formal behavior model**is created, from which can be derived:

* PLC code
* HMI structures
* Diagnosis
* documentation

Not separate.\
Not afterwards.\
But **from the same source**.

The result:

* consistent behavior
* automatic, correct diagnosis
* unambiguous state management
* stable documentation

***

### Why this is decisive

Selmo makes machines:

* **explainable**\
  → States, expectations and deviations are unambiguous
* **verifiable**\
  → Behavior is formally described, not interpreted
* **accountable**\
  → Decisions, reactions and safety assumptions can be justified
* **scalable**\
  → Complexity is structured, not distributed

***

### Safety, operation and responsibility

Selmo cleanly separates:

* sequence (Sequence)
* technology (Zone)
* behavior (Bit-Control)
* operation (Hardware-Zone)
* integrity (CMZ)

Manual and automatic operation are:

* no special logics
* no exceptions
* no bypasses

Safety is:

* modeled
* permanently active
* hierarchically effective

***

### Relevance for standards and the future

Through the formal model it is always traceable:

* which state was active
* which conditions applied
* why a reaction occurred

This is crucial for:

* functional safety
* standards argumentation
* auditability
* liability
* use of AI in programming

> **What is modeled is explainable.**\
> **What is explainable is accountable.**

***

### What Selmo consciously is not

Selmo is:

* not a low-code system
* not a PLC framework
* not a UI concept
* not a replacement for safety hardware
* not a shortcut for complexity

Selmo does not replace responsibility.\
Selmo makes it **visible**.

***

### The central statement

> **Selmo is a formal model for explainable machines.**

No more.\
But also no less.

If you understand the model,\
you understand the machine.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-documentation/1-why-selmo.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.