Thank you for your insights, orange.
> 3 A Project is defined and initiated and sent to the Inspector. You need a definition of a Project (who,what,when,where,how much and how often..)
Please keep in mind that the Inspections business is as pragmatic as something can be. Systems must be designed to achieve a result within the boundaries of law, they're not interested in recording anything else but the very essential. The project in this case is merely the boolean "projectExists". After that, during the visit, any observation in project or on site, is recorded in the visits table and as trivial as it can be, it can go either in one field or several records in an observations table with a VisitID FK, does not matter for the scope of the thread.
> These points must be clearly identified. What exactly is it (in the it'll)
"It" refers to the inspection.
> 6 Somewhere, the client must arrange with a third party the actual physical work. This is not part of the Inspector's work.
The physical work, if required, is not a concern for the Inspector. The inspector will compare the electrical project and the electrical installation to notify of the differences, errors and omissions found in both. This is recorded in the visits table.
> But your potential data models in post #7 above has an abundance of people and roles. This cannot be unimportant if your model is anywhere reflective of the business.
There are many people involved, but it is not important to record the interactions, only their names, data and the role. The role in the context of the inspection is enough to know what they did and at what point. Further details are not important, if added they would represent data that inspectors won't use, making them waste time.