Were I too, to face this situation, my first step would be to download the latest Category Listing Report (aka “Reverse Feed Report”) for the impacted ASIN(s), and then compare what I found there with what I found listed as possible attribute fields in the latest Product Template downloaded from the (now-clunkier) APvU Dashboard’s (“Add Products via Upload”) “Download spreadsheet” ‘tab.’
The goal would be an attempt to discern whether or not there were some unassigned field that the PT (“Product Types and Attributes”) Initiative/“Attribute Harmonization Initiative”/“Size Normalization Initiative” Amabots might be keying on with unwelcome overwrites and/or additions, with a view towards trying to force through a file upload which removed the spurious contribution, making a note of any and all Batch IDs for such attempt(s) for possible future use in a Seller Support Case.
Failing that, I’d try the XML route of uploading a machine-readable Feed Upload, again making careful note of Amazon-supplied identifiers for possible use in a future Seller Support Case.
If, after ALL that wasted effort still found me hanging on for dear life to the skirts of Amazon’s AI-generated eight-ball, I’d probably give it the ‘old college try’ of opening a short, succinct SeSu case pointing out the error, and (possibly, depending upon circumstances) alluding to the fact that I’d already utilized Amazon’s automated mechanisms in attempting to pull the Amabot’s wee little noggin out its arse (in appropriate Professional Business Correspondence language, of course).
Failing all, I’d be forced to consider other alternatives - none of which are particularly pleasing.
Ay, there’s the rub, isn’t it?
As far as I’m presently aware, AI-generated changes are not specifically identified by the SP-API without resort to ETL (“Extract, Transform, Load”) implementations.