A branch's collection-management system starts exporting its nightly catalogue extract with two columns swapped after an unannounced vendor update, and the archive network's pipeline Copy activity maps source columns to the warehouse table by position. The next morning the pipeline run shows a green succeeded status, but curators report accession numbers landing in the condition-notes field. What should the engineer check first to confirm this is the root cause?

A Copy activity that maps columns by ordinal position has no way to notice that the source reordered its fields; it copies whatever sits in column three into whatever sits in destination column three, so the run finishes without a single thrown error while the data is silently wrong. The fix for diagnosis, not for redesign, is to open the run in the pipeline monitoring view and inspect the Copy activity's detailed input and output, which shows the exact source schema and mapping used for that execution. Checking the trigger only confirms the pipeline ran on time; it says nothing about what shape of data it moved once it started. Spark pool autoscale settings govern notebook and job compute and have no bearing on a Copy activity's column mapping. The Eventstream monitoring page belongs to a streaming item entirely separate from this batch pipeline and wouldn't show anything about a nightly catalogue extract. As an operational check, compare the failed run's recorded source schema against a known-good prior run before re-enabling the schedule, since a silent success like this one will keep corrupting data every night until the mapping is corrected.