Discuss with Wolfgang before assigning.

Agreed to address this after the first 1.05 release of Part 3.

The companion specification that include the column had very clear definition on how the read write column applied and the base specification - since it now support must follow that rule, or the Companion specifications need to return to having there own column that defines the required behavior. That behavior is very clear and it only involves two bits in the Access level mask. Read and Write - if the column list ReadOnly, the read bit shall be set and the write bit cleared and it applies to all instances based on the declaration. If it is WriteOnly the read bit is clear and the write bit is set, if it is ReadWrite both bit are set and these setting apply to all instances that are created based on the type definition that includes the column. (if not set, nothing is defined and instance can do what every they want). This does not govern the UserAccess, which can further restrict these settings (i.e. it is ReadOnly, but a specific user might still not be able to read it, if they do not have the rights)

Where the companion specification were less clear is how this would be applied to subtypes (and if it could be over written) - but the general consensus was that it could be overwritten in a subtype, but it would still have to be explicitly set, i.e. a subtype could change something ReadWrite to ReadOnly, but the spec would have provide the updated definition.
I don't believe anything beside text needs to be added to part 3 - think of it as the default value - they are copied into the instance when they are created. It would be up to certification to check that if a companion specification requires read only that nothing updated it after an instance was created. When semantic validation become available, all of the items written in text can be convert to rules.

As a generic note, please note, that the instantiation is also allowed to use the overriding rules on top of the subtype having those overriding rules. Thus, there might need to be or not a separate rule then to define if the instantiation of a type is allowed still to change the bits, or does it need to obey the same rules. Effectively the InstanceDeclarations are all of their own "mini-TypeDefinitions" of their own, since they are allowed to override and add stuff from the TypeDefinitions of from which they are instantiated as an InstanceDeclaration in the first place.

I'm not sure is it clear that does the instantiation have same or different (maybe more limited) rules. And could companion specs to make up "their own rules" (e.g. that "all real instances of an InstanceDeclaration shall use a non-abstract DataType" as an example).

Not enough of a pain point right now. May best be handled by semantic validation.