Quality and Validation
Safety software is only as good as the evidence behind it. A regulator should not have to trust a vendor. A regulator should be able to check.
In process safety, validation is not a step at the end of development. It is the product. A consequence model that has not been compared against experiment is an opinion, however sophisticated the physics behind it.
Regulators do not buy speed. They buy demonstrated agreement with experiment. We have built the company around that from the beginning.
Three separate disciplines
Three permanent functions, not three phases of a project
Verification
Does the software solve its mathematics correctly?
Checked at the level of each individual model, and re checked automatically on every change.
Validation
Does the physics agree with reality?
Compared against full scale and laboratory experiments and against published field data, with the accuracy stated for the conditions tested.
Testing
Does it hold up in use?
The quality discipline expected of safety critical software, with every requirement mapped to a result.
How a capability is released
One gate, and it is not held by the people who built the thing
1
Capability built
The development team implements the physics.
2
Validation case run
The capability is compared against experiment, against acceptance criteria fixed in advance.
3 · The gate
Independent sign-off
The Head of Quality, who does not report to development, judges whether the case passed.
4
Released
The capability reaches users, with its validation position on the record.
Does not pass. The capability returns to development. Nothing is released on a failed case, and the judgement is not development’s to make.
Independent sign off
The people who wrote the physics do not grade it
Our Head of Quality is structurally independent of the development team and holds binding authority over every validation claim the company makes. No capability is released until its validation case passes, and that judgement is not made by the people who wrote the physics.
In safety critical software this separation is the difference between evidence and marketing.
Open by choice
We publish our validation basis
This is a deliberate decision. It is not the norm in this industry, and we think it should be.
Open publication lets a regulator, an academic or a customer repeat our comparison and see what we saw. It builds trust faster than any claim we could make about ourselves, and it holds us to a standard we cannot quietly lower.
Where the evidence comes from
Published experiment, and the people who ran it
Our validation draws on published large scale experimental campaigns in fire, explosion and dispersion, and on the experience of a founding team that spent careers designing and running such campaigns.
Our methodology follows the practice established by the international process safety and fire engineering communities, with quantitative acceptance criteria that a capability must meet before release.
Reviewing us?
We will answer with the evidence.
If you are a regulator, a customer or a technical assessor and you would like the current validation position on a specific capability, please write to us.
Talk to us
If you are an operator, a consultant, a regulator or a research partner, we would like to hear from you.