@@ -22,7 +22,7 @@ This specification goes beyond ApplicationCore. It has impact on other ChimeraTK
## Detailed requirements ##
1. All `ChimeraTK::NDRegisterAccessor` implementations (including but not limited to the `ChimeraTK::ProcessArray`) must have the `ChimeraTK::DataValidity::faulty` flag set after construction for the receiving end. This ensures, all data is marked as `faulty` as long as no sensible initial values have been propagated. The sending end must have `ChimeraTK::DataValidity::ok`, so that the first written data automatically propagates the ok state. [TBD: What about bidirectional variables?]
1. All `ChimeraTK::NDRegisterAccessor` implementations (including but not limited to the `ChimeraTK::ProcessArray`) must have the `ChimeraTK::DataValidity::faulty` flag set after construction for the receiving end. This ensures, all data is marked as `faulty` as long as no sensible initial values have been propagated. The sending end must have `ChimeraTK::DataValidity::ok`, so that the first written data automatically propagates the ok state. [TBD: What about bidirectional variables? -> ideally change NDRegisterAccessor interface to allow separate validities for sending and receiving...]
2. All `ChimeraTK::NDRegisterAccessor` implementations must have initially a `ChimeraTK::VersionNumber` constructed with a `nullptr`, which allows to check whether this variable is still at its "first value" or the initial value propagation already took place.
3. All `ChimeraTK::ApplicationModule`s and similar entities (like `ChimeraTK::ThreadedFanOut` and `ChimeraTK::TriggerFanOut`), that store a `ChimeraTK::DataValidity` directly or indirectly e.g. in form af a counter, must have their internal `DataValidity` flag set to `ok` after construction.
4. The initial `ChimeraTK::DataValidity::faulty` flags must not be propagated actively. The first propagated data must be always `ok` and must have a valid value.
