Protect the baseline after code or configuration changes.
Release behavior checks are repeatable regression runs used to confirm that the simulator still behaves correctly after code or configuration changes. They are not a substitute for full engineering validation, but they help protect the baseline.
Check order
- Confirm the active TT and VT trained tables are the intended ones.
- Confirm the intended scenario JSON files are in use.
- Run the smoke or target scenario.
- Compare output against the saved baseline.
- Review the summary and state-by-state report.
When to run
- After simulation engine changes
- After fault or alarm logic changes
- After TT or VT register-binding changes
- After report/export changes that depend on runtime events
- After trained-table packaging changes
Expected output
- Which scenario ran
- Which baseline was used
- Whether the result stayed inside the allowed tolerance
- Which state or variable drifted if it did not
Why this page matters on the site
Release checks show that the application is not only a concept demo. They also support confidence for customers who want repeatable engineering behavior after updates, packaging changes, or project-specific configuration work.