Technical responsibility for software developed under European medical-device regulation and ISO-oriented processes.
In most software, a bad decision costs you a rollback. Here it does not. The consequence is regulatory, operational or clinical, and it is not reversible by deploying again.
That changes the architecture rather than the paperwork. Validation, traceability, risk management and change control are decisions taken at the start, not documents assembled at the end.
Being able to show that a given requirement produced a given piece of software, that it was verified, and that the verification is current, is not something you can reconstruct afterwards from a repository and a spreadsheet. Either the structure carries it or it does not.
The practical test is a change: when a requirement moves, the system should tell you what is now unverified. If answering that takes a person a week, the traceability was a document rather than a property.
Risk management under these processes is not a register somebody maintains alongside the work. It is an input to the design: what can this fail into, what detects it, and what does the system do when the detection itself fails.
Features that cannot answer those questions do not get simplified. They get declined.
Working under a regime where every change has to be justified before it ships makes the cost of a change legible in a way that ordinary product work hides. I now evaluate features the same way outside this context: not only can it be built, but what does it commit us to, who maintains it, and what does it cost when it is wrong.
The device, the intended use, the classification, the organisation or any part of the technical file. Described at a high level under NDA.
Work carried out under NDA. This page describes the engineering, not the employer. No employer names, internal architectures, client details or proprietary systems appear anywhere on this site, and none will be added.