@shecorwe Please keep this thread posted on the progress of this report - to date we have had zero success trying to get BYU RLL to resolve any issue we have reported to them (see the thread I linked to above).

@ShawnFReid Thanks for the PIDs, I will look to add this issue to the evidence I am collecting re BYU RLL's impact on the data quality of the Tree.

@shecorwe will know as a mod, @ShawnFReid, I am an ordinary user not a FS person.

@shecorwe did you ever get any feedback on this, please?

@ShawnFReid @shecorwe

After some investigation via my analysis database I think I have got to the bottom of this.

In my view the issue is that BYU RLL's automation scripting (user TreeBuilding Project) is using the Update Person Source Reference API in an inappropriate manner when adding source tags to sources attached by other people.

I found 57 attachments, including various of Shawn's as above (and coincidentally also one of my own) where an existing 'Reason This Source Is Attached' was cleared by TreeBuilding Project.

I am pretty confident the API itself is fine - I did a tag change via RootsMagic and my 'Reason This Source Is Attached' was, as expected, unaffected.

The really key point here is that, in the underlying data, the 'Reason This Source Is Attached' is not stored as a 'change info reason', as are seemingly all other reason statements, it is stored as an 'attribution changeMessage'. If you want it to remain in place after an Update Person Source Reference API call, it would appear that you need to retrieve the initial value first and resend it on the API call, otherwise it is cleared, as we are seeing. See https://developers.familysearch.org/main/docs/update-person-source-reference . BYU RLL is (typically) clearly not looking at the existing data at all; not only do they lose the 'Reason This Source Is Attached' when they actually change the tags, they also make a pointless (but still potentially damaging) API call when the tags were already set how they wanted them (resulting in the Change Log entries we are seeing on which no actual change is indicated).

I will add this matter to the detailed BYU RLL data quality incident report I am about to submit - see my latest comments on the long BYU RLL thread for more information:

Having said all of the above, this doesn't feel like FS' greatest piece of design. I can see that BYU RLL aren't the only people who are accidentally (?) clearing the 'Reason This Source Is Attached'. Unfortunately I have found no way of telling whether a particular update was made via the API or via the FS user interface.