Most conversations start with the same question: which document do you check against to know whether the machine behaves correctly? What follows depends on your answer, not on our agenda.
Usually that is a WhiteBox Assessment on a bounded section of the line — and we tell you beforehand what it costs and what it does not do.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.There are lines and situations where the method changes little. Saying so costs us a project and costs you nothing — which is why we say it.
A passed acceptance test is a snapshot of a sample.You do not have to prepare anything and do not have to disclose anything. What helps is a concrete situation instead of a general question.
A line, a station, a machine — the more concrete, the more usable the answer. An example from the last commissioning is enough.
A recurring stoppage, an acceptance that took longer than planned, a behavior nobody could explain.
A conversation with procurement alone gets neither side further. Whoever knows the line recognizes within five minutes whether the method holds.
After the call you receive a short written assessment: what we understood, what follows from it, and what we cannot judge.
An offer comes when you want one — and then with scope, price and what is not included.
What you say in the call stays in the call. We name references only with written consent of those named.
An intro call is not the entry into a series of appointments. If nothing follows, nothing follows.
The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code — and that is exactly what we talk about: Verification asks: was it built right? Validation asks: was the right thing built? Both questions need something to check against.
Selmo replaces neither commissioning nor experience — it reduces the space of possible causes. And what is checked is always the defined behavioral space: what is not modeled is not covered.