Where do things stand right now —
at your machine?
Five properties
of a WhiteBox.
WhiteBox does not mean you can see the code. WhiteBox means conformity is decidable rather than a matter of judgment. What a WhiteBox has, a BlackBox lacks — every no shows where.
The target behavior exists as an object of its own before programming starts. Without it, start-up loss arises.
Conformity is decided, not judged. Without it, evidence loss arises.
A deviation is determined, not searched for. Without it, downtime loss arises.
Changes start in the target behavior. Without it, change loss arises.
The knowledge is tied to an object, not to people. Without it, dependency loss arises.
A passed acceptance test is a snapshot of a sample: what was never observed has not been tested — it simply did not come up. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code.
Answer for one machine,
not for the whole company.
Yes, No or Don’t know. “Don’t know” counts as No: what cannot be established is not decidable.
Is there a separate document for the behavior of your machine — like the wiring diagram for the electrical system?
Does this document exist before programming starts?
Does the document take precedence over the code when the two contradict each other?
Does it describe states and transitions — not just functions?
Does it specify faults and interruptions, not just the normal sequence?
Is it part of the delivery and of acceptance?
Can you check the behavior without reading the program?
Is it specified for every step how you can tell that it has been met?
Are times and limits specified as target values?
Is acceptance checked against the target behavior — not against an as-built?
Do two people independently reach the same conclusion about the same situation?
Is it specified what applies when a signal is missing or invalid?
Does the machine show which expectation was not met?
Does a fault name station, step and reason in plain language?
Do you know how long it takes on average from a fault to its cause?
Can you assign downtime in time and parts to a cause?
Is performance loss detected even when no fault is reported?
Do your analyses work without experts who have to interpret the data?
Is a change made in the target behavior first?
Before a change, is it known which parts of the behavior it affects?
Is the machine checked against the target again after every change?
Is it traceable which program version is running and what it changed?
Do documentation and machine still match after changes?
Can changes be made safely without the original programmer?
Does the knowledge stay when the person or the supplier leaves?
Could another supplier take over the machine without asking questions?
Is the behavior described independently of the control vendor?
Can your own team read and check the behavior?
Can a controller be replaced without reinventing the behavior?
Are identical machines at different sites described the same way?
30 questions still open.
Your profile
Profile based on your self-assessment: 0–1 No present · 2–3 No partial, carried by people · 4–6 No missing. Verification asks: was it built right? Validation asks: was the right thing built? No questionnaire answers either — the maturity level L0–L5 is assigned only by the WhiteBox Assessment, with evidence at the line.
Decidability requires technology. Where no reaction can be detected, nothing can be formally decided either — the method makes this visible, it does not remove it.
A question for you
How much of this could you evidence today?
Full evaluation in the intro call15–30 minutes, free of charge and without obligation.