Let me give a hypothetical example: in report FOO, field "Secondary Record" used to contain record number but now it's something else. Should the parser change output type to string? Or try to see if there is a record number somewhere in that string and return it? Or just pretend that this unparseable field does not exist? In my opinion, all of those options are terrible. The parser should stop parsing and alert human maintainer (me). A human will look at new data and decide what to do with it - maybe change the output type, or maybe there is now a record title as well which needs to be handled separately.
As for "pro-actively adjusted" -- well, that would be great, but the data comes through a long chain of services, and while each individual one has tests, there is no overall test for the whole chain. Could I make one and hook it up to each team's CI, so that parser never fails? Sure, but the service is in maintenance mode, so I am not going to do it.
Right now the downstream consumers are OK with the fact that sometimes data stops updating and they have to live with the stale data until I fix the parser. If they ever want more, great! We can set up the project, decide a priority, allocate time (mine or someone else's) and do it. But until this happens, the project is in maintenance mode.
There is a ton of software that is less a true product and more an integration of systems that only gets improvements and updates when things break. That’s maintenance and you weigh when to make larger changes against what’s valuable to the business, how much toil is associated with it, impact on team morale, etc. If you don’t you’re just making uninformed decisions for the sake of some fuzzy metric representing how connected to code you are.