It names two limits: the section that was checked and the moment it was checked. The first is closed by the Behavior Reference (BR), because what is checked is what is defined rather than what happened to occur. The second stays open as long as the comparison happens once instead of running along.
A changed parameter, a replaced sensor, an adjusted recipe. The evidence that held before no longer holds after — but it does not disappear, it stays in the folder and keeps being quoted.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.The Behavior Reference (BR) is present on the machine at runtime. In operation, every deviation from the defined behavior is detected against it. When the target behavior changes, the changed reference is transmitted again — reference and runtime reference remain one and the same statement.
The reference closes the sample. The runtime reference closes the moment.Lifecycle Services are not a maintenance contract for software. They keep up the statement that held at the end of the project — across changes, staff turnover and years.
A change starts in the Behavior Reference (BR), not in the code. From the changed reference the affected derivations are renewed and checked against it. The evidence is renewed, not overwritten.
What is detected is the deviation from the defined behavior. The defined behavioral space is the checked space: what is not modeled is not covered. That limit is part of the statement — otherwise it would be a promise.
New operating modes, changed products, extended modules. What is added to the line is added to the reference — otherwise the uncovered space grows unnoticed.
One entry per change: what was changed, in which reference version, who released it, what was re-checked, with what result, and what remained open. That keeps the chain of evidence readable years later.
The result is not an availability promise but the ability to say, at any moment, what the line is currently checked against — and since when.
Per change: changed reference version, affected derivations, scope re-checked, result.
The continued chain of all changes with six entries each — readable without us and without the person who made the change.
What came up in operation against the runtime reference, stating whether it lay inside or outside the modeled space.
The current Behavior Reference (BR) in the exchange format, with version status and release note.
Anything that could not be checked for reasons of time or access is marked in the record — not silently contained in it.
A gate is a decision, not a date. In operation the same one repeats: whether after the change there is again an integrated, operable, checkable system.
The target behavior is changed and released in the Behavior Reference (BR) — before anyone touches the code.
Behavior Gate
The affected derivations are renewed, the check runs against the changed reference. Where a digital twin exists, there first.
Verification Gate
The changed reference is transmitted again. An entry in the Evidence Record, so the current status stays determinable without asking.
—
An offer does not become stronger by covering everything. It becomes stronger when its edge is known.
Change in the reference, renewal of the affected derivations, check against the changed reference, record.
Continuation of the model and of the chain of evidence, so that together they carry the current status.
Response times are set in the contract. Support presupposes an ongoing working relationship.
Mechanics, electrics and upkeep remain trades of their own and stay with your partners.
If a section of the line has no Behavior Reference (BR) yet, that is the PTF- & Behavior-Reference-Pilot.
A new section of the line is a Behavior Defined Machine (BDM) Engineering Project, not a change.
The service provides material for the evidence trail. Conformity assessment remains with the machine builder.
The order is the path, not the revenue. Lifecycle Services are the sixth step and the only one without an end. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code — in operation that means a change starts in the reference, not in the controller. Verification asks: was it built right? Validation asks: was the right thing built? After every change the first question is open again — which is exactly why it is called Change Verification and not change management.
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 detected is the deviation from the defined behavior. The defined behavioral space is the checked space: what is not modeled is not covered.
The question every lifecycle starts from
15–30 minutes. We bring the answer, not the presentation.