It holds for the section that was checked and for the moment it was checked — because there is no document to check against. Today the code is plan and execution at once. As long as that is so, every acceptance test is a comparison with experience, not with a determination.
The BlackBox does not come from poor work. It comes from behavior existing nowhere as an object of its own — it sits distributed across code, HMI, heads and habits. The pilot produces that object.
Today one person does both at once — planning and executing — and carries both alone. That is not a question of missing qualification but of missing division of work.PTF (Process · Technology · Function) separates what a functional description usually mixes: what should run, what it is implemented with, and what a building block has to be able to do. Only once separated does each of the three become decidable.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.The pilot works on a module, not on a line. That is not a saving but the condition for ending with a statement rather than an interim status.
Before the first line of model comes the edge: which actuators, which sensors, which interfaces to the rest of the line. A blurred edge later produces exactly the assumptions the pilot is meant to remove.
Process: what should happen in what order. Technology: with what, within which limits and with which detectable reaction. Function: what a building block has to be able to do so that the process runs on that technology.
Behavior is determined as a model: which states exist, which transitions are permitted and what blocks them. What is not in it does not hold later — which is why the completeness check is part of the work, not an appendix.
The reference is released by you. That makes it the basis to check against later — and an object that belongs to the operator and is transferable.
At the end there is no presentation but a reference in an exchange format, a list of evidence, and the statement of what the model covers and what it does not.
The released behavior model for the unit module — states, transitions, interlocks, operating modes.
Process, technology and function documented separately, with the places where the separation exposed an assumption.
What share of the module behavior is modeled and which operating modes deliberately sit outside it.
The reference is available as PLCOpen XML. That makes it readable without us standing next to it.
Anything that could not be settled during the pilot is marked in the reference — not silently contained in it.
A gate is a decision, not a date. The pilot leads to the Behavior Gate: whether the expected behavior is defined completely enough that the implementation does not have to invent behavior of its own.
Module edge, interfaces, existing documents, conversations with the people who know the module.
—
Separating the three questions and build-up of the Behavior Reference (BR), alternating with your specialists — not behind closed doors.
—
Completeness and freedom from contradiction of the reference, walkthrough, release by you.
Behavior Gate
An offer does not become stronger by covering everything. It becomes stronger when its edge is known.
Bounding, separating the three questions, build-up of the Behavior Reference (BR), completeness and contradiction check.
Your people work with us, not for us. Whoever is to change the reference later has to have been there when it was made.
The reference is owned by the operator and transferable as an object — in the exchange format, not as a screenshot.
Deriving code, HMI and documentation and verifying against the reference are the Behavior Defined Machine (BDM) Engineering Project.
The finding across several lines is the WhiteBox Assessment.
The pilot stays with the module. Carrying it over to further modules is a separate decision after the gate.
Qualifications for your team are part of Certification & Training.
The order is the path, not the revenue. The pilot is the third step: it produces the reference. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code — in the pilot that is not an attitude but the order of work. Verification asks: was it built right? Validation asks: was the right thing built? The pilot answers the second question in advance by determining what the right thing is. The first only becomes answerable afterwards.
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.
What is modeled is the defined behavioral space. What is not modeled is not covered — the reference makes the edge visible, it does not move it.
The question every pilot starts from
15–30 minutes. We bring the answer, not the presentation.