It holds for the section that was checked and for the moment it was checked. What was never observed has not been tested — it simply did not come up. And any later change voids the evidence without anyone noticing. Before any of that can change, it has to be established where this condition actually applies today.
Without a reference there is no way to say what share of possible machine behavior was ever checked. The question is not whether gaps exist — but where they are and which of them you can carry.
A gap you know is a risk. A gap you do not know is an assumption.An assessment is not a pre-sale for a project. It can also conclude that a section of the line needs no action at all — and that statement is worth its price, because it prevents an investment.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.The assessment works with what is there: your documents, your line and the knowledge of your people. It requires no preparation and no change of tooling.
We review functional descriptions, HMI specifications, parameter tables and acceptance documents, and talk to the people who know the line. No remote questionnaire — the statements are formed at the machine.
Each behavioral requirement is rated: directly decidable, indirectly, conditionally, or not decidable. These four levels are the core of the result — they say what you could check against today and what you could not.
The line is placed in the six maturity levels: BlackBox, Described, Explicit states, Decidable, Lifecycle, Architecture. The turning point is Decidable — before it everything is description, after it evidence begins.
Not every gap has to be closed. The path names which steps make the biggest difference, which can wait, and which parts of the line may stay exactly as they are.
The result is yours and is written so that someone else can read and check it. It states where each judgment came from and what would refute it.
One of the four levels per requirement, with reasoning and the document or observation that supports it.
The placement in L0 to L5, separated by section of the line, so that inconsistency across the plant becomes visible.
The places where behavior has no reference — ordered by impact, not by effort.
A proposal for the sequence, with the next checkable step and what it presupposes.
Anything we could not establish is marked in the report as an assumption — not as a result.
A gate is a decision, not a date. The assessment leads to exactly one: whether the intent is determined well enough for engineering to start without silent assumptions.
Bounding the section of the line under review, collecting documents, clarifying contacts.
—
Review, conversations and observation at the line. One to three days depending on scope.
—
Rating per requirement, maturity profile, path of measures, handover in conversation.
Gate 0
An offer does not become stronger by covering everything. It becomes stronger when its edge is known.
Document review, conversations, observation at the line, rating, maturity profile, path of measures.
The report is not mailed, it is discussed — with the people who will work with it afterwards.
The report is yours and may be used internally and towards third parties without asking us.
Creating a released Behavior Reference (BR) is the PTF- & Behavior-Reference-Pilot.
Derivation and verification against the reference are the Behavior Defined Machine (BDM) Engineering Project.
Qualifications for your team are part of Certification & Training.
The assessment provides material for the evidence trail. Conformity assessment remains with the machine builder.
The order is the path, not the revenue. The assessment is the second step: it establishes where you stand. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code — which is why modeling comes after this, not before it. Verification asks: was it built right? Validation asks: was the right thing built? The assessment answers neither question. It establishes whether the first one can be answered at all today.
Target picture, use case and roadmap.
Where conformity is decidable today and where behavior has no reference.
One released Behavior Reference (BR) for a bounded unit module.
Implementation derived from the Behavior Reference (BR) and verified against it.
Behavior-Centric Engineering (BCE) as the standard across several plants.
Behavioral integrity across the lifecycle, changes as change verification.
Enabling the team, Selmo-owned qualifications.
Decidability presupposes technology. Where no reaction is detectable, nothing can be decided formally either — the method makes that visible, it does not remove it.
The question every assessment starts from
15–30 minutes. We bring the answer, not the presentation.