The reason you're not allowed to request vendor delayed RICs when delay capability is enabled is because the vendor delayed stream (/RIC) is used to populate image in the cache and the initial response and updates to applications while the real-time stream (RIC) is being aged in the delay files for 20-30 minutes depending on delay rules.

So what happens in ADH/ADS when getting a request for example TRI.N is creating consumer item for TRI.N and creating producer items for TRI.N and /TRI.N and make actual requests to the upstream components. The consumer item for TRI.N will then multiplex responses from both producer items seamlessly for applications to get the best data available at a time.

The key reason for not allowing /RICs to delay services from applications is to avoid complexity of many-to-many relationships of consumers and producer items here as doing so will introduce a lot of changes and overly complex logic in the current design just to achieve this (not that it’s not possible to make changes but the size of changes and impact to achieve this).

This logic is the same since the old day with RDTIC. The decision was made back then based on the assumption that Delay capability is enabled so the better quality of delayed data is already available through the request for TRI.N item so it’s not worth introducing more complexity to support request for /TRI.N. You can simply request for TRI.N and ADH/ADS will manage to stream the best delayed data available whether it’s from /TRI.N or delayed stream of TRI.N. If this is not what you want, you can disable Vendor Delayed feature from ADH/ADS so you can request for /RICs but you will not be able to get the /RICs image populated into the responses for the request for RICs that is still being aged in the files.