What does “validatable software development” mean?

“Our software is validatable” appears in many proposals. The sentence is rarely wrong but almost always empty – strictly speaking any software is validatable if you put enough effort in. The statement only becomes interesting once it answers at what effort a fitness case can be made and what is already prepared for it.

1. The wrongly posed question

Validatability is not a property you can see in a product. It arises from the interplay of three things: a clearly defined intended use, system behaviour that repeats reliably, and artefacts that show testing happened. If one is missing, validation does not become impossible – just expensive.

2. Validated, validatable, verified

The third row is the only one that permits a statement about a product before it is used. It is therefore the only one a vendor can make at all – and only in that form.

3. Five structural prerequisites

1. Requirements with identifiers and acceptance criteria. Without a reference point there is nothing to validate. A requirement that cannot be tested blocks the evidence regardless of the technology.
2. Explicit structure instead of implicit convention. Data model, roles, permissions and validation rules have to be nameable and comparable – not spread across twenty classes.
3. Reproducible artefacts. The same state has to yield the same result, otherwise every run tests something different.
4. Automatic, retained evidence. Test results, checks and approvals have to stay attributed to the exact version.
5. Controlled change. Without assessed changes, any evidence once produced expires with the next release.

4. Determinism and reproducibility

The most frequently underestimated point. A system that behaves differently in the same configuration cannot be tested meaningfully – every test run would be a one-off observation. Practical consequences:

• Builds from a versioned definition, not from the state of a machine.
• Dependencies with pinned versions, not with floating ranges.
• Configuration as an artefact, not as a manually maintained environment.
• Deliberate handling of time, randomness and ordering dependencies in the code.

Using AI in development changes none of this: it is not the act of creation that has to be reproducible but the shipped artefact. A model may phrase things differently twice – the reviewed and released version is still unambiguous.

5. What a platform can contribute

A development platform cannot create validatability but can make it considerably cheaper. What it can contribute:

• explicit models for data, roles, permissions and validation rules,
• history and traceable configuration changes,
• reproducible builds from a versioned project definition,
• standardised, already proven base functions instead of project-specific in-house builds,
• analysable logs of delivery and target environment.

The effect is twofold: less individually developed functionality means less to evidence per project – and the remaining evidence work becomes easier thanks to existing artefacts. How CodamAI implements this is on the features page.

6. What the organisation has to do

The rest is and stays organisational – and can be delegated to no product:

• define and bound the intended use,
• assess risks and derive the test depth from them,
• plan and approve the validation scope,
• name roles and responsibilities,
• assess and document deviations,
• maintain the validated state across changes.

That is why the permissible wording from a vendor is always a supporting one: a platform can be used in validation-sensitive processes, provided project-specific requirements are implemented and validated. Anything beyond that would be a promise nobody can keep.

7. Why validatability fails

• An unclear intended use. Without it any test depth is arbitrary – and therefore either too expensive or too thin.
• Scattered domain logic. When the same rule is implemented in four places, it has to be evidenced four times.
• Manual environments. “It ran on the test system” is not evidence when nobody knows the state of the test system.
• Evidence in volatile tools. What is deleted after 30 days does not exist for the inspection.
• Changes without assessment. Evidence produced once ages with every release.

Checklist: preparing for validatability

Conclusion

“Validatable” is not a seal but a statement about effort. Anyone who means it can back it up: with identified requirements, explicit structure, reproducible builds and evidence that arises while working.

The pleasant side effect is that these points are good practice outside regulated projects too. Validatability is therefore rarely a special effort – mostly it is simply solid engineering, carried through consistently.