I do agree that transparency is important in determining the source of local data manipulation. A method I like to use in RSLogix 500 projects, where the source is a write from a Logix 5000 controller, is to assign several words in a dedicated Data File for the Source node. The name of the Data File reflects, as best possible with so few characters, the type of message and the node number. Also, the descriptions for each word in the Data File would reflect the write command from the source, and then the individual bits, if boolean data, will have a "header" in their descriptions denoting that they are externally written to.
Example: (if all boolean data)
Data File: N100 "ND20WRT" (Write From Node 20) with 10 elements N100:0 - N100:9.
Each word description: "MESSAGE WRITE FROM NODE 20"
Bit description: N100:0/0 "Node 20 WRT::Start Command"
Or N100 could have say 100 elements with groups of words for writes from several nodes and be named generally as "WRT_IN", or similar. Each group of words again reflecting the node writing to them in their descriptions.
It does help a lot, especially in busier systems.
I do agree also that it could be possible to incorrectly assign the wrong word(s) addressing in the MSG instruction of a Write controller, especially when a single Data File is used in the target, like in my example with 100 elements. I have had one or two cases before where data was overlapping (two controllers writing to the same block of words). They weren't my projects originally though and the naming convention did nothing to help. In one case a controller was accidentally writing 40 words instead of 20, overlapping the next 20 words being written to by another node. It does take some time tracing the other nodes to find the culprit. But if the target addressing is descriptive enough to identify the correct source, then it at least points you away from that node and on to the others, however many there may be.
Regards,
George